Bug#229357: New Build-Options field and build-arch option, please review
On Thu, 10 Jul 2008, Felipe Sateler wrote: El 10/07/08 18:02 Raphael Hertzog escribió: Hello, in order to fix #229357 I decided to add a new Build-Options field. I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS. And I added support for a build-arch option, that if present, will let dpkg-buildpackage call debian/rules build-arch and build-indep. It's not obvious that this was the right choice when you think of the currently existing build options but once you start thinking of possible additions (as requested in #489771), it becomes more evident that it makes sense. Even if some build options should really only be used in the field while others should only be used in the environment variable, the possibility to override the former with the latter is nice. I'm not really sure this is right. There are two things that we want to do here: declare that a package supports something, and asking the package to do something. This difference is blurred now, and I think it is confusing. Even if there's only two things, the fact is that the package maintainer wants not only to decide what is supported but he might also want to enable some features... if you check the case that I listed above, we also want to use Build-Options to _enable_ specific hardening measures. Because the maintainer knows best which hardening measures should be enabled. But we also want the builder to be able to override them for example to test if the package now supports a previously disabled hardening measure. The meaning of each build options is specific to each, there's no global rule that works for all cases. That's why we have documentation of each option in dpkg-buildpackage. I fear it will give rise to abuses such as setting parallel=n in the control file. There are dozens of ways to abuse any interface if you choose to use it in a way that contradicts the documentation. But that's not a reason to limit the flexibility offered by an interface. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490270: marked as done (dpkg: [S-S-D] start-stop-daemon --stop fails if the daemon is not running.)
Your message dated Fri, 11 Jul 2008 09:16:04 +0200 with message-id [EMAIL PROTECTED] and subject line Re: Bug#490270: dpkg: [S-S-D] start-stop-daemon --stop fails if the daemon is not running. has caused the Debian Bug report #490270, regarding dpkg: [S-S-D] start-stop-daemon --stop fails if the daemon is not running. to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 490270: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490270 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: dpkg Version: 1.13.25 Severity: important Dear dpkg maintainers, I was trying to remove `fam' in an Etch chroot, but was blocked by the following error: [EMAIL PROTECTED]:/# dpkg --purge fam (Reading database ... 54012 files and directories currently installed.) Removing fam ... Stopping file alteration monitor: FAMstart-stop-daemon: nothing in /proc - not mounted? (Success) invoke-rc.d: initscript fam, action stop failed. dpkg: error processing fam (--purge): subprocess pre-removal script returned error exit status 2 Starting file alteration monitor: FAMstart-stop-daemon: nothing in /proc - not mounted? (Success) invoke-rc.d: initscript fam, action start failed. dpkg: error while cleaning up: subprocess post-installation script returned error exit status 2 Errors were encountered while processing: fam The postinst script of fam fails because of invoke-rc.d stop fails: [EMAIL PROTECTED]:/# more /var/lib/dpkg/info/fam.prerm #!/bin/sh set -e # Automatically added by dh_installinit if [ -x /etc/init.d/fam ]; then if [ -x `which invoke-rc.d 2/dev/null` ]; then invoke-rc.d fam stop || exit $? else /etc/init.d/fam stop || exit $? fi fi # End automatically added section invoke-rc.d fails because /etc/init.d/fam uses start-stop-daemon, that does not realise that fam is not running and fails later trying to stop it. casee $1 in start) log_daemon_msg Starting $DESC $NAME start-stop-daemon --start --quiet --exec $DAEMON -- $FAMOPTS log_end_msg $? ;; stop) log_daemon_msg Stopping $DESC $NAME start-stop-daemon --stop --oknodo --quiet --exec $DAEMON log_end_msg $? ;; The consequence of this is that it is difficult to remove not runnign daemons on Debian. Apparently, fam uses templates from dh-make and debhelper, so the bug may be that the template is wrong if the behaviour of start-stop-daemon is right... Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan ---End Message--- ---BeginMessage--- On Fri, 11 Jul 2008, Charles Plessy wrote: Package: dpkg Version: 1.13.25 Severity: important Dear dpkg maintainers, I was trying to remove `fam' in an Etch chroot, but was blocked by the following error: [EMAIL PROTECTED]:/# dpkg --purge fam (Reading database ... 54012 files and directories currently installed.) Removing fam ... Stopping file alteration monitor: FAM start-stop-daemon: nothing in /proc - not mounted? (Success) Does this message not sound as an alarm to you ?? I'm afraid there's no bug here but a user problem because you had /proc not mounted. Furthermore before reporting new bugs, it's always best to see if you can reproduce it with the current sid version... s-s-d has had quite a few fixes during the lenny cycle. Closing the bug. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ ---End Message---
Bug#490270: dpkg: [S-S-D] start-stop-daemon --stop fails if the daemon is not running.
Le Fri, Jul 11, 2008 at 09:16:04AM +0200, Raphael Hertzog a écrit : [EMAIL PROTECTED]:/# dpkg --purge fam (Reading database ... 54012 files and directories currently installed.) Removing fam ... Stopping file alteration monitor: FAM start-stop-daemon: nothing in /proc - not mounted? (Success) Does this message not sound as an alarm to you ?? I'm afraid there's no bug here but a user problem because you had /proc not mounted. Furthermore before reporting new bugs, it's always best to see if you can reproduce it with the current sid version... s-s-d has had quite a few fixes during the lenny cycle. Closing the bug. Cheers, -- Raphaël Hertzog Hi Raphaël, 1) I think that one should be able to remove Debian packages with /proc not mounted. 2) I chose to report this bug against Etch's version because not being able to remove some packages can complicate upgrade to next release. fam is not the first only with such a behavior. In the case of fam, the failure is due to /proc not being mounted. In other cases, for instance the peercast package (#489366), the failure has another origin. But the real problem is that despite the daemon is not running, the package can not be removed. Can I reopen this bug in Etch and mark it fixed in Lenny+Sid if it has been solved in these versions ? Have a nice day, -- Charles Plessy Debian-Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#489040: dpkg: handles (menu) triggers inconsistently
Processing commands for [EMAIL PROTECTED]: reassign 489040 menu 2.1.39 Bug#489040: dpkg: handles (menu) triggers inconsistently Bug reassigned from package `dpkg' to `menu'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489040: dpkg: handles (menu) triggers inconsistently
reassign 489040 menu 2.1.39 thanks On 2008-07-03 01:08 +0200, Evgeni Golov wrote: Package: dpkg Version: 1.14.20 Severity: normal Hi, while preparing a new upload of pokerth, I stumbled over a very weird behaviour of dpkg when it comes to menu file triggers. When I install the package via apt, everything is fine, and I can see pokerth in the Debian menu of my Xfce. But when I install the very same file direclty via dpkg, the menu entry vanishes. The output is slightly different (I think it's related): # apt-get install pokerth --reinstall [...] Processing triggers for menu ... Processing triggers for man-db ... Setting up pokerth-data (0.6.2-1) ... Setting up pokerth (0.6.2-1) ... Processing triggers for menu ... # dpkg -i /var/cache/apt/archives/pokerth* [...] Setting up pokerth-data (0.6.2-1) ... Setting up pokerth (0.6.2-1) ... Processing triggers for menu ... Processing triggers for man-db ... In both cases pokerth was already installed on my system. I hope you can see the problem, if not, ping me on IRC (Zhenech) or via mail. I can reproduce the problem, thanks. To figure out why this happens I modified the menu postinst: --8---cut here---start-8--- --- menu.postinst~ 2008-05-21 11:21:21.0 +0200 +++ menu.postinst 2008-07-11 10:40:36.0 +0200 @@ -17,7 +17,7 @@ triggered) # This is triggered by any installation of a menu file and by # any call to update-menus made in a package maintainer script. - update-menus --trigger + update-menus -d --trigger exit 0 ;; *) --8---cut here---end---8--- and then reinstalled pokerth with dpkg: , | # dpkg -i /var/cache/apt/archives/pokerth_0.6.2-2_i386.deb | (Reading database ... 132148 files and directories currently installed.) | Preparing to replace pokerth 0.6.2-2 (using .../pokerth_0.6.2-2_i386.deb) ... | Unpacking replacement pokerth ... | Setting up pokerth (0.6.2-2) ... | Processing triggers for menu ... | update-menus[11210]: Reading installed packages list... | update-menus[11210]: Reading translation rules in /etc/menu-methods/translate_menus. | update-menus[11210]: Reading menu-entry files in /etc/menu/. | update-menus[11210]: 6 menu entries found (6 total). | update-menus[11210]: Reading menu-entry files in /usr/lib/menu/. | update-menus[11210]: 2 menu entries found (8 total). | update-menus[11210]: Reading menu-entry files in /usr/share/menu/. | update-menus[11210]: file /usr/share/menu/pokerth line 5: | Discarding entry requiring missing package pokerth. | update-menus[11210]: 201 menu entries found (209 total). | update-menus[11210]: Reading menu-entry files in /usr/share/menu/default/. | update-menus[11210]: 0 menu entries found (209 total). | update-menus[11210]: Running menu-methods in /etc/menu-methods/. | update-menus[11210]: Running method: /etc/menu-methods/xdg-desktop-entry-spec-sessions | update-menus[11210]: Running method: /etc/menu-methods/icewm-common | update-menus[11210]: Running method: /etc/menu-methods/xdg-desktop-entry-spec-apps | update-menus[11210]: Running method: /etc/menu-methods/xdg-desktop-entry-spec-dirs | update-menus[11210]: Running method: /etc/menu-methods/menu-xdg | update-menus[11210]: Running method: /etc/menu-methods/blackbox | Processing triggers for man-db ... ` Here is the excerpt of dpkg.log for that run: , | 2008-07-11 10:58:47 startup archives install | 2008-07-11 10:58:47 upgrade pokerth 0.6.2-2 0.6.2-2 | 2008-07-11 10:58:47 status half-configured pokerth 0.6.2-2 | 2008-07-11 10:58:47 status unpacked pokerth 0.6.2-2 | 2008-07-11 10:58:47 status half-installed pokerth 0.6.2-2 | 2008-07-11 10:58:47 status triggers-pending menu 2.1.39 | 2008-07-11 10:58:47 status half-installed pokerth 0.6.2-2 | 2008-07-11 10:58:47 status triggers-pending man-db 2.5.2-2 | 2008-07-11 10:58:47 status half-installed pokerth 0.6.2-2 | 2008-07-11 10:58:47 status half-installed pokerth 0.6.2-2 | 2008-07-11 10:58:47 status triggers-awaited menu 2.1.39 | 2008-07-11 10:58:47 status unpacked pokerth 0.6.2-2 | 2008-07-11 10:58:47 status unpacked pokerth 0.6.2-2 | 2008-07-11 10:58:47 configure pokerth 0.6.2-2 0.6.2-2 | 2008-07-11 10:58:47 status unpacked pokerth 0.6.2-2 | 2008-07-11 10:58:47 status half-configured pokerth 0.6.2-2 | 2008-07-11 10:58:47 status triggers-awaited pokerth 0.6.2-2 | 2008-07-11 10:58:47 trigproc menu 2.1.39 2.1.39 | 2008-07-11 10:58:47 status half-configured menu 2.1.39 | 2008-07-11 10:58:49 status installed menu 2.1.39 | 2008-07-11 10:58:49 trigproc man-db 2.5.2-2 2.5.2-2 | 2008-07-11 10:58:49 status half-configured man-db 2.5.2-2 | 2008-07-11 10:58:49 status installed pokerth 0.6.2-2 | 2008-07-11 10:58:49 status installed man-db 2.5.2-2 ` As you can see, pokerth had the status triggers-awaited when update-menus --trigger ran, and update-menus seems to consider that state as not installed, incorrectly skipping its menu
Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Jul 10, 2008 at 07:19:16PM -0400, Felipe Sateler wrote: El 10/07/08 18:02 Raphael Hertzog escribió: Hello, in order to fix #229357 I decided to add a new Build-Options field. I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS. And I added support for a build-arch option, that if present, will let dpkg-buildpackage call debian/rules build-arch and build-indep. It's not obvious that this was the right choice when you think of the Maybe it is not obvious, but since noone proposed another working solution in the ten years this issue exists, there is no alternative. currently existing build options but once you start thinking of possible additions (as requested in #489771), it becomes more evident that it makes sense. Even if some build options should really only be used in the field while others should only be used in the environment variable, the possibility to override the former with the latter is nice. I'm not really sure this is right. There are two things that we want to do here: declare that a package supports something, and asking the package to do something. This difference is blurred now, and I think it is confusing. OTOH, it gives the benefit of being able to ignore the package capabilities via the environment (ie, unset a given option). I fear it will give rise to abuses such as setting parallel=n in the control file. I concur. This also create a namespace problem by conflating the 'Build-Options' namespace with the DEB_BUILD_OPTIONS namespace. Since a developer can put virtually anything in DEB_BUILD_OPTIONS (and check for it in debian/rules) even if it is not mentionned in policy, this is a real issue. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489771: New Build-Options field and build-arch option, please review
Raphael Hertzog [EMAIL PROTECTED] writes: Even if there's only two things, the fact is that the package maintainer wants not only to decide what is supported but he might also want to enable some features... if you check the case that I listed above, we also want to use Build-Options to _enable_ specific hardening measures. Because the maintainer knows best which hardening measures should be enabled. But we also want the builder to be able to override them for example to test if the package now supports a previously disabled hardening measure. This doesn't make sense to me. The maintainer writes debian/rules; why would they need to change Build-Options in debian/control to enable anything about the build? I'd rather see Build-Options in debian/control be clearly defined as capabilities that the package supports and not used as a substitute for the existing DEB_BUILD_OPTIONS method of controlling what the build does in practice. (And I'd prefer it to be called Build-Options-Supported or something along those lines.) I think this still fits for #489771; the presence of the hardening option in Build-Options-Supported indicates that the package can usefully be built with hardening (it doesn't cause the package build to break or the binaries to malfunction). If the package maintainer wants the package to always be built with those options, they should make that change directly in debian/rules, not via this method. They're going to have to test each flag that goes into the hardening options separately anyway to make sure that it works (the current proposed hardening flags break many packages, and if you follow debian/changelog files, you'll see that many maintainers have added them blindly and then had to roll back when they break). Using a debian/control field to set DEB_BUILD_OPTIONS in dpkg-buildpackage is a solution looking for a problem, IMO, and I'd rather not see that tangled up with the much-needed problem of specifying which options a package supports and finally dealing with the whole build-arch/build-indep mess. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#77828: dpkg: [PATCH]: users should be able to use update-alternatives (not only root)
Hallo Raphael and *, Am 2008-07-06 17:49:25, schrieb Raphael Hertzog: tags 77828 - patch tags 77828 + wontfix thanks On Sat, 25 Nov 2000, Martin Quinson wrote: Here is an (unified) patch against update-alternatives.pl as found today in the CVS. Its purpose is to allow the users to manage an alternative system on their account. I'm not really inclined to support such a feature. I have yet to see a valid use case. When the user wants to override a system-wide setting, there are already dozens of solutions going from using some environment variable to changing the PATH so that ~/bin/ is looked first. And ~/bin/ can contain symlinks corresponding to the various name of alternatives and have them point to their program of choice. I would support this whishlist bug since update-alternatives.pl support already an infrastructure and yes, ~/bin should be used. I have written for some time an tool which is based on update-alternatives Not sure for now (no fsck Web-Access currently), but AFAIK I have it as Debian Package on my website and use (X)dialog which can easyly used under the X-Window-System. I have writen it, because there are noobs which are USER-ONLY and have no clue about system configuration. So my Xdialog Tool has helped many peoples already, even it is very simple coded. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
