Bug#687932: ITP: python-django-openstack-auth -- A django authentication backend for Openstack
Package: wnpp Severity: wishlist Owner: Mehdi Abaakouk * Package name: python-django-openstack-auth Version : 1.0.1 Upstream Author : Gabriel Hurley * URL : https://github.com/gabrielhurley/django_openstack_auth.git * License : BSD Programming Lang: Python Description : A django authentication backend for Openstack Django authentication backend for use with the OpenStack Keystone Identity backend. -- Mehdi Abaakouk mail: sil...@sileht.net irc: sileht signature.asc Description: Digital signature
mass bug filing about packages manipulating/deleting shipped files
Hi, another recent addition to piuparts is running debsums to see whether shipped files are being incorrectly modified. This feature is in a experimental stage and not available in the git repository, yet. So far I have seen these problems: * package modifies a conffile it ships * package modifies a non-conffile it ships * package deletes a (conf)file it ships * (maybe all these bad things on files shipped by other packages, too, but I didn't analyze the logs and packages in detail, yet) and not only as a single occurrence :-( What's the appropriate severity for these bugs? I would assume serious. Modifying conffiles is forbidden by policy 10.7.3 I'm not sure about the other cases, but that should be forbidden as well. Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5056f3c5.7040...@abeckmann.de
Re: mass bug filing about packages manipulating/deleting shipped files
On 09/17/2012 11:56 AM, Andreas Beckmann wrote: > Modifying conffiles is forbidden by policy 10.7.3 Well, conffiles are sometimes modified due to the result of asking questions with debconf - at least the md5sum might change, although the content stays the same with debconf priority=high. Are you sure you didn't find such things? Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5056f490.8080...@bzed.de
Bug#687934: ITP: stevedore -- Manage dynamic plugins for Python applications
Package: wnpp Severity: wishlist Owner: Julien Danjou * Package name: stevedore Version : 0.4 Upstream Author : Doug Hellmann * URL : http://pypi.python.org/pypi/stevedore * License : Apache Programming Lang: Python Description : Manage dynamic plugins for Python applications Manage dynamic plugins for Python applications. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917100521.22118.55640.report...@dex.adm.naquadah.org
Re: mass bug filing about packages manipulating/deleting shipped files
On Mon, Sep 17, 2012 at 11:59:44AM +0200, Bernd Zeimetz wrote: > On 09/17/2012 11:56 AM, Andreas Beckmann wrote: > > Modifying conffiles is forbidden by policy 10.7.3 > Well, conffiles are sometimes modified due to the result of asking > questions with debconf - at least the md5sum might change, although the > content stays the same with debconf priority=high. Are you sure you > didn't find such things? If you modify conffiles through debconf config scripts, your package is RC buggy. See also [1]. Kind regards Philipp Kern [1] http://release.debian.org/wheezy/rc_policy.txt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917104927.ga13...@hub.kern.lc
Re: mass bug filing about packages manipulating/deleting shipped files
On 09/17/2012 12:49 PM, Philipp Kern wrote: > On Mon, Sep 17, 2012 at 11:59:44AM +0200, Bernd Zeimetz wrote: >> On 09/17/2012 11:56 AM, Andreas Beckmann wrote: >>> Modifying conffiles is forbidden by policy 10.7.3 >> Well, conffiles are sometimes modified due to the result of asking >> questions with debconf - at least the md5sum might change, although the >> content stays the same with debconf priority=high. Are you sure you >> didn't find such things? > > If you modify conffiles through debconf config scripts, your package is RC > buggy. See also [1]. So we shall drop things like automatic configuration of postfix? It actually even asks the user if the config file should be modified. That is just one example of a lot others that jump into my mind. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5057050a.5030...@bzed.de
Re: mass bug filing about packages manipulating/deleting shipped files
On Sep 17, Bernd Zeimetz wrote:
> So we shall drop things like automatic configuration of postfix? It
> actually even asks the user if the config file should be modified. That
> is just one example of a lot others that jump into my mind.
/etc/postfix/{main,master}.cf are not conffiles, so there is nothing
wrong about the postfix package.
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: mass bug filing about packages manipulating/deleting shipped files
On 2012-09-17 13:10, Bernd Zeimetz wrote: > So we shall drop things like automatic configuration of postfix? It > actually even asks the user if the config file should be modified. That > is just one example of a lot others that jump into my mind. It's perfectly fine to do this on configuration files that are not conffiles. http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50570725.6060...@abeckmann.de
Re: mass bug filing about packages manipulating/deleting shipped files
On 09/17/2012 01:18 PM, Marco d'Itri wrote:
> On Sep 17, Bernd Zeimetz wrote:
>
>> So we shall drop things like automatic configuration of postfix? It
>> actually even asks the user if the config file should be modified. That
>> is just one example of a lot others that jump into my mind.
> /etc/postfix/{main,master}.cf are not conffiles, so there is nothing
> wrong about the postfix package.
Oh well yes, bad example. We still have a lot of packages which modify
/etc/default/* with debconf. Portmap, sysstat, ... - and they are
supposed to be conffiles - which is rather annoying as the default
snippets not being written by deconf would mean that you have to store
the debconf generated stuff somewhere else, and source it...
Additionally to the snipped in /etc/default. Yet another waste of
developer time.
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50570883.7040...@bzed.de
Re: mass bug filing about packages manipulating/deleting shipped files
On Mon, Sep 17, 2012 at 01:24:51PM +0200, Bernd Zeimetz wrote: > Oh well yes, bad example. We still have a lot of packages which modify > /etc/default/* with debconf. Portmap, sysstat, ... - and they are > supposed to be conffiles - [...] Why are they supposed to be conffiles? It's fine for them to be not. (Which is true, e.g., for portmap.) Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917115757.ga14...@hub.kern.lc
Re: mass bug filing about packages manipulating/deleting shipped files
On 09/17/2012 05:56 PM, Andreas Beckmann wrote: Hi, another recent addition to piuparts is running debsums to see whether shipped files are being incorrectly modified. This feature is in a experimental stage and not available in the git repository, yet. So far I have seen these problems: * package modifies a conffile it ships * package modifies a non-conffile it ships * package deletes a (conf)file it ships Very nice. Did you run this archive wide? Can I see your log file? Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5057283b.50...@debian.org
Re: Towards d-i wheezy beta 3
On Mon, Sep 10, 2012 at 12:07:46AM +0200, Cyril Brulebois wrote: >Hello, > >tiny wrap-up for beta 2: the release happened one week after the >prospective date. Some tiny delays on various fronts added up and >explain that, but the overall results don't seem too bad to me. > >That's why I'm going to propose the same timing for beta 3: 3 weeks for >development and bug fixes (let's call it a “merge window”), 1 week for >dealing with udeb-related unblock requests, building/testing images and >preparing release announcement. > >The FTP Team Sprint is scheduled 2012-09-14 → 2012-09-21, but that >should still leave enough time for development. > >Dates would be: > 2012/09/29-30: d-i wheezy beta 3 merge window closes. > 2012/10/06-07: d-i wheezy beta 3 is released. > >Features expected to be merged: > - UEFI support (Steve). Before anyone asks, and as far as I can tell: > it's not about supporting secure boot. > - IPv6 support in d-i (Philipp). > - Possibly more xz-related unblocks (Ansgar). > >If anybody wants to see something land into this release, it would be >nice to mention it now instead of after the end of the merge window. I'd like to get my EFI changes merged, please. A small set of changes in d-i packages, plus minor bootloader updates. The biggest change is a tweak to the d-i build process for debian-cd_info.tar.gz (to add EFI images). -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917135918.gd4...@einval.com
Re: mass bug filing about packages manipulating/deleting shipped files
On 09/17/2012 01:57 PM, Philipp Kern wrote: > On Mon, Sep 17, 2012 at 01:24:51PM +0200, Bernd Zeimetz wrote: >> Oh well yes, bad example. We still have a lot of packages which modify >> /etc/default/* with debconf. Portmap, sysstat, ... - and they are >> supposed to be conffiles - [...] > > Why are they supposed to be conffiles? It's fine for them to be not. > (Which is true, e.g., for portmap.) To cite http://release.debian.org/wheezy/rc_policy.txt: Packages' /etc/default scripts must be treated as configuration files. > > Kind regards > Philipp Kern > > -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50572d41.9040...@bzed.de
Re: mass bug filing about packages manipulating/deleting shipped files
On Sep 17, Bernd Zeimetz wrote: > To cite http://release.debian.org/wheezy/rc_policy.txt: > Packages' /etc/default scripts must be treated as configuration files. Which are not the same things as conffiles. -- ciao, Marco signature.asc Description: Digital signature
Re: Microcode and the installer (Re: Towards d-i wheezy beta 3)
On Thu, 13 Sep 2012, Henrique de Moraes Holschuh wrote: > On Mon, 10 Sep 2012, Jonathan Nieder wrote: > > (replying to -devel and -boot only) > (I am not subscribed to -boot. Please keep -devel on replies, or CC me > directly). > > > Henrique de Moraes Holschuh wrote: > > > On Mon, 10 Sep 2012, Philipp Kern wrote: > > >> If we do that the same should also happen for firmware-linux-nonfree. > > >> Loading > > >> the radeon KMS module without firmware available results in an unusable > > >> (text) console. (Yes, it might be considered a bug that radeon is > > >> loadable > > >> without.) > > > > > > Sounds good to me. > > > > > > What should I clone and hack to try to implement this? > > > > , I think. > > It is actually the hw-detect module, and adding support for the two system > processor microcodes is somewhat trivial... as long as I ignore VMs. I just > need to add a hook to pre-pkgsel.d. > > If I want to skip installing the processor microcode on VM images, I need to > install and "in-target" run virt-what before the hook can decide whether > installing the microcode packages is warranted or not. > > Should I attempt to install virt-what (which brings dmidecode as a > dependency) to avoid wasting space on VM images ? PING? I need some feedback from debian-boot or from VM users! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917150633.ga32...@khazad-dum.debian.net
Re: mass bug filing about packages manipulating/deleting shipped files
On Mon, 17 Sep 2012 13:10:02 +0200 Bernd Zeimetz wrote: > On 09/17/2012 12:49 PM, Philipp Kern wrote: > > On Mon, Sep 17, 2012 at 11:59:44AM +0200, Bernd Zeimetz wrote: > >> On 09/17/2012 11:56 AM, Andreas Beckmann wrote: > >>> Modifying conffiles is forbidden by policy 10.7.3 > >> Well, conffiles are sometimes modified due to the result of asking > >> questions with debconf - at least the md5sum might change, although the > >> content stays the same with debconf priority=high. Are you sure you > >> didn't find such things? > > > > If you modify conffiles through debconf config scripts, your package is RC > > buggy. See also [1]. > > So we shall drop things like automatic configuration of postfix? It > actually even asks the user if the config file should be modified. That > is just one example of a lot others that jump into my mind. Simple solution I use is to have a conffile which is a foo.conf.sample and not package foo.conf which is generated in the postinst from the debconf question and it is this file which is used by the package, not the .sample. Otherwise, there's little point having debconf. The point is not to modify / delete a file listed under dpkg -s or dpkg -L but to create a new file based on content read from those files. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpkms3wMddZT.pgp Description: PGP signature
Re: Handling /etc/modprobe.d and module load order
Ben Hutchings decadent.org.uk> writes: > > > > Trying to load usbhid and passing a quirks parameter so that it ignores > > a specific device. Then, I have my own kernel module to control that > > device. > > What is this driver? It is a driver for a PIC microcontroller board. I was using usbhid but there was a bug that I couldn't work around. So I am bundling a custom kernel module. I need to blacklist that device from usbhid otherwise it tries to control the device. > > > > OK. So I blacklist the modules in package.modprobe. And then load them > > in the order I want in package.init by just calling modprobe? > > Unless you're doing something very unusual, you let udev load the module > automatically based on its device ID table. > I haven't thought of this. How does this work in the case when usbhid already has the device in its device ID table. Thanks for your help. Amit -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20120917t184208-...@post.gmane.org
Re: mass bug filing about packages manipulating/deleting shipped files
On 2012-09-17 15:40, Thomas Goirand wrote: > Very nice. Did you run this archive wide? Archive wide test is currently running in my local piuparts instance. This may still take some time until all packages have been retested. > Can I see your log file? Unfortunately my piuparts instance is not publicly available :-( Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/505768ff.1010...@abeckmann.de
how to handle partial upgrade problems?
Hi, I wanted to write a long and technical email about this subject ... and started over, doing it this way: I started looking for partial upgrade problems some time ago. Any *valid* mixture of packages from, for example, squeeze and wheezy (i.e. all (Pre-)Depends/Breaks/Conflicts are fulfilled) should be installable without errors, shouldn't it? Since there are probably A LOT of these valid combinations, I've restricted my testing to candidates that are potentially more error prone: packages that ship the same filename or where a filename was moved from pkg1 to pkg2. There are two common error classes: * pkg2 is missing a versioned Replaces: pkg1 this usually results in a file overwrite error * pkg2 is missing a versioned Breaks: pkg1 this results in files disappearing from pkg1 after the sequence install pkg1, install pkg2, remove pkg2 If such bugs showed up on the upgrade paths tested by piuparts, they have already been reported as release critical (and most of them have been fixed long ago). But how should we handle these bugs in different upgrade paths? As these are *valid* (at least w.r.t. not having Breaks/Replaces that would forbid them) paths, shouldn't we properly "invalidate" them? I'd vote for filing them as RC bugs, too. We can never know which upgrade path will be taken on a real system (with its unique set of installed packages). And having the relationships tight from the beginning will show less of these subtle errors after a release. For those interested in numbers: squeeze->wheezy file overwrites: 40 file disappearance: 84 wheezy->sid file overwrites: 2 file disappearance: 10 These numbers qualify for a mass bug filing discussion, too. Would it be appropriate to do a RC MBF here? And if this is confirmed, I could need some help doing this. Or better, piuparts could use some help to make bug reporting easier. We have collected quite some bug templates (text files with some gaps) over time, but it still needs a lot of manual work: substituting values (distros, package names, versions), inserting log snippets, attaching a compressed logfile, ... before this can go to submit@. And that's just after reading the logfile, classifying the problem we found and selecting the template ... not to forget checking the BTS for existing reports (that may just need usertagging). Thanks go to Ralf Treinen, dose-debcheck, http://edos.debian.net/, and piuparts. Cheers! Andreas And apologies for working on getting the RC bug count up, not down :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5057931a.4050...@abeckmann.de
Re: Handling /etc/modprobe.d and module load order
On Mon, 2012-09-17 at 16:46 +, Amit wrote: > Ben Hutchings decadent.org.uk> writes: > > > > > > > Trying to load usbhid and passing a quirks parameter so that it ignores > > > a specific device. Then, I have my own kernel module to control that > > > device. > > > > What is this driver? > > It is a driver for a PIC microcontroller board. I was using usbhid but > there was a bug that I couldn't work around. A bug in which? > So I am bundling a custom > kernel module. I need to blacklist that device from usbhid otherwise it > tries to control the device. > > > > > > > OK. So I blacklist the modules in package.modprobe. And then load them > > > in the order I want in package.init by just calling modprobe? > > > > Unless you're doing something very unusual, you let udev load the module > > automatically based on its device ID table. > > > > I haven't thought of this. How does this work in the case when usbhid > already has the device in its device ID table. They both get loaded. Ben. > Thanks for your help. > > Amit > > -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
