Re: Bug#437392: debhelper: subroutine "isnative" in Dh_Lib.pm is confused by NMU of native package
On Tue, Aug 14, 2007 at 01:38:04PM -0400, Joey Hess wrote: > Bart Martens wrote: > > Policy does not explicitly state that the presence/absence of a > > "debian_revision" or that the presence/absence of hyphen(s) "-" indicate > > whether or not the package is a "native Debian package". > > > > It is optional; if it isn't present then the > may not contain a hyphen. This format represents the case where > a piece of software was written specifically to be turned into a > Debian package, and so there is only one "debianisation" of it > and therefore no revision indication is required. > > This strongly implies that debian native packages don't use debian_revision. That's why it is in the normal case. > > > I don't know why the > > > developers reference choses to ignore that. Because it may be more important to be able to identify an NMU from the version number than to be able to identify a native package from the version number... > > Policy and developer's reference do not contradict explicitly on the > > version numbering of an NMU of a native package. > > The developer's reference chose to ignore or change a longstanding practice > of never using debian revision numbers in native packages. Changing this > breaks software that has relied on this practice for ten or more years. > Not just debhelper, but debstd and cdbs, and who knows what else. How does it break them? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mixing different upstream sources in one package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jay Jay Berkenbilt wrote: >>From time to time, someone announces an intention to package some tiny > script or program, and people suggest including it in some other > package instead to avoid pollution of the archive with lots of tiny > packages. Although I understand the reasoning and the issues here > (additional overhead for each package), this has always bothered me a > little. I'm not sure that, as an upstream author, I would necessarily > want the debian version of my package to be bundled with other > software that was similar in functionality but otherwise unrelated to > my package. > > I've recently taken over maintenance of psutils and am gradually > working through the outstanding bugs on that package. A few of the > bugs suggest adding external programs. Assuming there are no other > impediments (like licensing problems), do people generally think that > it's reasonable to do this even if the other packages aren't really > part of the upstream package? If so, are there usual mechanisms for > doing this? What about version numbers? > > My inclination would be decline requests to add unrelated packages to > psutils, but I thought I'd solicit input from others in case someone > has some perl (oops, pearl) of wisdom that I have overlooked. Thanks! Maybe you could consider to add a package psutils-addons or something similar? Cheers Luk - -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDf2WT5UTeB5t8Mo0RArGCAJ9+3kDynQ68OrCg1XOkQ5Wb9qgKEQCgzEGT Hu6Wb0xZdC4vbYZjdP136D8= =hk7a -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Automatic closing of bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin B. McCarty wrote: > Simon Richter wrote: > > >>Matthew Palmer wrote: >> >> >>>Your mission, should you choose to accept it, is dig through the Perl >>>code in merkel:/org/bugs.debian.org/scripts and work out how to add >>>this functionality. >> >>You can use "package foo" as a command to control@ to tell it ignore >>everything that does not affect bugs against foo. I am unsure whether >>comma notation is allowed (so katie could generate "package bar,wnpp" >>at the beginning of bug closing emails). > > > Yes, but for multi-binary source packages, the package changelog doesn't > specify which binary package the bug applies to, so katie would have no > way of knowing whether to say (e.g.) "package bar", "package libbar1", > or "package libbar-dev". I think this functionality would have to be > implemented on the BTS side. It could however say package bar,libbar1,libbar-dev and any package from the list will do :-) Cheers Luk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDkIAc5UTeB5t8Mo0RAlk4AJ0SHO6jk/rkkvDotYUh2WlxexVK7wCfZBBf ycGt76qfSA+A2GMtjnraHUM= =FBlm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Requesting NMU for toshutils
Roberto Sanchez wrote: > Greetings, Hi > Bug #346896 was recently filed against toshutils. I am not able to correct > this bug right now and would sincerely appreciate it if someone could NMU it > for me. I've tried to fix this bug, but the package FTBFS with the following error: gcc -mtune=i486 -O1 -Wall -I../pixmaps -DLINUX -DXTHREADS -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DVERSION=\"2.0.1\" -DBINDIR=\"/usr/bin\"\ -DXMESSAGE=\"/usr/bin/X11/xmessage\" -DWALL=\"/usr/bin/wall\" -c thotswap.c thotswap.c: In function 'DisplayXMessage': thotswap.c:187: error: 'XMESSAGE' undeclared (first use in this function) thotswap.c:187: error: (Each undeclared identifier is reported only once thotswap.c:187: error: for each function it appears in.) make[2]: *** [thotswap.o] Error 1 make[2]: Leaving directory `/home/luk/tmp/toshutils-2.0.1/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/luk/tmp/toshutils-2.0.1' make: *** [build-stamp] Error 2 Any hint to fix this is welcome. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: yorick package maintainer
David H. Munro wrote: > Hello, Hi > An etch release-blocking bug (#346861) has been reported against > my yorick package, as part of the mass xlib-dev build dependency bug. I could prepare an NMU if you like, though... > I'm ashamed to admit that I can't fix it myself because my PGP(!) > key is no longer supported by Debian. I've made a few attempts to > get myself reinstated via [EMAIL PROTECTED] and [EMAIL PROTECTED], > but so far no one has been able to help me. If anyone can help me get > back to the point that I can use the automated LDAP system described at > https://db.debian.org/doc-mail.html I would greatly appreciate it. > (Needless to say, I've followed the instructions posted there and the > [EMAIL PROTECTED] mail daemon does not respond, even when I > sign the request with the obsolete PGP key that is used to sign the > current yorick-1.5.14-1 package.) you might want to have a look at [1] as that is the procedure to follow to have a new key added to the keyring when you don't have any existing valid key anymore AFAICT. > Thank you very much for any help you can provide; I apologize for > letting things slide for so long. You're welcome :-) Cheers Luk [1] http://keyring.debian.org/replacing_keys.html -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)
Steinar H. Gunderson wrote: > On Fri, Jan 13, 2006 at 12:03:28AM +0900, Charles Plessy wrote: > >>Of course, this is trivial, but fixing this bug (251 days old) is >>also trivial. Then why complain ? I feel that it gives a bad image of >>debian, when it suggests to use a broken tool while another one is being >>repaired. I agree and have sent an intention to NMU. Though like Jesus Climent mentioned in the bug log, it could actually be seen as 2 bugs: a wishlist bug for trying alternatives and a release critical (at least IMHO) bug about not depending on packages which are used by the package. > But if you read this bug (#307833), you'd see that the maintainer doesn't > consider it a bug, and has documented why in the README file. It is a bug as the package is not usable without curl or wget installed. Though, I give him a chance to respond to my intention to NMU... > You could of course disagree about whether it's a bug or not, but in that > case, you would want to appeal to the tech-ctte, not debian-devel. ...before going to the Technical Committee. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)
Anthony Towns wrote: > On Thu, Jan 12, 2006 at 06:48:38PM +0100, Luk Claes wrote: > >>>But if you read this bug (#307833), you'd see that the maintainer doesn't >>>consider it a bug, and has documented why in the README file. >> >>It is a bug as the package is not usable without curl or wget installed. >>Though, I give him a chance to respond to my intention to NMU... > > > An NMU is not the place to "fix" things that the maintainer has > specifically said aren't bugs. Well the maintainer doesn't tag the bugs wontfix nor closes them all, so he probably thinks it *are* bugs that don't need immediate attention? >>>You could of course disagree about whether it's a bug or not, but in that >>>case, you would want to appeal to the tech-ctte, not debian-devel. >> >>...before going to the Technical Committee. > > > I'm sure Florian'll be giving you a serve for being so threatening any > moment now... Sorry, I don't meant to threaten anyone, I was just saying that I first want to try all other means before I would consider going to the Technical Committee. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Debian Games Team
Miriam Ruiz wrote: > Hi, Hi Miriam > We've been recently talking about creating a group to maintain games in Debian > in a collaborative way. As a starting point, I've created a mailing list in > alioth for coordination, and also for create discussion threads about the main > problems related to game development and games packages in Debian. You can > join that list at: [...] > You're welcome to join the group, or say whatever you think about this > project. I think it's a marvellous idea as gaming is one of the aspects that is IMHO still underrepresented in Debian :-) Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)
Jesus Climent wrote:
> On Thu, Jan 12, 2006 at 12:07:02PM -0600, Bill Allombert wrote:
>
>>There are technical ways to solve the problem (e.g. to depend on
>>wget|curl and to detect which one is available at start up).
>>
>>If the mainatiner is willing to give more input than 'it is not a bug'
>>on what behaviour he would accept, we can probably come up with a patch.
>
>
> That would be an ideal solution, which was already proposed in
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307833;msg=75
Indeed, though I think it's rather another wishlist bug...
> And was responded on a mail (dunno remember if to the bug, to d-d or on IRC)
> that the user can utilize several other download managers, but that defeats
> the whole purpose of having it done automatically. Besides, if that is the
> case, the maintainer can find the most common downloaders and put them as |
> dependencies, and receive patches to add config snipets for the most common
> case.
and this answers IMHO what the maintainer wants a patch for: a system
that would work with all download managers.
> Depending on some basic utilities (wget is installed by default on a debian
> system) and not providing a simple check for finding the one which is already
> installed and use it, instead of giving an error that does not explain the
> nature of the problem (heh,
> [ -x $(which curl) ] || { echo "install curl or modify /pathtoconf" ; exit 1;}
> would do it) is nonsensical.
>
> The current intent to NMU is not solving the problem, since depending in
> wget|curl and having to modify the config file leads to the same problem if
> the config points to curl and the user has wget.
The current intent to NMU is proposing curl | wget which doesn't need
any modification to the config file if curl is installed. Though you're
right that you still need to change the config file when curl is not
installed. This is IMHO however not a *severe* bug as some packages need
configuration if you don't choose to use the default.
Cheers
Luk
--
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D
signature.asc
Description: OpenPGP digital signature
Re: What's wrong with update-excuses?
Frank Küster wrote: > Hi, Hi > http://qa.debian.org/developer.php?excuse=tetex-base > > says that tetex-base is 0 days old. However, unstable has 3.0-13 which > was uploaded on Jan 18th: > > http://lists.debian.org/debian-devel-changes/2006/01/msg01818.html > > Is this just a bug in the qa scripts, or worse? It's just a matter of britney not been running the last couple of days AFAIK (though it has run today... so it will probably be shown as 1 days old tomorrow?). Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: What's wrong with update-excuses?
Frank Küster wrote: > Luk Claes <[EMAIL PROTECTED]> wrote: > > >>Frank Küster wrote: >>>http://qa.debian.org/developer.php?excuse=tetex-base >>> >>>says that tetex-base is 0 days old. However, unstable has 3.0-13 which >>>was uploaded on Jan 18th: >>> >>>http://lists.debian.org/debian-devel-changes/2006/01/msg01818.html >>> >>>Is this just a bug in the qa scripts, or worse? >> >>It's just a matter of britney not been running the last couple of days >>AFAIK (though it has run today... so it will probably be shown as 1 days >>old tomorrow?). > > > Hm, does that mean that I will have to wait 10 days more for the testing > transition? Or will the testing script detect the mismatch? No, the Release Team can change that, though they won't if not everything is ready (like more RC bugs in version in unstable than in the one in testing)... Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Request for key signing help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Roberto > I am looking for someone to sign my gpg key. I have contacted > the three people listed as offering to sign keys in Ohio [0], > but I have received no response after a few days. Anibal > suggested I ask on d-d. So, if anyone is able to sign my gpg > key so I can get recognized by the front desk, I would > appreciate it. Please reply off-list and we can make arrangements > to meet. > > -Roberto > > [0] http://nm.debian.org/gpg_offer.php If you don't find someone to sign your key, you can register a keysigning request on [1] (which looks very similar as [0] indeed). I'll also contact the remaining DDs in the neighbourhood and ask them to contact you. Cheers Luk [1] http://nm.debian.org/gpg.php PS: The contact address for keysigning coordination is [EMAIL PROTECTED] as listed on the Debian's Organizational Structure page [2] [2] http://www.debian.org/intro/organization -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCjc3j5UTeB5t8Mo0RAkGpAJ42cYf+GZO6scLstI7WYFKY133O/gCdEuPG UjdkECP+xf8RCaRt6eDA4AY= =yAYX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: namespace conflict != package Conflict?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Majer wrote: > Sebastian Kuzminsky wrote: > > >>Hi folks, I have a noob question for you. I maintain the Cogito package >>(my first), and it wants to install an executable as /usr/bin/git. The >>GNU Interactive Tools package (git) also wants to install an executable >>as /usr/bin/git. To avoid this conflict I made cogito Conflict with git. >> >> >> > > Of course this is *seriously* wrong. Why are you preventing people from > using git and cogito together? > > >>I have been told by Jurij Smakov that this is "seriously wrong", and >>I'm asking for help here. What's the proper way to handle this situation? >> >>The cogito /usr/bin/git is a tiny little helper script hardly worth its >>inode, but it's in the upstream package and I dont want to remove it or >>rename it. >> >> > > rename /usr/bin/git to /usr/bin/cogito-git or whatever. It is not that hard. Or why not usr/bin/cogit or usr/bin/git-common or something like that? Cheers Luk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCqS3h5UTeB5t8Mo0RAi55AJ4ivcDX0iBqNg7L1dYn9EFQx5O3gQCgzZIl LWFhYzqINl8/N3hgyDzzo+s= =yLSy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Transitioning packages to testing that are not built anymore on some arches
Hi There are quite some packages mainly in contrib and non-free that aren't built anymore on some (release) architectures. These packages don't transition to testing as that would mean a regression. Though it's not always feasable/better to have these packages built on all arches where they once built. There are two solutions to get these kind of packages into testing. The first and in many cases best solution is to get these packages built on the missing architectures. Though sometimes it might be better to ask for removal of the existing binary packages on architectures where the package is not built anymore which is the other solution to get these kind of packages into testing. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Firmware poll
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 6c557439-9c21-4eec-ad6c-e6384fab56a8 [ 1 ] Choice 1: Release etch on time [ 3 ] Choice 2: Do not ship sourceless firmware in main [ 2 ] Choice 3: Support hardware that requires sourceless firmware [ ] Choice 4: None of the above -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Of course I have to choose releasing etch on time first as a RA :-) As I want to have all hardware supported (in some way or another), that's my second option. As I can live with shipping sourceless firmware in main, I put it above NOTA. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Buildd maintenance for dummies
Hi I recently took over the buildd maintenance of signy.farm.ftbfs.de, a mips buildd for experimental, sarge-backports, sarge-volatile and non-free (whitlisted packages). I actually started in helping with the buildd maintenance of odin.farm.ftbfs.de which is a similar buildd for sparc. As newbie I made some stupid mistakes... I hereby want to announce a wiki page to make sure newbies in buildd maintenance don't make this mistakes again :-) The wiki page [0] only talks about answering to build logs as there is already some decent information for setting up and configuring a buildd host and wanna-build [1] [2] [3]. Don't hesitate to add or improve content of the page, it's a wiki page after all... Cheers Luk [0] http://wiki.debian.org/Buildd/BuildLogs [1] http://kmuto.jp/open.cgi?buildd [2] http://www.debian.org/devel/buildd/ [3] https://db.farm.ftbfs.de/farm-reference/index.en.html -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Source package contains non-free IETF RFC/I-D's
Simon Josefsson wrote: > Some raised a concern with false positives in my reports -- and also > tagged all the bugs with etch-ignore. I went through all bug reports > manually yesterday (see earlier mail), but I also realized that it > would be possible to do this automatically, to provide further > assurance that the bugs indicate real and confirmed problems. Note that it was not the only reason to tag them etch-ignore... > I've updated my script to do this, view it last on the page: > http://wiki.debian.org/NonFreeIETFDocuments > > The script will run md5sum on the RFC/I-D in source packages, and > compare them against a known-real repository (rsync'ed against > ftp.rfc-editor.org). > > The output of the script is very long, so I won't include it here. An > URL to it is: > http://josefsson.org/bcp78broken/debian-ietf-documents-diff.txt > > To parse the output yourself, look for lines beginning with 'pkg'. > Those denote the start of a new package with potential problems. > After that there will be lines such as 'tar xfz...' and two MD5 sums. > If the MD5 sums match, it will print MATCH. If the MD5 sums mismatch, > it will print MISMATCH. If it can't find a known-good file to compare > with, it prints FETCH-FAIL. > > Some statistics: > 74 packages > 401 MATCH, i.e., the RFC in the source package is an authentic RFC > 79 MISMATCH, i.e., the RFC differ from the authentic RFC >6 FETCH-FAIL Note that not all authentic RFC documents have the same license, some of them are probably even DFSG compliant... So there can be more than 79 false positives... Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: First draft of review of policy must usage
Manoj Srivastava wrote: > Hi, Hi Manoj Can everyone please focus on the release and discuss things that don't help to release on December 4th at all till after that date? Thank you very much. Luk PS: For those people that seem to think they can't help: there is still a long list of RC bugs, the release notes definitely still need work, translations can still be improved, installation and upgrade tests are always welcome... -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: First draft of review of policy must usage
Manoj Srivastava wrote: > Dear Luk, > > On Wed, 25 Oct 2006 08:16:59 +0200, Luk Claes <[EMAIL PROTECTED]> said: > >> Manoj Srivastava wrote: >>> Hi, > >> Hi Manoj > >> Can everyone please focus on the release and discuss things that >> don't help to release on December 4th at all till after that date? > >> Thank you very much. > > The next time you feel the urge to be patronizing, ponder on > these: > a) what gives you the right to pontificate and tell people what to > do from your high horse? Look who's talking... > b) Why do you think getting on a soap box is likely to help > anything, including a dialogue on this list? I don't understand this sentence: 'getting on a soap box'? > c) that for some of us doing things right trumps releasing on some > arbitrary deadline hands down? Same for 'trumps' in previous sentence. > Part of doing things right it to lick the technical policy in > shape; reviewing the must directives for bloat has been long > overdue. If the policy is so far from reality that release managers > do not consider violation of must directives as something that would > compromise the high standards of what Debian considers fit for > release, then it seems to me we need to fix policy. You keep putting things in the release managers' mouth... It's not because in some cases the must in policy isn't considered RC that release managers think violation of must directives is ok to release with in general... > Now, if you can stop lecturing and review the changes, and > provide feedback on whether my judgement for thechanges is on the > right path, you would be helping. If noit, could you please let the > rest of us work on getting a better technical policy out? I don't like the timing at all. As you said above it's long overdue, so I don't see why it should happen near release time? Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: First draft of review of policy must usage
Joerg Jaspert wrote: > On 10818 March 1977, Luk Claes wrote: > >> Can everyone please focus on the release and discuss things that don't help >> to >> release on December 4th at all till after that date? > > No, the release is no reason to stop everything else. > It was not meant that way at all. I just don't like that people start to discuss topics that are long overdue near release time... Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: First draft of review of policy must usage
Manoj Srivastava wrote: > On Wed, 25 Oct 2006 18:51:26 +0200, Luk Claes <[EMAIL PROTECTED]> said: > >> Joerg Jaspert wrote: >>> On 10818 March 1977, Luk Claes wrote: >>> >>>> Can everyone please focus on the release and discuss things that >>>> don't help to release on December 4th at all till after that date? >>> No, the release is no reason to stop everything else. >>> > >> It was not meant that way at all. I just don't like that people >> start to discuss topics that are long overdue near release time... > > In a project this size, not all activities come to a dead end > every couple of years for a few months. Consistent with releasing, > activities geared towards improving the infrastructure, subsystems, > and packages can and should still be on going. Indeed, though starting such discussions near release time is unfortunate at the least... > The reason I have initiated this at this point is that I was > not aware that policy is perceived to be so far out of whack with the > project processes that violations of MUST directives in policy are > considered to be unrelated to bugs serious enough to warrant > fixing -- and that policy directives linking ciolations to bug > severities are now considered an unreported bug in policy itself. I rather see policy as a guideline for long term compliance, but the etch RC policy for short term compliance. Of course there are some bugs in policy and it's indeed a good idea to review the consitency, but I think you overreact when you say that must directives in policy are unrelated to serious bugs... > Also, consider the fact that we are all (for the most part), > volunteers. there a re number of demands on our time. Real life > intervenes. Private and pet projects go hot or cold. the release > process is just one such drain on our timel but there are others. Right, though a release should be a common goal. It should be a joined effort... > For a process like a broad review of policy, where one needs to get > the buy in and eye balls of a large group of developers, it is > impossible to pick a time that is convenient for every one. Sure, but that's something else than not a really good time for anyone... > Unlike Etch, there is no pressing directive that policy review > be all done by Dec 4rth; we can and should take our time and do > this _right_. Correctness and completeness should be preferred over > speed at this point. This is true for release work too, but the time between releases should be manageable. If we release on Dec 4th with nasty bugs, I'd rather have we release at middle or end of december without these nasty bugs... Sorry if my message came across too harsh, but I do think quality of the release is more important than quality of the policy at the moment and not only because I'm on the release team, but because I as a user want to still be proud to be part of Debian after Dec 4th :-) Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: madison not working correctly on merkel
Julian Gilbey wrote: > I've noticed (and I'm not the only one) that the package database as > access by madison on merkel is no longer up-to-date. Does anyone know > why? Could someone rectify this situation, please? The updates have not been reactivated since the move of ftp-master.d.o AFAIK. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Explications needed...
Pierre Habouzit wrote: I happened to have had access to the internet during my vacation, and I happened to read a backlog on #debian-release that frightens me: 15:52 aj | "# unilateral action to run an emulated buildd -- all arm changes sidelined until fixed." 15:52aba | oh, where? 15:52 aj | cron.unchecked, -> queue/delayed [...] 15:58aba | (and btw, I would expect that ftp-master send someone who runs such buildds mail to please stop it ...) [...] 16:18 aj | and now aurel32 will presumably fly off the handle 16:22aba | aj: I don't think that is a good idea either if the porters do uploads - i.e. blacklisting is probably better than whitelisting 16:23aba | aj: and please let e.g. people upload to non-free and experimental, e.g. tbm or kmuto 16:28 aj | aba: not at this time Aurelien mailed debian-arm, went to #debian-arm, had no response. He then warn about his intention [1] to run qemu-based autobuilders to fill the gap due to broken arm buildds. He did that on the open, and got ... zero answers. I must say I'm shocked to see he has not been contacted yet, to kindly ask him to stop. This looks like a petty personnal war, whereas aurelien did a wonderful work. So, why : * does aurelien initiative causes troubles ? * aurelien hasn't been contacted by the ftp-master team first ? aurelien is really easy to contact, so there is no excuse to this completely inadequate behavior. * do someone found the time to blacklist everybody except elmo, whereas no one found the time to fix the arm build daemons ? I also noted that now that only elmo can upload arm packages, the whole arch:any packages migration to testing can be stuck by a single man, I really really ask the DPL that took this decision to (1) reconsider, (2) explain himself about that. Full quote as Aurelien was not Cc-ed... First I don't think the DPL took that decision... How did Aurelien get wanna-build access for his buildd without explaining to the respective team how the buildd was maintained in the first place or did he not ask for it... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#322762: no blocking bugs anymore
Daniel Schepler wrote: > On Friday 05 January 2007 20:56 pm, Thijs Kinkhorst wrote: >> Hi, > It appears that inform's postinst still creates a /usr/doc symlink, and this > seems to have been missed. > > What's the appropriate severity for a bug to be filed against inform? important Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: etch before vista
Joerg Jaspert wrote: > On 10603 March 1977, A. Mennucc wrote: > > [...] > > Nice. > > >>I hope we do manage to release in Dec 2005 (and I thank people who >> work hard to this end). > > > We wont, im sure. Can you please elaborate on specific problems you think will not be solved on time? Cheers Luk PS: Please, don't send this kind of messages if you can't elaborate or at least put a smily behind it so we know you don't really mean it :-) -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Keysignings and other "meetups" (Was: etch before vista)
Jeroen Massar wrote: > On Sat, 2006-03-25 at 11:53 -0500, Benjamin Seidenberg wrote: > >>Kevin Mark wrote: >> >>>On Fri, Mar 24, 2006 at 09:28:47PM -0500, Benjamin Seidenberg wrote: >>> >>> >>>>Kevin Mark wrote: >>>> >>>> >>>>>Hi *, >>>>>I noticed on occassion on -devel and planet that folks mention in passing >>>>>that "I'll be in MN in US from MAR 01 thru 05" and I'd like to have a >>>>>beer and do keysigning. Would it be worthwhile to create a list like >>>>>'debian-meetup' (or debian-beer-meetup x-))that would allow folks to >>>>>give this info on what would be a low-volume list. > > [..] > > >>I was thinking more about how easy it is to access old data. > > > You might want to check https://www.biglumber.com/ which contains > already a very nice interface for all of this. Or you might want to use https://nm.debian.org/gpg_offer.php. Have a look at https://nm.debian.org/gpg.php if you want to be listed... Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: GPG signing of debian packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 gregor herrmann wrote: > On Sat, Apr 15, 2006 at 10:19:33AM +0200, [EMAIL PROTECTED] wrote: > >> >> dpkg-deb: building package `sshguard' in `../sshguard_1.0.0-4_all.deb'. >> signfile sshguard_1.0.0-4.dsc >> gpg: skipped "Tomas Davidek <[EMAIL PROTECTED]>": secret key not >> available >> gpg: [stdin]: clearsign failed: secret key not available >> >> The name and email address match those which I used for key generation, so >> this should be ok. Maybe one has to specify the sign-command (-p) in >> dpkg-buildpackage ? If so, how does such a command look like ? Or is >> there anything else wrong ? If you're the (co-)maintainer of the package the string in debian/control should match the string in debian/changelog and in the uid of your key... If the "John Doe <[EMAIL PROTECTED]>" doesn't match 100% you'll get the above failure... >>From man dpkg-buildpackage: > >-kkey-id > Specify a key-ID to use when signing packages. This is only needed when the Uploader in debian/changelog doesn't match an uid of the key (sponsoring) AFAIK. Cheers Luk PS: This kind of questions should be sent to debian-mentors@lists.debian.org - -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEQPrr5UTeB5t8Mo0RAuutAJ4rIa+MPpapQ0UUgokG6uXBIadEGgCgk3qY xGmvKZajOILXoCkI5w15Sjg= =iKYB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPG signing of debian packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Metzler wrote: > [EMAIL PROTECTED] wrote: >> Dear experts, >>I am trying to build my own debian packages with GPG signature. I set >> up gnupg, ran gpg and gpg --gen-key and also filled the variable >> default-key with my generated keyID in ~/.gnupg/gpg.conf. I thought that >> this is all I have to do, since Debian Maintainer's guide claims that >> dpkg-buildpackage -rfakeroot >> needs as the input the secret passhprase (twice). I expected I >> would be asked for the passphrase, but it's not the case. > [...] > > Hello, > I think question has been answered already, just a tidbit: > > - I personally always run dpkg-buildpackage with -uc -us and use > debsign -kkeyid foo_changes to sign the /final/ packages > afterwards. I usually build the packages more than once before > uploading as I often find some last-minute bug, and don't like to > type in my gpg-passphrase more frequently than necessary. Even than you should not need to specify the -kkeyid... Cheers Luk - -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEQRbY5UTeB5t8Mo0RAs2NAKCZu5scoMYGMoHEnn5kEM/3+Av2OgCfW9Rn aASp4/h78E1hdVf4YRxXrJA= =WXnC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362809: ITP: libcrypt-openssl-bignum-perl -- Perl module to access OpenSSL multipresicion integer arithmetic libraries.
Package: wnpp Severity: wishlist Owner: Luk Claes <[EMAIL PROTECTED]> * Package name: libcrypt-openssl-bignum-perl Version : 0.03 Upstream Author : Ian Robertson <[EMAIL PROTECTED]> * URL : http://cpan.org/ * License : same as Perl Programming Lang: Perl Description : Perl module to access OpenSSL multipresicion integer arithmetic libraries. Presently, many though not all of the arithmetic operations that OpenSSL provides are exposed to perl. In addition, this module can be used to provide access to bignum values produced by other OpenSSL modules, such as key parameters from Crypt::OpenSSL::RSA. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362956: ITP: libcrypt-openssl-rsa-perl -- Perl module providing basic RSA functionality.
Package: wnpp Severity: wishlist Owner: Luk Claes <[EMAIL PROTECTED]> * Package name: libcrypt-openssl-rsa-perl Version : 0.23 Upstream Author : Ian Robertson <[EMAIL PROTECTED]> * URL : http://cpan.org/ * License : like Perl Programming Lang: Perl Description : Perl module providing basic RSA functionality. Provides a glue to the RSA functions in the OpenSSL library. In particular, it provides the following functionalities: create a key from a string, make a new key, save key to a string, save public portion of key to a string using format compatible with OpenSSL's command-line rsa tool, encrypt, decrypt, sign, verify, return the size in bytes of a key, check the validity of a key. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362953: ITP: libcrypt-openssl-dsa-perl -- Perl module which implements the DSA signature verification system.
Package: wnpp Severity: wishlist Owner: Luk Claes <[EMAIL PROTECTED]> * Package name: libcrypt-openssl-dsa-perl Version : 0.13 Upstream Author : T.J. Mather, E <[EMAIL PROTECTED]> * URL : http://cpan.org/ * License : like Perl Programming Lang: Perl Description : Perl module which implements the DSA signature verification system. A wrapper to the DSA (Digital Signature Algorithm) functions contained in the OpenSSL crypto library. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362957: ITP: libcrypt-openssl-random-perl -- Perl module for RSA encoding and decoding, using the OpenSSL libraries.
Package: wnpp Severity: wishlist Owner: Luk Claes <[EMAIL PROTECTED]> * Package name: libcrypt-openssl-random-perl Version : 0.03 Upstream Author : Ian Roberts <[EMAIL PROTECTED]> * URL : http://cpan.org/ * License : like Perl Programming Lang: Perl Description : Perl module for accessing the OpenSSL pseudo-random number generator. Provides the ability to seed and query the OpenSSL library's pseudo-random number generator. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: utnubu-desktop for the masses
Joey Hess wrote: > Mike Bird wrote: >> Metapackages are great. Need to add KDE to a system? Wham. Done. >> If you don't like them, don't install them. > > The kde metpackage is a spacial case, since KDE is all one related > thing, that shares a release schedule. And yet it still causes many of > the problems I mentioned. This is why you'll see the release team time > and time again having large transitions involed in getting KDE into > testing. The gnome metapackages have the same issues. Note that the KDE meta packages are only really taken care of near a release because of the transitioning problems... If the meta packages get to testing earlier it's very probable they will not be installable for a long time... Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: NMU procedure and /usr/bin/nmudiff defaults
Adeodato Simó wrote: > Hi all, Hi > for those who don't know, nmudiff is a small script by Steinar H. > Gunderson that, when invoked in the source tree of a NMU, will create a > diff with respect the previous version, and send it to the BTS. I've > found it quite useful myself, and probably others have as well. Yes, indeed! > By default, the current version of nmudiff opens a new bug against the > package and attaches the diff to it. I recently submitted wishlist > #370056 against devscripts so nmudiff behaves like this only if --new is > passed, and by default sends the patch to the bugs the NMU fixes. I always thought sending the patch to existing bugs is better... Though opening a new bug when NMUing has the advantage that more maintainers explicitely acknowledge NMUs instead of just use the NMU, but letting the respective bugs being tagged fixed without closing them. > So, to summarize, I think introducing --new as non-default is a good > change, but more opinions are welcome. I do think the option of just sending the patch to existing bugs is required and in many cases even preferred. >> Yes, I recognize that; however, I don't like the approach when there are >> multiple bugs involved. OTOH, this is a bit of a personal issue, and as you >> say, the method of not opening a separate bug might be more common these >> days. I can understand it especially after having opened a new bug when NMUing for some time now... >> Actually, I think what _should_ be done on this, is to establish some kind of >> consensus on what's the right thing to do, document it in the developer's >> reference and then decide on the default. This is especially true since >> what's "right" yesterday might not be "right" today or tomorrow, with the BTS >> gradually getting full version tracking (so, the need to actually track bugs >> fixed in NMUs this manual way would completely go away). I'm not sure what >> the future holds here, and I'd like to get some input on it from someone >> more knowledgeable before this goes in. I do think that both options (sending patches to existing bugs and opening a new bug) are appropriate, though I dislike not sending any comment to an existing bug report when the package is uploaded to the (not zero days) delayed queue or when the package enters the NEW queue. Because of this some people might prefer to send the patches to existing bugs when NMUing even if there are many bugs involved... To summarize: I would like the patch to be applied and I propose to not change the existing wording about NMU practice (at least not excluding one of the two existing options). Cheers Luk PS: As a sid note, I would like people to also have a look at the l10n, documentation and porting bugs (at least) when NMUing for RC bugs... -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Getting the buildds to notice new architectures in a package
Ludovic Brenta wrote: > Hello, Hi Ludovic > Package asis (=3.15p-10) supports i386, kfreebsd-i386, sparc, and > powerpc. > > I uploaded the next version (=2005-3) a couple of days ago. It adds > support for more architectures, namely: amd63, hppa, and ia64. You should contact the buildd maintainers (actually the Packages-arch-specific maintainers [1]) when you add support for an architecture. > I notice that the buildds have successfully built the powerpc and > sparc packages, but seem to ignore the new architectures. I am > waiting for all architectures to be rebuilt so that I can re-upload > adacontrol, which build-depends on asis. In the mean time, adacontrol > has a RC bug #378160 because of this problem. > > Where should I ask for help? Neither buildd.debian.org nor > www.debian.org/devel/buildd, mention where the buildd admins can be > reached; and lists.debian.org does not have a "buildd@" list. @buildd.debian.org is the way buildd admins can be reached. > I will upload ~20 source packages in the next few weeks, adding > support for more architectures to each package. So I'm really looking > for a general solution and not one that only applies to asis. This is already known by the Release Team, I'm not sure if the news has already reached the P-a-s maintainers... > PS. Please reply to me directly, as well as to the list. Ok. Cheers Luk [1] These maintainers are listed at the top of the file http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Disturbing uploads (Re: release update: Etch 4.0, Blockers and Goals, Arch status, kernel 2.4, etc)
Marc Brockschmidt wrote: > Please note that as of now, RC bugs and problematic transitions are our > main concern. There has been progress, but we still need to lower the > number of release critical bugs further. There will be a couple of Bug > Squashing Parties soon, so please consider to join one or more of them. [1] > > We want to ask you to not do disturbing updates of your packages in > unstable without contacting the release team before. If you need a staging > area or simply want to use Debian infrastructure to show newer packages, > you can always upload to experimental, which is nowadays mostly autobuilt. [2] Probably everyone know one should avoid problematic transitions and disturbing updates of packages, though what looks like a simple change in your package might be a disturbing update and might cause a problematic transition... A simple example would be changing the name of a library package which has a couple of reverse dependencies. This doesn't look that disturbing at all... but has the potential to cause major trouble for testing transition... Another example would be uploading a package which links some transitions together... The first example can cause trouble if the old package is not available anymore (as virtual package or oldlibs for instance) as all packages depending on the library package become instantly uninstallable, you might want to look at [1] for some hints to avoid trouble with this kind of upload. These uninstallables might cause other uninstallables, failures to build and a harder testing migration as all these packages need to be installable again before they can all together transition to testing... The second example looks innocent from a package maintainer's point of view as it might only involve small fixes in packaging or documentation or whatever. Though it can make life of the Release Team quite hard. Without the intention to point fingers, lets look at a real life example, just to show you how things work: Looking at [2] you see the perl transition which involves 60 packages (recursively). If you click on perl you see the list of 60 packages. Looking at these packages you can find out that there are 4 of them which link other transitions with the perl transition: obexftp, subversion and rapidsvn. obexftp links the bluez-libs transition with the perl transition, subversion links the neon transition with the perl transition and rapidsvn and pdl link the wxwidgets2.6 transition with the perl transition. The perl transition is due to the way perl dependencies are handled for the moment: it makes sure the package will be installable as it depends on the most recent perl the package was built with. The bluez-libs transition is actually a transition like the pattern in the first example. This transition involves 14 source packages (13 extra). kdepim links in the gnokii transition which luckily doesn't involve extra packages. The neon transition involves 20 source packages (8 extra), though these 8 don't link other transitions with the neon one. The wxwidgets2.6 transition involves 12 packages (10 extra), though these 10 also don't link other transitions with the wxwidgets2.6 one. So all these packages should enter testing together unless they will still be installable in testing and the version in unstable is not ready to enter testing yet (not old enough, RC bug, not built on all release arches...) To conclude, please try to avoid linking transitions together and try to avoid making packages instantly uninstallable if possible. Cheers Luk [1] http://wiki.debian.org/TransitionBestPractices [2] http://bjorn.haxx.se/debian/stalls.html -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: device nodes with udev?
Miles Bader wrote: > [EMAIL PROTECTED] (Marco d'Itri) writes: > >>>I presume that default kernels need legacy ptys to support older systems >>>that don't use udev, right? >> >>Wrong. Nothing needs BSD ptys but some *very* old applications (I would >>not even know where to find one). > > > I was thinking about the case where someone has a (very old) static /dev > and simply never bothered to add /dev/pts (though I don't know if such a > configuration would even work in a modern debian). > > In any case, does anyone else know if there are really such old > applications still around? > > -Miles FWIW, I just remove udev and revert to static /dev because I did not get udev to create /dev/fd0 for me. It happen to both kernel version 2.6.12 and 2.6.14. I think older version of udev (before 0.70?) have no such problem. Regards, ST -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [rfc] mass-mod old ita/itp bugs back to rfa/rfp?
Sebastian Pipping wrote: > i noticed that there exist many ita/itp bugs that are much older than > two month. would it make sense to set them back to rfa/rfp? > if so how many days would be good to be the "too old" edge value? There is already a process that does that, though it takes into account any follow-up on the bug report to reset the timer which you clearly don't... > click this to get a quick overview: :-D > http://debian.binera.de/wnpp/?type%5B%5D=ITA&type%5B%5D=ITP&sort=age;desc Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removal of xmms and its reverse-dependancies - what is the status?
Marcin Owsiany wrote: > An xmms rev-dep I maintain (xmms-xf86audio) is useless without xmms, and > not really portable to any of its replacements. Therefore I agree it > should be removed if xmms is removed. However: > > - the reporter said to ask for removal after xmms is removed > - the ftpmaster removal wiki page says reverse-dependancies should >usually be removed first. > - #461309 (against ftp.debian.org) is tagged moreinfo > - the thread mentioned in #461309 is dead > > So what's the status? Is xmms removal decided yet, or not? Should I ask > for xmms-xf86audio removal now, or wait? xmms removal was decided some time ago. Yes, if the package is useless without xmms and cannot be adapted to one of xmms' alternatives, you should ask for removal of your package. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removal of xmms and its reverse-dependancies - what is the status?
Sebastian Pipping wrote: > Luk Claes wrote: >> xmms removal was decided some time ago. > > i am working on a project partly depending > on parts of xmms. in case it is removed > i will need at least backups of all > related package sources so i can still > have the packages at my place. It would probably better to focus on one of the alternatives of xmms like audacious, xmm2 or bmpx... > where can i find more information about this? snapshot.debian.net might help if you really want to stick with xmms... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Processing of ip4r_1.03-1_multi.changes]
Robert Edmonds wrote: > I uploaded these[0] files last week and expected to see a corresponding > "ip4r_1.03-1_multi.changes is NEW" mail (due to the new binary package > postgresql-8.3-ip4r), but one never came, nor do I see the package in > NEW or incoming. Where did it go? > > I uploaded the package again last night but it similarly disappeared. > > [0] http://people.debian.org/~edmonds/ip4r/ It was rejected with the following message: Rejected: ip4r_1.03-1_multi.changes: Missing mandatory field `description'. You should have got a REJECTED mail telling you btw. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Mike Bird wrote: > On Mon February 11 2008 02:20:26 Cyril Brulebois wrote: >> On 11/02/2008, Mike Bird wrote: >>> On *production* Debian systems, saving 30 seconds in a boot which >>> may occur once a year for a kernel security update is not worth a >>> single broken script, nor a single failed backup, nor a single lost >>> data bit. >> Since you're talking about *production* systems, “stable” case above, >> so “not a problem”. > > Release notes do not offset the millions of person-hours needed to review > and maybe-rewrite and retest the millions of tiny shell scripts that have > been written and tested by millions of Debian users with no thought to the > possible consequences of subsequent changes to /bin/sh. > > Why do you believe it is better for Debian to harm millions of Debian > users rather than simply using #!/bin/sh.minimal within Debian scripts? Users don't have to upgrade if they don't want to or they could just change bin/sh to bin/bash in their scripts and be done with it. So no need to rewrite or invest time except for a simple script to change bin/sh to bin/bash. Like you said, it's production, so there is no need to upgrade at all... Any decent argument left? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
Nikita V. Youshchenko wrote:
> Hi
>
> I maintain libetpan package, which build-depends on libcurl4-gnutls-dev.
> Resulting library package dependency is calculated using ${shlib:Depends},
> however libdev package dependency on libcurl4-gnutls-dev is manually
> written in debian/control file. The build package dependency is valuable
> since -lcurl is among 'libetpan-config --ldflags' output.
>
> I've got a wishlist report (#467297), where reporter asks to add
> alternative dependency libcurl3-gnutls-dev for better backporting support.
>
> While it is easy for build-dependency (just use libcurl4-gnutls-dev |
> libcurl3-gnutls-dev), I see a problem here with libdev package dependency.
> It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on
> exact one that was actually used when building package.
In general alternative build dependencies are not recomended as we want
to have a predictable build process. The main thing when backporting is
changing build dependencies AFAICS. Normaly the intention is to change
as less as possible between the old version and the backported version's
environment unless necessary for new features AFAICT, so for someone who
is used to backport it should still be straight forward either way AFAICS.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Ian Jackson wrote:
> William Pitcock writes ("Re: dpkg semi-hijack - an announcement (also,
> triggers)"):
>> On Tue, 2008-03-11 at 22:06 -0700, Mike Bird wrote:
>>> It's easy to see negatives such as making it harder to merge
>>> long-awaited features. What positives do you see for Debian?
>> The horse is dead. Stop beating it.
>
> While I don't agree with everything Mike Bird has written and I think
> it would be better for him to avoid posting so much:
>
> It would be flogging a dead horse if we didn't have the core packaging
> software maintained by an obstructive and naive programmer supported
> by someone who is more interested in pretty revision logs than good
> code.
Confrontation is not going to solve this dispute in your advantage, on
the contrary...
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: s390 buildd?
Reinhard Tartler wrote: > Petter Reinholdtsen <[EMAIL PROTECTED]> writes: > >> [Steve Langasek] >>> The s390 buildd maintainer presumes to mark all packages as >>> 'Not-for-us' if he doesn't feel like building them for the arch, >>> without bothering to reach a consensus first together with the >>> maintainer, the ftp masters, or the maintainers of the P-a-s >>> overrides. >> Is the unilateral flagging of not-for-us being addressed in any way? > > Similar the ia64 buildd admin, see #464932. Or is there anything I could > do myself about this? Hmm, you do realise that lcd4linux is mentioned in P-a-s because it includes sys/io.h, right? So this is not similar at all... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to install Suggested (Was: Are all recommended modules equally important?)
Andreas Tille wrote: > On Wed, 19 Mar 2008, Charles Plessy wrote: > >> By the way, is there a way to install package with all the 'Suggest'ed >> dependancies, something like aptitude install bioperl --with-suggested >> ? I have >> not found anything in the manpage. > > Neither did I in man apt-get, man apt.conf, man apt-config, man aptitude > nor in the output of apt-get --help or aptitude --help. > I'm sure there was such a method mentioned before and I can not imagine > that there is no way to force installation of Suggested packages. So > I would regard this as a documentation bug - but before I'm going > to file a bug report I would like to hear the solution. > > Kind regards > >Andreas. > Hello Andreas, "man apt.conf" points you to /usr/share/doc/apt/examples/configure-index.gz. Maybe it has something you want. :-) Regards, ST -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to install Suggested (Was: Are all recommended modules equally important?)
Andreas Tille wrote:
> On Wed, 19 Mar 2008, LUK ShunTim wrote:
>
>> "man apt.conf" points you to
>> /usr/share/doc/apt/examples/configure-index.gz. Maybe it has something
>> you want. :-)
>
> Ahhh, nice place to hide some information. Users only have to
>
> $ find /usr/share/doc/apt -type f -exec zgrep -li suggest \{\} \;
> ./changelog.gz
> ./examples/configure-index.gz
I'm just a user, and not that sophisticated. :-)
[snipped]
>
> Any body else disagrees that this feature is missing or at least
> de-facto undocumented?
No, no disagreement from me. :-) It'd certainly be nice if all relevant
information are in one place, clear and precise. And a "man whatever"
gives you everything you want.
BTW, it just struck me that the style of the apt.conf manpage is
somewhat different -- more like some explanatory essay than telling you
how to do something. It relegates the details to an example document.
>
> Kind regards
>
>Andreas.
>
Regards,
ST
--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
Bas Wijnen wrote: > On Wed, Mar 19, 2008 at 11:37:07AM -0700, Russ Allbery wrote: >> Bas Wijnen <[EMAIL PROTECTED]> writes: >> We have other ways of tracking that information than the version, though. > > Yes, and I don't really care, I just think going from +s1+nmu1 to +s2 > seems to be doing things that it doesn't (revert the NMU). Strange reasoning as 1.0-0.1 followed by 1.1 is also not reverting an NMU perse... >>> So we should go for +deb31[+]_1 or something? To make it clear again: >>> >>> +deb is a fixed part which means this is a security upload >> Or any other stable upload, yes? > > Yes, sorry. I forgot that those exist as well. :-) Why are we bothering to make something up if everyone is using etch etc? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#472468: RFH: bash-completion -- programmable completion for the bash shell
Package: wnpp Severity: normal I request assistance with maintaining the bash-completion package. Upstream has handed over the maintenance, so working on the package is also working on upstream... I've set up an alioth project to coordinate, but the import of the history and current state still needs to happen. Any help with the initial setup as well as continued bug triage and/or co-maintainership is welcomed. The package description is: bash completion extends bashs standard completion behavior to achieve complex command lines with just a few keystrokes. This project was conceived to produce programmable completion routines for the most common Linux/UNIX commands, reducing the amount of typing sysadmins and programmers need to do on a daily basis. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#472470: RFH: update-inetd -- inetd.conf updater
Package: wnpp Severity: normal I request assistance with maintaining the update-inetd package. I've quite recently taken over the maintainership of update-inetd. Any help on bug triage and/or co-maintainership would be welcomed. The package description is: This package provides a program used by other packages to automatically update /etc/inetd.conf. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?
Peter Jordan wrote: > Hi, Hi > why are the keyrings of debian-multimedia.org and debian backports not > in the official repository of debian? > > At the moment you have to install untrusted keyrings before you can use > these repositories. Because they are no official Debian services (yet?). Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?
Peter Jordan wrote: > Luk Claes, 04/07/08 20:05: > >> Peter Jordan wrote: >>> Hi, >> Hi >> >>> why are the keyrings of debian-multimedia.org and debian backports not >>> in the official repository of debian? >>> >>> At the moment you have to install untrusted keyrings before you can use >>> these repositories. >> Because they are no official Debian services (yet?). >> > > but the repositories does not need to be official debian services, only > the keyrings should be available over the official debian repository. No, as that would imply that they are or at least will be official Debian services and open the door for every archive provider to ask for adding their key... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?
Ron Johnson wrote: > On 04/07/08 13:20, Luk Claes wrote: >> Peter Jordan wrote: >>> Luk Claes, 04/07/08 20:05: >>> >>>> Peter Jordan wrote: >>>>> Hi, >>>> Hi >>>> >>>>> why are the keyrings of debian-multimedia.org and debian backports not >>>>> in the official repository of debian? >>>>> >>>>> At the moment you have to install untrusted keyrings before you can use >>>>> these repositories. >>>> Because they are no official Debian services (yet?). >>>> >>> but the repositories does not need to be official debian services, only >>> the keyrings should be available over the official debian repository. >> No, as that would imply that they are or at least will be official >> Debian services and open the door for every archive provider to ask for >> adding their key... > > Governments need silly all-encompassing rule sets to appear fair. > Debian doesn't. IOW, adding debian-multimedia-keyring and > debian-backports-keyring doesn't mean that you've got to add every > other unofficial archive keyring, even though that archive's owner > screams "that's not fair!". Indeed, so we don't need to add these neither even though you scream it's unfair :-) There has to be a line somewhere and the current line makes sense to everyone, so I don't need we will change it... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
Stripping Ccs, in particular debian-release as it's no discussion list.
Goswin von Brederlow wrote:
> Ove Kaaven <[EMAIL PROTECTED]> writes:
>> Andreas Barth skrev:
>>> * Lennart Sorensen ([EMAIL PROTECTED]) [080415 22:26]:
>>> People, we want to release soon. Anyone is welcome to hack on feature in
>>> experimental, but please do not push for stuff to unstable which is
>>> expected to break stuff. If it wasn't important enough to push it during
>
> Have you read the patch? All it does is add more SEARCH_DIR("...");
> entries to the /usr/lib/ldscripts/ and correct the entries that are
> wrong now. The risk is virtually zero. Far far away from "expected to
> break stuff".
>
>>> the last 12 months, it isn't important enough to hold up the release
>>> now.
>
> It has been pushed since sarge. Unfortunately pushing doesn't mean
> anything will give. The glibc and gcc teams where nice enough to add
> the patches for multiarch support but binutils has just kept stubborn.
>
>> The way I understand it, they HAVE been pushing... and pushing... for
>> a long time... against a nonresponsive binutils maintainer. This
>> thread is just their latest, last-ditch effort since nothing else
>> worked so far. But I could be wrong, I guess.
>
> You are right. The patch has been around for years and requests for any
> response to the patch have just been ignored.
According to the bug log the patch was not ready when the maintainer
wanted to apply it and nobody bothered to start an NMU process...
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
Goswin von Brederlow wrote: > Luk Claes <[EMAIL PROTECTED]> writes: > >> Goswin von Brederlow wrote: >>> Ove Kaaven <[EMAIL PROTECTED]> writes: >>>> The way I understand it, they HAVE been pushing... and pushing... for >>>> a long time... against a nonresponsive binutils maintainer. This >>>> thread is just their latest, last-ditch effort since nothing else >>>> worked so far. But I could be wrong, I guess. >>> You are right. The patch has been around for years and requests for any >>> response to the patch have just been ignored. >> According to the bug log the patch was not ready when the maintainer >> wanted to apply it and nobody bothered to start an NMU process... > What bug are you reading? > > Sat, 27 May 2006 10:16:36 +0200: initial report with patch > Wed, 21 Jun 2006 00:48:26 +0200: NMU attempt gets vetoed Nope, this is only a patch with a mail subject 'Patch for pending NMU of binutils' > Wed, 28 Jun 2006 11:01:53 +0200: 2. maintainer misunderstands the patch > Thu, 29 Jun 2006 22:44:30 +0200: some discussion about the misunderstanding > Mon, 11 Sep 2006 15:58:28 +0200: patch update for the i386->i486 ABI change > Sun, 29 Apr 2007 00:12:48 +0200: prodding the maintainer for an reaction > Thu, 28 Jun 2007 03:43:16 +0100: first real reply by maintainer Patch was not ready... > Mon, 02 Jul 2007 19:14:35 +0200: patch fix for issues raise by maintainer Didn't look like the issue was settled as the mail of Aurélien on 03 Jul was ending questioning the patch... > Thu, 26 Jul 2007 15:56:45 +0200: patch split into the ABI and multiarch parts > > An NMU was tried and it and all future NMU where vetoed by the maintainer. I only see discussion about the misunderstanding of a patch and fixing of the patch after the maintainer comment. There was no mail asking if it was allright to NMU, nor a real NMU attempt AFAICS... > In summary: > > - 13 month from initial report to raising a minor issue that has no > negative effects on the functionality > - 4 days to fix the issue Not clear from the bug log that everything was right already... > - 9 month without reaction and counting 9 month waiting instead of trying to resolve the issue... Btw looks like a very colored summary to me... If I want a feature to be included in a package which the maintainer is not really interested in, I would make sure that my patch would be ready to apply and/or make sure I tried to actually NMU... Cheers Luk PS: I would not mind having multiarch support myself... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
Charles Plessy wrote: > Le Wed, Apr 16, 2008 at 04:39:56PM +0100, Adam D. Barratt a écrit : >> Andreas Tille wrote: >>> Rejected: epcr_2.3.9-1.dsc: sha1 check failed. >>> Rejected: epcr_2.3.9-1.dsc: actual file size (1289) does not match >>> size (1052) in .changes sha1 Rejected: epcr_2.3.9-1.dsc: sha256 check >>> failed. Rejected: epcr_2.3.9-1.dsc: actual file size (1289) does not match >>> size (1052) in .changes sha256 >> As Matthew said, you need to make sure you're using devscripts 2.10.25 so >> that debsign knows to update the file size in the new Checksums-* fields. > > Should dpkg-dev conflict with devscripts < 2.10.25, then ? This would > not solve all problems, but at least some of them. It wouldn't solve much as dpkg-dev is used in the build environment (unstable), while the troublesome signing is done in a production/desktop environment (oldstable/stable/whatever). Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
Kevin Mark wrote: > On Sun, Apr 20, 2008 at 09:06:15PM +0100, Roger Leigh wrote: >> Robert Millan <[EMAIL PROTECTED]> writes: >> >>> On Sun, Apr 20, 2008 at 05:28:23PM +0200, Bernd Zeimetz wrote: >> If you do want to wait for permission/refusal, you might find you >> never get a reply and end up waiting forever. So, why not wait long >> enough for a reply, say a fortnight, and then go ahead and hijack it >> after that if you have no response (and tell them in the mail that >> this is what you will do). > Is there a guideline or policy for such hard-to-reach Developers with > regard to hi-jacking or NMU? There is a guideline for doing NMUs which kind of includes this case in the Developer's Reference... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Extending the update-rc.d API to change runlevel and disable scripts?
Stefano Zacchiroli wrote: > On Fri, Apr 25, 2008 at 10:15:27AM +0200, Petter Reinholdtsen wrote: > Similarly, a counter action for this new "disable" action should be > provided. I frequently dig into postinsts to retrieve the info about in > which position I should put back a service I've disabled. (Sure this > won't be needed with dependency based boot system, but in the meantime > it still is.) Isn't this just a matter of stopping the service and renaming the S (K) links to s (k) links so one can easily revert? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: clive: volatile or not-for-stable?
Mikhail Gusarov wrote: > Hello, > > Package I maintain (clive) relies in functioning on external resources > (YouTube, GoogleVideo and less known ones) which change frequently. This > means clive need to be regularely updated to continue to function. > > I suppose clive should not be included in stable release due to such > unsatisfactory state of things, but what should I do instead? I've read > debian-volatile procedures and it seems quite restrictive - upload only > by maintainer, and I'm not a DD (yet) and unclear. > > Is it ok just to file RC bug "Should not enter testing" and forget about > the problem with clive in stable releases forever? I guess the question is rather debian-volatile or backports.org and maybe it would be better to use volatile-sloppy? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org/password.html : Why ~/.ssh/id_dsa.pub to setup OpenSSH for RSA
Osamu Aoki wrote: > Hi, > > Recent openssl issue lead me to http://db.debian.org/password.html and > made me wonder why script example uses DSA key while main text only > talks about RSA key. The text talks about RSA keys as they are preferred over DSA keys. > | Alternatively, you can do without a password and use PGP to manipulate your > | LDAP information through the mail gateway and use SSH RSA Authentication to > | access the servers. To setup OpenSSH for RSA you need to first generate a > | private RSA key using ssh-keygen and select a good passphrase for it. Then > send > | the public portion of the key to the LDAP directory: > | > | gpg --clearsign < ~/.ssh/id_dsa.pub | mail [EMAIL PROTECTED] > | > | NB: Only version 2 RSA keys are accepted. Version 1 RSA keys (i.e. > identity.pub > | files) will not work. > > > If main text is s/RSA/RSA\/DSA/g , I understand script example but ... > > Is there any reason to use DSA key insted of RSA key(~/.ssh/id_rsa.pub) ? On the contrary, it's better to use RSA keys as they can be bigger and are faster. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Current build status of the mips port
Hi Thiemo Thanks for this status report. Thiemo Seufer wrote: > I went again through the mips build problems and collected the appended > list which records the current state, with a few annotations added. > Needs retry > --- All given back when still needed. Please don't include packages in such a listing that have a sane wanna-build state: packages in Needs-Build or Dep-Wait or Building (for a normal amount of time)... > Maybe needs retry (TODO: check) > --- > -- Qt ABI, fix by waiting for next Qt version -- > kde4libs # needs rebuild to fix ABI (or wait for new version) > kdebase-runtime > merkaartor > universalindentgui > sailcut > psi > ktoon # Broken qt ABI Do they or do they not need wanna-build magick? > -- ghc6 stuff -- > washngo # vm exhausted, (arm armel mips mipsel powerpc) > haskell-haskell-src # vm exhausted, (mips mipsel alpha) > lhs2tex > pandoc > gtkrsync > highlighting-kate > haskell-happs-data > haskell-happs-ixset > haskell-happs-server > haskell-happs-state > haskell-happs-util > haskelldb-hsql-mysql > haskelldb-hsql-odbc > haskelldb-hsql-postgresql > haskelldb-hsql-sqlite3 > arch2darcs > darcs-buildpackage > hpodder Will these probably build fine when retried? > -- other -- > mlt # (ia64 mips mipsel powerpc) > vdr-plugin-live > kde-style-qtcurve # not reproducible, but see #462001, (amd64 arm hppa mips > powerpc s390 sparc) > mozart > gpsdrive > libgtk-java # needs libcairo-java-dev > qtnx # needs libnxcl1 > tuxguitar > music-applet # needs libxml-parser-perl, (mips mipsel powerpc) > mplayer # (hppa mips mipsel powerpc sparc) > edenmath.app > gnome-chemistry-utils > virt-manager > gsynaptics > ucspi-proxy > epiphany-extensions What does this list mean? > Should be in in P-a-s (or not-for-us?) > -- Did you contact P-a-s administrators (and buildd maintainers) about it? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Large data packages in the archive
Raphael Geissert wrote: > Hi all, > > What about going the 'b.)' way but define it as a RG (or even RC) with some > other changes to policy (like requiring big data package's source packages > to be arch-indep and not build anything else but the data packages). > > That way the transition could be done gradually for lenny+1 so there's no > bloating. > > And, mirror admins could then have plenty of time to decide whether to > mirror the data packages or not. Are you sure that the current sync scripts make that possible and won't sync everything unless explicitely stated differently and will keep working without intervention for the time being? Because otherwise it's like Joerg said not an option IMHO. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Large data packages in the archive
Raphael Geissert wrote: > Luk Claes wrote: >> Are you sure that the current sync scripts make that possible and won't >> sync everything unless explicitely stated differently and will keep >> working without intervention for the time being? Because otherwise it's >> like Joerg said not an option IMHO. > > I can't tell for sure, but I don't even think that's relevant. > Because let's say source package foo is already in the archive and builds > foo and foo-data, the former being an arch-dependent package and the latter > independent. If the 'data' component is added, next upload of foo should > build foo-data placing it under 'data', causing no more traffic than the > one caused by a new upload of foo without the data component. I don't think existing packages would be the main part as they usually are 'small'... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Mike Bird wrote: > On Mon June 2 2008 09:27:08 Raphael Hertzog wrote: >> I think it's important that the release team supports the work done on >> tasksel (by the d-i team) by not removing unilateraly packages which are >> listed in tasks. They have been added there in the first place for a >> reason, it would be nice to be able to offer a continued user experience >> from release to release and not have significant functionalities >> disappear just because we (as Debian, not as release team) have not been >> able to recruit volunteers for the corresponding packages. > > A good idea but it doesn't go far enough. Personally I don't find > d-i tasks to be any more important than "the packages I need", and > I suspect millions of Debian users have equivalent opinions. That's what rc-alert is for. > Packages are summarily removed from Testing far too often, and then > find it much harder to return because they are then "new". I don't > know if the algorithms were changed six months ago, but starting > around the turn of the year we've frequently had to resort to Sid > when replicating existing configurations onto new boxes. This is a > bar to adoption by new users, and new users are usually desktop or > laptop users who need Testing for hardware support. Accusing won't help at all, no the algorithms are not changed. Fixing RC bugs for instance in the list you get from rc-alert might prevent your apparently changing view... > Artificially lowering the RC count in Testing is not always > preferential to keeping Testing in a state amenable to testing. You say yourself that it's not artificially as RC bugs in "new" packages don't get that easily in testing anymore... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Time to phase out net-tools?
Robert Edmonds wrote: > On 2008-06-13, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: >> On Fri, 13 Jun 2008, Martín Ferrari wrote: > rarp is obsolete. It's not, I do use it from time to time, do you have a replacement? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Robert Millan wrote: > On Sat, Jun 21, 2008 at 03:52:12PM +0200, Alexander Wirt wrote: >> I'm still not that sure if its a good idea to add a non-offical debian repo >> keyring into the archive... But I let the decision to the ftp-masters.. > > Well, currently a problem is the only way to get a trusted path to the bpo > repository is by fetching debian-backports-keyring from it, checking your > signature in its .dsc, etc. So this is what I'm trying to solve. Hmm, are there not 2 other ways documented on backports.org as you can see below? Cheers Luk -- If you are using etch and you want apt to verify the downloaded backports you can import backports.org archive’s key into apt: apt-get install debian-backports-keyring or gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16BA136C gpg --export | apt-key add - or wget -O - http://backports.org/debian/archive.key | apt-key add - -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#489132: lenny release notes, upgrade dpkg first
Raphael Hertzog wrote: > On Thu, 03 Jul 2008, Bryan Donlan wrote: >> On Thu, Jul 3, 2008 at 6:25 AM, Raphael Hertzog <[EMAIL PROTECTED]> wrote: >>> Package: release-notes >>> Severity: important >>> >>> To work-around a problem that can happen in the perl 5.10 upgrade (see >>> #479711), the perl scripts contained in dpkg (update-alternatives, >>> dpkg-divert) have been modified... but for the work-around to be used, the >>> new dpkg must obviously be installed first, before the dist-upgrade. >>> >>> Given that the new dpkg also supports triggers, we should probably also >>> recommend to upgrade apt/aptitude at the same time otherwise those tools >>> might be confused by the new package status... >> Would it be better to just set pre-depends on the appropriate version >> of dpkg in perl? That ought to ensure they are upgraded in the correct >> order, even for people who don't read the release notes :) > > Hum, this might be possible indeed. We don't like frequent use of > Pre-Depends but this one might be justifiable. Ccing -devel for comments > and [EMAIL PROTECTED] as they'd have to do it. > > I'd like to also note that dpkg conflicts with the old version of > apt/aptitude, so this will also force the upgrade of apt/aptitude. Requiring from everyone wanting to upgrade to first manually upgrade dpkg (and apt/aptitude) should be avoided if possible. If the Pre-Depends will not break anything in whatever scenario it's definitely preferred. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Fwd: Delivery Status Notification (Failure)]
Hi Below the content of a bounce I got when replying to a wanna-build request... blacklisting domains seems to be accepted as the ones in control of its mailservers should be able to fix possible issues, but blacklisting all mail based on the country part of a domain??! I guess it's another sign that we already lost against spammers? Cheers Luk Original Message Subject: Delivery Status Notification (Failure) Date: 30 Jun 2009 23:05:42 +0200 From: Mail Delivery System To: l...@debian.org The following message to was undeliverable. The reason for the problem: 5.1.0 - Unknown address error 550-'5.7.0 ... Your country has been blacklisted due to its serious SPAM problems' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching the default /bin/sh to dash
Petter Reinholdtsen wrote: > [Giacomo A. Catenazzi] >> Hmm, so a switch to dash it is not because of POSIX, but because >> of "better code" and lighter shell for our scripts? >> >> Which is also a good reason for the change. > > Yes, it is a good change. I would love to switch every installation > to dash as /bin/sh, but believe the path of least surprises to the > sysadmin is to only change new installations and not existing systems. Right, though how would you implement that? It doesn't look trivial at all to me and will possibly be an extra source of errors. It should also only affect external scripts that are bash specific AFAICS and they would be easily 'fixed' by changing bin/sh to bin/bash in the shebang (can even happen unconditionally). Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Coordinating efforts to get a new kernel in testing?
Christian Perrier wrote: > During the last meeting of the D-I 'team' (ahem) which logs can be read > from http://wiki.debian.org/DebianInstaller/Meetings, the situation > of the kernel packages wrt testing transition was raised. > > Apparently, having a new kernel in testing (whether this is 2.6.30 or > whatever other funky new version appears soon is not really relevant) > is quite hairy. It needs quite some work to get reverse dependencies handled and getting it built on all architectures. Both of which are the main responsability of the kernel team... > Could this be prioritized by the involved teams (mostly kernel and > release, I'd guess) or are there already some plans for this to > happen? There are no plans to force anything in like some propose in such situations as there is no clear plan of the kernel team to get the remaining issues solved soon after it would be forced in. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Coordinating efforts to get a new kernel in testing?
maximilian attems wrote: > On Sat, Jul 11, 2009 at 01:08:05PM +0200, Luk Claes wrote: >> It needs quite some work to get reverse dependencies handled and getting >> it built on all architectures. Both of which are the main responsability >> of the kernel team... > > it is mostly done, beside the strange cpio missing build dep, > that funnily surfaced now on i686. fixed in latest repo and > scheduled for upload latest on this upcoming week. > >>> Could this be prioritized by the involved teams (mostly kernel and >>> release, I'd guess) or are there already some plans for this to >>> happen? >> There are no plans to force anything in like some propose in such >> situations as there is no clear plan of the kernel team to get the >> remaining issues solved soon after it would be forced in. > > without force hints linux-2.6 goes nowhere. If you mean this in general then you are misinformed. If you mean atm, then you know the answer to your following question. > what are the remaining issues that you are concerned about? The ones that prevent linux-2.6 from migrating once it would be unblocked. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: mail server broken: are debian reject messages logged ?
Alastair McKinstry wrote: > Hi, Hi > I've just returned from a two-week vacation during which time my > mailserver at home > was broken (ADSL line problems). In fact the DNS was also unreachable, > so mail bounced badly. > If you sent me a mail in the last two weeks, please resend. > > In particular, I had some packages uploaded to the NEW queue in this > period, and they have disappeared: > I think they must have been rejected. Are the ftp master messages logged > anywhere ? I'd like to know why > they were rejected. Yes, you can find them on merkel:/srv/ftp.debian.org/queue/reject/*.reason Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to orphan a package without being the maintainer
LIU Qi wrote: Hi all, Long time ago I ITA(http://bugs.debian.org/430431) a package, prokyon3. Because few persons use this software and I switched to gtk instead of qt after I adopted this package (it is qt based), I use this software very rarely and I want to orphan it. I have not uploaded this package once and I am not the maintainer of this package. How should I orphan this package? Just change the owner of this bug to QA group? Also I think I submitted a wrong bug report: http://bugs.debian.org/537334 How should I deal with that? If I understand you correctly, it's just a matter of retitling the ITA bug to RFA again. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of debhelper/dbus breakage
Wouter Verhelst wrote: On Fri, Jul 17, 2009 at 11:19:50AM +0200, Steffen Moeller wrote: Not? Was the originally uploaded package correct? Amazing. Hm. Then, it should be lintian errors that denote a build as a failure, indeed, and these should somehow be detected by the mechanism that uploads the packages ... not by the buildd admin. It's impossible to catch every issue in an automated way. There are things that can be caught (such as, /maybe/, this), but you have to deal with the fact that some things will still slip through the cracks. I'm also not at all sure whether sbuild runs lintian during the build. Perhaps that would be good, though. AFAIK the FTP Team is working on a system to prevent uploads which have lintian errors. The whole category of lintian errors has already been assessed and possible overrides are planned to arrive in the NEW queue at least once... Please do note that I'm talking about errors, not about warnings. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of debhelper/dbus breakage
Wouter Verhelst wrote: On Fri, Jul 17, 2009 at 11:44:54AM +0200, Luk Claes wrote: Wouter Verhelst wrote: On Fri, Jul 17, 2009 at 11:19:50AM +0200, Steffen Moeller wrote: Not? Was the originally uploaded package correct? Amazing. Hm. Then, it should be lintian errors that denote a build as a failure, indeed, and these should somehow be detected by the mechanism that uploads the packages ... not by the buildd admin. It's impossible to catch every issue in an automated way. There are things that can be caught (such as, /maybe/, this), but you have to deal with the fact that some things will still slip through the cracks. I'm also not at all sure whether sbuild runs lintian during the build. Perhaps that would be good, though. AFAIK the FTP Team is working on a system to prevent uploads which have lintian errors. The whole category of lintian errors has already been assessed and possible overrides are planned to arrive in the NEW queue at least once... Please do note that I'm talking about errors, not about warnings. Right. However, having sbuild run lintian would allow a buildd maintainer to assess issues with packages by looking at *warnings*, rather than 'just' errors. This isn't something an automated system can do. Right, though that's why we expect maintainers to look at them. Although there may be architecture specific lintian warnings, they should be really rare. Besides, we want to get some support for autosigning packages built on the buildds. So we improve the speed of buildd uploads and we make the job of buildd maintainer more attractive to porters so they could really investigate (architecture specific) build errors instead of spending time in downloading, checking and signing successful build logs. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of debhelper/dbus breakage
Wouter Verhelst wrote: On Fri, Jul 17, 2009 at 12:10:56PM +0200, Luk Claes wrote: Wouter Verhelst wrote: Right. However, having sbuild run lintian would allow a buildd maintainer to assess issues with packages by looking at *warnings*, rather than 'just' errors. This isn't something an automated system can do. Right, though that's why we expect maintainers to look at them. Although there may be architecture specific lintian warnings, they should be really rare. They would still catch this kind of bug, though. Also, there *are* many system-specific warnings emitted by gcc, and those can easily be picked up by mutt highlighting. Besides, we want to get some support for autosigning packages built on the buildds. So we improve the speed of buildd uploads and we make the job of buildd maintainer more attractive to porters so they could really investigate (architecture specific) build errors instead of spending time in downloading, checking and signing successful build logs. Hmm. I'm not sure that's very useful, really. Due to scripts and mutt's GPG key passphrase caching, my daily buildd mail signing stuff never takes more than a minute[1], even on days with hundreds of logs that need to be signed (except if highlighting tells me that there's something that needs to be looked at, obviously). Perhaps such scripts could be shared, but other than that... Unless you have a light speed internet connection you're cheating here... Additionally, I personally dislike a buildd host that is silent in the usual case. The fact that there is routinely "something to do" forces me to continually think about it and not neglect the things I need to do to maintain it[2]. You'll note that there've been times when the powerpc dailies were broken for long amounts of time in a row, when I used to maintain it; this is mainly because the system's output would not be very different between 'nothing is working' and 'everything is working fine', so I just wouldn't notice when things were broken. There are still the admin messages which give a summary of what happened and the logs for the non successful builds. In other words, I personally do not feel that, from a buildd maintainer's point of view, the "disadvantages" of having to sign mails (which is no work at all, really) outweigh the advantages (me being much, /much/ more aware of what's happening, and being able to take care of it that much better). I understand that the delay in uploading that's inherent in manual action isn't ideal from an RM's point of view, but then that shouldn't be more than 24 hours in the usual case anyway (and if it is, that's a sign that the buildd maintainer is getting bored with the job, or needs help, or some such, which shouldn't be the usual case anyway). In the usual case at least one of the buildd maintainers takes more than 24 hours to process the log. [1] and a minute really is exceptional; the average is more like 10 seconds or so. You're only counting the time autosigning would need, not the time needed to download the log, process it and wait till the cronjob acts on the to be uploaded package. The latter could be done without autosigning, but as it's measured in hours (maximum), it doesn't make sense to optimise it currently... You seem to only look at the most optimal situation which is very rare in practice. [2] obviously there'll always be times when I'm too busy to look at that stuff for a few days in a row, but those are the exception rather than the rule. Though unfortunately they don't collide with times when other people are too busy and for a few days it's also not very comfortable to switch to someone else for processing the logs... Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash (part two)
Kurt Roeckx wrote: On Sun, Jul 19, 2009 at 06:04:13PM +0200, Raphael Geissert wrote: Hello everybody, This is a follow up to my previous thread, with a slightly different proposal. What actually needs to be done is: * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. I'm not sure what an "interactive upgrade" is. How do you detect that? Is that when it's not run from d-i or something? interactive is when it's not in d-i and has an interactive debconf frontend. Detecting it will probably mean looking if bash is installed or not (during d-i/debootstrap, we will make sure dash is installed before bash). Does this mean it's going to ask us on each upgrade? No, only on first installation. With the Depends you're letting people install it now, so on first _install_ it's going to divert it without prompt? Or is that part of the "interactive upgrade"? No, on first installation it will ask. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash (part two)
Raphael Geissert wrote: Henrique de Moraes Holschuh wrote: It is not like you will be able to remove bash from the vast majority of the Debian systems out there anyway, so it doesn't matter if it remains "essential" for a while. The goal of dropping bash from essential is not to remove bash from the systems (or from Debian), it is about making packages really using it depend on it. Yes, moving bash out of essential is a worthy goal, though I think we're not yet ready to do that: the move of the default system shell has not been completed and there are still quite some bashisms around... Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash (part two)
Steve Langasek wrote: On Sun, Jul 19, 2009 at 06:04:13PM +0200, Raphael Geissert wrote: This is a follow up to my previous thread, with a slightly different proposal. What actually needs to be done is: * Make dash essential, make it divert the current /bin/sh symlink by default, make another essential package depend on dash. Prompt the user before diverting on interactive upgrades. Is this latter part actually needed, or do we just need some package in the required set to depend on it? Note that, when essential functionality is being split between packages, the authoritative way to handle upgrades is to have an existing Essential: yes package *Pre-*Depend on the new package; but we're not actually splitting any essential functionality in this case, since bash is still Essential and will still provide all the same functionality. No, the latter part is not necessary, though the consensus seemed to be that people did not want the change to happen without them having the chance to easily prevent it on upgrades. If we're to have an Essential package depend on dash for upgrades, I suppose base-files is the obvious choice. Well, bash is already doing it now and we did not want to bother people during d-i or debootstrap and having bash depend on dash made that easier. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Sam Hartman wrote: Folks, there was a longish discussion on IRC starting about an hour ago about dash and bash. I agree we want to move the default /bin/sh to /bin/dash. However I'm failing to understand why we want dash to be essential. If I'm not using dash as my /bin/sh why do I need it? > If the answer is that we really do want it everywhere independent of what /bin/sh is, that's fine. However, that's not obvious to me. We want everyone to use dash by default. If someone does not want to use the default, they are free to do so, but the default system shell is supposed to always be on the system. So, a proposal for doing a switch with dash not essential. 1) all /bin/sh shells know about each other. Not going to happen AFAICS. bash does not know about any for instance. 2) The prerm script for a /bin/sh shell finds another /bin/sh shell and updates the symlink if the current /bin/sh link is the one being removed. Might be possible, but currently needs a lot of work and I don't see anyone interested to do that. 3) The postinst for a /bin/sh shell can update the link if it decides that the installed shell would make a better /bin/sh 'it' decides :-) 4) There is a package `the-shell ' that is essential and pre-depends on one of the /bin/sh shells. This seems ugly, I would rather go for a virtual package in that case similar to awk. I really don't mind if we go forward with the current proposal. However, I think I and a lot of other people would appreciate clarity, so far not expressed, about why dash needs to be essential. You do not want to give the possibility to remove /bin/sh from the system. Currently this is done by making the default system shell essential. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Comments on the "Changing the default system shell" talk
Goswin von Brederlow wrote: Hi, Hi in the talk you said you add a choice for /bin/sh and you add more freedom. The choice being that the admin may dpkg-divert /bin/sh to whatever shell he wants and he then can fix whatever breaks. Great. We already have exactly that now. There is nothing added. No mechanism and no assurances that things won't break. By fixing most of the bashisms, there is a bigger assurance that nothing will break when you do that. You say that dash is configurable as /bin/sh via debconf but in the next sentence you say you want dash to ship a /bin/sh link to dash. So the deconf thing is purely a temporary thing and goes away. There won't be a choice left. Users will just get /bin/sh pointing to dash period. ... by default, they can change it later on if they want to. You say that the default /bin/sh must be an essential package as only way to make sure it is always present. That is clearly wrong and we have mawk/gawk as a real life example of having something always installed (awk) while still keeping the choice open. It must be essential as you want to make sure that /bin/sh always exists, which is not guaranteed when another shell does not divert it properly. Overall I take 2 things from your talk: 1) You are removing bashisms from scripts using /bin/sh That is a good thing and your work there is verry welcome. Thanks for investing time there. This is actually where all the benefits really come from. Kudos there. Everything else seems to be just window dressing. A faster and smaller default system shell is important to a lot of our users. 2) You are bloating the system and essential packages list You are simply replacing A with B. You are not adding any choice mechanism or garanties that a /bin/sh other than dash will work. If admins dpkg-divert /bin/sh and use another shell they will be totaly left out in the cold with fixing any problems. Some maintainer will just close bugreports saying the only /bin/sh is dash. Sure, we did not solve the universe, but hey people that are really interested in doing that, now have more chance of getting there eventually. You say you give admins a choice to divert /bin/sh to whatever (posix) shell they like. But you only give them a choice of adding yet another shell. Not a choice of replacing dash. Only a choice of adding even more. After diverting /bin/sh instead of having one useless shell we now have 2 useless shells on the system. At least until bash becomes non essential. The last thing we want is that people break their systems by not being careful enough. We made sure it will be easier to get rid of bash in the future while not going for the jump in the deep... Will it eventually be policy that essential/required/standard packages must not depend on bash? Because as long as something in the core packages depends on bash it will remain non removable. Eventually it will very probably be policy that required packages should try to avoid depending on bash features. Currently the one in shadow is already being taken care of and the one in libpam0g is being considered. Cheers Luk PS: Please be a bit more positive, we now that things are moving slowly, but at least they are moving. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Comments on the "Changing the default system shell" talk
Manoj Srivastava wrote: On Sun, Jul 26 2009, Luk Claes wrote: Goswin von Brederlow wrote: A faster and smaller default system shell is important to a lot of our users. I see this asserted a lot. I am pretty sure that the average user very likely does not care. The embedded system folks certainly do --- but I am not sure that the counter assertion that systems will break if /bin/sh is changed under them do not equal in number the people who benefit from small default system shell. I think it is OK to start with dash as the default on new installations, and to ask if people want to switch older ones. Forcing the switch would be, in my opinion, buggy behaviour. Pardon me if forcing the /bin/sh to point to dash on existing machines is not the plan. On upgrades you are asked if you want to have dash as default system shell unless you have dash already installed, then we leave it as is. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Comments on the "Changing the default system shell" talk
Jonathan Wiltshire wrote: On Sun, Jul 26, 2009 at 05:08:20PM +0200, Luk Claes wrote: On upgrades you are asked if you want to have dash as default system shell unless you have dash already installed, then we leave it as is. On my unstable box I received dash a few days ago, because an upload of bash started depending on it. After upgrading dash to 0.5.5.1-2.2 today, /bin/sh is still bash. Presumably this means unstable users are going to have to dpkg-reconfigure dash to get any benifit from this change? For unstable users, this kinda defeats the point of pushing such a change. The dependency on dash was a bit premature, and indeed for unstable users that upgraded to bash already without getting any debconf question it's a matter of dpkg-reconfiguring dash. Note that there will follow a message on debian-devel-announce about the swith to dash with pointers to possible issues. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Comments on the "Changing the default system shell" talk
Goswin von Brederlow wrote: Raphael Hertzog writes: I just would like it to be even better. And I haven't seen any real constructive discussion about different methods of providing /bin/sh. Mostly just angry replies along the lines of "We don't want to break things. We do it this way." without disclosing what or why things would break. If my reply sounded angry, it was certainly not meant to be. Currently if you install any shell other than bash or dash to provide /bin/sh, you have moments were /bin/sh is not available on the system. This might introduce all kind of breakage and is the breakage we're talking about. Using a mechanism like alternatives for instance does not make sure that there is always a working /bin/sh on the system. There seems to be one group of people that would like more flexibility (including the option of keeping bash as /bin/sh even in the long run) and the other group being dead set on the dash plan. And no dialog between the groups. Both sides (and feel free to include me there too) stay in their corner and say "nay" to each other. It is sad that we can't discuss the merrits and problems of proposals rationally and work out a solution that works for all. It's perfectly fine to have people wanting to have more flexibility. Note that keeping bash as /bin/sh even in the long run is not at all excluded the way we implemented the new default system shell btw. Though working out a solution that works in a more flexible way is far from trivial and it does not seem like anyone is interested enough to work on it. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Comments on the "Changing the default system shell" talk
Goswin von Brederlow wrote: Manoj Srivastava writes: On Sun, Jul 26 2009, Raphael Geissert wrote: Goswin von Brederlow wrote: So the deconf thing is purely a temporary thing and goes away. There won't be a choice left. Users will just get /bin/sh pointing to dash period. No, /bin/sh is shipped to guarantee a symlink. I take this to mean that installaations with /bin/sh -> /bin/bash will not be affected? That is good, if true. How could it not be changed? Unless something dpkg-diverts /bin/sh away from dash (which sort of conflicts with dash possibly dpkg-diverting it away from bash) then dpkg will overwrite /bin/sh when it unpacks the new dash. So unless you tell dash not to divert and then add a dummy diversion of /bin/sh from dash before updating you will get /bin/sh changed. Or dash could have preinst code that adds the diversion on itself if it detects it is being updated from a system that has bash as /bin/sh. Didn't see a plan for that. If that is planed then be a step forward. It's what has been implemented. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Comments on the "Changing the default system shell" talk
Goswin von Brederlow wrote: Luk Claes writes: Manoj Srivastava wrote: On Sun, Jul 26 2009, Luk Claes wrote: Goswin von Brederlow wrote: A faster and smaller default system shell is important to a lot of our users. I see this asserted a lot. I am pretty sure that the average user very likely does not care. The embedded system folks certainly do --- but I am not sure that the counter assertion that systems will break if /bin/sh is changed under them do not equal in number the people who benefit from small default system shell. I think it is OK to start with dash as the default on new installations, and to ask if people want to switch older ones. Forcing the switch would be, in my opinion, buggy behaviour. Pardon me if forcing the /bin/sh to point to dash on existing machines is not the plan. On upgrades you are asked if you want to have dash as default system shell unless you have dash already installed, then we leave it as is. Cheers Luk Two things: 1) I updated dash the last day and I didn't get asked and I don't remeber ever having been asked before. Having dash installed before shouldn't prevent the question. Please do always ask the question if it wasn't asked before. If you installed dash before, we assume that you already chose if you wanted dash as /bin/sh or not. If that's not the case you are welcome to dpkg-reconfigure dash to change your mind. 2) That changes when dash ships the /bin/sh link. So the question really is: What mechanism will you use, if any, to preserve bash as /bin/sh later when dash does ship /bin/sh? At the moment I don't see any reason why we should change what we currently implemented which leaves the option to choose bash or dash while shipping /bin/sh in both packages. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian GNU/Linux 6.0 "Squeeze" release goals
Paul Wise wrote: > On Sun, Aug 2, 2009 at 11:59 AM, Stefano Zacchiroli wrote: > >> I'm eager for more details, in particular: > > In addition: > > I seem to remember that some arch:all packages can only be built on > some architectures due to being firmware for specific CPUs or similar. > Will there be a Build-Arch field or a way to override discarding > uploaded .debs? There will be a Build-Arch field or some other way to make sure the arch:all packages can be built reliably. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian GNU/Linux 6.0 "Squeeze" release goals
Daniel Baumann wrote: > Stefano Zacchiroli wrote: >> - which auto-builder will rebuild arch:all packages? > > especially because this will break packages with 'faked' arch:all binary > packages, such as e.g. syslinux where syslinux-common has to be build on > i386. This will be solved by an extra field which tells on what arch the arch:all package should be built (or a similar solution to the same effect). Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Launching and l10n NMU campaign for the squeeze release cycle
Christian Perrier wrote: > Despite the current incertainties about the planned release date, I > think it is now time to launch the l10n NMU campaign for squeeze. I agree that it's probably not a bad timing to start a l10n NMU campaign. > The process is roughly the following: > > - warn the maintainer (through the @packages.d.o address) about my > intent to build an NMU of the package, fixing all l10n bug reports [...] > Of course, at any time of the process, things may be negotiated with > the maintainer, and adapted to his|her work process...including fully > abandoning the NMU intent..:-) > > This time, I'll look closer at packages I intend to NMU. Probably > those that are at the top of the list might be poorly maintained > packages, or even abandoned ones. For the last NMU campaigns, I took > care of even those packages, but, this time, I might consider asking > for the package removal if it appears too buggy, useless, outdated, or > whatever else. Not a bad idea. Please do share the ones were you did not get any maintainer response with the MIA Team even if you proceed with the NMU so they can look into the specific reasons why the maintainer seems to be inactive. Also note that there is a process for tracking possible orphaning or removal of a package by the QA Team which is called bapase [1]. Cheers Luk [1] http://wiki.debian.org/qa.debian.org/bapase -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
Manoj Srivastava wrote: > Hi, > > I would like to set up a selinux related release goal for > Squeeze. > > Developer assiociated: Manoj Srivastava (Perhaps also Russell Coker, > but I have not discussed this with him) > Issues to be solved: >(a) Get all Debian patches to the reference security policy merged in >upstream. Status: In progress, we have all patches submitted, >some need to be tweaked and resubmitted based on feedback > Time line: 1-2 months, depending on free tie I have While this is relevant to Debian, it does not look like it impacts what is in Debian or are there possible changes in Debian depending on the feedback? >(b) Update reference security policy to allow standard machines to be >in enforcing mode. >Status: It is possible to run minimal virtual machines in >enforcing mode, but real machines are somewhat crippled; these >denials need to be inspected, and determination needs to be made >for how to resolve them (no not want security holes enshrined in >policy) > Time line: 6-8 months (can be done in tandem with a, if here were > more people working on it) Are the issues identified already or do you have an idea about how many issues there are to tackle? Do you have any documentation for possible contributors to help you with this? Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Wouter Verhelst wrote: > On Fri, Sep 04, 2009 at 01:31:40AM +1000, Ben Finney wrote: >> Charles Plessy writes: >>> Le Thu, Sep 03, 2009 at 12:47:44PM +0200, Wouter Verhelst a écrit : >>>> I know it is fancy and modern to think that Debian native packages >>>> should only be used for things that are specific to the Debian >>>> infrastructure, but there is nothing in policy that requires that, >> To be clear (and I know you probably already know this): just because >> some practice is not explicitly mentioned in Policy, does not mean there >> is no good way to decide whether or not it's good practice. > > True. However, if something is not explicitly forbidden by Policy (and > this isn't), and it does not cause (obvious) harm to Debian as a whole > (which this doesn't), there is no good reason why people should pretend > it's a bad idea. This sounds very wrong, as if it would be ok to cause harm to some part of Debian when it's not forbidden in Policy. I also don't agree that there are no good reasons why it's a bad idea. >> As far as whether this idea is “modern”, I don't know whether “more than >> 8 years” is outside that range for an operating system only 16 years >> old, but the consensus on this 2001-01 ‘debian-mentors’ thread >> http://lists.debian.org/debian-mentors/2001/01/msg00191.html> seems >> to be that packages should be native only if the package is specific to >> the Debian infrastructure. > > That thread has four people stating the downsides of making a package a > native package; however, several of them also explicitly state the > opinion that making a package native is perfectly okay, after having > considered those downsides. That's pretty much what I was saying in my > previous mail. Yes, though only after considering all the downsides, including having these discussions and people requesting you to reconsider from time to time. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
Marc Haber wrote: > On Sat, 19 Sep 2009 15:52:17 + (UTC), Philipp Kern > wrote: >> On 2009-09-19, Marc Haber wrote: >>> On Fri, 18 Sep 2009 15:56:07 + (UTC), Philipp Kern >>> wrote: >>>> On 2009-09-18, Tom Feiner wrote: >>>>> Looks like this method works well for clamav-data and other similar >>>>> packages >>>>> which needs to update databases frequently on stable/oldstable. >>>> clamav-data is scheduled for deletion as soon as volatile moves onto >>>> ftp-master, so that's no precedent. (I.e. there is opposition against >>>> daily builds entering the archive without real developers signing them.) >>> Why does the person responsible for these uploads not know about this >>> opposition? Why was the person doing the significant work not informed >>> about the fact that every single minute put into the package is wasted >>> anyway? >> If I recall the channel discussion correctly you were present and aware of >> the discontinuation. Maybe I recall it incorretly, though. > > Das muss ich verdrängt haben. I still get absolutely furious about > this "decision" when I think about it, so I'd better not think about > it. > > Thanks for the reminder. I'm going to kill off clamav-data the second > the build process breaks for the next time. It's really a shame to see > weeks of work going down the drain due to political restrictions. Hmm, nothing is black and white. The current way of uploading clamav-data is suboptimal and ftpmasters don't want that to continue when volatile is integrated in the main archive. Though that does not mean there are no alternatives. Back then you did not seem interested in any alternative way of doing it and rather discontinue the service completely. Is this still true or should we start thinking of alternatives? Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
Marc Haber wrote: > On Sun, 20 Sep 2009 18:28:30 -0300, Henrique de Moraes Holschuh > wrote: >> On Sun, 20 Sep 2009, Marc Haber wrote: > No. The process runs on a virtual machine on a host privately owned > and operated by the previous ftpmaster of Debian volatile, and was > carefully designed in close cooperation with the former Debian > volatile team. It is a real shame that the new Debian volatile team > decided to put up more hoops to jump through after clamav-data was one > of the first packages to be included with Debian volatile. Please stop spreading FUD. The extended team decided to try to integrated with the main archive. The ftpmasters of the main archive have more strict rules about how packages can be accepted, though it will still be the volatile team that decides which packages could go in. The time complaining in this thread could probably better spent by talking to ftpmas...@d.o and implementing a solution btw. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Python2.6 in unstable?
Bastian Venthur wrote: > Stefano Zacchiroli schrieb: >> On Thu, Sep 03, 2009 at 04:32:10PM +0800, Paul Wise wrote: >>> See the recent threads on debian-python, debian-devel and debian-release. >> Given that Bastian's post is the first time I've seen the question >> posed straight away for the -devel public, can you please summarize an >> answer for us? > > Since I didn't receive an answer on my question I summarize what I > found. Python 2.6 will definitely not become the standard Python for > Squeeze. It is also very unlikely that it will enter unstable soon as > far as I understood due the way 2.6 handles site packages and the > resulting packaging issues. Python 2.6 should become the standard Python for Squeeze. > Someone asked for a list of open issues so people can jump in and try to > help to solve the issues so 2.6 can at least be in Squeeze, but > apparently this list does not exist. AFAIK the process of filing and fixing bugs to be able to build with python 2.6 is already happening. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: different .diff.gz for different platforms (armel) prohibiting upload
Holger Levsen wrote: > Hi, > > On Montag, 28. September 2009, Rene Engelhard wrote: >> I just said that there are buildd admins/porters who are hard to deal >> with because they just don't care about build failures not caused by >> the package to be built and neither with any package else but by >> buildd/machine/arch issues. > [...] >> At which time it'll get even more funny when buildds don't try to >> build stuff - and yes, even security buildds. You really believe >> a DSA is possible nowadays without uploading handbuilt binaries? Then >> you haven't seen reality. > > Well, I think this reality sucks and should be fixed. Uploading manually > build > security packages is a workaround which is error prone, as could be seen in > the last months, where there were several uploads done in wrong build > environments. > > If there are really such non-caring buildd admins/porters this should be > fixed > at the root of the problem and not by using a workaround, which introduces > new problems and doesnt touch the root at all. The real problem IMHO is that we have only very few real porters left. Some of them apparently think that unless they are contacted directly there are no issues while many buildd admins are swamped with other work and don't get to filing bugs for porting issues. To all people interested, please have a look at the buildd pages [1] and file bugs where necessary (please don't file duplicates nor file bugs when fixing the build chroot or setting a dep-wait would suffice). Cheers Luk [1] https://buildd.debian.org/status (click on the architecture you are interested in and look at the Failed, Build-Attempted and Maybe-Failed categories) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Michael Banck wrote: > Hi Manoj, > > On Sat, Oct 31, 2009 at 01:03:00PM -0500, Manoj Srivastava wrote: >> getting around to filing bugs on policy MUST violations and others that >> make the package too buggy to be in Debian > > Please respect the tradition and discuss mass-filing of bugs on > debian-devel. +1 It seems that many of the bugs have a chance of false positives or should not be RC. Besides if policy is not meant as normative as you regulary claim, then these are very probably bugs in policy. As there are for some categories of bugs you files many packages not conforming. So either policy is wrong there or policy is normative which would mean that there are a lof of other bugs in policy that noone cares about fixing (or even filing). Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Steve Langasek wrote: > On Tue, Oct 27, 2009 at 03:06:07PM +0100, Joerg Jaspert wrote: >> The second category is named "error" and the tags listed can not be >> overridden. Those are tags corresponding to packaging errors serious >> enough to mark a package unfit for the archive and should never happen. >> In fact, most of the tags listed do not appear in our archive >> currently, the few packages listed below should be easily fixable with >> their next upload. > >> We will provide a static url for the list of tags soon, for now you can >> look at them using [1]. > >> There are multiple files in [2] showing you the packages affected, >> together with the tags they hit. > >> [1] http://ftp-master.debian.org/~joerg/lintian/lintian.tags >> [2] http://ftp-master.debian.org/~joerg/lintian/ > > Since I'm not familiar with most of these lintian errors by name, I've run > the list of fatal errors through lintian-info with the following script: > > $ wget -O - -q http://ftp-master.debian.org/~joerg/lintian/lintian.tags \ > | sed -e'1,/error:$/d; s/^[[:space:]]\+-/E: ftp-master:/' | lintian-info > > I'd recommend that others do likewise, to get an appropriately large set of > eyeballs on this change. > > Some problems I find with this list: > > E: ftp-master: wrong-file-owner-uid-or-gid > N: > N: The user or group ID of the owner of the file is invalid. The owner > N: user and group IDs must be in the set of globally allocated IDs, > N: because other IDs are dynamically allocated and might be used for > N: varying purposes on different systems, or are reserved. The set of the > N: allowed, globally allocated IDs consists of the ranges 0-99, > N: 64000-64999 and 65534. Hmm, why is 100-999 not mentioned here or does this lintian check only check files shipped by the package as opposed to created in the postinst? > N: Refer to Debian Policy Manual section 9.2 (Users and groups) for > N: details. > N: > N: Severity: serious, Certainty: certain > N: > > Policy 9.2 does /not/ prohibit shipping files with owners outside these > ranges; it prohibits relying on user or group IDs outside these ranges being > static, but there doesn't appear to be anything in Policy that prohibits > creating the user in the package preinst and then unpacking the package such > that ownership is applied by /name/. (Unless I'm mistaken, this is > precisely what dpkg does.) If the check is only about files shipped by the package, I see no reason how this objection can be anything more than theoretical. If it's also about files created in the postinst: Steve: Can you give an example of a dynamically allocated non system user needed by a package? Dynamically allocated system users are covered in the range 100-999. > E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate > This one has been mentioned previously in the thread. Yes, it's a blemish > in the package to list "Upstream Author(s)", but the lintian maintainers > have correctly marked this as being of "normal" severity. We should not be > blocking packages from the archive for such low-severity issues; please drop > this check. It would indeed be good to have consensus first on the severity and certainty of a lintian check before auto rejecting on it IMHO. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Cyril Brulebois wrote: > Manoj Srivastava (01/11/2009): >> This was not a mass filing as I reaed it. Each bug was filed >> after being checked individually, and was filed one by one, >> manually. This was not a massive script which could have massive >> numbers of false positives, and thus these are just bugs filed about >> violations of Debian policy. > > Then you probably should read Policy 7.1.1. Individual checks or > non-automation doesn't make it less massive. As before Manoj seems to interpret things and word things so they fit the way he can use them at the moment he needs them. As long as that continues I'm not going to even try to get the Debian Policy and RC bug policy consistent and the Debian Policy will remain not useful for anything release related as it will be incomplete and sometimes conflicting with actual practice. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Russ Allbery wrote: > Luk Claes writes: > >> As before Manoj seems to interpret things and word things so they fit >> the way he can use them at the moment he needs them. As long as that >> continues I'm not going to even try to get the Debian Policy and RC bug >> policy consistent and the Debian Policy will remain not useful for >> anything release related as it will be incomplete and sometimes >> conflicting with actual practice. > > On behalf of the other four Policy maintainers who aren't Manoj and who so > far as I know you don't have personal conflicts with, let me just say > "gee, thanks." This is how we can ensure that Policy continues not to be > the document that it should be and people have to keep reading multiple > documents to figure out what they're required to do. Note that this predates me joining the Release Team, so I don't think it's just a personal issue between Manoj and me... > I have a limited amount of time to spend on Debian as a whole, which is > divided between Lintian, Policy, and my own packages. Reading things like > the above is extremely demoralizing and both tends to reduce that overall > time committment and the amount of time I'm willing to invest in Policy in > particular. If people are going to undercut or ignore that work, what's > the point of me trying to fight upstream? Exactly, I have only a limited amount of time and don't want to spend it on demotivating discussions with Manoj about why he uses two standards. Though just ignoring these is also of no help, so in general I just point out when he does it (probably not in a very objective way due to how hard it demotivates me to see people in such positions doing that). For the actual matter at hand I think it's very wrong to do a MBF without going through d-devel for several reasons: - it gives developers a chance to fix bugs before they are filed to decrease high bug traffic that is normal for MBFs - it gives developers a chance to discuss the severity and tags that should be used without the need to change them afterwards - it gives developers a chance to change the preconditions for bugs before they are filed - it gives developers a chance to share ideas on how to fix the bugs and include that information in the bug reports - it gives developers a chance to update any relevant documentation before the bugs are filed Cheers Luk Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Matthew Johnson wrote: > On Mon Nov 02 11:40, Luk Claes wrote: >> For the actual matter at hand I think it's very wrong to do a MBF >> without going through d-devel for several reasons: > >> > > Otoh, this is a slightly special case, since they are things which are > causing the package to become non-uploadable. In this case the correct > place to have the discussion about the scope et al of the bugs is with > ftp-master about what constitutes rejection criteria; the bug filing is > purely a reflection of that. Right, though filing bugs already is ignoring that step completely. > I certainly don't think that having packages with an upload-critical bug > with no bug filed against them is a good idea I'm not saying that bugs should not be filed, though the content and meta information of bugs can be very much improved by discussing before filing them. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
