Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
On Tuesday, December 11, 2012 03:56:30 AM Colin Guthrie wrote: > 'Twas brillig, and Thomas Spuhler at 11/12/12 04:51 did gyre and gimble: > > On Sunday, December 09, 2012 11:55:13 AM Colin Guthrie wrote: > >> 'Twas brillig, and Thierry Vignaud at 09/12/12 18:48 did gyre and gimble: > >>> On 9 December 2012 13:18, Colin Guthrie wrote: > >> So I've just pushed the package mageia-prepare-upgrade to mga2 > >> core/updates_testing. > >> > >> This package, when installed will add a new menu option to your > >> bootloader. Simply install this package, reboot, select the "Mageia > >> 3 Upgrade Preparation" entry boot, wait while your FS is converted > >> and then perform a urpmi upgrade as you would normally. > >> > >> I've not specifically tested the upgrade part, only the installation > >> and creation of the initrd and bootloader entries in grub. I've also > >> not done this on an mga2 machine yet but will do soon enough. > >> > >> I just wanted to get this package "out there" for anyone wanting to > >> update their mga2 machines to mga3 a3 but not wanting to use the > >> installer. > >> > >> At present there are a few limitations: > >> > >> 1. It requires kernel 3.3.8-2.mga2 to be installed (any flavour > >> should work). A specific kernel version is not really 100% > >> necessary but it does mean I can add hard requires to the package. > >> This is only desirable to prevent the situation where users install > >> this upgrade package but do not run it and later remove the kernel > >> used to generate the initrd for the bootloader menu item, thus > >> breaking it. Any smarter ideas on how to manage this welcome. > >> > >> 2. If you have /usr in a separate partition and have it mounted ro > >> in your fstab, you will have to manually change the fstab to rw for > >> the upgrade boot. > >> > >> > >> Happy testing. Let me know if it kills any kittens. Please keep a > >> backup etc. etc. > >> > >> Col > > > > Thanks Colin. > > The conversion works. But then the problem shows, we have no network. > > doing a urpmi --download-all --auto-update only downloads the fist > > 120+ rpms (the ones needed before restart-urpmi > > > > What is needed is to add some directories and then the network will > > start /var/run/netreport > > /var/lock/subsystem/network > > > > I will check after the upgrade if they can be deleted > > Hmm, yes, I guess after doing the upgrade the various /var/run and > /var/lock folders would be nuked. In mga3 they will be created by > tmpfiles but not with a simple reboot on mga2... > > Hmm, I wonder how best to do this... perhaps we could ship updated > packages for each of the packages which absolutely *need* this to do > the download... or perhaps we could just ship some essential config > tweaks in the this mageia-prepare-upgrade file. It shouldn't do any > harm to do the latter and it's a bit easier on the QA folk. > >>> > >>> Humm we could just package mageia-prepare-upgrade in mga3 and add > >>> it to urpmi priority list. > >>> Thus it would also work for people who never apply updates... > >>> My 2 cents > >> > >> Not sure it would help. I mean users have to install it, reboot and then > >> install the rest... > >> > >> Also how does the urpmi priority list work? Does that not require that > >> we install urpmi first? If so that likely won't work as there is a > >> chicken and egg scenario that prevents the rpm+urpmi from mga3 being > >> installed until the fs is updated. > >> > >> > >> Basically, a fully up-to-date mga2 (including rpm package and the > >> mageia-prepare-upgrade package) + reboot for preparation is needed for a > >> urpmi-based upgrades to work. > >> > >> Col > > > > OK, I started all over again from a completed mga 2 with all updates. > > > > The requires are: Pizza and beer > : > :D > : > > install mageia-prepare-upgrade > > change sources to cauldron > > No need to change sources yet, but no harm in it either. > > > reboot with mageia-prepare-ugrade > > > > eat pizza and drink beer, it takes a lot of time to pass all the > > time-outs > > Hmm, this shouldn't take long... Especially if /usr is on the same > partition as / (it should take < 30s then really as it's "copying" using > hardlinks which are very quick). What kind of timeouts are you seeing here? > > Perhaps remove "silent" and "splash" here to get more verbose output. > > > (it will boot into a none graphic shell) > > Hmm, interesting. It seems the kernel entry added does not honour the > vga= argument. Need to work out why that is not propagated from the > other kernel entries. > > > login as root ans then startx > > > > create /var/run and then start the network > > Hmm, you need to *create* /var/run? This definitely should not be > needed. Are you s
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
Op dinsdag 11 december 2012 20:27:23 schreef Remy CLOUARD: [...] > > I presume your setup is such that /var is indeed on a separate partition? > > Yeah, I don’t see the point of having a separate usr so that one went > smoothly. However, having a separate /var is useful even on a desktop > for me, because of /var/cache/urpmi (I had aptitude fill my / on a > safe-upgrade that ended up not being that safe once so I kinda became > paranoid :p) [...] this reminds me... what should we do with /var/cache ? /var/cache/urpmi-proxy could potentially take quite some space... how should i handle that?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release flamerobin-0.9.2-3.mga3
On Tue, 11 Dec 2012 20:28:54 +0100 (CET) philippem wrote: > Name: flamerobin Relocations: (not > relocatable) Version : 0.9.2 Vendor: > Mageia.Org Release : 3.mga3Build Date: > Tue Dec 11 20:25:14 2012 Install Date: (not installed) > Build Host: jonund.mageia.org Group : > Databases Source RPM: (none) Size: > 903807 License: BSD-like Signature : > (none) Packager: philippem > URL : http://www.flamerobin.org/ > Summary : Graphical client for Firebird > Description : > FlameRobin is a database administration tool for Firebird DBMS based > on wxgtk toolkit. > > philippem 0.9.2-3.mga3: > + Revision: 329795 > + rebuild (emptylog) You should not use SILENT in all commit msgs between two releases. Or when there's only one commit with whole commit msg silenced and you bump the rel. All these breaks the %changelog. :( I'm pretty sure there are changes between releases to be shown in %changelog.
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
On Sun, Dec 09, 2012 at 06:49:03PM +, Colin Guthrie wrote: > 'Twas brillig, and Colin Guthrie at 09/12/12 12:14 did gyre and gimble: > > 'Twas brillig, and Remy CLOUARD at 08/12/12 12:25 did gyre and gimble: ... > >> I’ve followed the procedure and could upgrade my system from 2 to > >> cauldron, but I still have an issue with the filesystem package. > >> > >> Somehow it seems like it fails to move /var/run to /run and /var/lock to > >> /run/lock. > >> > >> I would be glad if there could be a workaround for this. ... > >> The only way out I think would be to manually do the symlink from > >> another install. > >> > >> Could you confirm that ? > > > > Actually yes, there is still a problem at present with /var on a > > separate partition... I need to look into that. > > So the latest package should mount /var in the initrd in much the same > way it does with /usr (not exactly the same but I want to make the > changes as unobtrusive as possible and ideally separate from the main > dracut package for convenience of updating). > > I presume your setup is such that /var is indeed on a separate partition? Yeah, I don’t see the point of having a separate usr so that one went smoothly. However, having a separate /var is useful even on a desktop for me, because of /var/cache/urpmi (I had aptitude fill my / on a safe-upgrade that ended up not being that safe once so I kinda became paranoid :p) > > In order to fix this, simply mv the folders out the way and just do the > symlinks manually - it'll mess up the current boot, but a reboot should > fix it. > That’s what I did indeed, then I could upgrade filesystem, thanks for the answer ;) > If the symlinks disappear and are replaced again by folders, then also > make sure you disable mandriva-clean-var-run-lock.service as it > helpfully nukes the symlinks (the update does this but perhaps it's > somehow been run/re-enabled?) Can’t answer for that, most of the time I never shutdown my laptop, only pm-suspend. I should also mention that each try at installing filesystem resulted in a temporary symlink being created like: lock;50b68005. I assume these symlinks can safely be removed, just thought I would point that out. Thanks for your help ! Regards, > > Cheers > > Col > -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release qscintilla-2.7-3.mga3
Le 11/12/2012 17:52, matteo a écrit : matteo 2.7-3.mga3: + Revision: 329742 - obsoleting lib qscintilla2_8 Why ? The whole point of using versioned package names is to allow coexistence of old libraries on end user systems, even after the package providing them has been updated. If you don't want old libs versions to stay behind, just don't ship them in a separate package. -- BOFH excuse #266: All of the packets are empty.
[Mageia-dev] abrt+libreport
Hi, I have updated versions of these packages (part of my /var/run updates) locally. Can I submit them? It updates both to the latest upstream, but I have no real way to test it properly. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] /var/run after /usr/move
Hiya, 'Twas brillig, and Olivier Thauvin at 11/12/12 16:26 did gyre and gimble: > The "/usr move" included the move of /var/run to /run, however this has > not been done into packages, like quagga: > > [...] > %dir %attr(0750,root,root) /var/run/quagga > [...] > > Shouldn' this be changed ? Yes, I've mentioned this on the list a few times and also have worked through a few of the main, high profile packages already. I've also pushed a new rpmlint-mageia-policy update which bans files in /var/run, /var/lock and /run. It also bans udev rule files in /etc/udev.d and tmpfiles in /etc/ (the /etc/ tree is for admin config, and packaged files should be in /usr/lib/udev/rules.d and /usr/lib/tmpfiles.d respectively). It would be good to get this updated set of rules pushed to the infrastructure before the mass rebuild and beta2. Help here on updating packages is most welcome. The files/dirs in these folders basically need to be translated to tmpfiles configs instead. I've written a wiki page to document about how to handle tmpfiles: https://wiki.mageia.org/en/System_Service_policy This will give you a nice list: urpmf "^/var/(run|lock)/" | sort -u Unfortunetly in the last week or so, some new ones are appearing: ngircd tomcat so the sooner the lint policy is added the better IMO :) I do also still have one problem (reported on this list) that needs fixing that's the postfix+cyrus-sasl saslauth socket issue. Previously it was hardlinked, such that chrooted postfix worked OK. This is no longer possible due to it crossing filesystems, so we'll have to do some bind-mounting black magic I think :s > BTW: I recently updated a fresh mga2 to mga-cualdron and separated /var > is still not handle automatically when moving /usr. How recently? I pushed a new mageia-prepare-upgrade package to mga2 core/updates_testing on Sunday which should handle /var mounting in the initramfs for processing the usrmove. Certainly it worked fine for me in my tests (ext4 / + swap + LVM /var and LVM /usr + encrypted LVM /home (all on the same Volume Group) and it worked fine with that somewhat overly complex example. Minor problem with the vga= line from the kernel not being propagated to the newly installed bootloader entry but other than that it worked fine, not tested with lilo tho' - only grub, although all manipulation is via our tools so should be OK in theory) I mentioned this already on the "ANN: Upgrading from Mageia 2 via urpmi" thread which has seen several new posts over the last few days, so there may be some additional info in there. Hope this helps. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] New install repo options
On Tue, 11 Dec 2012 17:27:03 +0100, Manuel Hiebel wrote: > Certainly as a option Good! Thank you... -- /\/\aurice
Re: [Mageia-dev] New install repo options
Le 11/12/2012 13:03, Maurice Batey a écrit : > On Mon, 10 Dec 2012 22:58:21 +0100, Manuel Hiebel wrote: > >> (grub2 coming too) > As default, or as an option? > Certainly as a option
[Mageia-dev] /var/run after /usr/move
Hello, The "/usr move" included the move of /var/run to /run, however this has not been done into packages, like quagga: [...] %dir %attr(0750,root,root) /var/run/quagga [...] Shouldn' this be changed ? BTW: I recently updated a fresh mga2 to mga-cualdron and separated /var is still not handle automatically when moving /usr. Regards. -- Olivier Thauvin CNRS - LATMOS ♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ pgpwFGYrPcoh8.pgp Description: PGP signature
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release qscintilla-2.7-2.mga3
On Tue, 11 Dec 2012 16:42:21 +0100 (CET) matteo wrote: > Name: qscintilla Relocations: (not > relocatable) Version : 2.7 Vendor: > Mageia.Org Release : 2.mga3Build Date: > Tue Dec 11 16:36:54 2012 Install Date: (not installed) > Build Host: ecosse.mageia.org Group : > System/Libraries Source RPM: (none) Size: > 2846048 License: GPLv2+ Signature : (none) > Packager: matteo > URL : > http://www.riverbankcomputing.co.uk/software/qscintilla/intro > Summary : Port to Qt of Neil Hodgson's Scintilla C++ editor class > Description : As well as features found in standard text editing > components, QScintilla includes features especially useful when > editing and debugging source code. These include support for syntax > styling, error indicators, code completion and call tips. The > selection margin can contain markers like those used in debuggers to > indicate breakpoints and the current line. Styling choices are more > open than with many editors, allowing the use of proportional fonts, > bold and italics, multiple foreground and background colours and > multiple fonts. > > matteo 2.7-2.mga3: > + Revision: 329693 > - added missing conflict definition This forces removal of the old lib. IMHO better fix would've been splitting the translations out of the lib pkg (if you added conflicts because of those files).
Re: [Mageia-dev] [changelog] [RPM] cauldron tainted/release audacious-plugins-3.3.3-1.mga3.tainted
'Twas brillig, and Götz Waschk at 11/12/12 15:41 did gyre and gimble: > On Tue, Dec 11, 2012 at 4:05 PM, wally wrote: >> This package is in "Tainted" as it violates some patents. > Thanks Wally. Could this be done automatically in the future? If a > tainted version exists, build the new release for tainted as well? That's always been the plan... not sure how far it's progressed recently tho', I know some folk have been working on build-related scripts these past few days... not sure this is on that list tho'. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] [changelog] [RPM] cauldron tainted/release audacious-plugins-3.3.3-1.mga3.tainted
On Tue, Dec 11, 2012 at 4:05 PM, wally wrote: > This package is in "Tainted" as it violates some patents. Thanks Wally. Could this be done automatically in the future? If a tainted version exists, build the new release for tainted as well? -- AL I:40: Do what thou wilt shall be the whole of the Law.
Re: [Mageia-dev] [soft-commits] [6573] Add script to rebuild a list of packages
On 12/12/10 15:02 +0100, nicolas vigier wrote: > > Isn't this duplicate with the magpie tool? > > http://jquelin.blogspot.fr/2011/02/magpie-mageia-perl-integration-easy.html > > Ah ? Is there something in magpie to rebuild a list of packages on the > build system ? No. "magpie dwim" will update local packages to their latest cpan version (and submit them), "magpie sort" will sort a list of packages needing a rebuild according to their requires. But nothing exists within magpie to do a mass rebuild. mdvsys used to be able to do this kind of operation. Jérôme
Re: [Mageia-dev] New install repo options
On Mon, 10 Dec 2012 22:58:21 +0100, Manuel Hiebel wrote: > (grub2 coming too) As default, or as an option? -- /\/\aurice
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Thomas Spuhler at 11/12/12 04:51 did gyre and gimble: > On Sunday, December 09, 2012 11:55:13 AM Colin Guthrie wrote: >> 'Twas brillig, and Thierry Vignaud at 09/12/12 18:48 did gyre and gimble: >>> On 9 December 2012 13:18, Colin Guthrie wrote: >> So I've just pushed the package mageia-prepare-upgrade to mga2 >> core/updates_testing. >> >> This package, when installed will add a new menu option to your >> bootloader. Simply install this package, reboot, select the "Mageia 3 >> Upgrade Preparation" entry boot, wait while your FS is converted and >> then perform a urpmi upgrade as you would normally. >> >> I've not specifically tested the upgrade part, only the installation >> and creation of the initrd and bootloader entries in grub. I've also >> not done this on an mga2 machine yet but will do soon enough. >> >> I just wanted to get this package "out there" for anyone wanting to >> update their mga2 machines to mga3 a3 but not wanting to use the >> installer. >> >> At present there are a few limitations: >> >> 1. It requires kernel 3.3.8-2.mga2 to be installed (any flavour should >> work). A specific kernel version is not really 100% necessary but it >> does mean I can add hard requires to the package. This is only >> desirable to prevent the situation where users install this upgrade >> package but do not run it and later remove the kernel used to >> generate the initrd for the bootloader menu item, thus breaking it. >> Any smarter ideas on how to manage this welcome. >> >> 2. If you have /usr in a separate partition and have it mounted ro in >> your fstab, you will have to manually change the fstab to rw for the >> upgrade boot. >> >> >> Happy testing. Let me know if it kills any kittens. Please keep a >> backup etc. etc. >> >> Col > > Thanks Colin. > The conversion works. But then the problem shows, we have no network. > doing a urpmi --download-all --auto-update only downloads the fist 120+ > rpms (the ones needed before restart-urpmi > > What is needed is to add some directories and then the network will > start /var/run/netreport > /var/lock/subsystem/network > > I will check after the upgrade if they can be deleted Hmm, yes, I guess after doing the upgrade the various /var/run and /var/lock folders would be nuked. In mga3 they will be created by tmpfiles but not with a simple reboot on mga2... Hmm, I wonder how best to do this... perhaps we could ship updated packages for each of the packages which absolutely *need* this to do the download... or perhaps we could just ship some essential config tweaks in the this mageia-prepare-upgrade file. It shouldn't do any harm to do the latter and it's a bit easier on the QA folk. >>> >>> Humm we could just package mageia-prepare-upgrade in mga3 and add >>> it to urpmi priority list. >>> Thus it would also work for people who never apply updates... >>> My 2 cents >> >> Not sure it would help. I mean users have to install it, reboot and then >> install the rest... >> >> Also how does the urpmi priority list work? Does that not require that >> we install urpmi first? If so that likely won't work as there is a >> chicken and egg scenario that prevents the rpm+urpmi from mga3 being >> installed until the fs is updated. >> >> >> Basically, a fully up-to-date mga2 (including rpm package and the >> mageia-prepare-upgrade package) + reboot for preparation is needed for a >> urpmi-based upgrades to work. >> >> Col > > OK, I started all over again from a completed mga 2 with all updates. > The requires are: Pizza and beer :D > install mageia-prepare-upgrade > change sources to cauldron No need to change sources yet, but no harm in it either. > reboot with mageia-prepare-ugrade > > eat pizza and drink beer, it takes a lot of time to pass all the time-outs Hmm, this shouldn't take long... Especially if /usr is on the same partition as / (it should take < 30s then really as it's "copying" using hardlinks which are very quick). What kind of timeouts are you seeing here? Perhaps remove "silent" and "splash" here to get more verbose output. > (it will boot into a none graphic shell) Hmm, interesting. It seems the kernel entry added does not honour the vga= argument. Need to work out why that is not propagated from the other kernel entries. > login as root ans then startx > create /var/run and then start the network Hmm, you need to *create* /var/run? This definitely should not be needed. Are you saying you have no /var/run symlink? This should have been added as part of the conversion process. Can I ask: 1. Do you have /var on a separate partition? 2. If so, did my updated package allow you to mount it OK in the initrd (you can pass rd.break=mount and then check the /sysroot/var dir to see if it's mounted - y
Re: [Mageia-dev] Package drop request: ruby-ParseTree
'Twas brillig, and Remy CLOUARD at 11/12/12 06:38 did gyre and gimble: > On Mon, Dec 10, 2012 at 11:41:38PM +, Colin Guthrie wrote: >> So what if we provide this library and someone uses it as a component in >> some other app they write. >> >> They likely have an expectation that it will continue to be supported >> and that any security vulnerabilities in it are detected and fixed. >> >> If we don't have a mechanism to remove (or at least very strongly >> recommend to remove) package we no longer support, then we are leaving >> users vulnerable. >> >> The orphans system is fine, but it's certainly not as strong a mechanism >> as I think is needed. > Well, that would be very lazy from that person not to test the app and > release it. Actually, the ruby community has a strong focus on test > driven development. Since that library is broken with ruby 1.9, it won’t > pass the first test. So no worries here. Actually, I’m pretty sure it > couldn’t even stay on the machine just because it is linked against > libruby.so.1.8, and we provide libruby.so.1.9. > > In the ruby policy I added as a requirement a > Requires: ruby(abi) = version > I’m pleased to see this is now an automatic thing, meaning that a > package that’s doesn’t build won’t stand a chance to stay on people’s > machine. Yes, but keep in mind that the task-obsolete thing is not just about ruby and it also shouldn't rely on people not being lazy and releasing something. Perhaps their app is not for public release anyway. So sadly, we can't design mechanisms around this structure. > That being said it still requires human intervention to remove it from > the mirrors. I wonder if we could have a helper that runs on svn commit hook when a package is moved to the old tree? That would avoid the task-obsolete "abuse" but still doesn't provide a mechanism to remove from users machines... > To me this is a rather sane way to deal with the problem, because it’s > self-explanatory: the package can’t stay because its requirements are > not met. If you add it to task-obsolete, you provide no reason to the > user, most of the time the explanation is only a comment in > task-obsolete’s spec file. This only works when it's true :) Sometimes a package is dropped because it doesn't build with newer gcc and there is no maintainer or enough users to merit it being fixed. Lots of things other than "requirements not met" result in packages being dropped. And if they are dropped they are not supported and we do not accept bug reports etc. etc. These packages should, in theory, be removed from a users machine unless the user takes very specific action to block this. Personally I'd be more in favour of expanding the urpmq --not-available system. It could just be beefed up to allow exclusions (like skip.list, but rather a keep.list). Then a urpme --not-available could be added to remove any no longer available packages. This would require GUI enhancements but it might be a good compromise here. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
