Bug#714505: ITP: python-hacking -- Flake8 OpenStack Hacking Guidline Enforcement plugins
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-hacking Version : 0.5.6 Upstream Author : OpenStack * URL : https://pypi.python.org/pypi/hacking * License : Apache-2.0 Programming Lang: Python Description : Flake8 OpenStack Hacking Guidline Enforcement plugins Hacking is a set of flake8 plugins that test and enforce the OpenStack Style Commandments. -- 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/20130630073114.27760.56088.report...@buzig.gplhost.com
Re: boot ordering and resolvconf
> In addition resolvconf does not properly support mode (A), due to the > "local forwarding nameserver is running" requirement. It can leave > /etc/resolv.conf empty until the name server is actually started. Well, you are right that resolvconf was designed to support mode B, and only supports mode A as a trivial case of mode B where a local forwarding nameserver is always running. That resolvconf leaves resolv.conf empty of "nameserver" entries when no nameservers are available is intentional. The idea is to advertise only addresses where something is actually listening. I understand, though, (vaguely) that this is not how things work in the systemd world, so I expect that resolvconf, or the use of resolvconf, will have to be adapted for the systemd world. Help and advice will be appreciated: see bug report #700846. By the way, inconsistent with the aforementioned idea is the fact that the resolver defaults to using 127.0.0.1 if there are no "nameserver" lines in resolv.conf. Were you aware of that? > As far as I can tell the unbound part works very well on wheezy already. > Well except for ntpd not noticing. Thanks for pointing that out. I don't use unbound so I hadn't noticed that resolvconf hook scripts have been added to the unbound package. I will update the resolvconf README. -- Thomas
Mass bug filing for shared library broken symlinks detected by piuparts
Shortly, piuparts.debian.org will be elevating the broken symlink test in sid from a warning to an error status. In advance of that, bugs submissions are planned against packages which are responsible for such links. This message covers the bug filings at the 'serious' severity due to a Policy violation involving shared libraries. Section 8 states "Packages containing shared libraries must be constructed with a little care to make sure that the shared library is always available". Discussion about bug filings at other severities may be handled in separate threads. The package list was generated by running an instance of piuparts-slave/piuparts-master against sid, with the option "--fail-on-broken-symlinks" enabled. The resulting list was hand-massaged to eliminate a few packages which failed through the fault of a dependency. These 'serious' bug candidates were identified by testing the symlinks and targets against the regular expression "/usr/lib/.*lib.*so". There are 82 binary packages in this list, represented by 66 source packages and 53 maintainers. This is about a quarter of all of the packages reporting broken symlinks. A total of 279 broken symlinks are being flagged as 'serious' due to shared library issues. To see a piuparts log showing the broken symlinks, find the package under http://piuparts.debian.org/sid/broken_symlinks_issue.html and search for "WARN: Broken symlinks". That web page also lists reverse dependencies of packages with the issue. The initial bug reports will be based on this template: Subject: Broken library symlink detected in Package: Version: Severity: serious User: debian...@lists.debian.org Usertags: piuparts, broken-symlinks, broken-symlink-shared-library Hi, During a test with piuparts, I noticed your package is responsible for the presence of broken symlinks. Such failures may indicate a significant problem with the package. These are sometimes triggered because a Recommended or reverse dependency package owning the symlink target file is not yet installed. This type of failure mode needs to be eliminated so that other symlink problems become more visible. In this case, the problem can be resolved by creating a trigger for the target file. See the dpkg triggers documentation[1] and example on the net[2] for implementation details. This is being filed as Serious because it represents a violation of Policy. Section 8 states "Packages containing shared libraries must be constructed with a little care to make sure that the shared library is always available". A link to the log containing the indicated broken symlinks can be found on piuparts.debian.org[3]. Search for "Warn: Broken Symlinks" to see the failure point. A log showing the broken symlink as an error is appended. The specific symlinks are as follows: Note that there may be other broken symlinks. See the log for a full list. [1] - file:///usr/share/doc/dpkg-dev/triggers.txt.gz [2] - http://www.seanius.net/blog/2009/09/dpkg-triggers-howto/ [3] - http://piuparts.debian.org/sid/broken_symlinks_issue.html Regards Dave Steele Following is a list of affected packages, by maintainer. The symlinks involving shared libraries are also listed. Note that there may be other broken symlinks detected by piuparts with these packages. A. Maitland Bottoms libdime-dev : dime /usr/lib/libdime.so Andrew Ross libplplot-dev : plplot (5.9.9-5) /usr/lib/libplplotqtd.so /usr/lib/libplplotwxwidgetsd.so Arno Töll trafficserver-dev : trafficserver /usr/lib/trafficserver/libtsconfig.so /usr/lib/trafficserver/libtsmgmt.so /usr/lib/trafficserver/libtsutil.so Boris Dušek libspeechd-dev : speech-dispatcher /usr/lib/speech-dispatcher/libsdaudio.so Brian May heimdal-multidev : heimdal /usr/lib/x86_64-linux-gnu/heimdal/libotp.so /usr/lib/x86_64-linux-gnu/heimdal/libsl.so Bryan Sutula libopenhpi2 : openhpi /usr/lib/openhpi/libilo2_ribcl.so /usr/lib/openhpi/libipmi.so /usr/lib/openhpi/libipmidirect.so /usr/lib/openhpi/liboa_soap.so /usr/lib/openhpi/libsnmp_bc.so /usr/lib/openhpi/libsysfs2hpi.so /usr/lib/openhpi/libwatchdog.so Cristian Greco libpoco-dev : poco /usr/lib/libPocoCryptod.so /usr/lib/libPocoDatad.so /usr/lib/libPocoFoundationd.so /usr/lib/libPocoMySQLd.so /usr/lib/libPocoNetd.so /usr/lib/libPocoNetSSLd.so /usr/lib/libPocoODBCd.so /usr/lib/libPocoSQLited.so /usr/lib/libPocoUtild.so /usr/lib/libPocoXMLd.so /usr/lib/libPocoZipd.so Cyril Bouthors libwcat1-dev : libwcat1 /usr/lib/libwcat.so Daiki Ueno libm17n-im-config-dev : m17n-im-config /usr/lib/libm17n-im-config.so Daniel Baumann lib
Re: Mass bug filing for shared library broken symlinks detected by piuparts
On 2013-06-30 17:30, Dave Steele wrote: > [...] Thanks for working on improving Debian. > Debian Orbital Alignment Team > eclipse-platform-data : eclipse > > /usr/lib/eclipse/plugins/org.apache.ant_1.8.3.v20120321-1730/lib/ant-apache-resolver.jar Looks like a false positive for this being a shared library. I have a feeling the particular case is just a left-over (i.e. now unused) symlink rather than something that effects the functionality of the package. ~Niels -- 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/51d051aa.6060...@thykier.net
setgid bit and TMPDIR
Hello List, I want to pass TMPDIR to an executable with setgid bit: I know that TMPDIR then discarded by glibc; but I also noticed that TMPDIR can be passed provided that the group is forced to be the grout of the executable. Is there other tricks in the same vein ? Thanks in advance, Jerome -- 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/51d0655d.4000...@rezozer.net
Re: Mass bug filing for shared library broken symlinks detected by piuparts
On Sun, Jun 30, 2013 at 11:30:39 -0400, Dave Steele wrote: > Shortly, piuparts.debian.org will be elevating the broken symlink test > in sid from a warning to an error status. In advance of that, bugs > submissions are planned against packages which are responsible for > such links. > > This message covers the bug filings at the 'serious' severity due to a > Policy violation involving shared libraries. Section 8 states > "Packages containing shared libraries must be constructed with a > little care to make sure that the shared library is always available". > > Discussion about bug filings at other severities may be handled in > separate threads. > > The package list was generated by running an instance of > piuparts-slave/piuparts-master against sid, with the option > "--fail-on-broken-symlinks" enabled. The resulting list was > hand-massaged to eliminate a few packages which failed through the > fault of a dependency. These 'serious' bug candidates were identified > by testing the symlinks and targets against the regular expression > "/usr/lib/.*lib.*so". > > There are 82 binary packages in this list, represented by 66 source > packages and 53 maintainers. This is about a quarter of all of the > packages reporting broken symlinks. A total of 279 broken symlinks are > being flagged as 'serious' due to shared library issues. > AFAIK most of these get fixed up by ldconfig, which means they're not a problem in practice. I don't think "serious" is the right severity unless there's real world consequences to the broken symlinks. Cheers, Julien signature.asc Description: Digital signature
Re: Mass bug filing for shared library broken symlinks detected by piuparts
On 2013-06-30 19:08 +0200, Julien Cristau wrote: > On Sun, Jun 30, 2013 at 11:30:39 -0400, Dave Steele wrote: > >> Shortly, piuparts.debian.org will be elevating the broken symlink test >> in sid from a warning to an error status. In advance of that, bugs >> submissions are planned against packages which are responsible for >> such links. >> >> This message covers the bug filings at the 'serious' severity due to a >> Policy violation involving shared libraries. Section 8 states >> "Packages containing shared libraries must be constructed with a >> little care to make sure that the shared library is always available". >> >> Discussion about bug filings at other severities may be handled in >> separate threads. >> >> The package list was generated by running an instance of >> piuparts-slave/piuparts-master against sid, with the option >> "--fail-on-broken-symlinks" enabled. The resulting list was >> hand-massaged to eliminate a few packages which failed through the >> fault of a dependency. These 'serious' bug candidates were identified >> by testing the symlinks and targets against the regular expression >> "/usr/lib/.*lib.*so". >> >> There are 82 binary packages in this list, represented by 66 source >> packages and 53 maintainers. This is about a quarter of all of the >> packages reporting broken symlinks. A total of 279 broken symlinks are >> being flagged as 'serious' due to shared library issues. >> > AFAIK most of these get fixed up by ldconfig, which means they're not a > problem in practice. I don't think "serious" is the right severity > unless there's real world consequences to the broken symlinks. A cursory glance shows that many cases are a problem of missing dependencies in the -dev package, and that is usually a serious problem (e.g., binaries get linked statically). Cheers, Sven -- 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/87li5r8ot0@turtle.gmx.de
Bug#714555: ITP: django-macaddress -- MAC address model and form fields for Django apps
Package: wnpp Severity: wishlist Owner: Jonathan Wiltshire * Package name: django-macaddress Version : 1.0.1 Upstream Author : Ryan Nowakowski * URL : https://pypi.python.org/pypi/django-macaddress/ * License : BSD Programming Lang: Python Description : MAC address model and form fields for Django apps -- 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/20130630191523.31791.57306.report...@lupin.home.powdarrmonkey.net
Re: system-wide crypto policies
* Daniel Pocock: > Just out of interest, a CA can re-issue their root cert with the same > key pair but a stronger hash. This type of thing has happened before. That's possible because the self-signature is not actually meaningful. 8-) It's different further down the tree, and some protocols (including TLS) do not allow multiple certification chains. -- 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/874ncf4czn@mid.deneb.enyo.de
Re: Re: Reporting 1.2K crashes
> while the coverage is still tiny, there is an effort to collect contact > addresses listed in the debian/upstream file in the VCS where our source > packages are maintained. > > http://upstream-metadata.debian.net/table/contact > > In some cases, it is a valid email address. Perhaps you can give it a > priority > ? I appreciate the effort to collect contact information of upstream devs, and I hope it will gain more traction. As of know, less than 1% (6/752) of the packages containing crashes are included in the list. Best, Alex -- 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/CAF1AS2jq9-4=H+OGB=y-lfapge0fxxnewsyhn783yek34v-...@mail.gmail.com
Re: Mass bug filing for shared library broken symlinks detected by piuparts
On Sun, Jun 30, 2013 at 1:08 PM, Julien Cristau wrote: > AFAIK most of these get fixed up by ldconfig, which means they're not a > problem in practice. It wasn't clear to me how this would be the case, so I reran the logs with a piuparts mod making an ldconfig call before the symlink test. It did not affect the results. -- "Le mieux est l'ennemi du bien" - Voltaire -- 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/CAOHcdNYKS0rEaeLzVmB8CtGz1pa5RvDPM0pS=h-+GBxQc9_=i...@mail.gmail.com
Re: boot ordering and resolvconf
Helmut Grohne wrote: > All that I am aiming for is to declare one of the following practises > as broken: > > * Treating an empty /etc/resolv.conf as a permanent error or failing >to discover changes in /etc/resolv.conf later on. > * Changing /etc/resolv.conf during startup of a local dns cache. I think that the first one is broken. If name service is unavailable just after boot then that should not be treated as a permanent error. An answer from a nameserver that a domain name does not exist might more reasonably be treated as a permanent error, but that is disputable. In a world where computers move among LANs, DNS does not always look the same, so it's not unreasonable to retry periodically even after being told NXDOMAIN. A problem is that getaddrinfo() doesn't distinguish in its return status between "couldn't reach a nameserver" and "nameserver says the name doesn't exist". Either way it returns EAI_SYSTEM with errno=2 (ENOENT). > > I am not aware that there is anything (except perhaps ntpd) that needs to > > be fixed. > > It is true, that ntpd can work around this issue. Still it appears like > a bad design to treat EAI_SYSTEM as a temporary error. Can you explain why you think that? -- Thomas
Candidates for removal from testing (2013-06-30)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
We are considering removing the following packages from testing as
they have unfixed RC bugs filed against them. The packages can be
found in the attached dd-list.
The packages have been selected based on the following criteria:
- The package had at least one RC bug without activity for the past
14 days.
- If a bug is assigned to multiple packages, both packages will
be affected[1].
- The RC bug affects both unstable and testing.
- The affected package does not have any reverse dependencies in
testing.
- One of their RC bugs had "FTBFS" in their title. (*)
- The source package had a popcon inst value of 500 or less. (*)
(*) These extra filter rules was applied to keep the list "down". The
original list was 246.
If the relevant RC bugs in the affected packages (those listed in
"FTBFS-w-popcon-lt-500.txt") are not dealt with before the 8th of
July, the packages will be removed from testing. Note that "dealt
with" may also include downgrading a severity-inflated bug or fixing
affected versions in the BTS.
For reference, the original list is also included.
Thanks,
Niels (on behalf of the Release Team)
PS: This mail has been BCC'ed to "@packages.debian.org" for
packaged listed in "FTBFS-w-popcon-lt-500.txt".
8< FTBFS-w-popcon-lt-500.txt 8<
BUG [SRC]: TITLE
#712367 [bashdb]: bashdb: FTBFS: manuals build fails against textinfo5 because
some incompatibles changes wrt 4.13 and below (some warnings have turned into
errors)
#711787 [falconpl]: falconpl: FTBFS on mipsen
#701412 [prelude-manager]: prelude-manager: ftbfs with eglibc-2.17
#712329 [epix]: epix: FTBFS: manuals build fails against textinfo5 because some
incompatibles changes wrt 4.13 and below (some warnings have turned into errors)
#710633 [orafce]: orafce: FTBFS: plvlex.c:209:3: error: too many arguments to
function 'orafce_sql_yyparse'
#707399 [gedit-valencia-plugin]: gedit-valencia-plugin: FTBFS:
GIRepository-2.0.gir:240.11-240.30: error: expected start element of `parameter'
#710614 [bip]: bip: FTBFS: lex.l:19:6: error: conflicting types for 'yyparse'
#701319 [massxpert]: massxpert: ftbfs with GCC-4.8
#701334 [openvrml]: openvrml: ftbfs with GCC-4.8
#701328 [nwchem]: nwchem: ftbfs with GCC-4.8
#701367 [toonloop]: toonloop: ftbfs with GCC-4.8
#712321 [oneliner-el]: oneliner-el: FTBFS: manuals build fails against
textinfo5 because some incompatibles changes wrt 4.13 and below (some warnings
have turned into errors)
#701411 [prelude-lml]: prelude-lml: ftbfs with eglibc-2.17
#701348 [rnahybrid]: rnahybrid: ftbfs with GCC-4.8
#710636 [mididings]: mididings: FTBFS: src/python_caller.cc:151:42: error:
expected unqualified-id before numeric constant
#701438 [charybdis]: charybdis: ftbfs with eglibc-2.17
#708692 [dnsjava]: FTBFS: requires internet connectivity
#712344 [cfi]: cfi: FTBFS: Package babel Error: Unknow option `swedish'. Either
you misspelled it
#707373 [libccaudio2]: libccaudio2: FTBFS: friends.cpp:1189:25: error:
'ACCESS_DIRECTORY' is not a member of 'ucommon::fsys'
#701300 [ivtools]: ivtools: ftbfs with GCC-4.8
#701428 [turnserver]: turnserver: ftbfs with eglibc-2.17
#712349 [cdk]: cdk: FTBFS: This CDK release requires Ant 1.7.1 or better
#701342 [psychtoolbox-3]: psychtoolbox-3: ftbfs with GCC-4.8
#707411 [zoneminder]: zoneminder: FTBFS: zm_local_camera.cpp:742:49: error:
invalid conversion from '__u32 {aka unsigned int}' to 'v4l2_buf_type'
[-fpermissive]
#712327 [freepops]: freepops: FTBFS: Package babel Error: You haven't specified
a language option.
#711628 [libhttp-daemon-ssl-perl]: libhttp-daemon-ssl-perl: FTBFS: test failure
#701317 [mailavenger]: mailavenger: ftbfs with GCC-4.8
#711367 [python-django-localeurl]: python-django-localeurl: FTBFS:
NoReverseMatch: 'url' requires a non-empty first argument
#701298 [ion]: ion: ftbfs with GCC-4.8
#701281 [gcc-msp430]: gcc-msp430: ftbfs with GCC-4.8
#707420 [sdpnetstat]: sdpnetstat: FTBFS: strip.c:24:28: fatal error:
linux/if_strip.h: No such file or directory
#710501 [avinfo]: avinfo: FTBFS: ass.tab.h:104:5: error: conflicting types for
'yyparse'
#707501 [rpy]: rpy: FTBFS: grep: ecrm1095.log: No such file or directory
#708808 [nant]: nant: FTBFS: [csc] Cannot open assembly
'/usr/lib/mono/4.0/dmcs.exe': No such file or directory.
#706176 [openjpa]: FTBFS with hsqldb 2.2.9: cannot find symbol
(org.hsqldb.Trace)
#701308 [libpam-unix2]: libpam-unix2: ftbfs with GCC-4.8
#701416 [rrep]: rrep: ftbfs with eglibc-2.17
#710637 [sipwitch]: sipwitch: FTBFS: ../inc/sipwitch/service.h:111:14: error:
'id' was not declared in this scope
#602668 [libdevel-bt-perl]: libdevel-bt-perl: FTBFS on armel
#707872 [elmerfem]: src:elmerfem: FTBFS in sid
#701286 [geotranz]: geotranz: ftbfs with GCC-4.8
#701356 [sdpa]: sdpa: ftbfs with GCC-4.8
#701371 [xmlcopyeditor]: xmlcopyeditor: ftbfs with GCC-4.8
#708802 [pion-net]: pion-net: FTBFS: PionScheduler.cpp:105:40: error: expected
unqualified-id before
Bug#714574: ITP: libexperimental-perl -- pragma for making experimental features easy
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libexperimental-perl Version : 0.005 Upstream Author : Leon Timmermans * URL : https://metacpan.org/release/experimental/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : pragma for making experimental features easy The experimental pragma provides an easy and convenient way to enable or disable experimental features. Experimental features were introduced in Perl 5.18, together with a warnings category "exmperimental". When such features are used, the respective warnings have to be turned off additionally. Cf. https://metacpan.org/module/RJBS/perl-5.18.0/pod/perldelta.pod#New-mechanism-for-experimental-features -- 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/20130630222336.ga27...@jadzia.comodo.priv.at
Re: Mass bug filing for shared library broken symlinks detected by piuparts
On Sun, Jun 30, 2013 at 04:46:28PM -0400, Dave Steele wrote: > On Sun, Jun 30, 2013 at 1:08 PM, Julien Cristau wrote: > > AFAIK most of these get fixed up by ldconfig, which means they're not a > > problem in practice. > > It wasn't clear to me how this would be the case, so I reran the logs > with a piuparts mod making an ldconfig call before the symlink test. > It did not affect the results. I believe that he's referring to ld.so.cache containing a mapping of $SONAME -> $lib_realpath, so the broken symlink might not actually result in an unresolvable library. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: Bug#678607: Reporting 1.2K crashes
Le Sun, Jun 30, 2013 at 05:06:59AM +, Bart Martens a écrit : > On Sun, Jun 30, 2013 at 08:24:30AM +0900, Charles Plessy wrote: > > How about simply replacing "should name the original authors" by "should > > provide contact information for license questions" ? > > That would give the wrong impression that whatever that contact answers to > license questions applies. Hi Bart, do you have a suggestion for an alternative wording ? Or would it be fine with you to simply delete the requirement ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20130701034904.gd4...@falafel.plessy.net
Re: Candidates for removal from testing (2013-06-30)
Hi, Thanks a lot for this work. On 30/06/13 at 23:32 +0200, Niels Thykier wrote: > We are considering removing the following packages from testing as > they have unfixed RC bugs filed against them. The packages can be > found in the attached dd-list. > > The packages have been selected based on the following criteria: > - The package had at least one RC bug without activity for the past >14 days. >- If a bug is assigned to multiple packages, both packages will > be affected[1]. > - The RC bug affects both unstable and testing. > - The affected package does not have any reverse dependencies in >testing. > > - One of their RC bugs had "FTBFS" in their title. (*) > - The source package had ai popcon inst value of 500 or less. (*) > > (*) These extra filter rules was applied to keep the list "down". The > original list was 246. > > If the relevant RC bugs in the affected packages (those listed in > "FTBFS-w-popcon-lt-500.txt") are not dealt with before the 8th of > July, the packages will be removed from testing. Note that "dealt > with" may also include downgrading a severity-inflated bug or fixing > affected versions in the BTS. > > For reference, the original list is also included. Those criterias mix: - criterias that apply to the RC bugs (no activity for > 14 days, affects testing+unstable, title contains "FTBFS") - criterias that apply to the source package (no rev-depends, popcon<500) Some time ago, I experimented[1,2,3] with coming up with a list of criterias for "important packages" (which I just renamed to "key packages" to avoid the confusion with priority:important). Key packages are packages that must be part of our stable releases (= that must be in good shape to allow a Debian release). Currently, the following criterias are used: | Key packages are: | - packages whose popcon is higher than 5% of the max popcon (that's | >7570 insts currently) | OR | - packages of priority >= standard | OR | - packages of section debian-installer | OR | - debian-installer, debian-cd, piuparts | OR | - build-dependencies of key packages [binary dependencies are covered | by the popcon criteria] [1] https://lists.debian.org/debian-devel/2013/05/msg00496.html [2] http://udd.debian.org/cgi-bin/key_packages.cgi [3] http://anonscm.debian.org/gitweb/?p=collab-qa/udd.git;a=blob;f=web/cgi-bin/key_packages.cgi I think that having such criterias, and such a list of packages, would be useful to better direct the work of RC bug-fixing. For example, there are currently 1517 RC bugs affecting sid, but only 287 RC bugs affecting sid's key packages. Of course, fixing all those 1517 RC bugs would be very nice, but we might want to focus first on the 287 bugs, as those are the ones really preventing Debian from being releasable. Typically, the "key package" criteria could be used as a filter on http://udd.debian.org/bugs.cgi . Could you please comment on the criterias for key packages? I would like an "OK" from the release team before adding this to bugs.cgi, so that it's not just "lucas made up those criterias". Thanks, Lucas -- 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/20130701062130.ga...@xanadu.blop.info
Re: boot ordering and resolvconf
]] Helmut Grohne > * Treating an empty /etc/resolv.conf as a permanent error or failing >to discover changes in /etc/resolv.conf later on. > * Changing /etc/resolv.conf during startup of a local dns cache. > > So if /etc/resolv.conf is declared to be static (A), then the second > practise is broken. And if dynamic modifications are to be supported > (B), then the first practise is broken. I think changing /etc/resolv.conf automatically is broken at all. We should have a generated /run/resolv.conf that's overridden by the settings in /etc/resolv.conf (if it exists). This allows you to have a consistent set of domains searched for matching hosts even when roaming to other networks. It also allows me to express the preference «I want to use localhost as a nameserver, always» without resorting to chattr to prevent dhclient, NetworkManager and other tools from auto-updating the resolv.conf file. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m2ppv27pdv@rahvafeir.err.no
