Community ISO maintenance and build issues - 1

SolydXK is too quiet for you? SolydXK Enthusiast Editions, based on Debian Testing is for you! Here you can find news about Debian Testing and Unstable too, and also tests on SolydXK programs.
The support for SolydXK EE is provided by the community.
User avatar
grizzler
Posts: 2217
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: Community ISO maintenance and build issues

Postby grizzler » 31 Jan 2017 15:52

Nothing unusual then. Weird.

I wonder if the fact my build tools are Stretch based could make a difference. I assume you're building ISOs on a Jessie system?
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
Arjen Balfoort
Site Admin
Posts: 9514
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: Community ISO maintenance and build issues

Postby Arjen Balfoort » 31 Jan 2017 16:02

grizzler wrote:Nothing unusual then. Weird.

I wonder if the fact my build tools are Stretch based could make a difference. I assume you're building ISOs on a Jessie system?
That is correct!


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 2217
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: Community ISO maintenance and build issues

Postby grizzler » 31 Jan 2017 17:40

Unpacked the ISO to a different location, rebuilt it with my own tools, linked it to the same test VM as always... Boots. :shock:

W.T.F.?

So. Not the tools. Then what? :?

The only essential difference is the guest additions. I'm guessing something happens when they are installed that somehow doesn't happen on my machine. I know the kernel modules are built. What else could be missing?
I'm going to remove them from this build structure and then install them again. Build another ISO and see what happens with that.

Edit
Also works... :?:
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
Arjen Balfoort
Site Admin
Posts: 9514
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: Community ISO maintenance and build issues

Postby Arjen Balfoort » 31 Jan 2017 18:35

The virtualbox packages from sid are in the solydxk-9 repository.

I will continue with the theme on Thursday.


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 2217
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: Community ISO maintenance and build issues

Postby grizzler » 31 Jan 2017 19:17

Just did the same purge/reinstall/build procedure on my original X EE 64 build structure and... it works as well. :o

My cat is looking very inconspicuous, so I think he's responsible. Yes, that's about as much sense as I can make of this. I have no idea what's been wrong all this time and why it suddenly started working again. All I can think of is the order in which the additions are installed may be relevant. Because the whole mess seemed to center around the video drivers, I installed the X11 addition last this time (I used to do the dkms last). But for all I know this has nothing to do with it.

