Re: removal syncing among official and amd64 archive
On Sat, 2005-11-19 at 18:42 +0100, Goswin von Brederlow wrote: Stefano Zacchiroli [EMAIL PROTECTED] writes: While we are it ... I noticed that removal of packages from the official debian archive are not propagated to the amd64 archive. E.g. query packages.debian.org for the editex source package. Is that known? No. removals should propagate to amd64 with some delay. How long ago was it removed? A few months ago. = [Date: Thu, 28 Jul 2005 11:26:16 -0700] [ftpmaster: Jeroen van Wolffelaar] Removed the following packages from unstable: editex |0.0.5-6 | source libeditex-dev |0.0.5-6 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libeditex-ocaml |0.0.5-6 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libeditex-ocaml-dev |0.0.5-6 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libeditex0 |0.0.5-6 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc Closed bugs: 317298 --- Reason --- RoM; unsupported upstream, buggy -- = Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Thursday, November 24, 2005 11:17 AM, Wouter Verhelst [EMAIL PROTECTED] wrote: On Thu, Nov 24, 2005 at 02:11:45PM +1100, Matthew Palmer wrote: [...] On that score, the description for d-d-c says that it includes buildd logs, Then that description is wrong. It never did include buildd logs, and AFAIK, there are no plans to that effect, either. It doesn't say that. It says: Notices about uploaded packages for the unstable distribution, from developers, buildds and katie, the archive sentinel. i.e. the only e-mails from buildds involved are notices about uploaded packages, not logs. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages.debian.org service stop ?
On Thursday, January 12, 2006 11:59 PM, Junichi Uekawa [EMAIL PROTECTED] wrote: Hi, I've dug out some information from IRC logs: saens was overloaded around 5 Jan 2006, with load average of 140 or something, and eventually apache stopped. Since saens is one of ftp.debian.org, it had a large impact, and packages.debian.org is disabled temporarily as a workaround. FWIW, the same information is detailed in http://lists.debian.org/debian-project/2006/01/msg00035.html. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Obsolete packages in Experimental
On Thursday, January 19, 2006 11:35 AM, Jérôme Warnier [EMAIL PROTECTED] wrote: After the last update of OOo in Sid (aka Unstable), I wonder if it is generally considered acceptable to keep obsolete packages in experimental (currently, Sid has 2.0.1-2 and Experimental 2.0.1-1). Further to other answers, in this particular case you were about six and a half hours out of date ;-) = [Date: Wed, 18 Jan 2006 21:06:31 -0800] [ftpmaster: Ryan Murray] Removed the following packages from experimental: [...] openoffice.org |2.0.1-1 | source, i386, powerpc, sparc openoffice.org-base |2.0.1-1 | i386, powerpc, sparc [...] openoffice.org-writer |2.0.1-1 | i386, powerpc, sparc [...] --- Reason --- [rene] NVIU -- = (i.e. rene, the archive cruft remover flagged the experimental packages for removal as there was a newer version in unstable). Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: missing packages
On Wednesday, March 08, 2006 7:53 AM, Wolfgang Lonien [EMAIL PROTECTED] wrote: I did an 'apt-cache stats' today, and it was very nice to see that we have 17519 packages total. 3635 packages are missing, however. An 'apt-cache unmet | grep -c unmet dep: brings out 662 packages with unmet dependencies; 'apt-cache -i unmet | grep -c unmet dep: shows 219 of them as important. My results (i386) are different from yours, but within the same order of magnitude. fwiw, only about half of that 600-odd are strictly dependencies; the other half are Suggests or Recommends. Hmmm. That looks like a lot of work. But where to start? And who does that? The QA team? http://qa.debian.org/debcheck.php Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: possible mass bug filing: spamassassin 3
Duncan Findlay wrote, Wednesday, October 06, 2004 11:03 PM On Wed, Oct 06, 2004 at 10:51:46PM +0200, Jose Carlos Garcia Sogo wrote: [...] And, BTW, since version 2.64 we have: - Rules backported from 3.0.0 So though SA3 can make other things better (bayesian and so), SA2 is not so obsolete, and basically *works* in machines in which SA3 won't. I'm not really sure what you mean by rules backported from 3.0.0. Unfortunately, rules are fairly linked to releases. The above was a /direct/ quote from the 2.64-1 changelog: spamassassin (2.64-1) unstable; urgency=high * New upstream release - Rules backported from 3.0.0 - Problem on long headers fixed - Performance improvements * [SECURITY] Fixes a potential DoS attack, hence the urgency=high. -- Jesus Climent [EMAIL PROTECTED] Thu, 5 Aug 2004 08:50:17 +0300 Regards, Adam
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Mon, 2004-10-11 at 19:00, George Danchev wrote: Normally I wouldn't mention it but if you're going to pull people up on their grammar please at least get it right. :-) p.s. s/an MTA/a MTA Nope. An MTA, an SOS, a UPS. It's dependent on vowel /sounds/ rather than vowels. Adam
Re: packages.debian.org version discrepency
On Wednesday, October 13, 2004 5:06 PM, Shaun Jackman [EMAIL PROTECTED]
wrote:
The unstable link at http://packages.debian.org/freeguide shows
version 0.8, but http://packages.debian.org/unstable/misc/freeguide
shows version 0.7.2. Why is this?
gluck ({people,packages}.d.o}) became severely overloaded recently affecting
the generation of, amongst other things, the content of packages.d.o.
See #275047 and #276296 , filed against www.debian.org.
Regards,
Adam
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wednesday, January 05, 2005 8:42 AM, Ingo Juergensmann [EMAIL PROTECTED] wrote: Regarding James Troup... [...] I still believe that it would be better for the project when he would retire from some of his many positions, because he's too loaded with them. I'm assuming you haven't spotted the recent announcement that he now has assistance with much of the day-to-day work of one of those positions? (iirc, the one you're most fond of complaining about). [fwiw, if I understand correctly, the person in question was appointed after having spent considerable time contributing to the NM process and asking can I help lighten your workload?, as opposed to I don't think you're doing a good enough job, let me do it]. Cheers, Adam
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wednesday, January 05, 2005 10:05 AM, Ingo Juergensmann [EMAIL PROTECTED] wrote: [...] When Joerg Jaspert is already doing the dirty daily work, why does James still needs in place then? (Except he just stays in that position for a transitional period until Joerg is taking over that task and job completely. I would recommend that transitional period for other positions as well.) aiui, because James - or presumably some other member of -admin - needs to create the accounts once an nm has been approved (newsamosa, aka db.d.o is restricted). The most time-consuming part of DAM work is approving applicatants, which is what Joerg is now doing. afaics, once an applicant is approved, accounts are being created relatively quickly; so far it appears to be working well. Cheers, Adam
Re: Mass bug filing: failure to use invoke-rc.d when required
On Wednesday, May 17, 2006 7:59 AM, Lionel Elie Mamane [EMAIL PROTECTED] wrote: On Wed, May 17, 2006 at 12:53:39AM +0300, Lars Wirzenius wrote: ti, 2006-05-16 kello 09:53 +0200, Bas Zoetekouw kirjoitti: [...] AFAIK, vilolating policy always waarent a serious bug: [...] This is not what Steve Langasek tells me (or else I'm seriously misunderstanding). The etch_rc_policy.txt document is what documents what is release critical. Doesn't that mean the bug is severity serious, but should be tagged etch-ignore? That's what we did with sarge, if I remember well? No. The foo-ignore tags mean this issue /is/ RC, but we're ignoring it for the release of foo. Any bug tagged etch-ignore is by definition RC the moment etch is released. The exact definition of what qualifies for a severity of serious or above (i.e. RC) are the purview of the Release team, as noted at http://www.debian.org/Bugs/Developer#severities. A severe violation of Debian policy is one which violates the current release policy, as laid out by the Release team. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
On Thu, 2006-07-27 at 18:28 +0200, Goswin von Brederlow wrote: [breaking circular dependencies] Dpkg does it the way policy says it should do it and even slightly better since it checks for postinst files. That's unsurprising, given that the relevant sections of policy and dpkg were written by the same person. Specifically, the policy section was written as documentation of what dpkg /does/, rather than vice versa. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: huge wnpp bug report page
Hi, I tried to take a look at the wnpp bug page but neither Konqueror nor Firefox were able to handle it on my system. Really? Galeon handles it fine, as does Firefox (the latter on win32). 3182462 bytes for the HTML code of a single web page is a bit much, isn't it? Possibly. It's also 25% greater than the size of the page you quoted (wgetting the page gives an output of 2634857 bytes). Additionally, all links contain the server name. Why? Using a href=bugreport.cgi?bug=123456/a would be enough and would save a lot regarding download size. All the http://bugs.debian.org/cgi-bin/; prefixes could be ommitted. This would reduce page size by 93 bytes per bug ( 500KB total). Erm... no, they don't. For instance, having a copy of ftp.d.o's bug page handy :) : lia href=bugreport.cgi?bug=271782#271782: udeb sources need to be in sarge/a brPackage: a class=submitter href=pkgreport.cgi?pkg=ftp.debian.orgftp.debian.org/a; Severity: emimportant/em; Reported by: a class=submitter href=[EMAIL PROTECTED]Goswin von Brederlow lt;[EMAIL PROTECTED]gt;/a; Tags: strongsarge/strong; strong1 year and 323 days old/strong. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dresden-ocl missing orig.tar.gz
Hi, On Wed, 2006-08-09 at 14:50 -0300, Felipe Augusto van de Wiel (faw) wrote: I'm not quite sure how to report this. A user noted that whatever mirror he used to create his own mirror (using debmirror) he got a problem with dresden-ocl-1.0.1_orig.tar.gz. If he uses - --nosources then he can get the mirror. [...] And the .orig is not around. Not quite sure how to report this, and I would be happy to know for future references. ;) This is an instance of a known issue that occurs when packages move between components - in this case, from contrib to main (bug #341858 against ftp.debian.org). Specifically, the uploaded source package (.dsc, .debs and .diff.gz) are correctly placed in pool/main. The .orig.tar.gz is already in the archive in its original location in pool/contrib. There are two means of resolving the issue - convince an ftpmaster to fiddle the archive database or upload a new upstream version, and therefore a new .orig.tar.gz. The latter is far easier, particularly if there's a new upstream to upload anyway. In this specific instance, the issue has already been reported, as #367267 (also against ftp.d.o). Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: net-tools maintenance status
On Friday, August 05, 2005 3:42 PM, Olaf van der Spek [EMAIL PROTECTED] wrote: On 8/2/05, Bernd Eckenfels [EMAIL PROTECTED] wrote: On Tue, Aug 02, 2005 at 07:45:12PM +0200, Olaf van der Spek wrote: What's the maintenance status of the net-tools package? It is maintained. Patches are welcome. http://packages.qa.debian.org/n/net-tools.html Which patch are you talking about? The one for --wide Did you find it already? Any particular reason you didn't mail it to #222324? (I'm assuming that's the bug you're referring to; it's the only open bug against net-tools that mentions --wide, and neither of the bugs you've reported contain a patch) Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: http://www.debian.org/security/
On Tuesday, September 13, 2005 9:08 AM, Aaron Fisher [EMAIL PROTECTED] wrote: I am having the same problem with a sources.list file that reads as follows [...] deb http://security.debian.org stable updates [...] Err http://security.debian.org stable/updates Packages 404 Not Found That's hardly surprising, given that the path you've supplied doesn't - and isn't expected to - exist. As http://www.debian.org/security/ says, it should be: deb http://security.debian.org/ sarge/updates main contrib non-free (obviously contrib and non-free are optional, but (sarge|stable)/updates is one stanza not two and you need at least one of (main|contrib|non-free)). Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wed, 2005-09-28 at 23:56 +0300, Jari Aalto wrote: Alfie Costa [EMAIL PROTECTED] writes: | Wed, 21 Sep 2005 09:32:41 +, Gerrit Pape wrote: | | ...but try come up with a rule of thumb for '%%' (big suffix), '#' | (small prefix), etc.? Maybe the 'p' in percent is for Prefix -- but no, | the Prefix is the hash symbol; two signs are bigger than one, like Roman | numerals... it's a puzzle. It's in fact easier; the keys can be visualized easily. On keyboard: # % is on the leftis on the right Not on an en_GB keyboard they aren't. (Leaving aside the fact that at least en_GB iMac keyboards don't even have a key with a # legend). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Testing-watch emails
On Sat, 2005-11-05 at 00:17 +0100, Henning Makholm wrote:
Scripsit Steve Langasek [EMAIL PROTECTED]
If you're interested in making this happen I'll be happy to give
you any info I can;
OK, here are some questions.
1) The copy of britney in merkel:/org/ftp.debian.org/ does not seem
to be synced regularly. Is there a place where one can see the
current code? It's not in the dak cvs (which appears to be
out-of-date wrt the merkel mirror anyway), and I tried poking
around on {cvs,svn,arch}.debian.org to no avail.
http://ftp-master.debian.org/testing/update_out_code/ is the official
current code, afaik. From time to time, there may be other versions
floating around - there's a least one in ~ajt on ftp-master currently.
3) Do you (or somebody in QA who reads this) happen to know how the
'keyword' under which the PTS forwards emails is transmitted? I
cannot find any code in katie that sets this. Does the PTS analyse
subject lines for fixed patterns?
[EMAIL PROTECTED] is subscribed to -devel-changes and processes
the mails in real-time.
http://cvs.debian.org/pts/?cvsroot=qa is useful here.
http://wiki.debian.org/qa.debian.org/pts is linked from the front page
of p.qa.d.o, and contains a link to a presentation Raphael Hertzog
(buxy) made about the PTS.
(Currently I'm extrapolating from the documented
[EMAIL PROTECTED] syntax, but I'm not sure
that is the Right Thing to do).
I'm not sure this is the right list to ask on, what with this being
technical matters rather than a flamewar. :-) Feel free to move to
somewhere appropriate, cc'ing me.
In terms of the PTS, either asking buxy directly or [EMAIL PROTECTED] usually
works. britney and other ftp-master related topics are probably most
appropriate on [EMAIL PROTECTED], imho.
Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shell script sniplets in /usr/bin?
On Sun, 2005-01-30 at 17:18 +0100, Goswin von Brederlow wrote:
Matthew Palmer [EMAIL PROTECTED] writes:
[...]
Because I don't wanna play by the rules! is not a rationale. So you have
to specify a path -- so what? The way things stand at the moment, if I were
to drop a gettext.sh in my ~/bin (which is quite likely, except that I don't
like to put a .sh on my helper scripts) your shell scripts would suddenly go
tits-up in a most unpleasant fashion. Personally, *that* would be enough to
make me want to hardcode the path.
[...]
That is why you normaly have ~/bin last in PATH.
Not if you're using Debian's default install of bash you don't
(admittedly they're commented out by default, but...):
# set PATH so it includes user's private bin if it exists
if [ -d ~/bin ] ; then
PATH=~/bin:${PATH}
fi
More to the point, putting ~/bin last in PATH breaks most of the reasons
for having it there in the first place (being able to override
system-installed versions).
Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problems with public keys
Nico Golde [EMAIL PROTECTED] wrote, Wednesday, June 08, 2005 9:52 AM My qa page http://qa.debian.org/[EMAIL PROTECTED] looks like this: General information for Id: [EMAIL PROTECTED] (click to collapse) GPG key id not found! (key id was not found neither in the Debian keyring nor on a public keyserver) developer.php is currently configured not to check against any external keyservers. See #307461 and http://lists.debian.org/debian-qa/2005/05/msg2.html Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Questions on how to handle this: [EMAIL PROTECTED]: httperf_0.8-3_i386.changes REJECTED]
Roberto C. Sanchez [EMAIL PROTECTED], wrote, on Friday, June 17, 2005 6:37 AM: Below I have included the text rejecting my httperf package. I am taking over as maintainer and uploaded a new version that also closed a couple of bugs and moved it from non-US to main. If linking with libssl is not permissible, should the version that is currently in Sarge be slated for removal when 3.1r1 comes out? There is no httperf package in sarge, as there is no non-US archive for sarge, so the question is academic. As http://packages.debian.org/httperf shows, the package currently only exists in oldstable/non-US. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: anyone using interactive bugscripts
Bastian Venthur wrote: is anyone using interactive bugscripts? I mean scripts in /usr/share/bug/ which interactively demand answers from the user. I made a quick search on my system and I only found the texlive packages using getkey to force a user to read a text before the script is executed. I'd suggest adding yesno to your search terms. Regards, Adam -- 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
Cyril Brulebois wrote, Thu, 25 Jun 2009 14:51:46 +0200: Lucas Nussbaum lu...@lucas-nussbaum.net (25/06/2009): On 25/06/09 at 10:32 +0200, Harald Braumann wrote: Checkbashisms is a lintian check, right? No, it's in devscripts. Yes, it is also a lintian check. Although not as complete, see lintian's check/scripts file. For completeness... checkbashisms started life as basically a copy of the relevant section of checks/scripts and the two then developed separately. More recently there's been a crossover between devscripts and Lintian maintainership (i.e. me) so they've become much more closely synced. I tend to apply obvious fixes to both and let newer or more FP-prone features mature in checkbashisms for a bit before adding them to Lintian. Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Source package taking over removed package's place in the namespace
Magnus Holmgren wrote, Thursday, May 31, 2007 1:04 PM Situation: Two source packages collide in the namespace. The second one gets rather awkward name. Later, the first package dies and is removed from unstable, testing, and (after release) stable, but still remains in oldstable. Question: Can the second source package take the first source package's (less awkward) name, or does it have to wait until oldstable is archived? So far as I can tell, that should be fine. dak requires that (source, version) tuples be unique, so the new source package would need to have a different (practically, higher) version than the old one; that's not a problem in this case. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Filing FTBFS bugs and packages in NEW
Ron Johnson wrote: On 06/01/07 04:59, Kari Pahula wrote: I'd like to file a wishlist bug on people who file FTBFS bugs. It would be nice if you checked first whether there's a package pending in NEW or incoming and see if that might resolve the issue already. I'm looking at you, #426867. Even though I am not #426867, how do you access the NEW queue? For appropriate values of access - http://ftp-master.debian.org/new.html Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#427297: ITP: sturmbahnfahrer -- simulated obstacle course for automobiles
On Mon, 2007-06-04 at 21:33 +0200, Izak Burger wrote: [...] But no-one said english was logic :-) What with unkempt (no such word as kempt though) I didn't think there was, but http://www.askoxford.com/concise_oed/kempt?view=uk disagrees ;) Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 14:08 -0400, Felipe Sateler wrote: Mike Hommey wrote: On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov [EMAIL PROTECTED] wrote: On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote: billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!) =10^12 :) and Germany, France, former UdSSR, insert your country here Anywhere where milliard is 10^9, basically... Which includes England, according to Merriam-Webster [1]. [...] [1] http://www.m-w.com/mw/table/number.htm The American usage has been becoming more common in England (and the rest of Britain :-) over the past few years, particularly in science and finance related usage. I could be wrong, but I suspect most British people have never even heard of a milliard. It's usually referred to either as a billion or an American billion. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with closing certain bugs
On Fri, 2007-06-29 at 12:58 -0400, Daniel Schepler wrote: I appear to be unable to close certain bugs lately, while others work fine. One earlier example was #205163, which I was trying to close as it was fixed a long time ago. Then yesterday closing #379237 and #387587 worked, but in the same message my attempt to close #378102 was rejected. With both #205163 and #378102 I got a bounce message saying that [EMAIL PROTECTED] was an unknown user. #205163 and #378102 are both archived (and therefore by definition also closed). Modifications to archived bugs aren't possible, so debbugs won't accept mail for them. [#205163 was closed in October 2003 so would have been archived some time in November 2003. #378102 was closed in July 2006 whilst archiving was disabled and finally archived on June 17th this year.] FWIW, I'm guessing the two bug numbers may have been typos as #378102 is a mysql security bug and #205163 a translation for gnapster whereas your closure message refers to gcc. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 and ASCII character encodings
Neil Williams wrote, Wednesday, July 25, 2007 10:07 AM On Wed, 25 Jul 2007 14:13:23 +0530 Kumar Appaiah [EMAIL PROTECTED] wrote: [...] OK. It's in the NEW queue. Could you please tell me the procedure to prevent it from entering the archives? Retitle the ITP to a RM http://wiki.debian.org/ftpmaster_Removals and explain why. You can't remove something that's not in the archive... Probably best to also send an email (referencing this thread in the debian-devel archives) to [EMAIL PROTECTED] asking for the package to be rejected from NEW. The release team don't manange NEW. Kumar, you need to e-mail [EMAIL PROTECTED] and ask them to reject the upload from the NEW queue. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug closed by spam for the second times
[EMAIL PROTECTED] wrote: OK, this reopens and also reports. [...] echo reopen $bug| mail -s Reopening $bug closed by spam [EMAIL PROTECTED] w3m -dump http://bugs.debian.org/cgi-bin/bugspam.cgi?bug=$bug;ok=ok; else echo If you've got devscripts installed, then bts reopen $bug . reportspam $bug will do the same. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug closed by spam for the second times
Vincent Danjean wrote: Adam D. Barratt wrote: If you've got devscripts installed, then bts reopen $bug . reportspam $bug will do the same. I suppose that the 'reportspam' command does the same thing as the link 'Send a report that this bug log contains spam' on the bts webpage ? Yes. It GETs the URL that the link refers to. * Verify report for bug 343140 Yes, report bug 343140 as spam * and I did not validate here because I was not sure if the whole bug #343140 would be maked as spam or only some part of it. There's at least #498257 requesting that the text be clarified (I may have missed others, I remember that report as it was filed a few hours ago). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of RC-buggy source packages by maintainer/uploader
On Tue, 2008-10-07 at 05:56 +0200, Lucas Nussbaum wrote: On 06/10/08 at 18:36 -0500, Raphael Geissert wrote: Lucas Nussbaum wrote: [...] Steve Langasek [EMAIL PROTECTED] firmware-nonfree (U) mklibs (U) openldap (U) php5 (U) Steve stepped down from php's maintenance a couple of uploads ago (he is no longer in Uploaders even in the version in lenny); looks like a bug somewhere in UDD. I'm not sure how dd-list really works. I just ran dd-list to generate the per-maintainer list. It runs apt-cache showsrc (which doesn't include Steve here for php5 on sid). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Britney error with the gossip package?
On Tue, 2008-10-07 at 20:21 +0100, Neil Williams wrote: $ rmadison libloudmouth1-0 libloudmouth1-0 |1.4.0-1 | testing | alpha, amd64, arm, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc libloudmouth1-0 |1.4.2-1 | unstable | alpha, amd64, arm, armel, hppa, hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc How did gossip migrate with Build-Depends on a version of libloudmouth1-0 that still does not exist in Lenny? britney only considers installability, not buildability. That is to say, if package A depends on B (= 2) then an appropriate version of B must (in the absence of hints to the contrary) exist in testing, but if A /build/-depends on B (= 2) then britney does not care whether B exists in testing at all, yet alone with the correct version. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503087: ITP: openvpn-auth-ldap -- The OpenVPN Auth-LDAP Plugin implements username/password authentication via LDAP for OpenVPN 2.x.
Hi, Brivaldo Alves da Silva Jr wrote: Package: wnpp Severity: wishlist Owner: Brivaldo Alves da Silva Jr [EMAIL PROTECTED] I want to add this functionality to OpenVPN to auth on OpenLDAP. There's already a package of openvpn-auth-ldap (packaged by Debian's openvpn maintainer) in the NEW queue, waiting to be processed by the ftpmasters. http://ftp-master.debian.org/new/openvpn-auth-ldap_2.0.3-1.html Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503087: ITP: openvpn-auth-ldap -- The OpenVPN Auth-LDAP Plugin implements username/password authentication via LDAP for OpenVPN 2.x.
Hi, Thanks, How can I close this bug? Just e-mail [EMAIL PROTECTED] I've done that with this mail, so the bug should now be closed (or will be in a few minutes time). Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503367: [Debian-med-packaging] Bug#503367: plink: file conflict with putty-tools
On Sat, 2008-10-25 at 20:18 +0300, Teodor wrote: Since renaming seems to be the only solution, than IMO it is more appropriate to rename 'plink' in putty-tools than in the plink packages since this is exactly the source/binary package name. [...] This has been done already in putty-tools for the 'puttygen' binary. [...] piti:~# dpkg -L putty-tools [snip] /usr/bin/pscp /usr/bin/psftp /usr/bin/plink /usr/bin/puttygen Erm, puttygen isn't renamed. That's what the upstream binary is known as and has been ever since its creation more than four years ago (although more often puttygen.exe for predictable reasons). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: can buildd logs be sorted (again)?
On Wed, 2008-10-29 at 12:47 -0600, Raphael Geissert wrote: Peter Palfrader wrote: On Wed, 29 Oct 2008, Patrick Matthäi wrote: You should report a bug against qa.debian.org / www.debian.org. Neither of those is the correct contact/package regarding buildd.debian.org. I guess we don't have a metapackage for w-b and buildd.d.o. Maybe eventually that will be fixed. *cough*, what about contacting Ryan Murray? he is the one listed at buildd.d.o In this specific case, he was already CCed on Steve's mail which began this thread... Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibly excessive lintian warnings (was: NEW processing)
On Thu, 04 Dec 2008 01:00:17 -0800, Russ Allbery wrote: Sune Vuorela [EMAIL PROTECTED] writes: Latest, the warning about quilt patches without any description. Sure it is nice to have a description, but I don't need lintian to tell it. This is severity: minor, certainty: certain, which currently *barely* makes the W threshold. I think a very good argument could be made that this is actually severity: wishlist, which would downgrade it to an I. I'm copying debian-lint-maint to see what the other Lintian maintainers think. As I mentioned to Sune on IRC last night, the quilt tag's severity was copied from the equivalent dpatch tag (which was originally implemented as a warning and then moved to minor/certain during the transition). I've no problem with downgrading the severity, although we should make a corresponding change to the dpatch tag at the same time, unless there's some reason it's particularly worse for a dpatch to be missing a description. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW processing
On Wed, 03 Dec 2008 20:28:59 -0600, Raphael Geissert wrote: From the lintian hacker desk: $ lintian -I --exp-output format=letterqualifier [...] Other *experimental* output formats are 'xml' and 'colons' (currently b0rken). It's fixed in HEAD (well, it now works for me). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibly excessive lintian warnings
On Thu, 2008-12-04 at 12:51 -0800, Russ Allbery wrote: Adam D. Barratt [EMAIL PROTECTED] writes: As I mentioned to Sune on IRC last night, the quilt tag's severity was copied from the equivalent dpatch tag (which was originally implemented as a warning and then moved to minor/certain during the transition). I've no problem with downgrading the severity, although we should make a corresponding change to the dpatch tag at the same time, unless there's some reason it's particularly worse for a dpatch to be missing a description. I think they're equivalent cases. Personally, I vote for downgrading them both. I agree... Unless there are any objections, I'll do that in a bit. ... and did that an hour ago. Apologies for not waiting a little longer for objections / consensus. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Test suites after build and Build-Depends.
On Fri, 2009-01-30 at 09:00 -0800, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: In reality, it is an endangered mechanism, as it was deprecated in January 2008. I'm not sure what you're referring to here. I'd guess Charles meant the following addition to README.feature-removal-schedule, from the dpkg source package: What: substvars support in dpkg-source and dpkg-genchanges Status: deprecated When: lenny+1 Warning: program Why: substvars do not make sense during generation of .dsc and .changes files. This also means that it won't be possible anymore to override the Format field output by dpkg-genchanges. Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debhelper = 7.2.3, doc-base, and lintian
On Wed, 2009-03-11 at 15:33 -0400, Jay Berkenbilt wrote: I just built a new version of one of my packages, and I got some lintian errors like this: E: qpdf: prerm-does-not-call-installdocs usr/share/doc-base/qpdf-manual [...] Once I know where the problem is, I can either fix my packages or submit a bug to the appropriate place. The problem is that you have an out-of-date version of lintian. :-) lintian (2.2.7) unstable; urgency=low The debhelper 7.2.3 and lots of fiddly infrastructure fixes release. [...] + Removed - description-synopsis-has-leading-spaces - postinst-does-not-call-installdocs - prerm-does-not-call-installdocs [...] -- Russ Allbery r...@debian.org Sun, 08 Mar 2009 21:58:32 -0700 (on a related subject, note that lintian 2.2.8 will revert some of the debhelper 7.2.3 changes to the menu handling, to match changes in debhelper 7.2.5) Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: changes to default password strength checks in pam_unix
On Tue, 2007-09-04 at 07:53 +, Oleg Verych wrote: [...] What about having more secure Debian's sshd_config by default? PermitRootLogin no You'll have to convince the openssh package maintainers first - see #105571, #298138 and #431627 for their opinions on whether that change is more secure. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Releasing packages with 'pending' RC bugs
Daniel Baumann wrote, Thursday, September 27, 2007 11:43 AM out of curiousity.. imagine a package where: * the Debian maintainer is also upstream maintainer * the package has practically no users (popcon 10) * the package has RC bugs * the RC bugs are fixed upstream * the RC bugs are tagged pending in the BTS * the fixed package doesn't get uploaded (e.g. due to ENOSPONSOR) If I am not wrong (otherwise please do correct me) such a package would enter testing on the normal way, and hence, would be part of the upcoming stable release. You're wrong. Assuming that the RC bugs are not present in testing already, the testing scripts will not allow the package to migrate. Tagging bugs as pending does not stop them being RC and makes no difference to their impact on testing migration. If the package in testing is RC buggy it will get removed by the release team before release anyway. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: reportbug and usertags
On Tue, 2007-11-13 at 12:14 -0800, Don Armstrong wrote: [User: and Usertags: in reportbug-generated mails not reaching the BTS] Sounds like a bug in reportbug to me; it's probably stripping out unknown pseudoheaders. Indeed; see #418677 and #445144, both currently filed at wishlist against reportbug. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: late at night... can't think -- why is my bugs are not closed?
Hi, Yaroslav Halchenko wrote, Wednesday, January 23, 2008 8:03 AM In a fresh package (edac-utils) I have closed a bug in recent upload (proper Closes statement and a Closes in .changes). But bug remains Done but not closed: #456644. From edac-utils' bug index: Debian Bug report logs: Bugs in package edac-utils (versions 0.10-2 [alpha, amd64, arm, i386, ia64, mips, powerpc, s390, sparc], 0.10-1 [m68k]) in unstable [...] #456644: edac-utils: Errors were encountered during configuration Package: edac-utils (edac-utils 0.10-1; fixed: edac-utils 0.10-2); i.e. the m68k package in unstable is still buggy. The bug will stop being outstanding once it isn't present in any package - i.e. once m68k has -2 in the archive. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: late at night... can't think -- why is my bugs are not closed?
Hi, On Wed, 2008-01-23 at 22:39 -0500, Yaroslav Halchenko wrote: Well... as Neil pointed it seems not to be the case -- m68k arch is still -1 but now it is resolved. Where are you seeing it as resolved? It's still listed as outstanding on http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=edac-utils;dist=unstable Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Wed, 2008-01-30 at 10:29 -0800, Russ Allbery wrote: Raphael Geissert [EMAIL PROTECTED] writes: [...] The script basically uses find on those directories (under /usr/share it only searches for '*.sh') and then uses file on those to get a new list of those file being shell scripts which are then checked with checkbashisms. lintian shouldn't depend on checkbashisms. It already has its own implementation of this code (which from this thread is actually better). lintian's parsing code certainly sounds better (mainly because checkbashisms is based on an old version of the lintian code) but, from a quick look, checkbashisms flags more issues than lintian does. We do appear to be missing a few though; I'll have a look at getting them back in sync. Adam (with devscripts hat on) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Sat, 2008-02-09 at 16:39 -0800, Russ Allbery wrote: Raphael Geissert [EMAIL PROTECTED] writes: Atm, checkbashisms only complains with this: _From_: bashisms-amd64-2.10.15/libtool_1.5.26-1_amd64.deb possible bashism in ./usr/bin/libtool line 1218 (trap with signal numbers): trap $run $rm $removelist; exit $EXIT_FAILURE 1 2 15 This one is somewhat arguable. Pure POSIX doesn't allow signal numbers, but the XSI extension to POSIX does and dash and posh both support them. We do not, in general, accept XSI extensions, but it's hard to argue strongly for excluding a feature that even posh supports. That check was recently added during the lintian - checkbashisms sync. If the feeling is that its incorrect, it should probably be removed from lintian as well. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Sat, 2008-02-09 at 16:59 -0800, Ben Pfaff wrote: Raphael Geissert [EMAIL PROTECTED] writes: Atm, checkbashisms only complains with this: _From_: bashisms-amd64-2.10.15/libtool_1.5.26-1_amd64.deb possible bashism in ./usr/bin/libtool line 1218 (trap with signal numbers): It's weird that it calls this a possible bashism. It's not a bashism (at most, it's an XSI-ism) and it's so pervasively supported that even Autoconf uses it. In hindsight, checkbashisms may not have been the best name for the script, but checkscriptcompliestosus isn't quite as catchy. :-) I'm debating adding an option to ignore XSI-isms when checking scripts. However, I will add that a) the check is also in lintian, albeit only for maintainer scripts and b) so far as I can see, using it in scripts with a /bin/sh shebang is technically a policy violation, even if not one that people care about. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Version numbering for security uploads of native packages
[nutshell version for those who can't be bothered to read the full mail :-) - what version number should a security upload of a native package have] Hi, devscripts 2.10.19 (soon to be uploaded) will modify the behaviour of debchange --nmu to version an NMU of a native package as X+nmu1 rather than the current X-0.1. We're aware that the Developers Reference specifies that the latter format should be used, but it is problematic as -0.1 sorts before +b1 and, as such, the NMU will not supersede any previous binNMUs of the same package version. Whilst looking at this change, the question arose of what format security uploads of native packages should use, both in general and specifically when debchange's --security option is used. Currently, debchange will produce a version number of X-0.1 in such cases which suffers from the problem described above. It has been suggested that either one of +s1 / +sec1 / +security1 or release1 should be used to avoid the issue. The main difficulty with the latter from the point-of-view of adding support to debchange is that there's no easy way of mapping a changelog distribution (e.g. stable) to a release name, particularly as both stable and oldstable updates may have stable as the last distribution to which the package was uploaded. After some discussion amongst the team on IRC we decided we'd be happiest following either a request from the security team or a consensus view (or as close to a consensus as -devel ever gets :-). Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
On Sun, 2008-03-16 at 03:47 -0700, Steve Langasek wrote: The current binNMU numbering scheme was selected explicitly to allow security uploads to sort later by numbering as last_version+releaseserial; e.g., 1.2-5.1+etch1. That makes sense, although doesn't seem to match current practice. Was any consideration given as to where NMUs of native packages should sort? (I realise that they're the only case that doesn't automagically dtrt with respect to the numbering scheme). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote: [Adding bug #437392 to Cc, which deals with this issue for normal NMUs, because I'm making a suggestion about them.] On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote: devscripts 2.10.19 (soon to be uploaded) will modify the behaviour of debchange --nmu to version an NMU of a native package as X+nmu1 rather than the current X-0.1. Good idea. Even better, IMO, would be to use a system which is in line with non-native packages. How about this rule: [using X.1] IMO this solution is slightly better than +nmu1, because it makes versions of native and non-native packages more uniformly mangled. However, any solution is better than no solution. :-) That does seem the most logical suggestion thus far. As .19 fixes a couple of regressions I'd like to get it uploaded soon so may stick with +nmu for the moment (as you say, it's still better than -0.1). [...] It has been suggested that either one of +s1 / +sec1 / +security1 or release1 should be used to avoid the issue. The main difficulty with the latter from the point-of-view of adding support to debchange is that there's no easy way of mapping a changelog distribution (e.g. stable) to a release name, particularly as both stable and oldstable updates may have stable as the last distribution to which the package was uploaded. So the problem is that debchange is unable to know the version should be stable? Or is the problem that versions may collide when oldstable has a security update, and stable needs one as well? The problem is that the security team want to use version numbers such as Xetch1 or Xsarge1 and these can't reliably be deduced simply by looking at the package. If one takes the case of a package in etch or sarge that has not yet had a security update, how would dch know whether to use sarge1 or etch1 in the version number? The most recent changelog entry for both packages would be for stable. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote: Adam D. Barratt [EMAIL PROTECTED] writes: On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote: [...] Good idea. Even better, IMO, would be to use a system which is in line with non-native packages. How about this rule: [using X.1] IMO this solution is slightly better than +nmu1, because it makes versions of native and non-native packages more uniformly mangled. However, any solution is better than no solution. :-) That does seem the most logical suggestion thus far. I dislike this approach because it makes it impossible for tools like Lintian to recognize NMUs of native packages and perform other NMU-specific checks (such as making sure an appropriate changelog entry is present). There's no way of knowing whether a native package with a version number of 1.2.1 is an NMU or not. Indeed. Luk already pointed out on irc that this is the (or at least a) reason .1 wasn't suggested by DevRef. I like the +nmuN approach. devscripts 2.10.19 including +nmuN was uploaded earlier this evening. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Service stopping in prerm considered harmful
Ed Falk wrote, 2008-03-28 01:35: For the nth time squared, an initscript MUST NOT FAIL to stop an already stopped service. How is it supposed to do that? The service isn't running, so can't be stopped, therefore the script (if called to stop it) can only fail to stop it... If the service is already stopped, then the script should declare victory and return. Am I missing something? Yes - the fact that the comment you replied to was language pedantry rather than a technical argument. :) Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: uscan download URL mangling
Michal Čihař wrote, Monday, April 07, 2008 11:16 AM I currently have following, but it does not seem to work and the #md5= is not removed. opts=downloadurlmangle=s/#.*// \ http://pypi.python.org/simple/python-mpd/ \ http://pypi.python.org/packages/source/p/python-mpd/python-mpd-(.*)\.tar\.gz#.* downloadurlmangle affects the URL that uscan downloads, not the filename that the result is saved under; for the latter you want filenamemangle: opts=filenamemangle=s/^.*(python-mpd-.*?\.tar\.gz)#.*$/$1/ \ http://pypi.python.org/simple/python-mpd/ \ http://pypi.python.org/packages/source/p/python-mpd/python-mpd-(.*?)\.tar\.gz#.* There may be a better solution, but the above does work. Regards, Adam -- 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
Roberto C. Sánchez wrote, Thursday, April 17, 2008 2:24 AM On Wed, Apr 16, 2008 at 04:25:46PM +0100, Matthew Johnson wrote: do you have updated devscripts? debsign signs the dsc then updates the md5 hash in the changes before signing that. It needs to update the sha checks as well. The latest devscripts does. Will the devscripts in stable be updated to handle this? If so, when? If not, why not? (If you're looking for an answer from the maintainers of a package it's probably safer to ask them directly rather than assuming they read every post on debian-devel; admittedly several of us do, but... :-) I'm not convinced it meets the SRM team's criteria for a stable update, as laid out in http://release.debian.org/stable/4.0/4.0r3/ et al. 2.10.25 should migrate to testing over the weekend, so hopefully a bpo package won't be too much longer. In the meantime it's fairly easy to backport yourself, as several people have already done, or simply copy the new script over from an unstable machine. Other than the update for the new .changes file format, there have been relatively little changes to debsign since the version in etch, and those have all been bugfixes. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NMU versioning (was: DEP1: Clarifying policies and workflowsfor Non Maintainer Uploads)
Raphael Hertzog wrote, Friday, April 25, 2008 3:16 PM On Fri, 25 Apr 2008, James Vega wrote: On Thu, Apr 24, 2008 at 09:42:59PM +0200, Bas Wijnen wrote: This DEP is available on the Debian Wiki[1]. The version must be the version of the last upload, plus +nmuX, where X is a counter starting at 1. The above was added to the DEP to match dch but dch only uses that format for native NMUs as per the earlier discussion on -devel[0]. Is this an intended change to usk +nmuX for all NMUs or should the wording be updated to reflect current behavior? I want a consistent versioning scheme, thus +nmuX for both native and non-natives packages. Consider this a wishlist bug against devscripts. :-) I was already intending to implement that, _assuming the DEP gains acceptance_. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do I trace aptitude dependencies?
Russ Allbery wrote: Bryan Donlan [EMAIL PROTECTED] writes: Currently I have a situation where attempting to upgrade imagemagick from version 7:6.2.4.5.dfsg1-1+lenny1 to version 7:6.3.7.9.dfsg1-2+b1 pulls in over 200mb of dependencies, including mozilla-browser, iceape-browser, and half of gnome. Both devscripts and djvulibre have some really unfortunate Recommends right now. Most of the worst offenders in devscripts's case should have been fixed by now. Some of the remainder may not be ideal, but that mostly comes down to what one considers to be important functionality of the package, which we're well aware that there isn't exactly consensus on. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do I trace aptitude dependencies?
On Mon, 2008-04-28 at 09:40 -0700, Russ Allbery wrote: Goswin von Brederlow [EMAIL PROTECTED] writes: I recommend to always do an upgrade before doing a dist-upgrade (or install of something pulling in 200mb). The upgrade will never install new or remove packages so it is save. It usualy reduces the number of packages to something where the search algorithm doesn't go wrong. This is what I used to do as well, but it doesn't seem to be working that way any more. upgrade (and safe-upgrade) was pulling in a bunch of new packages due to devscripts's Recommends. That should gradually be improving, as the Recommends have been trimmed for the majority of the recent uploads (including the as-yet-unuploaded 2.10.27). Some of them (e.g. citadel-*) are side-effects of issues with other packages. :-/ Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: morse package is Architecture: any but build daemons won't act
On Wed, 2008-05-07 at 21:45 +0200, Joop Stakenborg wrote: It looks like the morse package isn't built by the build daemons, even though it is Architecture: any in the control file. I think this might be caused by the morse package in oldstable, which was a totally different package with the same name and i386 only. Someone needs to trigger the build daemons, please? It's listed in Packages-arch-specific (http://cvs.debian.org/*checkout*/srcdep/Packages-arch-specific?root=dak) as being i386-specific. If that's no longer the case, you need to e-mail one of the people listed at the top of the file and ask them to remove it. Regards, Adam -- 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
On Wed, 2008-05-14 at 19:50 +0200, Luk Claes wrote: 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. I assume Osamu was confused by the fact that this paragraph mentions RSA consistently: | 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: and then suggests using the following: | gpg --clearsign ~/.ssh/id_dsa.pub | mail [EMAIL PROTECTED] ^^^ in order to send your /RSA/ key :) (I'd guess the preceding text mentioned DSA at one point). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: possible mass-bug filing on fc-cache-using packages
martin f krafft wrote, Tuesday, May 20, 2008 1:41 PM also sprach Josselin Mouette [EMAIL PROTECTED] [2008.05.20.1323 +0100]: Le mardi 20 mai 2008 à 12:05 +0100, martin f krafft a écrit : if [ $1 = configure -a -x /usr/bin/fc-cache ] Note -that the $1 = configure check is wrong, see #446856. Also, the -a is a bashism, isn't it? It is, but one that policy 10.4 explicitly permits. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
Michael Meskes wrote, 2008-06-23, 10:07:27 +0200: With our move to dash as sh we have to remove all bashisms from scripts run by /bin/sh. However, checkbashism seems to moan about clauses that work in dash as well. I don't know in which shells a trap with a signal number is guaranteed to work, but it seems to work well in dash. It's not guaranteed to work in any shell implementing POSIX without extensions, which is what Policy says you're allowed to rely on (well, plus a few extensions, but not including trap and kill with signal numbers). In general the definition of bashism used by checkbashisms and lintian in this case is not portable to a shell implementing SUSv3 2004 without extensions, with the potential exception of those explicitly allowed by Policy. I just ran a short test, so if the devil's in the detail I might have missed something, but nevertheless I wonder if this feature can safely be used. It's safe for use with dash, but using it is technically a violation of Policy (albeit a widespread one). There is a Policy bug open requesting that the XSI extensions for trap and kill be permitted (#477240). Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
On Mon, 2008-06-23 at 19:28 +0200, Michael Meskes wrote: On Mon, Jun 23, 2008 at 05:39:07PM +0100, Adam D. Barratt wrote: It's not guaranteed to work in any shell implementing POSIX without extensions, which is what Policy says you're allowed to rely on (well, plus a few extensions, but not including trap and kill with signal numbers). Right. But what does this mean in terms of our Lenny release goal dash as sh which essantially was what I meant to ask. I'd assume it doesn't make any difference in terms of that release goal as (as you noted) dash supports the syntax. It's safe for use with dash, but using it is technically a violation of Policy (albeit a widespread one). There is a Policy bug open requesting that the XSI extensions for trap and kill be permitted (#477240). From this I'd say for Lenny using trap with a signal number is fine. As fine as it was for etch :-) Also they same question comes up with the local keyword. Dash seems to support this, while it is not POSIX. Policy contains an explicit exemption for local, although it places several restrictions on exactly how the keyword may be used. Again, if dash supports the syntax then the dash as sh release goal is achievable without changing the code; whether that code is Policy compliant is another matter. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
On Mon, 2008-06-23 at 19:45 +0200, Michael Meskes wrote: On Mon, Jun 23, 2008 at 01:33:21PM -0400, James Vega wrote: From this I'd say for Lenny using trap with a signal number is fine. Also they same question comes up with the local keyword. Dash seems to support this, while it is not POSIX. The local keyword is an explicitly supported extension. These are discussed in Section 10.4 of policy. Thanks to James and Adam for the explanations. Maybe I could ping the devscripts maintainers to add a not-xsi-but-supported-by-policy flag. :-) /me coughs in the direction of devscripts' Uploaders field (I'm assuming you'd noticed, but just in case :-) Assuming not-POSIX-but-supported-by-policy checkbashisms already has a flag to indicate whether echo -n should be flagged for exactly this reason; otherwise it errs on the side of not flagging constructs that are policy-compliant. Supporting local x would be relatively simple; suggestions for a reliable regex to catch use of -a/-o welcome... :) Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
On Mon, 2008-06-23 at 17:52 -0700, Russ Allbery wrote: Adam D. Barratt [EMAIL PROTECTED] writes: Supporting local x would be relatively simple; suggestions for a reliable regex to catch use of -a/-o welcome... :) There was a fairly good one in Lintian that I took out once Policy blessed it, or at least we didn't get a lot of false positive reports. Thanks; that looks like it stands a good chance of being resilient. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
On Tue, 2008-06-24 at 09:34 -0500, Raphael Geissert wrote: Russ Allbery wrote: Adam D. Barratt [EMAIL PROTECTED] writes: Supporting local x would be relatively simple; suggestions for a reliable regex to catch use of -a/-o welcome... :) There was a fairly good one in Lintian that I took out once Policy blessed it, or at least we didn't get a lot of false positive reports. Maintainer scripts are fairly simple so I don't think there will be many false positives ;) The expression looks fairly robust and passes my testing so far; admittedly the archive is full of scripts that break almost every assumption I ever made about shell scripting. This is getting a little off-topic for -devel I think :) Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
On Tue, 2008-06-24 at 13:36 +0200, Michael Meskes wrote: On Mon, Jun 23, 2008 at 07:00:13PM +0100, Adam D. Barratt wrote: Assuming not-POSIX-but-supported-by-policy checkbashisms already has a flag to indicate whether echo -n should be flagged for exactly this reason; otherwise it errs on the side of not flagging constructs that are policy-compliant. It does flag both, trap and local. This is how I came to my question. As per previous messages, the uses of trap flagged aren't policy compliant; the uses of local being flagged should also be those which aren't policy compliant - if that's not the case, it's a bug in checkbashisms. To be precise, the current tests flag the use of local foo=bar and local -n foo as neither is supported by policy; local x is permitted and therefore not flagged. The next release of checkbashisms will include a --posix flag which will allow the non-POSIX behaviours permitted by policy to be flagged. Currently neither set of local checks flags local x, y; I seem to remember there being a discussion relating to that syntax on the -policy list a while ago but need to check whether it reached any conclusions. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
Adam D. Barratt wrote: [...] The next release of checkbashisms will include a --posix flag which will allow the non-POSIX behaviours permitted by policy to be flagged. Currently neither set of local checks flags local x, y; I seem to remember there being a discussion relating to that syntax on the -policy list a while ago but need to check whether it reached any conclusions. Actually, ignore that. I was thinking of local a b which policy explicitly says can't be relied upon. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bashism question
Lars Wirzenius wrote:
To clarify: is local foo=bar policy-compliant or not?
(If not, *sigh*.)
To the best of my knowledge, no, it's not compliant. The relevant section
reads:
snip
* `local' to create a scoped variable must be supported; however,
`local' may or may not preserve the variable value from an outer
scope and may or may not support arguments more complex than
simple variables. Only uses such as:
fname () {
local a
a=''
# ... use a ...
}
must be supported.
snip
As foo=bar is an argument more complex than simple variables and the
example explicitly shows the use of local to declare the variable followed
by assignment to it, my reading of policy is that local foo=bar is not
permitted.
Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#491156: ITP: postgresql-8.3-plr -- Procedural language interface between PostgreSQL 8.3 and R
Andreas Tille wrote: On Thu, 17 Jul 2008, Thomas Viehmann wrote: The package was removed after noone was interested in maintaining it for four(!) years. Huh? [...] * Orphan package (see #228074). -- Martin Pitt [EMAIL PROTECTED] Sun, 30 Dec 2007 20:38:42 +0100 That's about 6 month and not four years. #228074 is an RFA for the package, filed in January 2004 and with no sign of any interest. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#161978: this really should be checked by lintian
Hi,
On Mon, August 25, 2008 11:56, Holger Levsen wrote:
downgrading severity, as this is about an old issue with tetex and because
there is probably even a lintian check for this already. (Too lazy to
confirm
now, thus I'm also not reassigning the bug to lintian yet.)
As far as I can see, the section of the bug report regarding tetex relates
to shipping content in /usr/local; if that's the case then it will indeed
be flagged by lintian, as {dir,file}-in-usr-local (both Error tags).
Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#605912: runit: Upgrade failure lenny - squeeze
# CC to debian-devel for squeeze blocker user release.debian@packages.debian.org usertag 605912 + squeeze-is-blocker thanks Hi, Thanks for looking at this bug. I think the patch you've suggested is the wrong solution, however. On Tue, 2011-01-04 at 01:14 +0900, Hideki Yamane wrote: I guess it is due to lack of flag in debconf templates file. Here's a proposal patch, it works in my chroot environment. [...] +runit (2.1.1-6.2) unstable; urgency=low + + * Non-maintainer upload. + * debian/control +- add missing depenedency debconf (= 0.5) | debconf-2.0 + * debian/runit.templates.in +- add runit-run/install (Closes: #605912) The code in the config script which sets the runit-run/install flag as seen (which is where this bug comes from) is guarded by a check for upgrades from versions = 2.0.0-1, which is the version in lenny. However, runit only ever suggested runit-run, so the code was always broken. As runit-run no longer exists after lenny, I think removing the entire block of code would be a better solution. In terms of the second part of the patch, the package's use of debconf looks a little odd. There is one template, which says can I signal init to restart?. Previously, the signalling was performed without asking, which broke in environments where there was no such process, such as vservers (see #542593). The implemented solution asks this question at low priority if an init process is found, and high priority if not; in both cases the default is yes, which does not seem to make much sense in the case where it has already been determined that there is no such process. It's possible that I simply need more coffee, but it may make more sense to simply rip the debconf use back out, and have the postinst signal init based simply on the existence of an init process. Comments welcome. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294505796.2903.5925.ca...@hathi.jungle.funky-badger.org
Re: /etc/profile.d
On Mon, January 10, 2011 09:57, Nicholas Bamber wrote: According to #370348, since 5.3 base-files has supported /etc/profile sourcing /etc/profile.d. I am using version 6.0. However /etc/profiles seems to be doing no such thing. When was the system in question installed? The changelog for base-files 5.3 says (emphasis mine) Changed *default* /etc/profile so that it sources /etc/profile.d/*.sh; /etc/profile is generated from the default file at initial install and not touched on upgrades, so if the system was installed with an earlier base-files version then you won't automatically get /etc/profile.d support. You can check /usr/share/base-files/profile in order to verify that the default file does include profile.d support. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/43e38a1e3a5c2d49e280cfd8e2163236.squir...@adsl.funky-badger.org
Your pdf-presenter-console upload
Hi, I was just having a look at the diff for your upload of pdf-presenter-console 1.1.1+git.02dfcf-3, fixing #609608, to check if it was suitable for unblocking for squeeze. Firstly, thanks for fixing the bug so quickly. Unfortunately, the upload included a couple of other changes which aren't really appropriate at this point of the freeze, specifically + * dh --parallel + * dh 8 One of the other changes means that the package is currently unbuildable in unstable: + * bump valac build-depends to 0.9.7+ per README.rst (debian/control) I've reported this as #609676. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/db7c866dcc3fe5258571e8afa2cfbbbf.squir...@adsl.funky-badger.org
Re: Your pdf-presenter-console upload
Gah, that was intended for debian-release, not debian-devel; please direct follow-ups to -release. On Tue, January 11, 2011 13:18, Adam D. Barratt wrote: Hi, I was just having a look at the diff for your upload of pdf-presenter-console 1.1.1+git.02dfcf-3, fixing #609608, to check if it was suitable for unblocking for squeeze. Firstly, thanks for fixing the bug so quickly. Unfortunately, the upload included a couple of other changes which aren't really appropriate at this point of the freeze, specifically + * dh --parallel + * dh 8 One of the other changes means that the package is currently unbuildable in unstable: + * bump valac build-depends to 0.9.7+ per README.rst (debian/control) I've reported this as #609676. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/db7c866dcc3fe5258571e8afa2cfbbbf.squir...@adsl.funky-badger.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52862eb945a9ea3a838e47639dc46b09.squir...@adsl.funky-badger.org
Re: Mass (non invasive) NMUs planned to fix debconf translations broken in multiple packages
On Wed, 2011-01-12 at 19:43 +0100, Christian PERRIER wrote: My plans are to upload before the end of the upcoming week-end an NMU for each of the affected package(s). I currently have: fwiw, from a quick look at the list, at least boxbackup would need a t-p-u upload in order to get fixed for squeeze; likewise bugzilla from Julien's original list. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294861399.9806.198.ca...@hathi.jungle.funky-badger.org
Re: security updates introducing breakage
On Thu, January 20, 2011 03:18, Paul Wise wrote: On Thu, Jan 20, 2011 at 10:59 AM, Brian May br...@microcomaustralia.com.au wrote: What is policy when security updates for stable introduce new regressions in software that weren't there before? Can these get fixed in stable? If a stable security update contained a regression, usually that is fixed with an update in the stable security archive. Please ping the maintainer and CC the security team about this. You will also want to unarchive the bug so that it can be closed again. Indeed, if an update via stable-security introduces regressions then these will usually be fixed via a further upload to stable-security. In this case, although the update was security related, it was actually made via proposed-updates as part of the 5.0.5 point release. Much the same applies in cases such as this, however. Alerting the maintainer should be the first step, with a CC to the Release Team being appreciated. I also wonder why the security team didn't pick this up, I guess they don't have any automatic tracking of bugs filed against versions they uploaded. I can't speak for the security team, but it's non-trivial for the Release Team to track all bugs filed against the version of a package in lenny and then determine whether the problem could have been introduced in a stable update. There's some great ongoing work to help ensure that RC bugs are correctly tagged and versionned to indicate whether they affect stable releases, and to help get them fixed where it's been determined that they do. For lower severity bugs, we do very much rely on maintainers and other interested parties bringing the issue to our attention. Once we're aware of the problem we're more than happy to get it fixed via a future point release; as with any such update, minimal, targetted and well tested patches are appreciated. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9ed67fdb1a765f1a4a2a3a5cf71c58d5.squir...@adsl.funky-badger.org
Re: Release file changes
On Mon, 2011-02-21 at 20:58 +0100, Joerg Jaspert wrote: until today our Release files included 3 Hashes for all their entries: MD5SUM, SHA1, SHA256. I just modified the code to no longer include MD5SUM in *all* newly generated Release files. When will that affect Release files for stable? Next point release? Because that unfortunatly completly breaks debmirror.. It did suddenly change for squeeze-updates without consultation with the suite admins. I expect that this is reverted. Good laugh that is. In any case, it would seem logical for squeeze and squeeze-updates to use the same set of hashes, imho; similarly the -proposed-updates suites. Each of the sister suites would generally be expected to be consumed (for want of a better word) by the tools in the corresponding (old)stable suite. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1298319528.14573.225.ca...@hathi.jungle.funky-badger.org
Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library
severity 615476 important tag 615476 + unreproducible thanks On Sat, 2011-02-26 at 21:25 +0300, sergey wrote: Some programs can not start because of missing libtiff.so.3 file. I suspect this is a local problem, as none of the packages in question depends on libtiff at all; I'm therefore lowering the severity and tagging this report as unreproducible for the moment. I found libtiff.so.3 dependencies in this files on my system: /usr/bin/gnuplot /usr/bin/xfe /usr/bin/xfview /usr/bin/xfwrite /usr/bin/multiget /usr/bin/xfimage /usr/bin/xfpack I've checked the copies of each of those binaries as shipped in squeeze on i386, and none of them appear to be using libtiff.so. Please could you provide the output of ldd -v $binary for each of the above? Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1298745818.535.6033.ca...@hathi.jungle.funky-badger.org
Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library
On Sat, 2011-02-26 at 13:08 -0600, Ron Johnson wrote: On Sat, 2011-02-26 at 21:25 +0300, sergey wrote: Some programs can not start because of missing libtiff.so.3 file. I suspect this is a local problem, as none of the packages in question depends on libtiff at all; I'm therefore lowering the severity and tagging this report as unreproducible for the moment. [...] Sid's gnuplot depends on libtiff.so.4 which while obviously not v3, is at least a libtiff.so. $ ldd -v /usr/bin/gnuplot | grep tiff libtiff.so.4 = /usr/lib/libtiff.so.4 (0x7fc3655a9000) /usr/lib/libtiff.so.4: Indeed, but ldd is recursive. gnuplot itself doesn't use libtiff, although one of its dependencies does - specifically libwx_gtk2u_core-2.8.so.0; see the output of objdump --private-headers, specifically the NEEDED entries. For completeness, I've checked the i386 package providing libwx_gtk2u_core-2.8.so.0 in squeeze, and it uses libtiff.so.4. My suspicion is that the ldd output will be sufficient in any case, and most likely point to a local copy of the library. If it doesn't, then we can narrow down where the dependency is coming from. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1298748799.535.6262.ca...@hathi.jungle.funky-badger.org
Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library
On Sun, 2011-02-27 at 14:33 +0300, sergey wrote: Is it possible that this problem exists because I have some old programs in /usr/local that I moved from my previous Slackware system? Yes, I suspect that's the problem; specifically: /usr/local/lib/libwx_gtk2u_core-2.8.so.0: The version of that library shipped by the Debian wx2.8 packages is linked about libtiff.so.4. Does moving the above out of the way resolve your issues? Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1298818956.535.10942.ca...@hathi.jungle.funky-badger.org
Re: Pushing tzdata updates to stable in time
On Fri, 2011-03-11 at 16:54 -0300, Henrique de Moraes Holschuh wrote: On Fri, 11 Mar 2011, Martin Zobel-Helas wrote: On Fri Mar 11, 2011 at 13:11:52 -0600, Gunnar Wolf wrote: Chile was supposed to leave the Summer daylight savings period this coming weekend, but it was pushed to April 2nd. The fixes have been accepted to the package in Sid, but many users will undoubtely appreciate it if it can be updated as well in stable-updates. [...] the correct way would be to ask the release team for a release of tzdata on stable-updates (formerly known as volatile) and get it updated in the next point release as well. [...] Is there a special process for this? or should we just make the DDs aware of the fact [by an email to d-d-a] that when one does a s-p-u upload which likely needs expedited handling, they should be very clear about that fact and email the stable release team ASAP? Those steps are backward, fwiw; the mail should come first for a p-u upload, not after the fact. I've made a note to mention stable-updates in an upcoming bits-from-SRM; now I just need to write one. :-) Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299873562.24129.116.ca...@hathi.jungle.funky-badger.org
Re: Pushing tzdata updates to stable in time
On Fri, 2011-03-11 at 13:54 -0600, Gunnar Wolf wrote: Martin Zobel-Helas dijo [Fri, Mar 11, 2011 at 08:31:36PM +0100]: Chile was supposed to leave the Summer daylight savings period this coming weekend, but it was pushed to April 2nd. The fixes have been accepted to the package in Sid, but many users will undoubtely appreciate it if it can be updated as well in stable-updates. [...] the correct way would be to ask the release team for a release of tzdata on stable-updates (formerly known as volatile) and get it updated in the next point release as well. Yes - although that should be preceded with a suitable package built targetted at Squeeze, preferrably by the package maintainers, right? There's a tzdata package in the p-u-NEW queue which includes the change. Unfortunately it was uploaded slightly too late to make it in to the 1952 dinstall but I'll check the diff this evening and get it marked for acceptance in to p-u in the 0152. Assuming everything goes according to plan (adding packages to squeeze-updates hasn't actually been tested yet) I'm planning on pushing the tzdata update in tomorrow morning. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299874042.24129.141.ca...@hathi.jungle.funky-badger.org
Re: Pushing tzdata updates to stable in time
On Fri, 2011-03-11 at 20:07 +, Adam D. Barratt wrote: Assuming everything goes according to plan (adding packages to squeeze-updates hasn't actually been tested yet) I'm planning on pushing the tzdata update in tomorrow morning. Unfortunately, that didn't happen yet. Adding packages to squeeze-updates appears to work now, but an issue with this morning's dinstall means we won't be able to add tzdata in until after the 13:52UTC dinstall has finished happily, so it won't start getting pushed out until during the 19:52UTC dinstall. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299931744.22892.618.ca...@hathi.jungle.funky-badger.org
Re: Pushing tzdata updates to stable in time
On Sat, 2011-03-12 at 12:09 +, Adam D. Barratt wrote: On Fri, 2011-03-11 at 20:07 +, Adam D. Barratt wrote: Assuming everything goes according to plan (adding packages to squeeze-updates hasn't actually been tested yet) I'm planning on pushing the tzdata update in tomorrow morning. Unfortunately, that didn't happen yet. Adding packages to squeeze-updates appears to work now, but an issue with this morning's dinstall means we won't be able to add tzdata in until after the 13:52UTC dinstall has finished happily, so it won't start getting pushed out until during the 19:52UTC dinstall. Actually, thanks to ftp-master, it made the 1352 dinstall after all, so should start appearing on mirrors within a couple of hours or so. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299941051.22892.1121.ca...@hathi.jungle.funky-badger.org
Re: new Contents generator on ftp-master
On Sat, 2011-03-12 at 11:01 +0100, Torsten Werner wrote:
we have disabled the contents generator of apt-ftparchive and replaced
it by a new implementation in dak. There are some visible changes:
[...]
The new implementation is currently only used for suites that are not
marked as untouchable. Oldstable and stable will switch during the next
point release.
Have you (or anyone else) verified that any tools in {old,}stable
parsing contents files are compatible with the new structure (and
filenames in the case of udebs)?
Apologies if this was answered elsewhere in the thread and I simply
missed it, in which case a pointer would be appreciated.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1300220640.2477.443.ca...@hathi.jungle.funky-badger.org
Re: new Contents generator on ftp-master
On Tue, March 15, 2011 21:40, Joerg Jaspert wrote:
The new implementation is currently only used for suites that are not
marked as untouchable. Oldstable and stable will switch during the next
point release.
Have you (or anyone else) verified that any tools in {old,}stable
parsing contents files are compatible with the new structure (and
filenames in the case of udebs)?
As far as I remember, there is currently no user for the udeb contents
files.
Or that was the case last we had a discussion about it. :)
That wouldn't surprise me. The filenames were a bit of an add-on thought
to be honest, my main concern was the tool compatibility.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/c84c74dad8297a327440c4cd27cd48f8.squir...@adsl.funky-badger.org
Re: expected stable-updates but got squeeze-updates
On Wed, 2011-03-30 at 20:45 +, Christoph Anton Mitterer wrote: Using the following in sources.list: deb ftp://security.debian.org/debian-security/ stable/updates main contrib non-free deb-src ftp://security.debian.org/debian-security/ stable/updates main contrib non-free The above is not related to the warning below. Compare the server names and suite names between the two. I always get warnings like these: W: Conflicting distribution: ftp://debian.mirror.lrz.de stable-updates Release (expected stable-updates but got squeeze-updates) when updating. Is this a false warning of apt[itude] or a problem on the ftp-servers? It's not really either of those, but rather due to your sources.list containing an entry for debian-mirror.lrz.de for the stable-updates suite. However, the suite is actually called squeeze-updates, and that's therefore what appears in the Release file. Changing sources.list to point at squeeze-updates instead should make the warning go away. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301521131.12508.4061.ca...@hathi.jungle.funky-badger.org
Re: expected stable-updates but got squeeze-updates
On Thu, 2011-03-31 at 00:10 +0200, Christoph Anton Mitterer wrote: On Wed, 2011-03-30 at 22:38 +0100, Adam D. Barratt wrote: On Wed, 2011-03-30 at 20:45 +, Christoph Anton Mitterer wrote: Using the following in sources.list: deb ftp://security.debian.org/debian-security/ stable/updates main contrib non-free deb-src ftp://security.debian.org/debian-security/ stable/updates main contrib non-free The above is not related to the warning below. Compare the server names and suite names between the two. Why not? It's the place where I set the suite name?! Because security.debian.org is not debian-mirror.lrz.de. The entries above are for security.debian.org, whereas the error message you quoted was for an entry containing debian-mirror.lrz.de; the entries for security are not what's causing your error message. It's not really either of those, but rather due to your sources.list containing an entry for debian-mirror.lrz.de for the stable-updates suite. However, the suite is actually called squeeze-updates, and that's therefore what appears in the Release file. Changing sources.list to point at squeeze-updates instead should make the warning go away. But then, why do we have those symlinks at all? And it's quite handy IMHO that one can just use stable and get the current stable suite. It's also not universally agreed to be a good idea, as once a new stable release occurs, your next apt-get update will suddenly pull in an entirely new release's package lists, which isn't generally what you want. However, having squeeze in sources.list whilst the Release file contains stable works okay, so I assume apt is managing the translation internally in that case. If it doesn't do so when the Release file contains a codename then this is likely to become a more general problem in future, given that ftp-master would like to move the archive to being codename-based internally. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301523849.12508.4212.ca...@hathi.jungle.funky-badger.org
Re: expected stable-updates but got squeeze-updates
On Thu, March 31, 2011 09:18, David Kalnischkies wrote: Its simpler: The Release files tell us which Codename and Suite this archive is for - if thats different from the one you mentioned in sources.list you will get this lovely warning And yes, Christoph is right, something is wrong with stable-updates as if we look at the current Release file of it [0] we can see that it says [ ] Suite: squeeze-updates Codename: squeeze-updates [ ] change Suite to 'stable-updates' and it will work again for everyone who has 'stable-updates' written in his sources.list. Actually, I suspect codename should be changed in this case - the suite is called squeeze-updates in projectb, so that's correct. I'm also not sure quite what's going to happen here once the rest of the archive moves to becoming codename-based internally, which is on ftp-master's to-do list. User with sources.list entries mentioning 'squeeze-updates' doesn't have a problem with it obviously The normal stable gets it right with 'stable' and 'squeeze'. Yep, I'd forgotten about the disparity there, and the fact that a bug already exists - #614310. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/fa12efec373be599ef1c0c6f54fbd221.squir...@adsl.funky-badger.org
Re: Packages upgraded to same version in Testing Excuses
On Sun, 2011-04-03 at 21:24 +0200, Johan Walles wrote: Look here: http://ftp-master.debian.org/testing/update_excuses/2011040311.html.gz Look at the following line: lia id=asymptote/amd64 name=asymptote/amd64asymptote/amd64/a (2.02-2 to 2.02-2) Why is asymptote being upgraded both from and to 2.02-2? Shouldn't it be upgraded from something older to something newer? Look three lines further down: liUpdated binary: asymptote (2.02-2 to 2.02-2+b1) The version numbers in the line you quoted refer to the source package version, which hasn't changed. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301860437.3992.562.ca...@hathi.jungle.funky-badger.org
Re: time based freezes
On Mon, 2011-04-04 at 12:12 -0400, Scott Kitterman wrote: On Monday, April 04, 2011 12:05:09 PM Neil McGovern wrote: I also note a lack of replies to feedb...@release.debian.org - these mails are definately useful, but I really would appreciate any comments going there, so I don't have to spend days trawling archives to pick up people's points. That seems like an odd reply to a message in a thread you started on debian- devel? Unless you're counting the d-d-a mail, Neil didn't start the thread; in fact, as far as I can see, it's his first post to it - the time based freezes thread in reply to the d-d-a mail was started by Zack. fwiw, the d-d-a mail said: The beginning of a release cycle seems the ideal time for that discussion and we hope to be in a position to start it after processing the results of the retrospective. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301949141.23878.263.ca...@hathi.jungle.funky-badger.org
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
On Wed, April 20, 2011 09:57, Paul Wise wrote: On Wed, Apr 20, 2011 at 4:47 PM, Neil Williams codeh...@debian.org wrote: .. as validated by the desktop-file-validate utility, as used by lintian. desktop-file-validate is not used by lintian, perhaps there should be a test similar to the man-db test though. fwiw, it has been requested that lintian use d-f-v (#455740) but at least at the time it apparently didn't fit the task properly and no one had enough free time to properly investigate its suitability. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/12562632d971f6e48f6623b0c33976d4.squir...@adsl.funky-badger.org
Re: Bits from the Release Team - Kicking off Wheezy
On Thu, April 28, 2011 19:03, Lucas Nussbaum wrote: On 28/04/11 at 12:05 -0400, Joey Hess wrote: And at the same time, having a non-frozen rolling release available during freeze time could easily distract people from working on testing/frozen at all, because a shiny rolling release that they and some users can use is still available. I am unhappy during the current choke point of testing being frozen, but that choke point does serve as an incentive for the whole project to work in the same direction: toward actually getting a good stable release out. That's not true. It serves as an incentive for a large number of DDs to just do something else until the freeze is over and they can start working on their packages again. There's a degree to which this is self-perpetuating though. The larger the number of maintainers who decide to just do something else until the freeze is over, the smaller the number of people actually working on getting the issues in testing fixed and the longer the freeze is likely to last, all other things being equal. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/341b334c5b7042c6d7b817b61ac8a9fb.squir...@adsl.funky-badger.org
Re: 0-day NMUs for RC bugs without activity for 7 days?
On Fri, 2011-05-06 at 18:38 -0400, Roberto C. Sánchez wrote: On Fri, May 06, 2011 at 11:14:55PM +0200, Lucas Nussbaum wrote: - Doing an NMU without trying to contact the maintainer beforehand could be considered an aggressive behaviour, or a way to punish the maintainer for not addressing bugs as fast as one would like. We are trying hard to fight the feeling that NMUs are an aggression, this could be counter-productive. So, my experience with #624819 was basically this. The bug was reported, followed by an NMU upload about 45 minutes after the bug was initially reported. For the avoidance of any doubt, that's not what's being suggested here and wouldn't be covered under the proposed patch (older than 7 days, without maintainer activity for 7 days). Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304722575.30839.673.ca...@hathi.jungle.funky-badger.org
Re: Lintian based autorejects
Brian May wrote: On Tue, Oct 27, 2009 at 02:57:35PM +, Simon McVittie wrote: - statically-linked-binary This is not always a bug. e.g. dar-static is supposed to be statically linked! Lintian intentionally doesn't warn about binaries with names ending -static, hence the non-appearance of dar-static on http://lintian.debian.org/tags/statically-linked-binary.html Cheers, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xulrunner, poppler, gnome and gupnp transitions
On Sun, 2009-11-08 at 12:48 +0100, Luk Claes wrote: * gupnp - libnice not yet rebuilt/reuploaded libnice was binNMUed as part of this transition so shouldn't be a blocker. The remaining issue that I can currently see here is gupnp-igd being out-of-date on mips. Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xulrunner, poppler, gnome and gupnp transitions
On Sat, 2009-11-14 at 15:45 +0100, Luk Claes wrote: Josselin Mouette wrote: [...] Le dimanche 08 novembre 2009 à 12:48 +0100, Luk Claes a écrit : [...] - empathy not built on kfreebsd* It’s waiting on geoclue, which in turn needs disabling of gammu support on !linux. There does not seem to be any bug filed about this, is there any progress in that regard? #556178 was filed against geoclue this morning, but has already been marked as wontfix and closed. The suggestion was to modify gammu to build without libusb support on !linux, but there doesn't appear to be any open request to do that. In either case, geoclue also Build-Depends on network-manager-dev, which is not available on kfreebsd-*; removal of the build-dep on those architectures was also requested in #556178. Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
