Re: [Mageia-dev] beta 4 installer notes
'Twas brillig, and Thierry Vignaud at 10/04/13 06:03 did gyre and gimble: On 10 April 2013 06:58, Liam R E Quin l...@holoweb.net wrote: (5) a message, script failed for mailman_2.1.15-3.mga3-x86-64: (there was a blank line underneath but no more text) the exact error should be in your /root/drakx/install.log (also included in your /root/drakx/report.bug.xz) it is, but the blank message doesn't seem very polished. we can just be notified by rpm there was an error in a callback. We don't have details at that stage. Those were spit by rpm itself in the log file. There's nothing we can do [[ /var/tmp/rpm-tmp.J7elL9: line 31: crontab: command not found /usr/sbin/postconf: warning: inet_protocols: disabling IPv6 name/address support: Address family not supported by protocol postalias: warning: inet_protocols: disabling IPv6 name/address support: Address family not supported by protocol su: Insufficient credentials to access authentication data su: Insufficient credentials to access authentication data %post(mailman-2.1.15-3.mga3.x86_64) scriptlet failed, exit status 1 mailman-2.1.15-3.mga3.x86_64 ]] This is due to moving 'filesystem' %post script in basesystem-minimal I think. Out of completeness, why does this cause problems? Also I see no %post script in basesystem-minimal anyway so not sure how it could cause problems :D Do you maybe mean the pretrans stuff in filesystem package itself (written in lua)? Even still I'm not sure how this would affect paths as the symlinks should mean all binaries are available under the same paths as they were before. I can't rule it out of course, but I (so far) don't see how this could affect things. Could be fixed by making mailman doing this: Requires(post): basesystem-minimal That should solve the crontab issue (so a grep for that should also be done I guess - although having now done that, it seems only mailman uses it :D). Colin, could you grep for packages invoking su in their post script so that we can fix them all? Not many: openbravo/current/SPECS/openbravo.spec bacula/current/SPECS/bacula.spec mailman/current/SPECS/mailman.spec mercurial-server/current/SPECS/mercurial-server.spec cyrus-imapd/current/SPECS/cyrus-imapd.spec -- 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] M3 beta - where to report problems?
'Twas brillig, and Frank Griffin at 10/04/13 12:00 did gyre and gimble: Starting afresh, I followed the steps up to running XFdrake (but not running XFdrake yet). I tried 'ifup eth0' but 'Running in chroot. Ignoring request'. After exit this changed to Running in chroot. ignoring request. ./network-functions: line 260: cd: /var/run/netreport: No such file or directory. I guess just bring up eth0 before entering the chroot After entering the chroot, you can also do: mount -t tmpfs none /run systemd-tmpfiles --create rm -f /run/nologin That should initialise all the temporary files you might need for a running system. 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] M3 beta - where to report problems?
'Twas brillig, and Thomas Backlund at 08/04/13 13:20 did gyre and gimble: Frank Griffin skrev 4.4.2013 19:12: On 04/04/2013 10:59 AM, Anne Wilson wrote: Not much progress. My usual method of editing the kernel line to get a level 3 boot doesn't work - same blank (but lit) screen. Failsafe appears to be doing better - at least I can see messages. It reaches Reached target Multi-User Reached target Graphical Interface and there it sticks. Does that give any clue as to what is failing, and what I need to do to rescue the system? Boot a rescue disk and mount your root partition. In /etc/systemd/system you should see a symlink like: lrwxrwxrwx 1 root root 36 Mar 29 11:00 default.target - /lib/systemd/system/runlevel5.target Just remove this and re-symlink to /lib/systemd/system/runlevel3.target and you should get a level 3 boot. It's actually easier than that. Add systemd.unit=multi-user.target on kernel / grub command line and ith will boot to runlevel 3 Or simply add a 3 onto the command line as has been the case for many years :) Of course I should probably discourage that seeing as 3 is pretty meaningless in absolute terms these days! :) 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] urpmi - strange read lock messages
'Twas brillig, and Nicolas Lécureuil at 05/04/13 23:11 did gyre and gimble: Le vendredi 5 avril 2013 23:48:08 Jose Jorge a écrit : Le 05/04/2013 14:29, Robert Fox a écrit : Thanks the point - I never aborted. Assuming I did, is there a way to clean this up? Rebuild rpm database?? I get this warnings each time MageiaUpdate applet after was used, then urpmi is used. i NEVER reproduced .But, using your testcase i can. Yeah, I frequently get these messages. I also use a mix of MageiaUpdate and urpmi directly. 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] HEADSUP: Full git clone of all package specs (with history)
'Twas brillig, and Christian Lohmaier at 05/04/13 12:44 did gyre and gimble: Hi Colin, *, On Fri, Apr 5, 2013 at 8:46 AM, P. Christeas x...@linux.gr wrote: On Saturday 23 March 2013, Colin Guthrie wrote: 'Twas brillig, and Colin Guthrie at 22/03/13 09:32 did gyre and gimble: [...] Just to avoid a crazy amount of scripting with svn checkouts and such like, I've set running a git svn clone of the cauldron package subversion tree. That said, running git blame takes *ages* even on an SSD drive. It was at least a couple minutes to display the results of a blame on a spec file. Let me remind you of the other suggestion: Put each package in a separate git repo, and then use submodules to bind all of them together into the Mageia repo.. Somewhat surprised that it takes so long - LO's core repo is much larger and is reasonably fast, even on traditional disk. Maybe git maintenance commands (gc and/or prune) may help? Care uploading the repo to github or similar? I can push the repo somewhere sensible if you wish, but it's not likely super useful unless you have the git-svn branch too. But I've done pruning of the empty commits (i.e. those ignored via --ignore-paths with git-svn) which took 3 days to run in a tmpfs filesystem!, and also done a git gc --aggressive. The times posted are what results from that. 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] M3 beta - where to report problems?
'Twas brillig, and Thomas Backlund at 08/04/13 22:43 did gyre and gimble: Colin Guthrie skrev 9.4.2013 00:31: 'Twas brillig, and Thomas Backlund at 08/04/13 13:20 did gyre and gimble: It's actually easier than that. Add systemd.unit=multi-user.target on kernel / grub command line and ith will boot to runlevel 3 Or simply add a 3 onto the command line as has been the case for many years :) Of course I should probably discourage that seeing as 3 is pretty meaningless in absolute terms these days! :) Are you sure ? IIRC there has been reports of people doing it and still eneded up at graphical.target ... Hmm, well the code suggests it should... will have to try it :) 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] raid 1 dracut
'Twas brillig, and Thierry Vignaud at 02/04/13 17:28 did gyre and gimble: On 2 April 2013 00:33, André Salaün andresal...@free.fr wrote: It was a fresh install Can you open a bug on https://bug.mageia.org and attach your /root/drakx/report*xz file to it? Also the output of sosreport.sh run from the dracut shell when it's unable to mount / This will output lots of information to /run folder. I'm presuming you're able to then fix things up manually and continue the boot, in which case the sosreport output should be stored in /run/initramfs IIRC. 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/
[Mageia-dev] [Mageia-sysadm] setup package not installed until quite late on...
The setup package contains /etc/group and friends, but when installing a chroot, it is not installed until after some packages which require the default groups it defines (e.g. sysvinit-legacy-tools requires the tty group yet it is installed before setup. Now here comes the tricky part... As part of the very first transaction which includes filesystem and glibc, dash-static is pulled in. dash-static requires the mail group defined by setup package. So really glibc requires dash-static which requires setup which requires glibc and shadow-utils and run-parts... Do we really want to add this loop? I'd suggest we should rejig setup to not have a hard require on glibc, shadow-utils and run-parts but still run it's current scripts if the needed binaries/tools are installed (i.e. on package upgrade) and then rejig dash-static to Require(pre): setup. This should ensure things are installed properly (I think - although not sure how this will affect the initial transaction split...) Any other/better thoughts? 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/ ___ Mageia-sysadm mailing list mageia-sys...@mageia.org https://www.mageia.org/mailman/listinfo/mageia-sysadm
Re: [Mageia-dev] [Mageia-sysadm] setup package not installed until quite late on...
'Twas brillig, and Thierry Vignaud at 01/04/13 14:37 did gyre and gimble: On 1 April 2013 15:24, Colin Guthrie mag...@colin.guthr.ie wrote: The setup package contains /etc/group and friends, but when installing a chroot, it is not installed until after some packages which require the default groups it defines (e.g. sysvinit-legacy-tools requires the tty group yet it is installed before setup. Now here comes the tricky part... As part of the very first transaction which includes filesystem and glibc, dash-static is pulled in. dash-static requires the mail group defined by setup package. So really glibc requires dash-static which requires setup which requires glibc and shadow-utils and run-parts... Do we really want to add this loop? I'd suggest we should rejig setup to not have a hard require on glibc, shadow-utils and run-parts but still run it's current scripts if the needed binaries/tools are installed (i.e. on package upgrade) and then rejig dash-static to Require(pre): setup. This should ensure things are installed properly (I think - although not sure how this will affect the initial transaction split...) Any other/better thoughts? rewrite glibc scriptlets in lua instead of sh See http://www.rpm.org/wiki/PackagerDocs/RpmLua The glibc scriptlets don't seem to really *need* dash-static anyway... [root@jimmy ~]# rpm -q --scripts glibc| grep dash preinstall scriptlet (using /usr/bin/dash.static): So it's only the preinst script. That should be trivial to rewrite in lua. OK, so that does avoid the loop, but... should we still try to work out a nice way to get setup (and thus the default groups that packages may use) installed early or is it just a housekeeping job to make sure packages Require(pre) setup package if they want to use the users defined in it? Perhaps we could add some kind of rpmfilter thingy to automatically add this Require(pre)? Is that possible? If so then it might also be possible to write similar automatic Require(pre,post,etc) to packages using rpm-helper stuff too... that would be be quire nice and reduce the packaging burden :) Col PS Replying on cauldron as my original mail wasn't really meant for sysadm list - just me being stupid! -- 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] raid 1 dracut
'Twas brillig, and André Salaün at 01/04/13 20:18 did gyre and gimble: I have installed mageia 3 b 4 on a fujitsu xt 100 s3. (intel c200 raid component). But booting the system dracut lets me in console. Obviously it should work but we'll need a lot more debug info to try and help here. Firstly was this an upgrade or did you install this fresh? 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/
[Mageia-dev] Freeze Push: libva
Hi, Just a minor bugfix update but also some packaging fix ups. The previous version bump kept a patch but the autoreconf was disabled due to an automake compatibility change. This resulted in the patch having no effect and various test binaries were added to the package where they were excluded before. The new version includes support for our automake but the patch no longer applied and rather than rebasing I simply rm'ed the files in the packaging script. Due to Mesa refactoring, I also added a BR on EGL-devel which restores the egl driver. Wayland support can now be compiled if we want it (tested that it builds) but I did not enable it to avoid adding a further automatic dep on wayland-client libs for now. If we want it it can either just be enabled, or enabled and packaged as a sub-package. 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/
[Mageia-dev] Freeze Push: gummiboot
Hi, New version, bugfixes etc. etc. This is an advanced user package and is not yet integrated into our management tools. The current version has some bugs that might overwrite boot entries in EFI variables, so better to use the most recent version available. 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] Freeze Push: libva
'Twas brillig, and Olivier Blin at 31/03/13 14:12 did gyre and gimble: Colin Guthrie mag...@colin.guthr.ie writes: [...] Wayland support can now be compiled if we want it (tested that it builds) but I did not enable it to avoid adding a further automatic dep on wayland-client libs for now. If we want it it can either just be enabled, or enabled and packaged as a sub-package. Hi, wayland-client libs are anyway already pulled by lib64gtk+3_0, gstreamer1.0-plugins-bad and lib64mesaegl1 (pulled by many graphics stack packages), so I guess you can keep wayland enabled in libva. Hmm, good point, well made :D I've enabled it. 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/
[Mageia-dev] Does anyone have a script that bumps releases?
Hi, Does anyone have a script that will bump the release of a given spec file? Obviously there are lots of different forms to set the release and I guess the script has to back through the definition chain to find the right place to add one. Cheers 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/
[Mageia-dev] urpmi output missing some packages in progress (with chroot)
Hi, Playing about a bit with chroots today. [root@jimmy home]# urpmi --root /home/chroot --no-suggests --auto --noclean basesystem-minimal http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/bash-4.2-37.4.mga3.x86_64.rpm http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/lib64termcap2-2.0.8-53.mga3.x86_64.rpm http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/update-alternatives-1.9.0-10.mga3.noarch.rpm http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/perl-base-5.16.3-1.mga3.x86_64.rpm http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/lib64python2.7-2.7.3-7.mga3.x86_64.rpm http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/dash-static-0.5.7-3.mga3.x86_64.rpm http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/glibc-2.17-4.mga3.x86_64.rpm http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/filesystem-2.1.9-19.mga3.x86_64.rpm installing bash-4.2-37.4.mga3.x86_64.rpm lib64termcap2-2.0.8-53.mga3.x86_64.rpm update-alternatives-1.9.0-10.mga3.noarch.rpm perl-base-5.16.3-1.mga3.x86_64.rpm lib64python2.7-2.7.3-7.mga3.x86_64.rpm dash-static-0.5.7-3.mga3.x86_64.rpm glibc-2.17-4.mga3.x86_64.rpm filesystem-2.1.9-19.mga3.x86_64.rpm from /var/cache/urpmi/rpms warning: filesystem-2.1.9-19.mga3.x86_64: Header V3 RSA/SHA1 Signature, key ID 80420f66: NOKEY Preparing... # 1/154: dash-static ##warning: group daemon does not exist - using root warning: group mail does not exist - using root ### 2/154: glibc # 3/154: lib64termcap2 # 4/154: perl-base # 5/154: update-alternatives # 6/154: bash # 7/154: lib64python2.7# -/154: # It seems the last one in that list is filesystem, but it has neither a number, nor is it's name printed. I suspect this might related to the fact that they key is no present which I'm attributing to the fact this is a blank chroot rather than an actual signing problem. 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] urpmi output missing some packages in progress (with chroot)
'Twas brillig, and Thierry Vignaud at 31/03/13 17:30 did gyre and gimble: On 31 March 2013 18:22, Thierry Vignaud thierry.vign...@gmail.com wrote: Preparing... # 1/154: dash-static ##warning: group daemon does not exist - using root warning: group mail does not exist - using root ### 2/154: glibc # 3/154: lib64termcap2 # 4/154: perl-base # 5/154: update-alternatives # 6/154: bash # 7/154: lib64python2.7# -/154: # It seems the last one in that list is filesystem, but it has neither a number, nor is it's name printed. I suspect this might related to the fact that they key is no present which I'm attributing to the fact this is a blank chroot rather than an actual signing problem. It means we failed to get this package fullname http://svnweb.mageia.org/soft/rpm/urpmi/trunk/urpm/install.pm?revision=7595view=markup#l121 After debuging, callback_open got called one too much (it got called twice for first package which is actually filesystem), thus we bump the index one too much. Sadly the doble call came from librpm's rpmtsRun() Interestingly, the open close calls are just before and after rpm prints: warning: filesystem-2.1.9-19.mga3.x86_64: Header V3 RSA/SHA1 Signature, key ID 80420f66: NOKEY It happens b/c filesystem as a %pretrans runTransScripts() calls rpmteProcess() which says: /* Dont bother opening for elements without pre/posttrans scripts */ But since we now have package with %pretrans due to /usr migration, it goes further and calls rpmteOpen()-rpmteFDHeader() which notifys us about a package opening in order to get its file descriptor. Since we now have %pretrans scriptlets, I'll adapt urpmi in order not to bump index out of actual transaction. Awesome :) Good debugging and interesting info above! Thanks as always Thierry :) 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] Freeze Push: libva
'Twas brillig, and Guillaume Rousse at 31/03/13 18:44 did gyre and gimble: Le 31/03/2013 14:14, Colin Guthrie a écrit : Hi, Just a minor bugfix update but also some packaging fix ups. error: command failed: ssh pkgsubmit.mageia.org /usr/local/bin/submit_package -t cauldron --define sid=0346a4f9-d9e3-47ec-91a7-0694aabcf28c -r 406866 svn+ssh://svn.mageia.org/svn/packages/cauldron/libva Hmm, seems I've had trouble uploading sources today (mgarepo up vs. mgarepo upload confusion in my sleepy mind) Should be fine now (I hope). 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] Freeze Push: gummiboot
'Twas brillig, and Guillaume Rousse at 31/03/13 18:43 did gyre and gimble: Le 31/03/2013 14:26, Colin Guthrie a écrit : Hi, New version, bugfixes etc. etc. This is an advanced user package and is not yet integrated into our management tools. The current version has some bugs that might overwrite boot entries in EFI variables, so better to use the most recent version available. error: command failed: ssh pkgsubmit.mageia.org /usr/local/bin/submit_package -t cauldron --define sid=b5b926bb-8444-416e-a525-87cb1a1e2bd4 -r 406860 svn+ssh://svn.mageia.org/svn/packages/cauldron/gummiboot Should be fine now I've uploaded the source. -- 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/
[Mageia-dev] Freeze Push: pavucontrol
Hi, Please push pavucontrol. It's a leaf package and this package exposes tools to adjust the latency offset and also see the port status (for headphones etc.) which aids debugging. Cheers 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] Freeze Push: xbmc
'Twas brillig, and Guillaume Rousse at 29/03/13 08:32 did gyre and gimble: Le 28/03/2013 21:39, Colin Guthrie a écrit : Hi, Please push xbmc 12.1. It's a bugfix release for 12. Leaf package so would be good to get the latest batch of fixes. Missing sources: error: File /var/lib/schedbot/repsys/tmp/tmpVz_Y9A/SOURCES/xbmc-pvr-addons-96774c4f775b156a46fb58151379dece3e773c96.tar.xz: No such file or directory D'oh! That damn bug between the chair and the keyboard again. Please retry at your convenience. 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] Freeze Push: mythtv
'Twas brillig, and Guillaume Rousse at 29/03/13 09:06 did gyre and gimble: Le 28/03/2013 20:41, Colin Guthrie a écrit : Hi, Been sitting on this update for a while due to general laziness. It's a leaf package and there are several updates over the current version. Please submit mythtv and after it's build mythplugins. I believe I'm allowed to submit myself to tainted afterwards, but if not, then please do the same on tainted too! Build failure: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130329083123.guillomovitch.valstar.5722/log Added yasm as a BR. Hopefully it's the only missing one! Please try again at your convenience. 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] Last versions of programs concerning Computer Assisted Music
'Twas brillig, and Barry Jackson at 29/03/13 09:31 did gyre and gimble:
BTW there was no need to use all the ../../ just removing %{buildroot}
on the target is enough.
Yup. All symlinks will be converted to relative ones by the packaging
script anyway (which is useful to not create broken symlinks in chroots
etc.)
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] Freeze Push: mythtv
'Twas brillig, and Colin Guthrie at 28/03/13 19:41 did gyre and gimble: I believe I'm allowed to submit myself to tainted afterwards, but if not, then please do the same on tainted too! Seems I cannot. Can you submit both to tainted too please? 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/
[Mageia-dev] Freeze Push: mythtv
Hi, Been sitting on this update for a while due to general laziness. It's a leaf package and there are several updates over the current version. Please submit mythtv and after it's build mythplugins. I believe I'm allowed to submit myself to tainted afterwards, but if not, then please do the same on tainted too! Cheers 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/
[Mageia-dev] Freeze Push: xbmc
Hi, Please push xbmc 12.1. It's a bugfix release for 12. Leaf package so would be good to get the latest batch of fixes. Tested locally and works well. Cheers 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/
[Mageia-dev] First: Freeze Push: libcec (was Re: Freeze Push: xbmc)
Hi, Before pushing xbmc, can you please push libcec. The new version is needed by xbmc. libcec is only used by xbmc and mythtv. Sadly mythtv needs the 1.x version (we currently have 2.0.5). I'll see if patches exist for mythtv and libcec 2. Cheers Col 'Twas brillig, and Colin Guthrie at 28/03/13 20:39 did gyre and gimble: Please push xbmc 12.1. It's a bugfix release for 12. Leaf package so would be good to get the latest batch of fixes. -- 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] Freeze Push: mythtv
'Twas brillig, and Colin Guthrie at 28/03/13 19:41 did gyre and gimble: Hi, Been sitting on this update for a while due to general laziness. It's a leaf package and there are several updates over the current version. Please submit mythtv and after it's build mythplugins. I believe I'm allowed to submit myself to tainted afterwards, but if not, then please do the same on tainted too! Please hold off on pushing this until libcec is pushed :) 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/
[Mageia-dev] Apache doesn't always like restarting....
Hiya, Not sure if others ever get this but sometimes my apache really doesn't like being restarted. Looking at things when it's in this stuck state it appears to be waiting on a mutex: Process 24205 attached futex(0x7fde0090c640, FUTEX_WAIT_PRIVATE, 2, NULL unfinished ... Eventually systemd gets tired waiting and kills it properly +++ killed by SIGKILL +++ which is nice from a cleanliness perspective - I'm pretty sure that before either sysvinit would have just hung or returned from the stop job without killing things properly and then started apache again and gotten then failed to bind to port 80 type error I'm sure I remember seeing. Anyway, don't think this is something we can easily fix just now and it's quite sporadic (doesn't always happen). One of these days I'll be able to attach to it properly and get a nice backtrace :) Cheers 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] Apache doesn't always like restarting....
'Twas brillig, and Guillaume Rousse at 27/03/13 13:11 did gyre and gimble: Le 27/03/2013 13:20, Colin Guthrie a écrit : Hiya, Not sure if others ever get this but sometimes my apache really doesn't like being restarted. Looking at things when it's in this stuck state it appears to be waiting on a mutex: Process 24205 attached futex(0x7fde0090c640, FUTEX_WAIT_PRIVATE, 2, NULL unfinished ... Eventually systemd gets tired waiting and kills it properly +++ killed by SIGKILL +++ This seems quite close from problem reported here: https://bugs.mageia.org/show_bug.cgi?id=9434 In my case, the problem vanished when switching to fedora-style systemd unit (started with -DForeground, with a notify type, instead of normal forking type). I'm pretty sure I've restarted it already after upgrading (actually it should have restart when it was upgraded anyway) and got bitten by it today, so not 100% convinced it's resolved by this switch. But either way, I'll keep my eyes open to see if it happens again (and I'll try and strace/gdb the main process before I do the restart to extract some useful info out if it too). Cheers 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] Apache doesn't always like restarting....
'Twas brillig, and Guillaume Rousse at 27/03/13 14:44 did gyre and gimble: Le 27/03/2013 15:09, AL13N a écrit : the other day i tried to get cores, but somehow unlimited meant 0 meant no core at all You need to set LimitCORE=infinity in unit file, according to systemd.exec man page. And you probably need the adequate sysctl setting (kernel.core_pattern) to ensure the core file get dumped into a predictible directory. Yup, I put LimitCORE=infinity in mine: [colin@jimmy conf]$ cat /etc/systemd/system/httpd.service .include /usr/lib/systemd/system/httpd.service [Service] LimitCORE=infinity But the *real* change here from before is in Apache config. With newer Apache's (starting 2.4??) you have to put: CoreDumpDirectory /tmp in your httpd.conf somewhere. Without this, it won't write the core file. Col PS I realised that with my customised httpd.service file (not the one above which avoids this problem, but a literal copy!), I wasn't actually using the new settings, so my previous test related to this thread was bunk... will see if this also fixes it for me!! -- 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] Apache doesn't always like restarting....
'Twas brillig, and AL13N at 27/03/13 18:46 did gyre and gimble: Op woensdag 27 maart 2013 15:44:48 schreef Guillaume Rousse: Le 27/03/2013 15:09, AL13N a écrit : the other day i tried to get cores, but somehow unlimited meant 0 meant no core at all You need to set LimitCORE=infinity in unit file, according to systemd.exec man page. And you probably need the adequate sysctl setting (kernel.core_pattern) to ensure the core file get dumped into a predictible directory. actually, no, setting LimitCORE=infinity (also our default as shown with systemctl show *.service) ends up with the actual limit being 0 as shown by prlimit. (this was with help from #systemd people) Can you point at a commit that fixes this then. I'm a little confused as I've used this setup to happily get segv's from apache (namely php) so I'm a little confused as to why it doesn't work for you :s Even running prlimit here, I don't see a problem: [colin@jimmy scripts (master)]$ ps aux | grep httpd root 4576 0.0 0.2 413372 21936 ?Ss 19:41 0:00 /usr/sbin/httpd -DFOREGROUND apache4577 0.0 0.3 426024 30288 ?S19:41 0:00 /usr/sbin/httpd -DFOREGROUND apache4579 0.0 0.1 413804 14408 ?S19:41 0:00 /usr/sbin/httpd -DFOREGROUND apache4581 0.0 0.1 414012 15680 ?S19:41 0:00 /usr/sbin/httpd -DFOREGROUND apache4582 0.0 0.1 413804 14312 ?S19:41 0:00 /usr/sbin/httpd -DFOREGROUND apache4583 0.0 0.1 413812 14380 ?S19:41 0:00 /usr/sbin/httpd -DFOREGROUND apache4584 0.0 0.4 434512 38160 ?S19:41 0:00 /usr/sbin/httpd -DFOREGROUND apache4585 0.0 0.4 434488 38140 ?S19:41 0:00 /usr/sbin/httpd -DFOREGROUND apache4586 0.0 0.1 413804 14344 ?S19:41 0:00 /usr/sbin/httpd -DFOREGROUND [colin@jimmy scripts (master)]$ prlimit -c -p 4576 prlimit: failed to get the CORE resource limit: Operation not permitted [colin@jimmy scripts (master)]$ sudo prlimit -c -p 4576 RESOURCE DESCRIPTION SOFT HARD UNITS CORE max core file size unlimited unlimited blocks [colin@jimmy scripts (master)]$ sudo prlimit -c -p 4577 RESOURCE DESCRIPTION SOFT HARD UNITS CORE max core file size unlimited unlimited blocks Are you absolutely sure it's not just apache resetting the value when you don't set CoreDumpDirectory in your httpd.conf? moreover, the systemd is compiled without coredump functionality, and that seems to have an effect on this and disallows one to configure systemd-coredump (which isn't build nor packaged) for usage with integrated coredumps with the systemd-coredump-ctl executable, (which is packaged). This was a deliberate decision at the time. There were not sufficient tools to extract coredumps from the journal logs and really the coredump support should be separate from the coredump capturing and logging to the journal anyway, so it shouldn't affect anything you're doing right now (e.g. it shouldn't affect how you setup apache) The fact that systemd-coredump-ctl is build is IMO a bug, and one that could very well be fixed upstream already (probably is) but I didn't want to keep the rm in the %install section of the spec lest it was accidentally left in there when we turn the feature on (when it's generally more useful - i.e. you can store cores in a directory outside of the journal etc etc.). @colin, so please, fix these 2 issues (first one looks like a systemd issue; while the second one is a packaging issue) Like I say I've not actually observed the first problem personally, and have actively gotten core files from apache and my prlimit settings seem to be different from yours so I'm not really sure what to solve. As for the core dump support, I would be happy enough re-enabling it again. I'm just not convinced that storing the dumps in the journal is a great idea. I mean if you get a constantly crashing service, your logs will fill up quickly and be rotated away quickly. I think the cores should be stored outside of the journal. I can't remember off hand if the patch that implemented this was finally committed or not - I'll have a look and check. 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] Apache doesn't always like restarting....
'Twas brillig, and Colin Guthrie at 27/03/13 17:20 did gyre and gimble: PS I realised that with my customised httpd.service file (not the one above which avoids this problem, but a literal copy!), I wasn't actually using the new settings, so my previous test related to this thread was bunk... will see if this also fixes it for me!! Nah, still got it on a restart just now. Hey ho. It's definitely one of the child processes tho' (i.e. one owned by apache, not root). Will continue to try and work out how to debug this issue :) 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 core/release apache-2.4.4-4.mga3
'Twas brillig, and Thierry Vignaud at 26/03/13 05:49 did gyre and gimble: On 25 March 2013 21:37, guillomovitch buildsystem-dae...@mageia.org wrote: guillomovitch guillomovitch 2.4.4-4.mga3: + Revision: 405238 - take advantage of mod_systemd for controlling apache (fix #9434) - use systemd service for htcacheclean instead of initscript - keep original fedora patches verbatim Installing apache-2.4.4-4.mga3.x86_64.rpm eus /mageia/unstable/x86_64/media/core/release Preparing ... 1/1: apache Failed to issue method call: Unit httpd-prefork.service failed to load: No such file or directory. See system logs and 'systemctl status httpd-prefork.service' for details. Warning : %post(apache-2.4.4-4.mga3.x86_64) scriptlet failed, exit status 6 ERROR: 'script' failed for apache-2.4.4-4.mga3.x86_64: Hmmm, I thought this was one of the problem guillomovictch was specifically trying to solve here... I think this is due to a stale symlink /etc/systemd/system/httpd.service which should be broken and pointing at /lib/systemd/system/httpd-prefork.service which no longer exists. Can you confirm this? The problem will go away when this broken link is removed but it should be done in the %post script... I had a half-written %post script to tidy it up but I stopped when I spoke to guillomovictch on IRC as he said it was WIP. Cheers 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] List of packages that use dbus-send in scriptlets.
'Twas brillig, and David W. Hodgins at 26/03/13 00:15 did gyre and gimble:
Is there any way to get a list of all packages that use dbus-send,
in the installation scriptlets?
As per https://bugs.mageia.org/show_bug.cgi?id=9534, which is for
the rtkit package, it uses dbus-send in it's postinstall scriptlet,
which doesn't work during upgrade, blocking urpmi until the
dbus-send is manually killed.
A list of packages using dbus-send in the scriptlets would help
ensuring upgrading with those packages is tested.
Using my handy git clone of all packages:
[colin@jimmy cauldron-packages (master)]$ grep --include=*.spec -r dbus-send
dbus/current/SPECS/dbus.spec:%{_bindir}/dbus-send
rtkit/current/SPECS/rtkit.spec:dbus-send --system --type=method_call
--dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig
/dev/null 21 || :
So basically, only rtkit. At least directly at any rate... there could
be other things that use scripts etc.
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] List of packages that use dconf in scriptlets.
'Twas brillig, and David W. Hodgins at 26/03/13 02:09 did gyre and gimble:
Like rtkit, updating gdm during an upgrade is also blocking
urpmi in a postinstall scriptlet. This time it's a dconf command.
https://bugs.mageia.org/show_bug.cgi?id=9535
A list of packages using dbus-send or dconf in the scriptlets
would be help helpful.
Regards, Dave Hodgins
[colin@jimmy cauldron-packages (master)]$ grep --include=*.spec -r
dconf[^a-z]
dconf/current/SPECS/dconf.spec:Obsoletes: %{_lib}dconf0
0.13.4
dconf/current/SPECS/dconf.spec:%{_mandir}/man?/dconf.*
dconf/current/SPECS/dconf.spec:%{_mandir}/man1/dconf-service.*
dconf/current/SPECS/dconf.spec:%{_libexecdir}/dconf-service
dconf/current/SPECS/dconf.spec:%{_datadir}/dbus-1/services/ca.desrt.dconf.service
dconf/current/SPECS/dconf.spec:%{_datadir}/glib-2.0/schemas/ca.desrt.dconf-editor.gschema.xml
dconf/current/SPECS/dconf.spec:%{_bindir}/dconf-editor
dconf/current/SPECS/dconf.spec:%{_mandir}/man1/dconf-editor.*
dconf/current/SPECS/dconf.spec:%{_datadir}/applications/dconf-editor.desktop
dconf/current/SPECS/dconf.spec:%{_datadir}/dconf-editor
dconf/current/SPECS/dconf.spec:%{_iconsdir}/hicolor/*/apps/dconf-editor.png
dconf/current/SPECS/dconf.spec:%{_libdir}/libdconf.so.%{major}*
dconf/current/SPECS/dconf.spec:%{_libdir}/libdconf-dbus-%{api}.so.%{dbusmajor}
dconf/current/SPECS/dconf.spec:%{_libdir}/libdconf-dbus-%{api}.so.%{dbusmajor}.*
dconf/current/SPECS/dconf.spec:%{_libdir}/libdconf.so
dconf/current/SPECS/dconf.spec:%{_libdir}/libdconf-dbus-1.so
dconf/current/SPECS/dconf.spec:%{_libdir}/pkgconfig/dconf.pc
dconf/current/SPECS/dconf.spec:%{_libdir}/pkgconfig/dconf-dbus-1.pc
dconf/current/SPECS/dconf.spec:%{_includedir}/dconf-dbus-1
dconf/current/SPECS/dconf.spec:%{_datadir}/vala/vapi/dconf*
onboard/current/SPECS/onboard.spec:BuildRequires: pkgconfig(dconf)
freeradius/current/SPECS/freeradius.spec:%{_bindir}/radconf2xml
gdm/current/SPECS/gdm.spec:# (cg) Setup dconf settings for gdm
gdm/current/SPECS/gdm.spec:dconf update
gdm/current/SPECS/gdm.spec:%{_sysconfdir}/dconf/profile/gdm
gdm/current/SPECS/gdm.spec:%ghost %{_sysconfdir}/dconf/db/%{name}
gdm/current/SPECS/gdm.spec:%dir %{_sysconfdir}/dconf/db/gdm.d
gdm/current/SPECS/gdm.spec:%{_sysconfdir}/dconf/db/gdm.d/00-upstream-settings
gdm/current/SPECS/gdm.spec:%dir %{_sysconfdir}/dconf/db/gdm.d/locks
gdm/current/SPECS/gdm.spec:%{_sysconfdir}/dconf/db/gdm.d/locks/00-upstream-settings-locks
gdm/current/SPECS/gdm.spec:touch %{buildroot}%{_sysconfdir}/dconf/db/%{name}
gnome-panel/current/SPECS/gnome-panel.spec:BuildRequires:
pkgconfig(dconf) = 0.13.4
ibus/current/SPECS/ibus.spec:BuildRequires: dconf-devel
ibus/current/SPECS/ibus.spec: --enable-dconf \
ibus/current/SPECS/ibus.spec:%{_sysconfdir}/dconf/db/ibus.d/00-upstream-settings
ibus/current/SPECS/ibus.spec:%{_sysconfdir}/dconf/profile/ibus
inn/current/SPECS/inn.spec:%attr(644,root,root)
%{_mandir}/man8/cnfsheadconf.8*
krb5/current/SPECS/krb5.spec:Patch16: krb5-1.10-buildconf.patch
php/current/SPECS/php.spec:./buildconf --force
sendfile/current/SPECS/sendfile.spec:%__install etc/{sfconf,sfdconf}
%buildroot/%_bindir/
apr-util/current/SPECS/apr-util.spec:# We need to re-run ./buildconf
because of any applied patch(es)
apr-util/current/SPECS/apr-util.spec:#./buildconf --with-apr=%{_prefix}
apr-util/current/SPECS/apr-util.spec:# buildconf is borked...
apr/current/SPECS/apr.spec:# We need to re-run ./buildconf because of
any applied patch(es)
apr/current/SPECS/apr.spec:# these are needed if apr-util is ./buildconf'ed
clusterscripts/current/SPECS/clusterscripts.spec:%{perl_vendorlib}/dhcpdconf_server_cluster.pm
clusterscripts/current/SPECS/clusterscripts.spec:%attr(755,root,root)
%{_bindir}/setup_dhcpdconf_server.pl
mpd/current/SPECS/mpd.spec:%doc README UPGRADING AUTHORS NEWS
doc/mpdconf.example doc/*.urpmi
sphinx/current/SPECS/sphinx.spec:sh ./buildconf.sh
ocaml-libaio/current/SPECS/ocaml-libaio.spec:make install
OCAMLFIND_INSTFLAGS=-ldconf ignore
--
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] Packagers meeting tonight (26/03/3013, 20h UTC)
'Twas brillig, and Pascal Terjan at 26/03/13 13:58 did gyre and gimble: On Tue, Mar 26, 2013 at 1:44 PM, Pierre-Malo Deniélou pierre-malo.denie...@rhul.ac.uk wrote: Hi all, There will be a packagers meeting tonight at 20h UTC as usual. Only one topic: - Release critical bugs: review and status Please all attend for progress to be made on these bugs. Reminder: https://bugs.mageia.org/buglist.cgi?bug_status=NEWbug_status=UNCONFIRMEDbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDpriority=release_blockerproduct=Mageiaquery_format=advancedversion=Cauldronorder=assigned_to%2Cbug_id%20DESCquery_based_on=release_blockerlist_id=2442 Can we also discuss what to do about http://check.mageia.org/cauldron/dependencies.html ? Should a thread be started for each to decide what to do about it? Bugs open? Any of those packages that doesn't get fixed will be dropped (as it can not be installed anyway) Note, mumble can be build without Ice support (I've submitted a build but for some reason I can't get the build deps right locally to test this seems I cannot install lib64db4.8-devel without it pulling in a whole bunch of i586 stuff - likely something to fix in that package too!) Note, pam_ldap should be nuked AFIUI. Drak tools has been updated to suggest pam_nss_ldap instead. - drakauth: o install nss-pam-ldapd instead of nss_ldap (mga#9375) However it seems pam_ldap remains when it should actually be dropped also... AFAUI, the nss_ldap+pam_ldap should be replced by the nss-pam-ldapd+sssd combo no? If so, then a further couple of tweaks are needed in drakauth methinks. 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] Packagers meeting tonight (26/03/3013, 20h UTC)
'Twas brillig, and Colin Guthrie at 26/03/13 14:21 did gyre and gimble: Can we also discuss what to do about http://check.mageia.org/cauldron/dependencies.html ? Should a thread be started for each to decide what to do about it? Bugs open? Any of those packages that doesn't get fixed will be dropped (as it can not be installed anyway) Note, mumble can be build without Ice support (I've submitted a build but for some reason I can't get the build deps right locally to test this seems I cannot install lib64db4.8-devel without it pulling in a whole bunch of i586 stuff - likely something to fix in that package too!) Yay, it builds, but I made it worse :D Due to the changed build options, mumble-server-web is no longer generated as a package. This will be removed magically after a while and the dep problem will disappear, but what should we do about installs? Should we Obsolete the package in the mumble-server package if that build option is set? It's not technically obsolete tho'. I guess users will get rpm conflicts and will be asked to remove the old mumble-server-web if they upgade mumble-server so perhaps this is all fine as it is? WDYT? 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] Last versions of programs concerning Computer Assisted Music
'Twas brillig, and PhilippeDidier at 26/03/13 23:24 did gyre and gimble:
+# Copy icons and mimetypes into the right folders
install -d -m 0755 %{buildroot}%{_iconsdir}
-cp -f %{buildroot}%{_datadir}/%{name}/icons/application-x-ardour_48px.png
%{buildroot}%{_iconsdir}/%{name}.png
+install -d -m 0755 %{buildroot}%{_iconsdir}/hicolor/16x16/apps
+install -d -m 0755 %{buildroot}%{_iconsdir}/hicolor/22x22/apps
+install -d -m 0755 %{buildroot}%{_iconsdir}/hicolor/32x32/apps
+install -d -m 0755 %{buildroot}%{_iconsdir}/hicolor/48x48/apps
+install -d -m 0755 %{buildroot}%{_iconsdir}/hicolor/16x16/mimetypes
+install -d -m 0755 %{buildroot}%{_iconsdir}/hicolor/22x22/mimetypes
+install -d -m 0755 %{buildroot}%{_iconsdir}/hicolor/32x32/mimetypes
+install -d -m 0755 %{buildroot}%{_iconsdir}/hicolor/48x48/mimetypes
+cp -f %{buildroot}%{_datadir}/%{name}/icons/application-x-ardour_16px.png \
+%{buildroot}%{_iconsdir}/hicolor/16x16/mimetypes/application-x-ardour3.png
+cp -f %{buildroot}%{_datadir}/%{name}/icons/application-x-ardour_22px.png \
+%{buildroot}%{_iconsdir}/hicolor/22x22/mimetypes/application-x-ardour3.png
+cp -f %{buildroot}%{_datadir}/%{name}/icons/application-x-ardour_32px.png \
+%{buildroot}%{_iconsdir}/hicolor/32x32/mimetypes/application-x-ardour3.png
+cp -f %{buildroot}%{_datadir}/%{name}/icons/application-x-ardour_48px.png \
+%{buildroot}%{_iconsdir}/hicolor/48x48/mimetypes/application-x-ardour3.png
+cp -f %{buildroot}%{_datadir}/%{name}/icons/ardour_icon_16px.png \
+%{buildroot}%{_iconsdir}/hicolor/16x16/apps/ardour3.png
+cp -f %{buildroot}%{_datadir}/%{name}/icons/ardour_icon_22px.png \
+%{buildroot}%{_iconsdir}/hicolor/22x22/apps/ardour3.png
+cp -f %{buildroot}%{_datadir}/%{name}/icons/ardour_icon_32px.png \
+%{buildroot}%{_iconsdir}/hicolor/32x32/apps/ardour3.png
+cp -f %{buildroot}%{_datadir}/%{name}/icons/ardour_icon_48px.png \
+%{buildroot}%{_iconsdir}/hicolor/48x48/apps/ardour3.png
FYI, these lines can be more neatly (IMO) done as:
install -D -p %{buildroot}%{_datadir}/%{name}/icons/ardour_icon_48px.png
%{buildroot}%{_iconsdir}/hicolor/48x48/apps/ardour3.png
(you can also add -m 0644 if you want to be specific about permission.
All that said, if the icons are being shipped already, why not just
symlink them rather than provide two copies? (in which case the install
-d lines should remain :D)
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] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Luca Olivetti at 24/03/13 16:02 did gyre and gimble: I performed the update under the Mageia 3 Upgrade Preparation and, since that had no graphical boot, the resulting new kernel also has no graphical boot. To restore it I had to manually run dracut once booted in mageia 3. Maybe I should have performed the update rebooting into the regular mageia 2? The wiki isn't clear about it. Yeah this is technically a bug! It just doens't copy across the vga= bit for some reason... another item on my TODO list methinks! 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/
[Mageia-dev] maven-dependency-tree (unsatisfied dep maven-artifact - cannot rebuild jetty)
Hiya, It seems we cannot submit jetty due to the fact that it needs maven-dependancy-tree which cannot be installed due to missing maven-artifact. Can you/someone take a look and submit jetty when it's all working? Cheers! 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] Freeze push :puppet
'Twas brillig, and Nicolas Lécureuil at 24/03/13 20:34 did gyre and gimble: please push puppet, this is a sec update. This won't work until the emacs-puppet and vim-puppet subpackages no longer conflict with puppet3. http://pkgsubmit.mageia.org/uploads/rejected//cauldron/core/release/20130324153428.colin.valstar.4845.youri I suggest renaming the puppet3 sub-packages or simply not shipping them in the puppet package if they are not really needed. 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] drakxtools drakx-installer-stage2 (mga#9428)
'Twas brillig, and Glen Ogilvie at 22/03/13 22:34 did gyre and gimble: Once this is figured out, I will happly update the Mageia wiki with details, which I think will be helpful for anyone wanting to make customised Mageia DVDs. Sounds good. I always go in circles trying to remember what to do when testing this stuff. I guess Thomas or Anne might be able to explain the rest. 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/
[Mageia-dev] HEADSUP: Full git clone of all package specs (with history)
Hi, Just to avoid a crazy amount of scripting with svn checkouts and such like, I've set running a git svn clone of the cauldron package subversion tree. It'll take a while to complete (likely about 24hrs in total by current estimates) and it should take up about 800MB (rough estimate) in total. When complete it will act as a handy source for doing full repository greps and such like. It will also be useful for making mass changes (git svn rebase and git svn dcommit are you friends). I'll endevour to make it available via a public clone when done, but due to it's size and nature it'll likely only appeal to a few people. Just thought I'd let you know. FWIW, I'll use this to add the necessary stuff to fix https://bugs.mageia.org/show_bug.cgi?id=9302 which requires finding several packages that use a specific macro and updating them. FAO: sysadm team. I'm using valstar for this as it's much closer network wise. Of course I stupidly still used svn+ssh rather than a direct file, thinking it would be more useful generally when moving it later, forgetting that I could probably just have editted the subversion URL after the clone was complete... but meh, it's done now and and it's almost half way through so no point in killing it half way through IMO. 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] drakxtools drakx-installer-stage2 (mga#9428)
'Twas brillig, and Glen Ogilvie at 22/03/13 11:20 did gyre and gimble: 2. When I've built a new stage2, any tricks on getting it into an ISO? I tend to have a urpmi-proxy setup and configure it to not check for updated stage2 (which is the default IIRC). I then just build the stage2 image and copy it to the urpmi-proxy. Then with a simply boot.iso, I point the http install to my server with urpmi-proxy installed and it download *my* stage2. That's how I generally test my modifications and seems quicker than building ISOs etc. 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] [soft-commits] [7587] do not build initrd if no bootloader is detected and --no-initd argument is supplied
'Twas brillig, and Thierry Vignaud at 21/03/13 23:16 did gyre and gimble: On 20 March 2013 00:26, r...@mageia.org wrote: Log Message do not build initrd if no bootloader is detected and --no-initd argument is supplied actually, that impacts installer too, so it should be in install/NEWS too... I wonder if I'll ever get this right :D Thanks for the ever watchful eye :) Added to the file for the next build (I'm sure there will be more to come :D) 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/
[Mageia-dev] drakrpm can no longer download packages
Hi, Since the updates recently, I can no longer use drakrpm to update packages. When trying to run MageiaUpdate it will happily show me a list of packages to update and then displays a Distribution Upgrade dialog and says it is downloading package xxx.rpm. This then fails. Console output: Fontconfig warning: /etc/fonts/conf.d/50-user.conf, line 9: reading configurations from ~/.fonts.conf is deprecated. getting lock on urpmi examining synthesis file [/var/lib/urpmi/synthesis.hdlist.CoreRelease-64.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.TaintedRelease-64.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.CoreRelease-32.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.TaintedRelease-32.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.MainRelease-Debug-64.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.NonFreeRelease-32.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.NonFreeRelease-64.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.TaintedRelease-Debug64.cz] unlocking urpmi database getting lock on urpmi getting exclusive lock on rpm retrieving rpm files from medium CoreRelease-64... Error: ...retrieving failed: Can't locate object method validate_cancel via package gurpm::RPMProgressDialog at /usr/lib/perl5/vendor_perl/5.16.3/Rpmdrake/pkg.pm line 205, $curl chunk 80. retrieving rpm files from medium CoreRelease-32... Error: ...retrieving failed: Can't locate object method validate_cancel via package gurpm::RPMProgressDialog at /usr/lib/perl5/vendor_perl/5.16.3/Rpmdrake/pkg.pm line 205, $curl chunk 80. unlocking urpmi database unlocking rpm database A few points: The Distribution update dialog stays in the way and looks kinda ugly when the error dialog pops up. It should really be dismissed. Running urpmi on the command line works fine. If I can provide any more info, please just ask. 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] Mageia3-B2 will no longer boot
'Twas brillig, and Maurice Batey at 20/03/13 22:03 did gyre and gimble: On my netbook, the bread-and-butter install is Mageia-2, but I have also been trying Mageia-3B2 to try to check out the Broadcom WiFi situation. Until the last Cauldron update I made 2 weeks ago, all has gone well, except the last time I used it was difficult to boot it, often needing 2-3 attempts. Today I checked again and it repeatedly failed to boot. (Mageia-2 still boots reliably.) When the Mageia-3B2 boot starts, it gets as far as 3 bubbles over the cauldron, then the screen goes blank, there is still a lot of disk activity for a few seconds, then nothing - even after 5 minutes. However , if I then tap the netbook's 'off' switch, momentarily I see a cauldron with *5* bubbles flash onto the screen before the screen dies from power-down. I could access the Mageia-3B2 install from Mageia-2 if anyone can suggest what settings might be usefully checked and/or changed. In the meantime my Mageia-3B2 is dead in the water... Have you tried switching to ctl+alt+f2 to see if you get a text login? Failing that, edit your kernel command line, and remove the quiet and splash options, and add systemd.log_level=debug systemd.log_target=console+journal Then see how far you get. It's likely waiting for something to complete, or some job had to be ejected due to initscript conflicts etc. 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] drakrpm can no longer download packages
'Twas brillig, and Barry Jackson at 20/03/13 22:00 did gyre and gimble: On 20/03/13 18:09, Thierry Vignaud wrote: On 20 March 2013 18:23, zezinho lists.jjo...@free.fr wrote: Em 20-03-2013 15:40, Colin Guthrie escreveu: Hi, Since the updates recently, I can no longer use drakrpm to update packages. +1, with the same error. real (wo)men rsync the full mirror then use rpmdrake to install local packages. just fixed anyway No change here with rpmdrake-5.42-2.mga3 1 installation transactions failed There was a problem during the installation: ...retrieving failed: Can't locate object method progress via package gurpm::RPMProgressDialog at /usr/lib/perl5/vendor_perl/5.16.3/Rpmdrake/pkg.pm line 216, $curl chunk 238. urpmi works OK Yup same here. Plus the Distribution Upgrade window still stays on screen and gets in the way of the other messages when they pop up after a failure (the other window cannot be raised above it). Cheers 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] USB Keyboard disabled in current stage1
'Twas brillig, and Frank Griffin at 19/03/13 15:25 did gyre and gimble: On 03/18/2013 10:20 AM, Colin Guthrie wrote: 'Twas brillig, and Frank Griffin at 18/03/13 13:49 did gyre and gimble: Trying a fresh install this morning (booting isolinux from grub), the select your install type curses menu comes up, but the keyboard is completely unresponsive. Perhaps stage1 is missing some kernel modules now that usb support on recent kernels split them up a bit. Here is the fix for that in dracut: http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=a28e2aeefec38f9118f36b3324e44d6a7d4fda7c I don't know the setup with stage1 enough to know if this is where the problem lies or not tho'. Problem still present in last night's installer upload... Were you able to try Thierry's suggestion? I don't see any significant changes: http://svnweb.mageia.org/soft/drakx/trunk/mdk-stage1/?view=log So it would still be interesting to know if the commit he mentioned (http://svnweb.mageia.org/soft?view=revisionsortby=daterevision=7542) is the one to blame for this. 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] USB Keyboard disabled in current stage1
'Twas brillig, and Frank Griffin at 18/03/13 13:49 did gyre and gimble: Trying a fresh install this morning (booting isolinux from grub), the select your install type curses menu comes up, but the keyboard is completely unresponsive. There's no problem with the keyboard itself, as it worked fine to navigate the grub menu to select isolinux. Isolinux gives the normal Detecting USB devices popup, but I suspect that it's not working, as the keyboard is USB. This is reinforced by the fact that the keyboard works perfectly booting the same isolinux in a VirtualBox VM. This was working OK on Mar 11 afternoon EST when I did the last install on this box. Perhaps stage1 is missing some kernel modules now that usb support on recent kernels split them up a bit. Here is the fix for that in dracut: http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=a28e2aeefec38f9118f36b3324e44d6a7d4fda7c I don't know the setup with stage1 enough to know if this is where the problem lies or not 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] [soft-commits] [7542] - fix loading modules with - in their names (mga#9242)
'Twas brillig, and AL13N at 15/03/13 06:50 did gyre and gimble: Op donderdag 14 maart 2013 21:25:15 schreef Thierry Vignaud: On 14 March 2013 20:29, AL13N al...@rmail.be wrote: - fix loading modules with - in their names (mga#9242) - add an easy buildtarget for testing A couple remarks: - next time do a commit a time (first your change, then bumping version) ah, ok, is there a reason for this (to have separate a change and then a version bump)? in order to have smaller easier to review commits. You really do not want to come on big old commits when trying to understand a problem. I hope you tested several modules with both case? yes, i tried with several. and since the xen-netfront modules aren't autodetected for some reason (i'm trying to look into it) b/c it has no pci/usb alias, only the following (which we do not look for) alias: xennet alias: xen:vif well, we don't know how to detect that. supposedly udev should give events to load that... but perhaps stage1 doesn't use udev? would you think it would be ok, to manually add such workaround code in stage1? For mga4 I hope I have the time to look into rebasing stage1 on dracut... not sure it is the right thing overall, but it would be nice to cut down on different things used in different places (assuming it doesn't cause any problems!). But, meh, we'll see how the time goes!! 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] Release critical bugs for Mageia 3
'Twas brillig, and Johnny A. Solbu at 15/03/13 16:02 did gyre and gimble: On Friday 15. March 2013 15.26, Anne Nicolas wrote: So here is a review of these bugs: https://docs.google.com/spreadsheet/ccc?key=0Ao3phYOTRNeQdEEtSjBSSWkxTmdIcmJZcGtfYjN1NVEusp=sharing Really!? So now we need to register at Google in order to help develop Mageia? (I'm asked to login in order to see it) What's wrong with the wiki, a html file or a plain old text file? We've used Google docs before for similar things - I used it a lot before for tracking service migrations because I wanted people to update the document, which they did. It's just convenient to use such a tool sometimes. Also a huge amount of interaction and collaboration these days is enabled via Google+. I can understand you not wanting a Google account, but it's a very important vector for me these days - critical I would say. Anyway if that's not good for you then no worries, a friendly request to copy/paste the info somewhere else would have been sufficient. 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] Freeze push policycoreutils
'Twas brillig, and Thomas Spuhler at 13/03/13 03:10 did gyre and gimble: On Tuesday, March 12, 2013 12:56:36 PM Guillaume Rousse wrote: Le 12/03/2013 18:24, Thomas Spuhler a écrit : On Tuesday, March 12, 2013 10:04:32 AM Guillaume Rousse wrote: Le 12/03/2013 18:03, Thomas Spuhler a écrit : Please push policycoreutils the previous version doesn't build It builds locally. Missing source file: error: File /var/lib/schedbot/repsys/tmp/tmpsmMaee/SOURCES/sepolgen-1.1.9.tgz: No such file or directory fixed. Sorry about this Submission error: - policycoreutils-2.1.14-1.mga3: - non-standard-group System Environment/Base Never heard of rpmlint ? Missed (updating) those. I didn't touch them and rpmlint flags them as warnings. They should have gone through. No, they are rejected. Lots of warning cases in rpmlint are considered errors for package uploads. To be fair tho', I've never found that running rpmlint actually helps me work out what would go through or not... 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] bogus packages that provides fonts-ttf-dejavu
'Twas brillig, and Thierry Vignaud at 12/03/13 21:33 did gyre and gimble: Hi As seen in bug #8820 (https://bugs.mageia.org/show_bug.cgi?id=8820), some packages bogusly package DejaVu fonts instead of requiring fonts-ttf-dejavu. This makes them bogusly provide 'font(XX)' (eg: 'font(fr)' which breaks urpmi since perl-URPM will only show arched packages when there's both arched nonarch packages providing the same provides $ urpmf DejaVuSans.ttf|grep -v fonts-ttf|sed -e 's!:.*!!'|sort -u ... None of those should do this. All these packages should be fixed to require fonts-ttf-dejavu instead of packaging. I wonder if these packages will break if they simply remove the fonts. Perhaps the packaging should be such that they symlink the fonts to the folder they expect them to be in also? Or perhaps, alternatively, whatever is responsible for the automatic font(XX) provides should only look at files in /usr/share/fonts/ and not in any other folders. That would presumably also solve the problem (assuming the packages listed are just rebuilt. 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] Freeze push policycoreutils
'Twas brillig, and Johnny A. Solbu at 13/03/13 09:50 did gyre and gimble: On Wednesday 13. March 2013 10.19, Colin Guthrie wrote: No, they are rejected. Lots of warning cases in rpmlint are considered errors for package uploads. Then perhaps warnings that is rejected in the build system should be changed to errors, so packagers can know what they need to fix before submitting. Yup, I think this has been mentioned before too. FWIW the config for what is actually rejected by youri on upload is here: http://svnweb.mageia.org/adm/puppet/modules/buildsystem/templates/youri/submit-upload.conf?view=markup#l176 Certainly the way packages are checked and validated is something we could make better. 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/
[Mageia-dev] RFC: Patch e2fsprogs to not print the clean message on fsck.
Hi,
I would like to propose that we push a patch to e2fsprogs to make it not
print out the clean message when it checks the filesystem.
In my current boot (which is an experiment without initrds), it prints
this message over the top of plymouth and stays during the nice fade
transition to gdm and generally makes the boot ugly.
I believe only the e2fsprogs print this message and the others do not
e.g. see this comparison with XFS:
[root@jimmy ~]# dd if=/dev/zero of=xfs.img bs=1M count=100 /dev/null
21; mkfs.xfs xfs.img /dev/null 21; xfs_check xfs.img
[root@jimmy ~]# dd if=/dev/zero of=ext4.img bs=1M count=100 /dev/null
21; mkfs.ext4 -F ext4.img /dev/null 21; fsck.ext4 -a ext4.img
ext4.img: clean, 11/25688 files, 8896/102400 blocks
My patch would propose to not print the clean message when the -a
option was passed. This is similar logic which prevents showing the
version when -a is passed.
I've not tested this but I will before committing if no-one disapproves
of this approach.
--- e2fsprogs-1.42.7/e2fsck/unix.c.orig 2013-03-13 10:57:22.349126868 +
+++ e2fsprogs-1.42.7/e2fsck/unix.c 2013-03-13 12:33:08.340522834 +
@@ -421,13 +421,14 @@
}
/* Print the summary message when we're skipping a full check */
- log_out(ctx, _(%s: clean, %u/%u files, %llu/%llu blocks),
- ctx-device_name,
- fs-super-s_inodes_count - fs-super-s_free_inodes_count,
- fs-super-s_inodes_count,
- ext2fs_blocks_count(fs-super) -
- ext2fs_free_blocks_count(fs-super),
- ext2fs_blocks_count(fs-super));
+ if (!(ctx-options E2F_OPT_PREEN))
+ log_out(ctx, _(%s: clean, %u/%u files, %llu/%llu blocks),
+ ctx-device_name,
+ fs-super-s_inodes_count -
fs-super-s_free_inodes_count,
+ fs-super-s_inodes_count,
+ ext2fs_blocks_count(fs-super) -
+ ext2fs_free_blocks_count(fs-super),
+ ext2fs_blocks_count(fs-super));
next_check = 10;
if (fs-super-s_max_mnt_count 0) {
next_check = fs-super-s_max_mnt_count -
fs-super-s_mnt_count;
--
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] RFC: Patch e2fsprogs to not print the clean message on fsck.
'Twas brillig, and Colin Guthrie at 13/03/13 12:35 did gyre and gimble:
Hi,
I would like to propose that we push a patch to e2fsprogs to make it not
print out the clean message when it checks the filesystem.
In my current boot (which is an experiment without initrds), it prints
this message over the top of plymouth and stays during the nice fade
transition to gdm and generally makes the boot ugly.
I believe only the e2fsprogs print this message and the others do not
e.g. see this comparison with XFS:
[root@jimmy ~]# dd if=/dev/zero of=xfs.img bs=1M count=100 /dev/null
21; mkfs.xfs xfs.img /dev/null 21; xfs_check xfs.img
[root@jimmy ~]# dd if=/dev/zero of=ext4.img bs=1M count=100 /dev/null
21; mkfs.ext4 -F ext4.img /dev/null 21; fsck.ext4 -a ext4.img
ext4.img: clean, 11/25688 files, 8896/102400 blocks
My patch would propose to not print the clean message when the -a
option was passed. This is similar logic which prevents showing the
version when -a is passed.
I've not tested this but I will before committing if no-one disapproves
of this approach.
--- e2fsprogs-1.42.7/e2fsck/unix.c.orig 2013-03-13 10:57:22.349126868
+
+++ e2fsprogs-1.42.7/e2fsck/unix.c2013-03-13 12:33:08.340522834 +
@@ -421,13 +421,14 @@
}
/* Print the summary message when we're skipping a full check */
- log_out(ctx, _(%s: clean, %u/%u files, %llu/%llu blocks),
- ctx-device_name,
- fs-super-s_inodes_count - fs-super-s_free_inodes_count,
- fs-super-s_inodes_count,
- ext2fs_blocks_count(fs-super) -
- ext2fs_free_blocks_count(fs-super),
- ext2fs_blocks_count(fs-super));
+ if (!(ctx-options E2F_OPT_PREEN))
+ log_out(ctx, _(%s: clean, %u/%u files, %llu/%llu blocks),
+ ctx-device_name,
+ fs-super-s_inodes_count -
fs-super-s_free_inodes_count,
+ fs-super-s_inodes_count,
+ ext2fs_blocks_count(fs-super) -
+ ext2fs_free_blocks_count(fs-super),
+ ext2fs_blocks_count(fs-super));
next_check = 10;
if (fs-super-s_max_mnt_count 0) {
next_check = fs-super-s_max_mnt_count -
fs-super-s_mnt_count;
FWIW, this patch is a bit wrong (as it still prints out a newline and
some other fluff about when the next check is etc.) and it causes a test
to fail.
But an updated and tested patch fixes it up. If there are no complaints,
I'll push it.
Cheers
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] No package named nss_ldap
'Twas brillig, and R James at 13/03/13 21:48 did gyre and gimble: I'd like to test LDAP client authentication hit a roadblock: [root@localhost ~]# urpmi pam_ldap A requested package cannot be installed: pam_ldap-186-4.mga3.x86_64 (due to unsatisfied nss_ldap[= 217]) Continue installation anyway? (Y/n) n [root@localhost ~]# urpmq -y nss_ldap No package named nss_ldap I'm using mirrors.kernel.org http://mirrors.kernel.org (core + nonfree) which is usually fresh. Is this a work-in-progress issue or shall I file a bug report? It's been reported before, but basically the solution is to not use nss_ldap or pam_ldap but alternative packages nss-pam-ldapd and sssd. See the previous thread nss-ldap missing from 7th Feb. I set a machine up with these pkgs not that long ago. We do still need to update our tools to cope 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] No package named nss_ldap
'Twas brillig, and Olivier Blin at 13/03/13 23:55 did gyre and gimble: Colin Guthrie mag...@colin.guthr.ie writes: 'Twas brillig, and R James at 13/03/13 21:48 did gyre and gimble: I'd like to test LDAP client authentication hit a roadblock: [root@localhost ~]# urpmi pam_ldap A requested package cannot be installed: pam_ldap-186-4.mga3.x86_64 (due to unsatisfied nss_ldap[= 217]) Continue installation anyway? (Y/n) n [...] It's been reported before, but basically the solution is to not use nss_ldap or pam_ldap but alternative packages nss-pam-ldapd and sssd. Shouldn't we drop pam_ldap then? Yup that too. 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] bogus packages that provides fonts-ttf-dejavu
'Twas brillig, and Luc Menut at 13/03/13 23:39 did gyre and gimble: Le 13/03/2013 10:25, Colin Guthrie a écrit : [...] Or perhaps, alternatively, whatever is responsible for the automatic font(XX) provides should only look at files in /usr/share/fonts/ and not in any other folders. It's already the case. eg. urpmq -l briquolo |grep ttf /usr/share/doc/briquolo/DejaVuSans.ttf-LICENSE /usr/share/games/briquolo/data/DejaVuSans.ttf urpmq --provides briquolo briquolo[== 0.5.7-6.mga3] briquolo(x86-64)[== 0.5.7-6.mga3] Hmm, so I'm not really sure I understand the problem reported then 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] cyrus-imapd
'Twas brillig, and Thomas Spuhler at 12/03/13 14:57 did gyre and gimble: On Tuesday, February 26, 2013 11:38:57 AM you wrote: Hiya Thomas, Firstly, thanks for taking time to update cyrus-imapd a while back. It's a horrible package with lots of gotchas. Sadly, I've just recently been bitten by fallout due to some of the many dropped patches when you updated the package to the 2.4 series in this commit: http://svnweb.mageia.org/packages/cauldron/cyrus-imapd/current/SPECS/cyrus- imapd.spec?r1=130115r2=196262 What the commit message said was: upgrade to 2.4.13 Unfortunately, this is really no where near enough information for the, very brutal changes that were introduced in that commit. 14 patches were disabled! That's a lot to go unmentioned! In my case some of the patches were very important - namely the autocreate and autosieve patches which are an important part of my setup. I don't add users very often but today I spent a long time trying to debug why my new user's mailbox didn't just work as it always has in the past. As I investigated the issue I saw this cleanup patch: http://svnweb.mageia.org/packages/cauldron/cyrus-imapd/current/SPECS/cyrus- imapd.spec?r1=259043r2=259168 Sadly this just compounded the above problem, and all the patch files themselves still remained in the SOURCES folder. As this is needed functionality for my setup (and likely other users too), I've taken the time today to investigate all the dropped patches and find replacements/updates where appropriate and drop those ones committed (or which have alternative fixes) upstream. Please can you take a look over the changes: http://svnweb.mageia.org/packages?view=revisionrevision=400402 http://svnweb.mageia.org/packages?view=revisionrevision=400404 As you'll see it took a little time and I documented all the changes as clearly as I could (I would have done it in individual commits but that isn't really easy with subversion - no ability to stage changes and I was too lazy to use git-svn here). The rmquota patch is still disabled, but only two others are slightly concerning now. The rest either still applied or had appropriate upstream fixes. Finally, I notice you made this change: http://svnweb.mageia.org/packages/cauldron/cyrus-imapd/current/SPECS/cyrus- imapd.spec?r1=389214r2=394129 In theory, this is what one of the patches you disabled should deal with. It silenced the user_deny.db verbosity. Sadly when rediffing the patch it seems the latest version has refactored that code. I cannot find anywhere where this message would be printed now (I see the error on mga2 tho'). Can you confirm if this change is really needed or if it was added after looking at the mga2 package rather than the current code? Cheers Col Colin, do you have a working cyrus-imapd? does lmtptest provide anything else than a connection refused message? In cauldron or on mga2? I have it working happily via mga2 after backporting all the fixes. It seems lmtptest is trying to connect via localhost which on my system is not running - my setup uses unix sockets to communicate over lmtp (as is the default I believe). For my setup this is the /var/lib/imap/socket/lmtp socket. 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] EFI/GPT
'Twas brillig, and Oliver Burger at 01/03/13 18:47 did gyre and gimble: Hi there, I have a question here in the german forums from ixsoft - a company selling linux based operating systems and much open source and linux related stuff. Do we have support for EFI/GPT in Mga3? Bernd Hentig from ixsoft says something about GPT partitions and EFI (without the secure boot stuff). I have not looked into that topic at all until now and don't know anything about it. Can anyone help me? Perhaps it would be good for someone with knowledge about that topic to contact Bernd himself. ixsoft is a major player in that field in Germany... Just to add a bit to what Thomas has already said, I'm currently running cauldron via UEFI+GPT partions without an initrd (using root=PARTUUID=x rootfstype=ext4 on kernel cmdline). /boot is my EFI partition which is FAT32 and thus doesn't support symlinks which some of our tools assume is allowed and thus need updating (e.g. for symlinking the config and the default initrds and kernel to nice names) I would generally promote this approach although care needs to be taken to lock down the permissions/mount options on the /boot partition such that regular users cannot read/write data on it - only root. This is easy enough to do, but something in drakx helpfully adds a permissive umask option to it - we'll need to fix that and perhaps add a special case for a fat32 /boot if it's detected. Oh and I'm using gummiboot as the actual bootloader. 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] Why is AHCI statically compiled into kernel?
'Twas brillig, and R James at 05/03/13 16:20 did gyre and gimble: I remember when PATA (IDE) drivers were statically compiled into the kernel, then we went to modular IDE which I liked because modprobe ordering could be controlled. (When dealing with parity RAID, its nice to have logical drive enumeration because SATA ports don't have UUID labels.) Anything that relies on ordering is just broken by design. We need to handle things gracefully regardless of the order they are detected. This is why UUIDs are the defacto method for filesystem identification these days and why in mga4 we'll likely switch to a consistent naming scheme for networking devices too. Also modprobe ordering is increasingly not true either as many modules are automatically loaded when the hardware is present. 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/
[Mageia-dev] cyrus-imapd
Hiya Thomas, Firstly, thanks for taking time to update cyrus-imapd a while back. It's a horrible package with lots of gotchas. Sadly, I've just recently been bitten by fallout due to some of the many dropped patches when you updated the package to the 2.4 series in this commit: http://svnweb.mageia.org/packages/cauldron/cyrus-imapd/current/SPECS/cyrus-imapd.spec?r1=130115r2=196262 What the commit message said was: upgrade to 2.4.13 Unfortunately, this is really no where near enough information for the, very brutal changes that were introduced in that commit. 14 patches were disabled! That's a lot to go unmentioned! In my case some of the patches were very important - namely the autocreate and autosieve patches which are an important part of my setup. I don't add users very often but today I spent a long time trying to debug why my new user's mailbox didn't just work as it always has in the past. As I investigated the issue I saw this cleanup patch: http://svnweb.mageia.org/packages/cauldron/cyrus-imapd/current/SPECS/cyrus-imapd.spec?r1=259043r2=259168 Sadly this just compounded the above problem, and all the patch files themselves still remained in the SOURCES folder. As this is needed functionality for my setup (and likely other users too), I've taken the time today to investigate all the dropped patches and find replacements/updates where appropriate and drop those ones committed (or which have alternative fixes) upstream. Please can you take a look over the changes: http://svnweb.mageia.org/packages?view=revisionrevision=400402 http://svnweb.mageia.org/packages?view=revisionrevision=400404 As you'll see it took a little time and I documented all the changes as clearly as I could (I would have done it in individual commits but that isn't really easy with subversion - no ability to stage changes and I was too lazy to use git-svn here). The rmquota patch is still disabled, but only two others are slightly concerning now. The rest either still applied or had appropriate upstream fixes. Finally, I notice you made this change: http://svnweb.mageia.org/packages/cauldron/cyrus-imapd/current/SPECS/cyrus-imapd.spec?r1=389214r2=394129 In theory, this is what one of the patches you disabled should deal with. It silenced the user_deny.db verbosity. Sadly when rediffing the patch it seems the latest version has refactored that code. I cannot find anywhere where this message would be printed now (I see the error on mga2 tho'). Can you confirm if this change is really needed or if it was added after looking at the mga2 package rather than the current code? Cheers 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] Nouveau nvidia vesa conflict
'Twas brillig, and zezinho at 25/02/13 15:10 did gyre and gimble: Em 24-02-2013 21:20, Thomas Backlund escreveu: So just install that one, regenerate the initrd and reboot. Would it be a bad idea that dracut install triggers by itself a initrd rebuild? Well, consider when this problem was introduced rather than when it was fixed it would have then actively *broken* your initrd's rather than fixing them. It's also a much bigger problem overall. The initrd copies binaries and libraries from your running system to create the initrd. You could argue that replacing any one of those components should also trigger a rebuild... Don't get me wrong, I think we should likely put some kind of infrastructure in place to make this easier, but I also don't want to see several initrd rebuilds during an upgrade. It's better to do it once, right at the end, but I don't think we really have any kind of post-everything kind of trigger we can use for that. FWIW, looking at how the kernel is packaged and how initrds are generated (or not) is on my todo list (hopefully with Thomas' support/input) for MGA4). In an ideal world we'd simply skip initrds for systems that don't need them (I've very deliberately configured my new laptop in a way that it shouldn't need an initrd for exactly this reason). 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] Gnome mess in Mageia SVN...
'Twas brillig, and Sebastian at 24/02/13 20:59 did gyre and gimble: I don't think Mageia providing GNOME 3.8 with the new classic mode made using extensions, rather than the old fall back mode, would cause loads of problems: http://worldofgnome.org/gnome-classic-not-classic-all/ The issue is not to do with the code itself, but generally to do with how well the rendering stuff works on older hardware without 3D acceleration capabilities. This requires the use of LLVM Pipe IIRC, but I've not investigated this. That said, I'm personally more than happy to discuss the options again, provided we enter it knowing all the potential problems. 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] Gnome mess in Mageia SVN...
'Twas brillig, and Olav Vitters at 21/02/13 09:08 did gyre and gimble: So you are making the same mess for upcoming mga3, that is also in mga2 updates svn, making everyone elses work harder, when svn does not match what's on mirrors... this is painful for QA and security maintenance... Apologies for trying to provide a new GNOME as requested _on_my_own_ and not finishing it. Not what I wanted, but not done on purpose. Mistakes happen. But we do need to ensure things are tidied up properly with appropriate svn revprops to silence the old commit messages to prevent them making it into built RPM changelogs. Automated scripts can be ok during open cauldron, but _never_ when we try to stabilize for a release. Meanwhile, Mageia 3 keeps getting delayed and delayed and not due to me. No, but that's hardly relevant here. You were involved in the general decision for 3.6 in mga3. If you would like to propose a change to that, that's fine - it can be discussed, but it's not really the right thread to do that on. So ... once again... please kill the script, clean up svn, revert packages to latest stable, and try to focus on providing a good / fully updated Gnome 3.6 will be available for Mga3. I rather take a break from Mageia. Please don't! We obviously value your work, but it would be really amazing if you could be a little more careful with the automated stuff especially at this stage and put more time into the polishing. It's what we all have to do - it's not always fun, but it's part of the process. And I hate these personal email habits. CC'ing mageia-dev. That's fine. I presume Thomas just wanted to let you know in private rather than posting something perhaps evocative on the public list. Sometimes it's better for people to get such mails in private because it then avoids them being embarrassed by a bug or mistake. Obviously in this case, you prefer it to be in public and that is fine :) Please keep up the good work. But yeah, please also kill the script for the time being while freeze is in effect :D 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] System doen't boot with LVM
'Twas brillig, and Colin Guthrie at 20/02/13 23:19 did gyre and gimble: 'Twas brillig, and Olivier Thauvin at 20/02/13 20:13 did gyre and gimble: * Colin Guthrie (mag...@colin.guthr.ie) wrote: 'Twas brillig, and Olivier Thauvin at 20/02/13 18:13 did gyre and gimble: * Colin Guthrie (mag...@colin.guthr.ie) wrote: Iirc I replaced for_each_host_dev_and_slaves by for_each_host_dev_and_slaves_all. Honestly I don't understand what it change... Hope this help. Yes, that helps a lot. I'm not sure why it makes a difference (considering my own setup here is at least partially similar to yours), but I'll definitely dig into it more. Can you describe the LVM setup? i.e. how the lvm sits on top of the physical disks etc? I really want to try and reproduce the issue so I can make a good upstream explanation of the problem with the patch. Sure, my disk is a SSD: Device Boot Start End Blocks Id System /dev/sda1 63 80324 40131 de Dell Utility /dev/sda2 * 81920 1622015 7700487 HPFS/NTFS/exFAT /dev/sda3 1622016 124499967614389767 HPFS/NTFS/exFAT /dev/sda4 124502016 500105215 1878016005 Extended /dev/sda5 124506112 125547974 520931+ 83 Linux /dev/sda6 125550592 500103449 187276429 8e Linux LVM /dev/sda5 = /boot /dev/sda6 = the whole lvm [root@localhost foo]# lvs LVVG Attr LSize Pool Origin Data% Move Log Copy% Convert crypt sagittarius -wi-ao--- 141,01g root sagittarius -wi-ao--- 12,77g swap sagittarius -wi-ao--- 3,91g tmp sagittarius -wi-ao--- 3,00g var sagittarius -wi-ao--- 1,95g the crypt lv is my /home: /dev/mapper/crypt_sagittarius_crypt on /home type ext4 (rw,noatime,commit=600,data=ordered) Don't hesitate if you need more output, especially device and dm number. I can produce debug output of dracut too if necessary. If you could supply debug output when generating initrd both with the packaged version and your patched version that would be very useful and may allow me to avoid having to exactly duplicate the setup!! Actually no need for debug output. I spoke to Harald upstream and he reckoned your change is indeed correct and required. I'll patch our package shortly. Thank you very much for debugging this and being so patient :) 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] NetworkManager 0.9.8
'Twas brillig, and Maurice Batey at 21/02/13 13:02 did gyre and gimble: Is there any move towards using NM as *the* network manager for Mageia? Not sure about the for Mageia bit, but overall most of the distros seem to use it and the DEs have nice integration. That said, I think there is still too much churn in this space to say that NM will be the winner long term. It certainly stands a good chance right now, but I'll reserve judgement for the next year or two. Regarding the static network configs (which is still something people want, especially for e.g. servers where a UI focused system is not really needed), which are soon to be pretty much the only role of the initscripts package, these will eventually be migrated to systemd. Work on this has not yet started as there is a lot of cross distro divergence in this area and coming down on a standard way of configuring things that will work for all the distros will take some time. 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] System doen't boot with LVM
'Twas brillig, and Colin Guthrie at 21/02/13 11:08 did gyre and gimble: 'Twas brillig, and Colin Guthrie at 20/02/13 23:19 did gyre and gimble: 'Twas brillig, and Olivier Thauvin at 20/02/13 20:13 did gyre and gimble: * Colin Guthrie (mag...@colin.guthr.ie) wrote: 'Twas brillig, and Olivier Thauvin at 20/02/13 18:13 did gyre and gimble: * Colin Guthrie (mag...@colin.guthr.ie) wrote: Iirc I replaced for_each_host_dev_and_slaves by for_each_host_dev_and_slaves_all. Honestly I don't understand what it change... Hope this help. Yes, that helps a lot. I'm not sure why it makes a difference (considering my own setup here is at least partially similar to yours), but I'll definitely dig into it more. Can you describe the LVM setup? i.e. how the lvm sits on top of the physical disks etc? I really want to try and reproduce the issue so I can make a good upstream explanation of the problem with the patch. Sure, my disk is a SSD: Device Boot Start End Blocks Id System /dev/sda1 63 80324 40131 de Dell Utility /dev/sda2 * 81920 1622015 7700487 HPFS/NTFS/exFAT /dev/sda3 1622016 124499967614389767 HPFS/NTFS/exFAT /dev/sda4 124502016 500105215 1878016005 Extended /dev/sda5 124506112 125547974 520931+ 83 Linux /dev/sda6 125550592 500103449 187276429 8e Linux LVM /dev/sda5 = /boot /dev/sda6 = the whole lvm [root@localhost foo]# lvs LVVG Attr LSize Pool Origin Data% Move Log Copy% Convert crypt sagittarius -wi-ao--- 141,01g root sagittarius -wi-ao--- 12,77g swap sagittarius -wi-ao--- 3,91g tmp sagittarius -wi-ao--- 3,00g var sagittarius -wi-ao--- 1,95g the crypt lv is my /home: /dev/mapper/crypt_sagittarius_crypt on /home type ext4 (rw,noatime,commit=600,data=ordered) Don't hesitate if you need more output, especially device and dm number. I can produce debug output of dracut too if necessary. If you could supply debug output when generating initrd both with the packaged version and your patched version that would be very useful and may allow me to avoid having to exactly duplicate the setup!! Actually no need for debug output. I spoke to Harald upstream and he reckoned your change is indeed correct and required. I'll patch our package shortly. Thank you very much for debugging this and being so patient :) commit 7d4d3f8da624ccc27798b01fdd0f3c594267f53a (HEAD, origin/master, origin/HEAD, master) Author: Harald Hoyer harald@... Date: Thu Feb 21 12:07:34 2013 +0100 lvm/module-setup.sh: use for_each_host_dev_and_slaves_all Use for_each_host_dev_and_slaves_all to get all lvm setups for the host-only case. Thanks to Olivier Thauvin Available soon in dracut-025-4.mga3. Thanks again! 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] Gnome mess in Mageia SVN...
'Twas brillig, and Olav Vitters at 21/02/13 14:45 did gyre and gimble: On Thu, Feb 21, 2013 at 10:08:40AM +, Colin Guthrie wrote: 'Twas brillig, and Olav Vitters at 21/02/13 09:08 did gyre and gimble: So you are making the same mess for upcoming mga3, that is also in mga2 updates svn, making everyone elses work harder, when svn does not match what's on mirrors... this is painful for QA and security maintenance... Apologies for trying to provide a new GNOME as requested _on_my_own_ and not finishing it. Not what I wanted, but not done on purpose. Mistakes happen. But we do need to ensure things are tidied up properly with appropriate svn revprops to silence the old commit messages to prevent them making it into built RPM changelogs. Mistakes are pointed out bluntly and assigned a task, when I ask for help (M2 GNOME update) I get silence. I must have missed that email. I'd be happy to help out a bit in this area, tho' I don't really have any mga2 machines running DE's to test on :( Can you point out the mail? Perhaps I can still do something to help? I wonder how we could attract more Gnome, erm, gnomes :) to help with packaging? 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] Why ntpdate still there?
'Twas brillig, and Colin Guthrie at 11/02/13 14:55 did gyre and gimble: 'Twas brillig, and Pierre Jarillon at 11/02/13 14:23 did gyre and gimble: Le lundi 11 février 2013 13:18:23, Colin Guthrie a écrit : So ntpdate as a service is just a one-shot thing, it happens once at boot to ensure the clocks are properly set and then ntpd takes over for the rest of the time that machine stays up. As far as I'm aware, there is nothing integrated into crontab regarding ntpdate, but please feel free to correct me on that one. Yes, this was the old system. I am not an expert in ntp, but I have read carefully http://ntp.org few years ago and I return on it now and then. I can miss something... I am not the truth! On the web site http://www.ntp.org/ -Implementation Documentation http://www.eecis.udel.edu/~mills/ntp/html/ntpdate.html said: Disclaimer: The functionality of this program is now available in the ntpd program. See the -q command line option in the ntpd - Network Time Protocol (NTP) daemon page. After a suitable period of mourning, the ntpdate program is to be retired from this distribution And http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html and the man tell us: -q Exit the ntpd just after the first time the clock is set. This behavior mimics that of the ntpdate program, which is to be retired. The -g and -x options can be used with this option. Note: The kernel time discipline is disabled with this option. -g Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options. See the tinker command for other options. The same options are set in the man of ntp. IMO, ntpdate should be replaced with: ntpd -gq Yup that would be fine. I don't understand why ntpdate is listed as an active daemon in drakxservices. This is simply because of the fact that drakxservices doesn't really grok the kind of granularity you want here. See the direct output from e.g. systemctl status ntpdate.service vs. systemctl status ntpd.service (hint: compare active (exited) vs active (running)) For the former, it's a oneshot and as it has been run and it ran successfully, it's is thus considered active. Really we should teach drakxservices to present that properly: e.g. show it as Completed or something, rather than Active In /etc/sysconfig/ntpd : - Mageia 1 : OPTIONS=-u ntp:ntp -p /var/run/ntpd.pid - Mageia 2 : OPTIONS=-g - Mageia 3 : OPTIONS=-g Then it seems that ntpdate is no longer useful since Mageia 2. Yes indeed. It seems the -g option passed there makes the separate ntpdate service obsolete. It basically gives ntpd a one-chance option to do a big jump, which is basically what we were achieving with that double unit setup. I'll kill off the ntpdate stuff. Many thanks for poking into this :) Hmm, actually, I'm not sure the -g argument is sensible to pass to the daemon process generally. It seems that if it cannot reach a server (i.e. no networking) then the daemon exits. Certainly that is what I've seen here. Also, running ntpd -qg here with a large skew seems to not actually work here :s [root@jimmy ~]# systemctl stop ntpd.service [root@jimmy ~]# date Thu 21 Feb 18:02:19 GMT 2013 [root@jimmy ~]# date Thu 21 Feb 18:02:23 GMT 2013 [root@jimmy ~]# ntpd -qg ntpd: time slew +0.00s [root@jimmy ~]# ntpdate pool.ntp.org 21 Feb 23:02:53 ntpdate[7741]: step time server 149.5.113.103 offset 18004.588317 sec [root@jimmy ~]# ntpd -qg ntpd: time slew +0.00s [root@jimmy ~]# systemctl start ntpd.service So perhaps we should restore the previous setup? 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] System doen't boot with LVM
'Twas brillig, and Olivier Thauvin at 20/02/13 18:13 did gyre and gimble:
* Colin Guthrie (mag...@colin.guthr.ie) wrote:
If it does fail then ultimately the problem will be in:
/usr/lib/dracut/modules.d/90lvm/module-setup.sh (or one of the utility
functions it uses). It should use udevadm info to query the system
about LVM info. You can add debug to the check_lvm function and then
re-run dracut -f foo.img again to see where it bails out.
If, however, it works fine on your running system then perhaps the
problem is with the installer lacking some udev rules to properly
capture all the needed metadata in udev database. This will require a
bit more fiddling (i.e. running udevadm info in the installer to look at
the properties it exports about the devices).
I did reproduced the issue.
By changing the end of check() function in
/usr/lib/dracut/modules.d/90lvm/module-setup.sh by this:
[[ $hostonly ]] || [[ $mount_needs ]] {
for_each_host_dev_and_slaves_all check_lvm || return 1
}
I got:
# cat ./etc/cmdline.d/90lvm.conf
rd.lvm.lv=sagittarius/swap
rd.lvm.lv=sagittarius/root
Iirc I replaced for_each_host_dev_and_slaves by
for_each_host_dev_and_slaves_all.
Honestly I don't understand what it change...
Hope this help.
Yes, that helps a lot.
I'm not sure why it makes a difference (considering my own setup here is
at least partially similar to yours), but I'll definitely dig into it more.
Can you describe the LVM setup? i.e. how the lvm sits on top of the
physical disks etc? I really want to try and reproduce the issue so I
can make a good upstream explanation of the problem with the patch.
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] System doen't boot with LVM
'Twas brillig, and Olivier Thauvin at 20/02/13 20:13 did gyre and gimble: * Colin Guthrie (mag...@colin.guthr.ie) wrote: 'Twas brillig, and Olivier Thauvin at 20/02/13 18:13 did gyre and gimble: * Colin Guthrie (mag...@colin.guthr.ie) wrote: Iirc I replaced for_each_host_dev_and_slaves by for_each_host_dev_and_slaves_all. Honestly I don't understand what it change... Hope this help. Yes, that helps a lot. I'm not sure why it makes a difference (considering my own setup here is at least partially similar to yours), but I'll definitely dig into it more. Can you describe the LVM setup? i.e. how the lvm sits on top of the physical disks etc? I really want to try and reproduce the issue so I can make a good upstream explanation of the problem with the patch. Sure, my disk is a SSD: Device Boot Start End Blocks Id System /dev/sda1 63 80324 40131 de Dell Utility /dev/sda2 * 81920 1622015 7700487 HPFS/NTFS/exFAT /dev/sda3 1622016 124499967614389767 HPFS/NTFS/exFAT /dev/sda4 124502016 500105215 1878016005 Extended /dev/sda5 124506112 125547974 520931+ 83 Linux /dev/sda6 125550592 500103449 187276429 8e Linux LVM /dev/sda5 = /boot /dev/sda6 = the whole lvm [root@localhost foo]# lvs LVVG Attr LSize Pool Origin Data% Move Log Copy% Convert crypt sagittarius -wi-ao--- 141,01g root sagittarius -wi-ao--- 12,77g swap sagittarius -wi-ao--- 3,91g tmp sagittarius -wi-ao--- 3,00g var sagittarius -wi-ao--- 1,95g the crypt lv is my /home: /dev/mapper/crypt_sagittarius_crypt on /home type ext4 (rw,noatime,commit=600,data=ordered) Don't hesitate if you need more output, especially device and dm number. I can produce debug output of dracut too if necessary. If you could supply debug output when generating initrd both with the packaged version and your patched version that would be very useful and may allow me to avoid having to exactly duplicate the setup!! Cheers 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] Fail2Ban vs Blockhosts vs DenyHosts vs iptable throttle for SSH
'Twas brillig, and Robert Fox at 19/02/13 11:45 did gyre and gimble: On Tue, 2013-02-19 at 12:35 +0100, Guillaume Rousse wrote: Le 19/02/2013 12:20, fi...@linuxbsdos.com a écrit : If that's how you feel about having a program like DenyHosts running by default, do you feel the same way about having a firewall running and configured out of the box. Is a firewall a sysadmin's or packager's choice? A sysadmin choice. Pushing always more stuff 'by default' doesn't help users to make educated choices. On one hand I agree, on the other hand - we want a distribution which simply works and common choices are made (like which firewall) from the distro side - a good enough Sysadmin can then change to his/her liking afterwards. This is more or less a distro philosophy question, but look why Mint has become so popular - because many choices are made upfront for the user - yet the flexibility is in the system (and enough packages) for an advanced user to change them! As long as the default settings are documented upfront - I see no issue in making such a decision on behalf of the average user - and making a more security robust distribution. Yup, I agree with this. I'm know my way around sufficiently that I can happily change the stuff I don't like. I think we do have to pick reasonably sensible defaults. Ultimately that's what msec does too - defines sensible defaults for the security level picked. So overall I'd welcome a default setup that allows things to be more secure/robust by default (obviously balanced against user experience - e.g. a *very* secure setup would be to ban all traffic in or out... but that's not a nice user experience :D). 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] Fail2Ban vs Blockhosts vs DenyHosts vs iptable throttle for SSH
'Twas brillig, and fi...@linuxbsdos.com at 19/02/13 12:44 did gyre and gimble: On 2013-02-19 12:13, Colin Guthrie wrote: So overall I'd welcome a default setup that allows things to be more secure/robust by default (obviously balanced against user experience - e.g. a *very* secure setup would be to ban all traffic in or out... but that's not a nice user experience :D). If you are referring to a firewall, banning all traffic in or out does not make sense. Yes... that's why I used it as an example of something that didn't make sense ;) -- 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] System doen't boot with LVM
'Twas brillig, and Olivier Thauvin at 18/02/13 11:19 did gyre and gimble: I rebooted my laptop this morning and it failed to boot: unable to find my / under lvm. Freshly updated cauldron booted fine for me this morning under LVM. I did try to do a fresh cauldron result but got same result. Apparently there are some issues doing an LVM install at present: https://bugs.mageia.org/show_bug.cgi?id=9032 Likely in some capacity an issue with lvm+udev (the linked bugs are likely not the same cause). Dracut gi a shell, It seems 'lvm vgmknodes' has no effect (the swap lv did existed already). In the dracut shell, what does /etc/cmdline.d/lvm.conf say? It should contain enough info to brink up both the root and the swap lvm. Note that the swap lvm is included thanks to the file 51-mageia-resume.conf (to handle the resume= case where swap is on LVM), but the root FS detection is built into dracut, so if it's entry is missing in the cmdline.d file then dracut itself is where the bug lies. Which version of dracut did you use to create the initrd used here? If it was dracut-025.1 then I think this is understandable as there was a bug related to something similar relating to encrypted filesystems (it didn't affect me here with pure LVM (no crypt), so it may not be the issue you have) If it's still a problem with dracut-025.3 then I'll need to look further. As mentioned, problem fixed seemed to manifest itself more with the fact that the encryption module wasn't included, but if you have an encrypted root (or the LVM is on an encrypted volume) then I can see this causing problems (due to not detecting the encrypted volume, it won't then traverse it to find any slaves needed for it and thus never get to the LVM parent) and the 025.3 dracut should fix it (at least in theory, tho' I would not rule out any other problems in this regard! So some more info about when the initrd was generated and when the latest dracut version was installed would be useful to debug this further. Also a description of your disk layout would be good too allow me to create a similar setup for debugging. Cheers :) 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] System doen't boot with LVM
'Twas brillig, and Olivier Thauvin at 18/02/13 12:48 did gyre and gimble: So ok, I just update my freshly installed mga2 to cauldron using network install (live upgrade don't work, it seems urpmi fail to find a way to update the system w/o filesystem). I have the exact same result: it don't boot. Hmm, re: live upgrade are you meaning just a urpmi based upgrade? If so, I've done a few similar updates in the last week or so in VMs and it's always been OK. I presume you installed the mageia-prepare-upgrade package from mga2/core/updates_testing, rebooted to the boot menu entry created by that package before upgrading? If so, please detail the process you went through and at which point if failed so I can debug this process more. I've not had many complaints about it, and it's worked for a variety of different filesystems structures for me, so I'm surprised it's failing here. Regarding the network install based upgrade there may be issues relating to bootloader config tools (in drakx) that related the use of the blkid cache which might make it miss the whole LVM volume (I've seen it manifest itself as putting root=/dev/ into grubs menu.lst rather than root=/dev/mapper/foo). I've fixed the calls in drakxtools, but it'll need a release to propagate it through to stage2 used there which I don't think has been done yet. I'll try and prep that tonight. * Colin Guthrie (mag...@colin.guthr.ie) wrote: Dracut gi a shell, It seems 'lvm vgmknodes' has no effect (the swap lv did existed already). In the dracut shell, what does /etc/cmdline.d/lvm.conf say? It should contain enough info to brink up both the root and the swap lvm. rd.lvm.lv=sagittarius/swap OK, so this basically means that only the swap partition is configured to be activated in the initrd (which is also what you observe so at least it's behaving at that level!) The problem is that dracut itself is not detecting that the LV needs activating when it runs. In order to get a booting system, just pass rd.lvm.lv=sagitarius/slash on the command line (obviously substituting the real name of your logical volume). This should make dracut initialise the lvm automatically. You should (at least in theory) also just be able to type something like lvm vgchange -ay into the dracut shell, then type exit (perhaps twice) to continue the boot process. Of course if your grub menu entry has been messed up (root=/dev/) then you'll need to fix that up too. Hopefully that should get you booting. 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] System doen't boot with LVM
'Twas brillig, and Olivier Thauvin at 18/02/13 14:55 did gyre and gimble: * Colin Guthrie (mag...@colin.guthr.ie) wrote: 'Twas brillig, and Olivier Thauvin at 18/02/13 12:48 did gyre and gimble: So ok, I just update my freshly installed mga2 to cauldron using network install (live upgrade don't work, it seems urpmi fail to find a way to update the system w/o filesystem). I have the exact same result: it don't boot. Hmm, re: live upgrade are you meaning just a urpmi based upgrade? If so, I've done a few similar updates in the last week or so in VMs and it's always been OK. I presume you installed the mageia-prepare-upgrade package from mga2/core/updates_testing, rebooted to the boot menu entry created by that package before upgrading? Ha, no, I followed the howto on the wiki: https://wiki.mageia.org/en/Feature:UsrMove and there is no reference to this package on the page :\ Yeah, I noticed that too this morning :s I'll update it (I could have sworn I had already, but I guess not - it was posted about quite a lot on the list but that's fairly transient and no excuse for my general failure to update the wiki!). The mageia-prepare-upgrade package is just a nice wrapper around those commands anyway, so you should be 99% OK with those commands all the same (although they certainly are more complicated than they now need to be - they were originally written for cauldron users during the transition process rather than a clean mga2-mga3, so this explains where there are urpmi commands with skip etc. in them. I think the time is such that I can remove some of that detail from the page - the number of cauldron users running pre-usrmove must be ~= 0 by now :) Regarding the network install based upgrade there may be issues relating to bootloader config tools (in drakx) that related the use of the blkid cache which might make it miss the whole LVM volume (I've seen it manifest itself as putting root=/dev/ into grubs menu.lst rather than root=/dev/mapper/foo). The entry in grub is fine (just checked it). Good :) In the dracut shell, what does /etc/cmdline.d/lvm.conf say? It should contain enough info to brink up both the root and the swap lvm. rd.lvm.lv=sagittarius/swap The problem is that dracut itself is not detecting that the LV needs activating when it runs. In order to get a booting system, just pass rd.lvm.lv=sagitarius/slash on the command line (obviously substituting the real name of your logical volume). This should make dracut initialise the lvm automatically. This method did work and I am now under linux. Yay! Lucky that the 51-mageia-resume.conf file caused the lvm module to be included in the first place otherwise the initrd wouldn't have the lvm command in it at all :D What can I do to understand why dracut did not detect the lvm to activate properly (and hopefully fix this definitivelly) ? Basically, the best bet is to run something like the following (as root): dracut -f foo.img mkdir foo cd foo zcat ../foo.img | cpio -id cat etc/cmdline.d/lvm.conf This should test whether your / lvm has been detected in addition to the swap one. I sort of hope that this fails, otherwise the problem will be harder to nail down!! If it does fail then ultimately the problem will be in: /usr/lib/dracut/modules.d/90lvm/module-setup.sh (or one of the utility functions it uses). It should use udevadm info to query the system about LVM info. You can add debug to the check_lvm function and then re-run dracut -f foo.img again to see where it bails out. If, however, it works fine on your running system then perhaps the problem is with the installer lacking some udev rules to properly capture all the needed metadata in udev database. This will require a bit more fiddling (i.e. running udevadm info in the installer to look at the properties it exports about the devices). You should (at least in theory) also just be able to type something like lvm vgchange -ay into the dracut shell, then type exit (perhaps twice) to continue the boot process. This has work except I was unable to enter my passphrase to read my encrypted /home. Ahh yes, the lvm vgchange -ay is a bit of a enable everything command (normally the initrd only initialises what it absolutely must - e.g. /, /usr and swap for resume= support). I guess it might mess up the passphrase stuff later on as a knock on effect, but really /home (and any passphrase needed for it) should be the domain of the booted system rather than the initrd (in theory!) But it's good to know this is posible. Yeah. the lvm command is only included if dracut detects lvm as being needed. In your current example it was somewhat fortunate that your swap was on LVM and the 51-mageia-resume.conf file detailed that. This 51-mageia-resume.conf is a bit of a hack really... I should likely find a nicer way to do it without hard-coded configs :) Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic
Re: [Mageia-dev] Changelog screwed on updates?
'Twas brillig, and Luca Olivetti at 14/02/13 09:18 did gyre and gimble: I was checking the changelog to see what changed in the last update and I see that the previous revision message went missing (actually, it got conflated in the last changelog), i.e: on a box without the latest update: - Notice how the 1.1.mga2 release is missing but its messages are under the 1.2mga2 release. I think this is just the long standing issue with markrelease tags on updates tree (or rather the lack of such tags) 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] [soft-commits] [7324] (call_blkid) always bypass blkid cache
'Twas brillig, and Pascal Terjan at 14/02/13 14:34 did gyre and gimble: Please add a comment in the code :) Done. I just said to look at the commit message tho' rather than copy paste everything :) 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] Freeze push: liblastfm
'Twas brillig, and David Walser at 12/02/13 00:19 did gyre and gimble: On a side note: if anyone has a subscription for last.fm now, it would be nice if you could build the lastfm-player that Götz updated in SVN and test that, so it could be pushed too. Listening to it since last week. There are a few niggles, but that's mostly upstream related (e.g. it's not as good at recovering from problems i.e. after the network is ripped out from under it, and it doesn't autoplay the last station on restart like the old player - the option is there but it's greyed out so might have to look into that one!). But overall I like it and I think it's worth pushing all the same. 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] created as .rpmnew lies?
'Twas brillig, and EatDirt at 12/02/13 10:06 did gyre and gimble: Within today update of cauldron: 7/232: Default-kde4-config ### warning: /var/lib/mageia/kde4-profiles/Default/share/config/kdm/kdmrc created as /var/lib/mageia/kde4-profiles/Default/share/config/kdm/kdmrc.rpmnew Now if I go to that directory, I see this is not the case: ls -trl total 80 -rw-r--r-- 1 root root 347 May 21 2011 backgroundrc -rw-r--r-- 1 root root 21677 Jun 6 2012 kdmrc.rpmsave drwxr-xr-x 3 root root 4096 Feb 6 22:29 themes/ -rw-r--r-- 1 root root 21689 Feb 12 11:02 kdmrc.ccpbackup -rw-r--r-- 1 root root 21630 Feb 12 11:02 kdmrc It has been created as kdmrc, with a rpmsave. It seems we have a problem in between the message and what is actually done? No, I think the file itself is indeed created as a .rpmnew at the time RPM prints that message. In the spec: http://svnweb.mageia.org/packages/cauldron/mageia-kde4-config/current/SPECS/mageia-kde4-config.spec?revision=397256view=markup#l117 we use the ccp program to merge the .rpmnew config to the current config (i.e. merging in your customisations to the new file, such that new comments and directives are present). This has the effect of subsequently deleting the .rpmnew file (although creating the kdmrc.ccpbackup file). Thus it's doing everything correctly, even if the use of ccp can result in the rpmnew warnings being misleading. I suspect the .rpmsave is a relic from previous package updates a while back. 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] Why ntpdate still there?
'Twas brillig, and Pierre Jarillon at 11/02/13 11:19 did gyre and gimble: ntpdate is no longer necessary because ntpd includes all functions necessary to set the clock. Use of ntpdate in crontab is a very bad idea because a great number of users can make a burst of activity and a saturation of servers. ntpd is more accurate with few requests and can also setup the clock. ntpd makes requests after a long time. More the clock is adjusted, more it waits before a new request. In man ntpdate, we can see: Disclaimer: The functionality of this program is now available in the ntpd program. See the -q command line option in the ntpd - Network Time Protocol (NTP) daemon page. After a suitable period of mourning, the ntpdate program is to be retired from this distribution. ntpdate and ntp are active in drakxservices... IMO, this is a nonsense. ntpdate is a service that is run prior to ntpd itself. This was done previously to ensure the time was set correctly due to a (deliberate) limitation in ntpd itself which did not change the clock when large jumps were involved. It attempts to keep the change continuous and avoids large jumps. See this section from the man page: Under ordinary conditions, ntpd slews the clock so that the time is effectively continuous and never runs backwards. If due to extreme network congestion an error spike exceeds the step threshold, by default 128 ms, the spike is discarded. However, if the error persists for more than the stepout threshold, by default 900 s, the system clock is stepped to the correct value. In practice the need for a step has is extremely rare and almost always the result of a hardware failure. With the -x option the step threshold is increased to 600 s. Other options are available using the tinker command on the Miscellaneous Options page. The issues should be carefully considered before using these options. The maximum slew rate possible is limited to 500 parts-per-million (PPM) by the Unix kernel. As a result, the clock can take 2000 s for each second the clock is outside the acceptable range. During this interval the clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time. So ntpdate as a service is just a one-shot thing, it happens once at boot to ensure the clocks are properly set and then ntpd takes over for the rest of the time that machine stays up. As far as I'm aware, there is nothing integrated into crontab regarding ntpdate, but please feel free to correct me on that one. 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] Why ntpdate still there?
'Twas brillig, and Johnny A. Solbu at 11/02/13 12:57 did gyre and gimble: On Monday 11. February 2013 12.19, Pierre Jarillon wrote: Use of ntpdate in crontab is a very bad idea because a great number of users can make a burst of activity and a saturation of servers. Then don't use it in crontab. ntpd is more accurate with few requests and can also setup the clock. ntpd makes requests after a long time. More the clock is adjusted, more it waits before a new request. I have a few setups where running an ntp daemon is undesired, yet I need to periodically manually set the clock. I have two laptops which is off most of the time, and when I do use them I don't always have a network connection. So I need to set the clock manually using ntpdate when I do have a connection. If it disappears I will miss it, and most likely look for a replacement, if there is one. I did mean to (but forgot) switch us to use crony by default as it's better for offline drift compensation and such like. I'll try and remember for mga4 as it's likely too late for mga3. 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] Why ntpdate still there?
'Twas brillig, and Pierre Jarillon at 11/02/13 14:34 did gyre and gimble: Le lundi 11 février 2013 13:57:52, Johnny A. Solbu a écrit : I have a few setups where running an ntp daemon is undesired, yet I need to periodically manually set the clock. I have two laptops which is off most of the time, and when I do use them I don't always have a network connection. So I need to set the clock manually using ntpdate when I do have a connection. If it disappears I will miss it, and most likely look for a replacement, if there is one. According my reply to Colin, ntpd -g does the same job than ntpdate. The option -g is now used by default in /etc/sysconfig/ntpd Perhaps a script ntpdate executing `ntpd -g` could be useful? I have also a question about ntp-wait : I have read its code (perl) but I don't understand what is its use. In theory it's meant to wait until the time is stable, and holds up time-sync.target accordingly. Thus any other systemd unit that is ordered After=time-sync.target will be delayed until after ntp-wait has exited. time-sync.target is meant to be a generic name and thus any units that need such ordering should use it and not ntp-wait.service directly (other ntp implementations may achieve the same result, but with different units). I'm not overly sure we actually have anything ordered after time-sync.target anyway, but that's why it exists (to the best of my understanding anyway) 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] [RFC] rsyslog vs journalctl
'Twas brillig, and eatdirt at 09/02/13 15:18 did gyre and gimble: Are you sure that there still is a problem? There were some bugs that have been fixed months ago. Aside from that the memory usage could be off as journal uses mmap. But systemd always uses the journal (not runtime configurable IIRC), so best to make it efficient. It should also somehow be low maintenance. Meaning: maybe it will use less memory when there is less available (guessing)? I don't know about mmap, but that's what a top gives on the current cooker: 326 root 1 0 1064m 37m 36m S0 1.9 0:14.73 systemd-journal even though it is only virtual, that's sound crazy to go up 1GB. rsyslog never goes above 1M. The virtual size is more or less irrelevant for judging how much memory it actually uses. In some cases it does help identify some leaks (tho' not classic memory leaks - more mmap leaks - found and fixed one of those a while back). It is a little higher than I'd expect all the same tho'. I'll double check that no regressions have snuck in on the mmap window caching stuff. 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] GNOME apps
'Twas brillig, and David Walser at 09/02/13 22:51 did gyre and gimble: tmb recently requested that the vinagre, vino, and eog apps (currently development 3.7 versions) be rolled back to the stable versions. This sounds sensible to me, but what is the plan for GNOME for Mageia 3? I had been under the impression that we would stick with 3.6, but Sebastian insisted on IRC that the Council had decided to go with 3.8. I don't know how that would work as it would mean it would be updated at the last minute and not tested. FWIW, I was under the imporession we would be sticking with 3.6. There are some changes in 3.8 that might make it a bit tricker to use it (i.e. what to do with fallback support etc.) without further testing and support (e.g. ensuring the llvm rendering works well enough on older h/w) Will be interesting to see if this situation has changed (in general I like the idea of 3.8 being pushed, but perhaps this should be done later as an update should there be a general consensus on that). 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] [RFC] rsyslog vs journalctl
'Twas brillig, and AL13N at 07/02/13 18:40 did gyre and gimble: Op donderdag 7 februari 2013 13:34:06 schreef Colin Guthrie: 'Twas brillig, and AL13N at 07/02/13 11:40 did gyre and gimble: [...] what about the tty12 bug? can this be fixed with journald? it seems to be a feature that people don't want to lose? Not sure. I'll find out. It should be trivial really... i.e. all it really needs is a journalctl -f command run on tty12. You could craft an agetty command that worked like that easily enough, although there may be something more elegant that is more efficient and cleaner. since the tty12 feature is present now, it would be nice if it could still be there and started as soon as possible, just like before. Just to try it, can you set: TTYPath=/dev/tty12 ForwardToConsole=yes in /etc/systemd/journald.conf I'm not 100% sure whether it really should be available by default tho'. I mean, if you are a logged in user you cannot view the system logs unless you are in the adm group or root. Why should you just be able to see it via switching to a tty? Seems somewhat counter intuitive to me. Of course you could say that if someone has physical access then all bets are off anyway... but IMO it does still seem slightly juxtaposed. Thoughts welcome on whether: a) This should be off by default (as now - but change from classic syslog) b) We should default it to on. c) We should provide an easy to use ticky box to turn it off/on easily via GUI. Regardless, we should probably configure all syslogs to not do this by default (as it will class if it's enabled in the journal). Thoughts? 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] [RFC] rsyslog vs journalctl
'Twas brillig, and AL13N at 07/02/13 18:43 did gyre and gimble: Op donderdag 7 februari 2013 15:10:43 schreef Guillaume Rousse: Le 07/02/2013 14:40, Colin Guthrie a écrit : Is anyone against the name system-logger? If so I'll update things accordingly. Other name suggestions welcome. Fine with me. that's fine. i just mentioned this because iirc lennart at his talk in FOSDEM said that journald didn't do remote syslogging Yup, for remote syslogging you still want a syslog. There are various things you can do with the journal remotely (e.g. you can mount remote journals via NFS to a single machine and then read all the logs in via the -m command to journalctl, or you can use the journal gatewayd to get a nice web interface to the logs on remote machines. There will be further efforts to do networking with the journal, but due to the fact it carries a lot more metadata than plain syslog, it cannot go directly via syslog protocol anyway. But yeah, if you want remote syslog logging, just install rsyslog or similar :) 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] [RFC] rsyslog vs journalctl
'Twas brillig, and Guillaume Rousse at 08/02/13 10:06 did gyre and gimble: Le 07/02/2013 19:40, AL13N a écrit : Op donderdag 7 februari 2013 13:34:06 schreef Colin Guthrie: 'Twas brillig, and AL13N at 07/02/13 11:40 did gyre and gimble: [...] what about the tty12 bug? can this be fixed with journald? it seems to be a feature that people don't want to lose? Not sure. I'll find out. It should be trivial really... i.e. all it really needs is a journalctl -f command run on tty12. You could craft an agetty command that worked like that easily enough, although there may be something more elegant that is more efficient and cleaner. since the tty12 feature is present now, it would be nice if it could still be there and started as soon as possible, just like before. I'd like tough than journald be reloaded if the host name change. That's a bit painful to get logs for 'localhost' just because the name was set after starting log system. Restarting journald is not a great idea if you can avoid it. At present it doesn't yet support a full reexec mode which preserves file descriptors which are connected to it thus some apps may lose their logging depending on how they are connected to it. Also I'm not sure what you mean... if I change my hostname, it's reflected properly in the journal. Does this not happen on your system? Perhaps some configuration probme with nss-myhostname (tho' not 100% that matters)? 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/
[Mageia-dev] Logging + Provides/Requires (Re: [RFC] rsyslog vs journalctl)
'Twas brillig, and AL13N at 07/02/13 18:43 did gyre and gimble: Op donderdag 7 februari 2013 15:10:43 schreef Guillaume Rousse: Le 07/02/2013 14:40, Colin Guthrie a écrit : Is anyone against the name system-logger? If so I'll update things accordingly. Other name suggestions welcome. Fine with me. that's fine. OK, so before I make the changes can we decide on the general process: Q) Will we make persistent disk-based journals optional? Yes: Makes it harder to ask a consistent question to extract debug. No: Some people will moan. To counter the no we can just say: Just do 'rm -rf /var/log/journal' and do that again if we issue updates to the systemd package. Not crazy elegant, but at least then it's the exception rather than the rule. Anyway, the reason I ask this question is that because basesystem requires systemd, and as systemd would be the package providing system-logger, there hardly seems any point in adding system-logger in the first place. It would only really make sense if we made it optional. In all other cases where apps don't strictly need a syslog (i.e. fail2ban may be an exception), they should probably just drop the requires on syslog-daemon. It's not like you could boot it without systemd anyway ;) So what do you think now? Yes or no for forcing disk-based journal logs? 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] [RFC] rsyslog vs journalctl
'Twas brillig, and Pascal Terjan at 08/02/13 10:33 did gyre and gimble: On Fri, Feb 8, 2013 at 10:31 AM, Pascal Terjan pter...@gmail.com wrote: On Fri, Feb 8, 2013 at 9:54 AM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and AL13N at 07/02/13 18:40 did gyre and gimble: Op donderdag 7 februari 2013 13:34:06 schreef Colin Guthrie: 'Twas brillig, and AL13N at 07/02/13 11:40 did gyre and gimble: [...] what about the tty12 bug? can this be fixed with journald? it seems to be a feature that people don't want to lose? Not sure. I'll find out. It should be trivial really... i.e. all it really needs is a journalctl -f command run on tty12. You could craft an agetty command that worked like that easily enough, although there may be something more elegant that is more efficient and cleaner. since the tty12 feature is present now, it would be nice if it could still be there and started as soon as possible, just like before. Just to try it, can you set: TTYPath=/dev/tty12 ForwardToConsole=yes in /etc/systemd/journald.conf I'm not 100% sure whether it really should be available by default tho'. I mean, if you are a logged in user you cannot view the system logs unless you are in the adm group or root. Why should you just be able to see it via switching to a tty? Seems somewhat counter intuitive to me. I think it used to be enabled or not by msec depending on security level /usr/share/msec/plugins/msec.py:def enable_console_log(self, arg, expr='*.*', dev='tty12'): A, OK, so perhaps just some tweakage there could do the trick... 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] Logging + Provides/Requires (Re: [RFC] rsyslog vs journalctl)
'Twas brillig, and Anne Nicolas at 08/02/13 13:07 did gyre and gimble: Le 08/02/2013 13:14, Olav Vitters a écrit : On Fri, Feb 08, 2013 at 10:31:42AM +, Colin Guthrie wrote: Q) Will we make persistent disk-based journals optional? Yes: Makes it harder to ask a consistent question to extract debug. No: Some people will moan. It is either persistent logging or logging in memory right? I assume people won't understand that it'll log anyways, just in memory. So no point in giving an option that does not do what people might expect. Just one point about this. It was said during meeting that having journalctl by default could break some other software like fail2ban. This should be checked. Yes this is pretty much the issue I'm trying to address really. e.g. basesystem package already requires systemd, so there is little point in it requiring syslog-daemon too as this is always satisified by systemd at present. My proposal was originally to add a new dep system-logger and allow systemd to satify that. In the process I would remove the dep from various packages that currently have it (cronie, postfix) as systemd is now a required component anyway and journald will capture their logs happily. The final part would be identifying packages, like fail2ban, which parse these logs and therefore do genuinely need something to satisfy syslog-daemon requires. In the future, fail2ban will have direct journal integration (posted the link earlier) and thus we can drop the dep when the time comes. So, I think what I'll do for now, is basically: 1. Forget about system-logger provide/require. It's not needed. 2. Make systemd not provide syslog-daemon. 3. Drop syslog-daemon require from basesystem* pkgs. 4. Drop syslog-daemon require from cronie and postfix (and others where it's not strictly needed any more). 5. Ensure fail2ban does have a require. 6. Start writing some docs here and there about it. Feel free to chime in on points 4 5 (I'm too stupid to know the right urpm* commands to work out what pkgs currently require syslog-daemon to evaluate if they really do need it. Also if people can think of any other log parsers like fail2ban, please let me know so we can make sure they have the right requires. Cheers 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] dhclient lease files location
'Twas brillig, and Guillaume Rousse at 07/02/13 08:37 did gyre and gimble: I'm taking this out of bugzilla for larger visibility: https://bugs.mageia.org/show_bug.cgi?id=8391 Initiallly (mageia2), we had both dhcpd (the server) and dhclient (guess what?) use a shared directory (/var/lib/dhcp), belonging to dhcp-common package, to store their lease file. And I had this bugreport about dhclient trying to store under a non-existent /var/lib/dhclient directory. I modified the dhcp package as in Fedora, to have each part (client/server) use their own, self-provided, state directory to store their lease file: /var/lib/dhcpd and /var/lib/dhclient. I expected to fix the issue, and making life easier by mimicating fedora setup. Then Dave reported he now had the same error message as before, but with the old directory: dhclient tries to store lease files under no more existent /var/lib/dhcp directory... I grepped /etc for occurences of '/var/lib/dhcp', without results. I had a look in networkmanager sources, which seems to be the culprit. It once used C macro NM_DHCLIENT_STATE_DIRECTORY for this purpose, but not anymore. Now, according to current code, it should uses its own state directory (/var/lib/NetworkManager) to store those files, but that's obviously not the case. And I'm myself having lease files in both directories (/var/lib/dhclient and /var/lib/dhcp). I'm suspecting a mix of hardcoded or default configuration between dhcp (the package), networkmanager and initscripts, but I can't figure where exactly. If someone with more knowledge of those deep arcanes could help, I'd be very grateful. Certainly here with my NM launched dhclient processes, it passes the -lf /var/lib/dhcp/dhclient-$FOO-eth0.lease argument to it. What is also strange however is that NM doesn't build for me here. Seems this was due to a commit by Olav to update it to 0.9.7.995 http://svnweb.mageia.org/packages?view=revisionrevision=388631 http://svnweb.mageia.org/packages/cauldron/networkmanager/current/SPECS/networkmanager.spec?r1=388631r2=388630pathrev=388631 Interestingly the commit message is SILENT: undo version change. Not quite sure what to make of that. Can you elaborate on the version change Olav? Perhaps I missed a mail somewhere asking for help rediffing a patch or something? My memory is buggy :p Anyway, going back to the 0.9.6.4 version (which is what is available as built) and I find this via a quick grep: [colin@jimmy NetworkManager-0.9.6.4]$ grep -rn --exclude=*.po \.lease ChangeLog:19635:dhclient with -lf /var/lib/dhcp/dhclient-%s.leases. src/dhcp-manager/nm-dhcp-dhclient.c:95: return g_strdup_printf (%s/dhclient%s-%s-%s.lease, This uses NM_DHCLIENT_LEASE_DIR which is different to what you mentioned above. This appears to be the code in question: #if defined(TARGET_DEBIAN) || defined(TARGET_SUSE) || defined(TARGET_MANDRIVA) #if defined(DHCLIENT_V3) #define NM_DHCLIENT_LEASE_DIR LOCALSTATEDIR /lib/dhcp3 #else #define NM_DHCLIENT_LEASE_DIR LOCALSTATEDIR /lib/dhcp #endif #else #define NM_DHCLIENT_LEASE_DIR LOCALSTATEDIR /lib/dhclient #endif I presume just removing the || defined(TARGET_MANDRIVA) bit of the first #if condition should do the trick. I'd like to see what Olav had in mind with that commit first tho'. Seems there are a few changes in NM that will mean we have to refactor things a bit (it should use NMSTATEDIR in the newer code like you say and thus be in it's own directory). 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] [RFC] rsyslog vs journalctl
'Twas brillig, and David Walser at 06/02/13 18:28 did gyre and gimble: Colin Guthrie mageia@... writes: Oh, for the avoidance of doubt, I don't think there is any argument that would suggest the removal from the repositories or obsoletion of rsyslog or syslog-ng etc. I agree, and that's consistent with what you've said in the past. I thought it was odd that the idea of obsoleting them came up yesterday in the packager meeting, but it did. The main reason was wanting to know if rsyslog should still be on the DVD, in case of users using it to upgrade from Mageia 2. It may be the case that not upgrading that particular package during the DVD upgrade won't *break* anything and it can just be upgraded after the system is booted and urpmi sources are added, in which case it doesn't *need* to be on the DVD. Otherwise, we should make sure it's on there. What I guess we could to to avoid putting rsyslog on the physical media would be to put a versioned conflicts in the main systemd package with rsyslog and syslog-ng. Thus the old packages should be removed when upgrading (AIUI). 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] [RFC] rsyslog vs journalctl
'Twas brillig, and Guillaume Rousse at 07/02/13 12:20 did gyre and gimble: Le 07/02/2013 12:40, AL13N a écrit : 'Twas brillig, and David Walser at 06/02/13 18:28 did gyre and gimble: [...] What I guess we could to to avoid putting rsyslog on the physical media would be to put a versioned conflicts in the main systemd package with rsyslog and syslog-ng. Thus the old packages should be removed when upgrading (AIUI). not a really good idea imho, i have a server which uses rsyslog for network remote syslogging... so upgrading that would break this. Indeed. Just because journal is installed (no choice here) shouldn't prevent to install a real syslog-daemon. I'd rather introduce another virtual package, such as syslog-daemon-minimal (or anything else), and lower the dependencies of basesystem to just require this last one. I'm not really sure what that gains... i.e. that's that's effectively what we have right now with the current provides of syslog-daemon via systemd itself. Arguably the semantics are wrong... e.g. it should really be called system-logger or something more generic. But as things stand you no longer *need* to install rsyslog et al - it's just an option. And as things stand right now, if rsyslog is included in the media it will be upgraded happily and keep on running. 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] [RFC] rsyslog vs journalctl
'Twas brillig, and AL13N at 07/02/13 11:40 did gyre and gimble: 'Twas brillig, and David Walser at 06/02/13 18:28 did gyre and gimble: [...] What I guess we could to to avoid putting rsyslog on the physical media would be to put a versioned conflicts in the main systemd package with rsyslog and syslog-ng. Thus the old packages should be removed when upgrading (AIUI). not a really good idea imho, i have a server which uses rsyslog for network remote syslogging... so upgrading that would break this. Only if you upgrade without a network connection. Like I say this suggestion would only cover the cases where there was a desire to remove rsyslog from the physical media (to make room for other stuff). It's only an option tho'. I'm not suggesting it's a solution or not. what about the tty12 bug? can this be fixed with journald? it seems to be a feature that people don't want to lose? Not sure. I'll find out. It should be trivial really... i.e. all it really needs is a journalctl -f command run on tty12. You could craft an agetty command that worked like that easily enough, although there may be something more elegant that is more efficient and cleaner. 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] grub2 package update announcement
'Twas brillig, and Jose Jorge at 07/02/13 12:46 did gyre and gimble: Le 07/02/2013 00:16, Barry Jackson a écrit : (os-prober may also be disabled while remaining installed if required.) Barry Thank you Barry for your work on that. One day GRUB2 will be mainstream ! ;-) I suspect not. I suspect the need for grub+grub2 will basically disappear as hardware all moves to UEFI instead (and our tools are updated to understand that) and complex file-system aware bootloaders will cease to offer any benefit. It'll obviously need to be around for a long time, but I hope it won't be mainstream as such. 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] [RFC] rsyslog vs journalctl
'Twas brillig, and Pascal Terjan at 07/02/13 13:35 did gyre and gimble: On Thu, Feb 7, 2013 at 1:30 PM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Guillaume Rousse at 07/02/13 12:20 did gyre and gimble: Le 07/02/2013 12:40, AL13N a écrit : 'Twas brillig, and David Walser at 06/02/13 18:28 did gyre and gimble: [...] What I guess we could to to avoid putting rsyslog on the physical media would be to put a versioned conflicts in the main systemd package with rsyslog and syslog-ng. Thus the old packages should be removed when upgrading (AIUI). not a really good idea imho, i have a server which uses rsyslog for network remote syslogging... so upgrading that would break this. Indeed. Just because journal is installed (no choice here) shouldn't prevent to install a real syslog-daemon. I'd rather introduce another virtual package, such as syslog-daemon-minimal (or anything else), and lower the dependencies of basesystem to just require this last one. I'm not really sure what that gains... i.e. that's that's effectively what we have right now with the current provides of syslog-daemon via systemd itself. Arguably the semantics are wrong... e.g. it should really be called system-logger or something more generic. But as things stand you no longer *need* to install rsyslog et al - it's just an option. And as things stand right now, if rsyslog is included in the media it will be upgraded happily and keep on running. I was wondering if some packages(like fail2ban) may want to require a traditional syslog https://github.com/fail2ban/fail2ban/pull/82 ;) But yes, that's a valid argument. Is anyone against the name system-logger? If so I'll update things accordingly. Other name suggestions welcome. 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/
