Re: successful upgrade to jessie - thanks!
On Thu, Nov 27, 2014 at 03:06:17PM +0100, David Kalnischkies wrote: > Hi Tomas, > > Great you like it! Many people are busy working on smoothing the edges > uncovered by all the inflowing bugreports, so the occasional "thanks!" > is a nice boost to troop morale. :) Btw, debian is the only complex software system I know of in the history of the universe that can point to 'successful' upgrade of the size and complexity that is going on now. I should qualify this as 'complex systems that can be used to re-create themselves with minimal external dependencies'. I am sure some mainframes have the level of upgradeability debian has, but you can't design a new mainframe CPU on a mainframe, and I can design a CPU (slowly) with tools in the debian archive. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141204200440.gi29...@nl.grid.coop
Re: successful upgrade to jessie - thanks!
On Thu, Nov 27, 2014 at 03:06:17PM +0100, David Kalnischkies wrote: > Hi Tomas, > > Great you like it! Many people are busy working on smoothing the edges > uncovered by all the inflowing bugreports, so the occasional "thanks!" > is a nice boost to troop morale. :) I will second the thank you.. I got through 2 machines with the jessie upgrade with less trouble than I had with removing bash when we had exploits a few months ago. > > On Thu, Nov 27, 2014 at 02:22:14PM +0100, Tomas Pospisek wrote: > > Allthough apt-get dist-upgrade broke half way through due to > > unresolvable package dependencies, I was able to finish the upgrade via > > aptitude's ncurses interface. > Something, somewhere broke hibernation/sleep on my macbook air, and the synaptics touchpad, and one of these days I'll figure it out. Now if we could just redirect all this negative energy into removing dependencies on the 'bizarre' syntax that bash has in init scripts, and I could do 'apt-get remove bash', a great thing will have happened ;) So, keep up the good work, and if you must talk about pain and doom and gloom, talk about the doom and gloom that comes if you remove bash :P -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141204195918.gh29...@nl.grid.coop
Re: successful upgrade to jessie - thanks!
Matthias Urlichs writes: > Hi, > > Philip Hands: >> It seems to me that we could: >> >> Make systemd link runlevel 2 to graphical.target, and 3,4 & 5 to >> multi-user.target, or perhaps in an attempt to be slightly less >> confusing to outsiders, how about: >> 2 & 5 --> graphical >> 3 & 4 --> multi-user >> > Or we could simply pop up a message, just like we're going to do for > nonstandard inittab. Just compare directories; standard installs should > have the exact same content in /etc/rc[2345].d, so run comm -3 on each > (adjacent) pair of "ls -1" outputs. If not, the differences may or may not > be relevant; I haven't checked the archive, but my development system has > 75 entries in /etc/rc[2345].d and no differences. > > Given this result, I don't think that deciding on a reasonable "standard" > mapping from runlevels to systemd targets makes sense: there is no > difference between the old runlevels 2-5, which means that any sysadmin who > actually needed a distinction between them is more likely than not to have > invented their own scheme. Well, quite, so the runlevel links on Debian are simply confusing, as they don't currently map to the runlevels that have been defined locally, and they don't reflect any meaningful link to what was standard practice in Debian's sysvinit either. Is there any pressing reason to keep them? Of course, that still leaves the problem of not starting [xk]dm under the multi-user.target, but that's a separate issue really. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpOqUveXj81j.pgp Description: PGP signature
Re: successful upgrade to jessie - thanks!
Hi, Philip Hands: > It seems to me that we could: > > Make systemd link runlevel 2 to graphical.target, and 3,4 & 5 to > multi-user.target, or perhaps in an attempt to be slightly less > confusing to outsiders, how about: > 2 & 5 --> graphical > 3 & 4 --> multi-user > Or we could simply pop up a message, just like we're going to do for nonstandard inittab. Just compare directories; standard installs should have the exact same content in /etc/rc[2345].d, so run comm -3 on each (adjacent) pair of "ls -1" outputs. If not, the differences may or may not be relevant; I haven't checked the archive, but my development system has 75 entries in /etc/rc[2345].d and no differences. Given this result, I don't think that deciding on a reasonable "standard" mapping from runlevels to systemd targets makes sense: there is no difference between the old runlevels 2-5, which means that any sysadmin who actually needed a distinction between them is more likely than not to have invented their own scheme. > I'd think that we need to tell people when upgrading that, if they've > done things that are important to them involving special meanings for > runlevels 2345, they need to work out how to port those things to > systemd, or opt to stick with sysvinit for now. > +1 -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: successful upgrade to jessie - thanks!
Felipe Sateler writes: ... > This is indeed unfortunate. Because runlevel[234] are links to > multi-user.target it means that distinctions between those runlevels are > not preserved. It also means that the ability to differentiate between > graphical.target and multi-user.target is almost lost for systems where the > dm does not provide a native systemd unit, because the sysv generator will > generate links from runlevel[2345].target.wants/ to the dm. > > This is the case with kdm: > > % cd /run/systemd/generator.late > % ls -l runlevel[2345].target.wants/kdm.service > lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel2.target.wants/kdm.service -> > /run/systemd/generator.late/kdm.service > lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel3.target.wants/kdm.service -> > /run/systemd/generator.late/kdm.service > lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel4.target.wants/kdm.service -> > /run/systemd/generator.late/kdm.service > lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel5.target.wants/kdm.service -> > /run/systemd/generator.late/kdm.service > > > Unless a user has disabled kdm in runlevels [234], there is no way to boot > the system without starting kdm. Is this not really a consequence of the combination of the fact that: Firstly, Debian Policy has left runlevels mostly alone, with the intent that local admins can do what they like with 3 & 4, and probably 5, because we default to 2 where we run everything that's installed, including graphical stuff; and secondly systemd seems to be using the more conventional assumption that runlevel 5 is the graphical one, and lower numbers run the non-graphical stuff only. It seems to me that we could: Make systemd link runlevel 2 to graphical.target, and 3,4 & 5 to multi-user.target, or perhaps in an attempt to be slightly less confusing to outsiders, how about: 2 & 5 --> graphical 3 & 4 --> multi-user Ensure that all graphical stuff (so display managers basically) get rid of their 234 runlevel start links, and change our default to 5 (cannot see that going well on upgrades TBH, might have been doable if we'd started about 5 years ago) Ensure that all display managers ship native systemd units before release. The last of these seems likely to at least partially address the problem at hand, because it'll make it possible to use the multi-user.target to avoid starting X, but does not fix the potential runlevel confusion. Given that we do not have well defined distinctions between runlevels, and the runlevels in systemd don't actually map directly to the old runlevels anyway, but rather go via the multi-user and graphical targets, should we not just remove the runlevel targets to avoid this confusion (or do they get used elsewhere)? I'd think that we need to tell people when upgrading that, if they've done things that are important to them involving special meanings for runlevels 2345, they need to work out how to port those things to systemd, or opt to stick with sysvinit for now. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpd8FoeCXHEm.pgp Description: PGP signature
Re: successful upgrade to jessie - thanks!
On Sat, 29 Nov 2014 11:36:20 +0100, Marc Haber wrote: > On Sat, 29 Nov 2014 08:34:46 +0100, Matthias Urlichs > wrote: >>Marc Haber: >>> It's learning and understanding more than just a few bizarre new >>> concepts. >>> >>I learned. I (think I) understand. But I do not think these fancy new >>concepts are bizarre at all. If anything, they make my life way easier. >> >>If anything, IMHO using words like "bizarre" isn't exactly conductive to >>rational dialogue … > > If we actually plan to release a distribution where a central piece of > software behaves contrary to its documentation, "bizarre" seems quite > logical to me. > > Right now, we have an init system that has something named "runlevel3", > which makes people say "Yeah, finally a concept that I am already > familiar with" and then find themselves stymied when this "something" > does something quite different from the something we used to know as > "runlevel3". Same goes for a something for which its documentation says > "non-graphical" with another something called "graphical", with no > visible differences between those two things' behavior, a system running > X. > > This is only a mild nuisance if everything is fine, but if a system dies > when X starts up, not having a clear way to prevent X from coming up is > bad. This is indeed unfortunate. Because runlevel[234] are links to multi-user.target it means that distinctions between those runlevels are not preserved. It also means that the ability to differentiate between graphical.target and multi-user.target is almost lost for systems where the dm does not provide a native systemd unit, because the sysv generator will generate links from runlevel[2345].target.wants/ to the dm. This is the case with kdm: % cd /run/systemd/generator.late % ls -l runlevel[2345].target.wants/kdm.service lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel2.target.wants/kdm.service -> /run/systemd/generator.late/kdm.service lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel3.target.wants/kdm.service -> /run/systemd/generator.late/kdm.service lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel4.target.wants/kdm.service -> /run/systemd/generator.late/kdm.service lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel5.target.wants/kdm.service -> /run/systemd/generator.late/kdm.service Unless a user has disabled kdm in runlevels [234], there is no way to boot the system without starting kdm. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m5d1e0$eal$2...@ger.gmane.org
Re: successful upgrade to jessie - thanks!
On Sat, 29 Nov 2014 08:34:46 +0100, Matthias Urlichs wrote: >Marc Haber: >> It's learning and understanding more than just a few bizarre new concepts. >> >I learned. I (think I) understand. But I do not think these fancy new >concepts are bizarre at all. If anything, they make my life way easier. > >If anything, IMHO using words like "bizarre" isn't exactly conductive >to rational dialogue … If we actually plan to release a distribution where a central piece of software behaves contrary to its documentation, "bizarre" seems quite logical to me. Right now, we have an init system that has something named "runlevel3", which makes people say "Yeah, finally a concept that I am already familiar with" and then find themselves stymied when this "something" does something quite different from the something we used to know as "runlevel3". Same goes for a something for which its documentation says "non-graphical" with another something called "graphical", with no visible differences between those two things' behavior, a system running X. This is only a mild nuisance if everything is fine, but if a system dies when X starts up, not having a clear way to prevent X from coming up is bad. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xufo0-0006iy...@swivel.zugschlus.de
Re: successful upgrade to jessie - thanks!
On Sat, 29 Nov 2014 09:09:19 +0100, Matthias Urlichs wrote: >Marc Haber: >> Which significantly changes things in Jessie since the majory of >> services is still started via the old rcX.d mechanism, and thus >> starting to runlevels behaves completely different from what users >> expect. >> >Well, I wouldn't expect runlevel 2 to start a graphical desktop either. >But it does; my /etc/inittab states that "2" is the default runlevel >and an unmodified /etc/init.d/gdm3 contains > ># Default-Start: 2 3 4 5 > >So, sorry, but the default behavior is already broken for a whole lot of >users – who simply fail to notice. There is _no_way_ I can boot my desktops >to a sane multi-user state (i.e. no X11 or *dm, if one of these decides to >act up and wedge the system) without jumping through hoops, and there has >not been one for ages. I have my runlevel 3 configured to not start kdm for ages, for exactly the reason that there might be situations where one wants to debug issues that survice when starting up X. It was unexpected to have this taken away from me when my system was upgraded to systemd. >At least systemd's named targets actually mean something. Which makes the surprise even worse when the symbolic name does not match the exact behavior. >> This is bad. > >Please consider that Fedora has changed their init system twice, so far. >Their world did not end when they did that, so please don't assume that >it will when we switch. I didn't. We even survived the libc5 => glibc move, and that was much less painful than what our users are facing once we have pushed the prematurely frozen jessie out of the door. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xufhc-0006hk...@swivel.zugschlus.de
Re: successful upgrade to jessie - thanks!
Hi, Marc Haber: > Which significantly changes things in Jessie since the majory of > services is still started via the old rcX.d mechanism, and thus > starting to runlevels behaves completely different from what users > expect. > Well, I wouldn't expect runlevel 2 to start a graphical desktop either. But it does; my /etc/inittab states that "2" is the default runlevel and an unmodified /etc/init.d/gdm3 contains # Default-Start: 2 3 4 5 So, sorry, but the default behavior is already broken for a whole lot of users – who simply fail to notice. There is _no_way_ I can boot my desktops to a sane multi-user state (i.e. no X11 or *dm, if one of these decides to act up and wedge the system) without jumping through hoops, and there has not been one for ages. At least systemd's named targets actually mean something. > This is bad. Please consider that Fedora has changed their init system twice, so far. Their world did not end when they did that, so please don't assume that it will when we switch. I fully expect that almost all of users will not notice. The rest will have to heed the "you have customized your init defaults" warning we still need to implement – and either test before they leap, or decide to stay with sys5 until they are in a position to fix problems on-site. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: successful upgrade to jessie - thanks!
Hi, Marc Haber: > It's learning and understanding more than just a few bizarre new concepts. > I learned. I (think I) understand. But I do not think these fancy new concepts are bizarre at all. If anything, they make my life way easier. If anything, IMHO using words like "bizarre" isn't exactly conductive to rational dialogue … -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: successful upgrade to jessie - thanks!
On Fri, 28 Nov 2014 22:33:08 +0100, Ansgar Burchardt
wrote:
>Marc Haber writes:
>> A few hours of reasearch later (which could have been a few minutes if
>> just the community would have been a bit more helpful) it turned out
>> they were right: We start kdm via an init script and sysvrc emulation,
>> and this does actually break the distinction between multi-user.target
>> and graphical.target.
>>
>> I have yet to find out why runlevel3.target doesn't work either.
>
>runlevel{2,3,4}.target are by default aliases for multi-user.target:
>
>$ /lib/systemd/system % ls -l runlevel*
>lrwxrwxrwx 1 root root 15 Nov 18 13:15 runlevel0.target -> poweroff.target
>lrwxrwxrwx 1 root root 13 Nov 18 13:15 runlevel1.target -> rescue.target
>lrwxrwxrwx 1 root root 17 Nov 18 13:15 runlevel2.target -> multi-user.target
>lrwxrwxrwx 1 root root 17 Nov 18 13:15 runlevel3.target -> multi-user.target
>lrwxrwxrwx 1 root root 17 Nov 18 13:15 runlevel4.target -> multi-user.target
>lrwxrwxrwx 1 root root 16 Nov 18 13:15 runlevel5.target -> graphical.target
>lrwxrwxrwx 1 root root 13 Nov 18 13:15 runlevel6.target -> reboot.target
Which significantly changes things in Jessie since the majory of
services is still started via the old rcX.d mechanism, and thus
starting to runlevels behaves completely different from what users
expect.
This is bad.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xuc8j-0005uv...@swivel.zugschlus.de
Re: successful upgrade to jessie - thanks!
Le vendredi 28 novembre 2014, 22:25:28 Marc Haber a écrit : > We start kdm via an init script and sysvrc emulation, > and this does actually break the distinction between multi-user.target > and graphical.target. Hi, Here is a native kdm service I'v copied from an other distro months ago; and used daily since. In theory it should go in /etc/systemd/system/ , but I guess that if you put it in /lib/systemd/system/ ; it will then be overwriten by dpkg once the package ship a native service. What begs me is that it actually works fine, without something matching the lengthlty setup_config() in init script; that is not replicated here. FYI: There is a more elaborate patch linked to this open bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=kdm-systemd.diff;att=1;bug=754314 Alexandre Detiste [Unit] Description=KDM Display Manager Conflicts=getty@tty1.service After=systemd-user-sessions.service getty@tty1.service plymouth-quit.service [Service] ExecStart=/usr/bin/kdm -nodaemon Restart=always IgnoreSIGPIPE=no [Install] Alias=display-manager.service WantedBy=multi-user.target
Re: successful upgrade to jessie - thanks!
On Fri, 28 Nov 2014 20:55:42 +0100, Philipp Kern wrote: >On Fri, Nov 28, 2014 at 07:08:09PM +0100, Marc Haber wrote: >> And this facing a mostly hostile upstream and a Fedora-Centric >> community. > >I have observed a mostly hostile Debian community in recent months. I'm not >sure if this jab at Fedora is particularly warranted. On #systemd yesterday, it took a mere twelve minutes until I got the first "maybe your distribution is broken" when I just wanted to debug a faulty X server. A few hours of reasearch later (which could have been a few minutes if just the community would have been a bit more helpful) it turned out they were right: We start kdm via an init script and sysvrc emulation, and this does actually break the distinction between multi-user.target and graphical.target. I have yet to find out why runlevel3.target doesn't work either. Thankfully kdm does still have an init script which honored a strategically placed exit 0. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xut2e-0004ll...@swivel.zugschlus.de
Re: successful upgrade to jessie - thanks!
Hi,
Marc Haber writes:
> A few hours of reasearch later (which could have been a few minutes if
> just the community would have been a bit more helpful) it turned out
> they were right: We start kdm via an init script and sysvrc emulation,
> and this does actually break the distinction between multi-user.target
> and graphical.target.
>
> I have yet to find out why runlevel3.target doesn't work either.
runlevel{2,3,4}.target are by default aliases for multi-user.target:
$ /lib/systemd/system % ls -l runlevel*
lrwxrwxrwx 1 root root 15 Nov 18 13:15 runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root 13 Nov 18 13:15 runlevel1.target -> rescue.target
lrwxrwxrwx 1 root root 17 Nov 18 13:15 runlevel2.target -> multi-user.target
lrwxrwxrwx 1 root root 17 Nov 18 13:15 runlevel3.target -> multi-user.target
lrwxrwxrwx 1 root root 17 Nov 18 13:15 runlevel4.target -> multi-user.target
lrwxrwxrwx 1 root root 16 Nov 18 13:15 runlevel5.target -> graphical.target
lrwxrwxrwx 1 root root 13 Nov 18 13:15 runlevel6.target -> reboot.target
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738932ep7@deep-thought.43-1.org
Re: successful upgrade to jessie - thanks!
On Fri, Nov 28, 2014 at 07:08:09PM +0100, Marc Haber wrote: > And this facing a mostly hostile upstream and a Fedora-Centric > community. I have observed a mostly hostile Debian community in recent months. I'm not sure if this jab at Fedora is particularly warranted. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: successful upgrade to jessie - thanks!
On Fri, 28 Nov 2014 09:30:01 +0100, Matthias Urlichs wrote: >Marc Haber: >> Updating of such systems has always been a pain, but this time it's >> going to be a gazillion times more painful. >> >Why? (Seriously.) Because this time fixing those things is more than just minor changes in some init script. It's learning and understanding more than just a few bizarre new concepts. And this facing a mostly hostile upstream and a Fedora-Centric community. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xupxh-0002zs...@swivel.zugschlus.de
Re: successful upgrade to jessie - thanks!
Hi, Marc Haber: > Updating of such systems has always been a pain, but this time it's > going to be a gazillion times more painful. > Why? (Seriously.) -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141128083000.gg6...@smurf.noris.de
Re: successful upgrade to jessie - thanks!
On Thu, 27 Nov 2014 23:50:08 +0800, Thomas Goirand wrote: >On 11/27/2014 09:22 PM, Tomas Pospisek wrote: >> Yesterday I've upgraded my laptop with quite massive foreign package >> sources and installations (qgis packages, backports, stuff from ubuntu >> PPAs, nodejs, a dozen packages from jessie etc.) from wheezy to jessie. > >That's probably why you had issues upgrading. That's not supported, and >breakage in dependencies are to be expected in this kind of cases. Updating of such systems has always been a pain, but this time it's going to be a gazillion times more painful. Prepare for pain. Lots of pain. It'll come. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xu5pv-0007hu...@swivel.zugschlus.de
Re: successful upgrade to jessie - thanks!
On Jo, 27 nov 14, 15:06:17, David Kalnischkies wrote: > > It's also not the worst idea to remove stuff from third party > repositories before upgrading and only install them again after the > upgrade. This way you can sure that they aren't interfering (something > which can't be prevented and just works most of the time because you are > lucky) and you can recheck that the 3rd party repository is still > maintained/supported or if this or a comparable package appeared in > Debian. If not, you should think about getting it into Debian… That has been the standard recommendation in the Release Notes since at least Lenny. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: successful upgrade to jessie - thanks!
On 11/27/2014 09:22 PM, Tomas Pospisek wrote: > Yesterday I've upgraded my laptop with quite massive foreign package > sources and installations (qgis packages, backports, stuff from ubuntu > PPAs, nodejs, a dozen packages from jessie etc.) from wheezy to jessie. That's probably why you had issues upgrading. That's not supported, and breakage in dependencies are to be expected in this kind of cases. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54774830.2000...@debian.org
Re: successful upgrade to jessie - thanks!
Hi Tomas, Great you like it! Many people are busy working on smoothing the edges uncovered by all the inflowing bugreports, so the occasional "thanks!" is a nice boost to troop morale. :) On Thu, Nov 27, 2014 at 02:22:14PM +0100, Tomas Pospisek wrote: > Allthough apt-get dist-upgrade broke half way through due to > unresolvable package dependencies, I was able to finish the upgrade via > aptitude's ncurses interface. Please lookup /var/log/apt/term.log and report a bug about the specific failure you see in there. I presume some maintainerscript is failing, preventing configuration of something which ultimately lets dpkg fail with an unresolved dependency error as the package is arguable not correctly installed… Your system state before the upgrade might be of interest to: You can find a backup of it in /var/backups. One of the files names "dpkg.status" with an 'old-enough' date will be it. Note that if apt-get failed "half way through" in the upgrade, aptitude more than likely would have failed just as well as the code running the installation process is shared. The difference between the two is "just" UI and dependency resolution before you press 'y'. Everything after that like the download, consistency check or the installation is the same… It's also not the worst idea to remove stuff from third party repositories before upgrading and only install them again after the upgrade. This way you can sure that they aren't interfering (something which can't be prevented and just works most of the time because you are lucky) and you can recheck that the 3rd party repository is still maintained/supported or if this or a comparable package appeared in Debian. If not, you should think about getting it into Debian… btw: apt-get is actually recommend for dist-upgrade as it is requiring less knowledge than the operation of aptitude. The later can also be a bit unpredictable in its resolution process, which has its advantages in day to day usage maybe with small solutions, but most people don't second-guess solutions involving >=2000 packages and just press 'y'… Point being: If apt-get doesn't work we ought to know so that can be solved one way or the other, but flipping package manager is unlikely to be the way at this stage. [Disclaimer: I (hopefully) don't say that only because I work on apt] Best regards David Kalnischkies P.S.: Despite many people believing it: -f isn't short for --force, but for --fix-broken. It can work on dist-upgrade, but it is probably better you just run "apt-get install -f" instead as adding new problems on top of the existing ones is usually not a good way forward… signature.asc Description: Digital signature