Anyway, now this is working again, I can only agree that what you came up with here is the best solution (as long as vbox packages aren't dropped from sid as well...).

By the way, I'll e-mail you a fixed apt script later this evening.
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
grizzler
Posts: 2217
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: Community ISO maintenance and build issues

Postby grizzler » 01 Feb 2017 21:43

Schoelje wrote:I'm also separating the solydx/k-info packages to prepare for the time when we have both jessie and stretch based ISOs. In testing I now have these packages to test:
  • solydx/k-info (transitional package)
  • solydx/kee-info (transitional package)
  • solydx/k-info-8/9
  • solydxk-system (will remove solydx/k(ee)-info package when the solydx/k-info-8/9 packages have been installed)
The solydx/k-system-adjustments packages have a Depends: solydx/k-system-adjustments-8. However, currently the system-adjustments packages are the same on jessie and stretch systems. So I expect the -8 package to be pulled in on both (haven't had time to actually test this yet...).

Also, when I was looking at adjust.py from solydxk-system, thinking you may have put some code in there to handle that, I noticed you check the presence of the mysql-client package to decide if a /var/log/mysql directory must be created. On my system that directory has UID:GID mysql:adm and not root:root. I'm quite sure I did not set these values myself.
The mysql-client (meta) package isn't even installed anymore here. Not sure why not, but I did see the mysql-5.6 branch has just been removed from testing and unstable while 5.7 hasn't migrated to testing yet. Anyway, this may also get complicated.

Lastly, did you realise the EEs will continue to be a separate set: Buster, Debian 10?
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
Arjen Balfoort
Site Admin
Posts: 9514
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: Community ISO maintenance and build issues

Postby Arjen Balfoort » 02 Feb 2017 06:20

grizzler wrote:The solydx/k-system-adjustments packages have a Depends: solydx/k-system-adjustments-8. However, currently the system-adjustments packages are the same on jessie and stretch systems. So I expect the -8 package to be pulled in on both (haven't had time to actually test this yet...).
On stretch, you'll need to install solydx/k-system-adjustments-9 manually. There was no way of making a transaction package (the old solydx/k-system-adjustments) that could decide whether to install the -8 or -9 version depending on the underlying Debian version.

I've uploaded my EE ISOs here: http://downloads.solydxk.nl/ce/testing/schoelje/
For SolydK EE I could use the default Grub boot. However, it boots into a black, unresponsive desktop but when you log out and back in again the desktop is fine :shock: (tested in VB only).
grizzler wrote:Also, when I was looking at adjust.py from solydxk-system, thinking you may have put some code in there to handle that, I noticed you check the presence of the mysql-client package to decide if a /var/log/mysql directory must be created. On my system that directory has UID:GID mysql:adm and not root:root. I'm quite sure I did not set these values myself.
The mysql-client (meta) package isn't even installed anymore here. Not sure why not, but I did see the mysql-5.6 branch has just been removed from testing and unstable while 5.7 hasn't migrated to testing yet. Anyway, this may also get complicated.
I've updated solydxk-system with your UID:GID. Let's tackle that problem when we get there.
grizzler wrote:Lastly, did you realise the EEs will continue to be a separate set: Buster, Debian 10?
That's why I split these SolydXK packages into different versions. The next EEs will get -10 in their names. This way these packages are tailored for their version and they will continue to be part of the system during the life-time of the system.


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 2217
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: Community ISO maintenance and build issues

Postby grizzler » 02 Feb 2017 10:47

Schoelje wrote:
grizzler wrote:The solydx/k-system-adjustments packages have a Depends: solydx/k-system-adjustments-8. However, currently the system-adjustments packages are the same on jessie and stretch systems. So I expect the -8 package to be pulled in on both (haven't had time to actually test this yet...).
On stretch, you'll need to install solydx/k-system-adjustments-9 manually. There was no way of making a transaction package (the old solydx/k-system-adjustments) that could decide whether to install the -8 or -9 version depending on the underlying Debian version.
OK. Pity.
For SolydK EE I could use the default Grub boot. However, it boots into a black, unresponsive desktop but when you log out and back in again the desktop is fine :shock: (tested in VB only).
Yes, that's what I wrote in this posting (last paragraph). This is the same on metal, by the way.
I have since found you can also get the desktop to appear like this: open System Settings, Workspace Theme, select "Use Desktop Layout from theme", click Apply.
grizzler wrote:Lastly, did you realise the EEs will continue to be a separate set: Buster, Debian 10?
That's why I split these SolydXK packages into different versions. The next EEs will get -10 in their names. This way these packages are tailored for their version and they will continue to be part of the system during the life-time of the system.
OK. Would you consider using the Jessie to Stretch transition for a change that would put the SolydXK repository more in line with how Debian's is set up?

Debian currently has repositories named jessie and stretch. They also have stable and testing, but these are just links to the jessie and stretch structures. When a user has jessie in their sources.list and doesn't change that, they will never upgrade to the next release. With stable however, they will upgrade automatically, because when stretch becomes stable, Debian changes the link. No need to mess with sources.list.
We currently have a stable branch which actually isn't. It's a jessie branch. If people want to move to the new stable, they'll have to change their sources.list. Can't be helped.

How about offering the suggestion/option to change to stable instead of stretch and also providing a linked SolydXK stable? That is, use the solydxk-9 and solydxk-10 repositories as basis and provide links like solydxk-stable (or solydxk-main or whatever you find appropriate) and solydxk-ee, so that people can either use a sources.list that tracks just stretch plus solydxk-9 indefinitely or one that will stay with stable, no matter the underlying release (for both Debian and SolydXK - provided the solydxk-stable and solydxk-ee links are changed when required, of course).
EE users would probably prefer to use solydxk-ee and testing anyway, as keeping solydxk-10 and buster in their sources.list would effectively end their EE status when the next release goes stable. Keeping the numbered SolydXK repository plus Debian testing is a bad idea, because this will get out of step (yes, I know, EE users are supposed to be aware of that and change their sources.list...).

What do you think? Would this be feasible?
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
Arjen Balfoort
Site Admin
Posts: 9514
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: Community ISO maintenance and build issues

Postby Arjen Balfoort » 02 Feb 2017 11:55

So, let me see if I understood correctly (I've got a terrible cold and my head is full of snot :oops: ).

You'd like a repository structure like this:
solydxk-8
solydxk-9
solydxk-stable -> solydxk-8
solydxk-ee > solydxk-9

Obviously, when Stretch becomes stable it would look like:
solydxk-8
solydxk-9
solydxk-10
solydxk-stable -> solydxk-9
solydxk-ee > solydxk-10

We already have a link called "solydxk" that now has the purpose of "solydxk-stable" and I'd suggest to use the numbered names for the stable versions.

Is that it?


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 2217
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: Community ISO maintenance and build issues

Postby grizzler » 02 Feb 2017 12:14

Schoelje wrote:So, let me see if I understood correctly (I've got a terrible cold and my head is full of snot :oops: ).
Nasty. Hope you get well soon.
You'd like a repository structure like this:
solydxk-8
solydxk-9
solydxk-stable -> solydxk-8
solydxk-ee > solydxk-9

Obviously, when Stretch becomes stable it would look like:
solydxk-8
solydxk-9
solydxk-10
solydxk-stable -> solydxk-9
solydxk-ee > solydxk-10
Yup. That's it.
We already have a link called "solydxk" that now has the purpose of "solydxk-stable" and I'd suggest to use the numbered names for the stable versions.
I'm not entirely sure what you mean by that last bit...
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
Zill
Posts: 1850
Joined: 13 Aug 2013 14:28
Location: Lincolnshire, UK

Re: Community ISO maintenance and build issues

Postby Zill » 02 Feb 2017 13:09

grizzler wrote:... When a user has jessie in their sources.list and doesn't change that, they will never upgrade to the next release. With stable however, they will upgrade automatically, because when stretch becomes stable, Debian changes the link. No need to mess with sources.list.
We currently have a stable branch which actually isn't. It's a jessie branch. If people want to move to the new stable, they'll have to change their sources.list.
At the risk of confusing things further...

IMHO, the Debian sources in the SolydXK list should continue to point to the codename (e.g. "jessie"), rather than the release (e.g. "stable"). This is because I think automatic upgrading of "stable" from "jessie" to "stretch" could lead to problems if this is done without adequate preparation, particularly if "upgrade" rather than "dist-upgrade" is used.

I suggest that the work needed before such a dist-upgrade is carried out needs to be clearly defined and possibly assisted by a suitable script.

Note that I am only referring to the Debian repos, not the SolydXK repos! I am still unsure about the implications of changing these. :?

kurotsugi
Posts: 2282
Joined: 09 Jan 2014 00:17

Re: Community ISO maintenance and build issues

Postby kurotsugi » 02 Feb 2017 13:20

stable user can't seamlessly move between stable release. AFAIK they need to do lot of stuff before (and after) upgrading their system. the update process can't be done with 'apt-get update' (the correct one is 'apt-get dist-upgrade'). IMO the upgrade process should not be done automatically just like debian did.

User avatar
grizzler
Posts: 2217
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: Community ISO maintenance and build issues

Postby grizzler » 02 Feb 2017 14:22

Tracking stable instead of a codename is an option. Nobody who uses plain Debian is forced to use stable in sources.list. However, for any SolydXK user who wants to track stable, the SolydXK repositories should follow the same pattern.
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
Arjen Balfoort
Site Admin
Posts: 9514
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: Community ISO maintenance and build issues

Postby Arjen Balfoort » 02 Feb 2017 15:13

grizzler wrote:
We already have a link called "solydxk" that now has the purpose of "solydxk-stable" and I'd suggest to use the numbered names for the stable versions.
I'm not entirely sure what you mean by that last bit...
I mean to say that I would like the future official releases to point to the "solydxk-8" repository instead of the current default "solydx" (link to stable solydxk-8) repository.

I've also been searching the net on how to change the default activity (desktop) of Plasma 5, but I cannot seem to find anything relevant. In KDE4 we use scripting (/usr/share/solydxk/default-settings/kde4-profile/default/share/apps/plasma-desktop/init/00-defaultLayout.js), but I cannot find how Plasma 5 does that.


SolydXK needs you!
Development | Testing | Translations

User avatar
Arjen Balfoort
Site Admin
Posts: 9514
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: Community ISO maintenance and build issues

Postby Arjen Balfoort » 02 Feb 2017 15:45

I found out that reprepro (our repository software) cannot create multiple suites (solydxk AND solydxk-stable) for the same codename (solydxk-8). Only one is allowed.

I cannot just change the suite name from solydxk to solydxk-stable and create a symlink manually. All stable users would get a warning when updating the apt cache:

Code: Select all

W: Conflicting distribution: http://repository.solydxk.com solydxk InRelease (expected solydxk but got solydxk-8)
However, I could create the suite solydxk-ee to solydxk-9. So, that should work.

So, now we have:
solydxk-8
solydxk-9
solydxk-10
solydxk > solydxk-8
solydxk-ee > solydxk-9


SolydXK needs you!
Development | Testing | Translations

User avatar
ilu
Posts: 2735
Joined: 09 Oct 2013 12:45

Re: Community ISO maintenance and build issues

Postby ilu » 02 Feb 2017 16:36

Schoelje wrote: solydxk > solydxk-8
solydxk-ee > solydxk-9
So what will happen after transition to current users of main edition?
solydxk > ?
solydxk-ee > solydxk-10 ?
But they might not have updated. I know I probably need to keep my system on jessie because of (still?) missing graphic drivers. I already have a parallel EE install that I will want to keep as the new stable. I know I will have to change sources.list there to make sure not to upgrade to debian 10.
But current stable users should not automatically point their solydxk repo to solydxk-9 before updating theitr system to stretch - like zill said. They need to keep the old solydxk jessie repo.
Otherwise, if a user who's totally out of the loop, decides to run updates after the transition, s/he ends up with debian jessie and solydxk-9. That should not happen, because stable should remain stable.

So I think it should be:
solydxk (which holds 8 but will run out eventually)
solydxk-9
solydxk-10
solydxk-stable > solydxk, transitioned to 9
solydxk-ee > solydxk-9, transitioned to 10
And the repos of SolydXK main edition should per default point to the numbered version (and to the named version on debian) so no accidental upgrade happens.

Or did I confuse anything?

User avatar
grizzler
Posts: 2217
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: Community ISO maintenance and build issues

Postby grizzler » 02 Feb 2017 16:59

Schoelje wrote:
grizzler wrote:
We already have a link called "solydxk" that now has the purpose of "solydxk-stable" and I'd suggest to use the numbered names for the stable versions.
I'm not entirely sure what you mean by that last bit...
I mean to say that I would like the future official releases to point to the "solydxk-8" repository instead of the current default "solydx" (link to stable solydxk-8) repository.
Ah, yes. OK.
I've also been searching the net on how to change the default activity (desktop) of Plasma 5, but I cannot seem to find anything relevant. In KDE4 we use scripting (/usr/share/solydxk/default-settings/kde4-profile/default/share/apps/plasma-desktop/init/00-defaultLayout.js), but I cannot find how Plasma 5 does that.
That's all done in one of the (sub)subdirectories of /usr/share/plasma. You have:
- desktoptheme/solydk/colors for the colours
- desktoptheme/solydk/metadata.desktop (presenting itself as "SolydK") for the wallpaper
- layout-templates/org.kde.plasma.desktop.defaultPanel/contents/layout.js to set the panel layout
- shells/org.kde.plasma.desktop/contents/ to set the shell
- look-and-feel/org.kde.solydk.desktop/contents/defaults for several other default settings
The subdirectories in look-and-feel/org.kde.solydk.desktop/contents also contain a number of qml scripts to set things. Don't ask me what sets what/how exactly. I mostly copied stuff from the breeze look and feel and made what I figured were "sensible changes" here and there.

I don't know what changed where to make this fail at startup. Like I mentioned elsewhere, documentation is perfectly absent.
So, now we have:
solydxk-8
solydxk-9
solydxk-10
solydxk > solydxk-8
solydxk-ee > solydxk-9
So solydxk instead of solydxk-stable? No problem, as long as that one continues to point to the 'current stable'.
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
Zill
Posts: 1850
Joined: 13 Aug 2013 14:28
Location: Lincolnshire, UK

Re: Community ISO maintenance and build issues

Postby Zill » 02 Feb 2017 20:26

grizzler wrote:Tracking stable instead of a codename is an option. Nobody who uses plain Debian is forced to use stable in sources.list.
I think using a release name, such as "stable" or "testing", rather than "jessie" or "stretch", is only really appropriate for experienced users who know what they are doing.

If an inexperienced user has "stable" in the Debian sources.list then, at the time of release transition, a simple apt-upgrade will drag in new packages without removing conflicting packages from the old release. This messy upgrade is highly likely to result in breakage of a supposedly "stable" system!

It should also be noted that some users may well wish to stay on what will become "old-stable" (the Debian LTS version) for many months, or even years, after the transition of stable to a new release. SolydXK should support this option for as long as the Debian "old-stable" is supported.

User avatar
palimmo
Posts: 824
Joined: 19 Nov 2013 19:44
Contact:

Re: Community ISO maintenance and build issues

Postby palimmo » 02 Feb 2017 22:00

Schoelje wrote:
palimmo wrote:Today:

Code: Select all

Reading state information... Done
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
 solydk-system-adjustments : Depends: solydk-system-adjustments-8 but it is not installed
E: Unmet dependencies. Try using -f.
Thanks, I've updated the package. Just run:

Code: Select all

apt update
apt -f install
I ran the command and reboot.
Apparently most of the theme settings are gone now...
Proud user of SolydK!

Dai diamanti non nasce niente, dal letame nascono i fior. http://aquilone.wordpress.com/

User avatar
Arjen Balfoort
Site Admin
Posts: 9514
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: Community ISO maintenance and build issues

Postby Arjen Balfoort » 03 Feb 2017 10:19

palimmo wrote:I ran the command and reboot.
Apparently most of the theme settings are gone now...
If you're on EE, and you most probably are, you need to install solydk-system-adjustments-9 (solydx-system-adjustments-9 for SolydX).


SolydXK needs you!
Development | Testing | Translations


Return to “Testing Zone”

Who is online

Users browsing this forum: No registered users and 9 guests