Re: The use of epoch in version
Hi, others have given alternatives to the epoch already and I would follow them. You can never get rid of an epoch again so think hard about adding one for the first time. Now to the reason i reply: Mats Erik Andersson mats.anders...@gisladisker.se writes: In setting a positive epoch in the control file, I still notice that all package files are assigned a version that does not display the epoch-prefix 1:, yet I know that many packages brought in from a repository displays such prefixes. Could it be that the build daemons assign those? The epoch contains a ':'. Since that is problematic character for some filesystems (or operating systems where you might have to download debs to for later installation). So is times long past someone decided that filenames should not contain the epoch so the files wouldn't be problematic. On the other hand when you download packages with apt it will rename them to include the epoch but encodes the : to avoid filesystem problems. The name of the file is really irelevant and dpkg only looks what is inside the file in the DEBINA/control file. Hope that explains what you see. MfG Goswin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
help with BTS mail interface
Dear Mentors, I've read some notes on how to use the Debian BTS via email [0] [1] [2], but I am still a bit confused. Rogério Brito has submitted a wishlist bug report for lbzip2 [3]. As Rogério has accepted my proposal to use an external tool for his need, I'd like to close the bug with a wontfix tag. My question to the mentors list is the following: (1) what addresses should I put in the To: field, and (2) how should I format the body of my message, so that (a) the bug gets closed, (b) the wontfix tag is saved in the appropriate place, (c) my explanation message shows up both on the bug report page, and also on another bug's page [4], (d) the submitter (Rogério) gets a copy? I'm thinking of something like this: v To: 567196-d...@bugs.debian.org, Rogério Brito Cc: 563...@bugs.debian.org Subject: alternative accepted by submitter Package: lbzip2 Version: 0.20-1 Tags: wontfix thanks longer explanation ^ Thank you very much, lacos [0] http://www.debian.org/Bugs/Developer#closing [1] http://www.debian.org/Bugs/Reporting#pseudoheader [2] http://www.debian.org/Bugs/Developer#tags [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567196 [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563929
Re: help with BTS mail interface
Hi! Let me address each point separately. On Fri, Jan 29, 2010 at 02:22:03PM +0100, Ersek, Laszlo wrote: Rogério Brito has submitted a wishlist bug report for lbzip2 [3]. As Rogério has accepted my proposal to use an external tool for his need, I'd like to close the bug with a wontfix tag. My question to Closing with a wontfix tag is something which people do, but I personally don't prefer. wontfix, IMHO, should be reserved for something like a potential problem or misfeature, which you acknowledge, but don't want to fix, at least for now. Usually, wontfix bugs are left open, so that 10 other people don't blindly submit the same bug report. I assume that you merely wish to close the bug in the following. the mentors list is the following: (1) what addresses should I put 1. nn-d...@bugs.debian.org in the To: field, and (2) how should I format the body of my message, so that (a) the bug gets closed, (b) the wontfix tag is saved in the appropriate place, (c) my explanation message shows up You cannot really close the bug and add the wontfix tag at the same time. You can send a separate mail to cont...@bugs.d.o with tags nn + wontfix to add the tag if you want to. both on the bug report page, and also on another bug's page [4], (d) the submitter (Rogério) gets a copy? Sending the mail to -done ensures that the mail is shown in the BTS page as well as the fact that the submitter receives it. I'm thinking of something like this: v To: 567196-d...@bugs.debian.org, Rogério Brito Cc: 563...@bugs.debian.org Subject: alternative accepted by submitter Package: lbzip2 Version: 0.20-1 Tags: wontfix thanks Won't work. :-) Check one of the several bugs which were just closed from the BTS. Randomly, I'll point you to this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547220#14 HTH. Kumar -- ...Deep Hack Mode--that mysterious and frightening state of consciousness where Mortal Users fear to tread. (By Matt Welsh) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: help with BTS mail interface
On Fri, Jan 29, 2010 at 08:34:49AM -0600, Kumar Appaiah wrote: [snipped OP's exampl Won't work. :-) Check one of the several bugs which were just closed from the BTS. Randomly, I'll point you to this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547220#14 By won't work, what I meant is that, while the bug would be closed, the tags won't be added; the pseudo-headers in your example won't be parsed by the BTS. Kumar -- World domination. Fast (By Linus Torvalds) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: help with BTS mail interface
On Fri, Jan 29, 2010 at 02:22:03PM +0100, Ersek, Laszlo wrote: need, I'd like to close the bug with a wontfix tag. My question to the mentors list is the following: (1) what addresses should I put in the To: field, and (2) how should I format the body of my message, so that (a) the bug gets closed, (b) the wontfix tag is saved in the appropriate place, (c) my explanation message shows up both on the bug report page, and also on another bug's page [4], (d) the submitter (Rogério) gets a copy? Ignoring for now the anomaly of closing a wontfix bug, which Kumar has already addressed, this is what I would send to achieve this result. Rationale: 567196-done closes the bug and copies the submitter, your existing CC is fine, and cont...@bugs.debian.org will process the commands at the top of the email. Your longer explanation will be ignored by it, but the whole thing will be recorded in the BTS for time eternal. v To: 567196-d...@bugs.debian.org Cc: 563...@bugs.debian.org, cont...@bugs.debian.org Subject: alternative accepted by submitter tag 567192 wontfix thanks longer explanation ^ HTH, -- Jonathan Wiltshire 1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: help with BTS mail interface
On Fri, 29 Jan 2010, Jonathan Wiltshire wrote: Ignoring for now the anomaly of closing a wontfix bug, which Kumar has already addressed, this is what I would send to achieve this result. I'll do this. Thank you both very much, lacos -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: foolscap (updated package)
* replace python-zopeinterface with python-zope.interface in Depends * please fix lintian warnings: W: foolscap source: source-nmu-has-incorrect-version-number 0.5.0+dfsg-1 W: foolscap source: changelog-should-mention-nmu use team name as last updater to fix these two ^ W: foolscap source: debhelper-but-no-misc-depends python-foolscap W: python-foolscap: binary-without-manpage usr/bin/flappclient W: python-foolscap: binary-without-manpage usr/bin/flappserver -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
RFS: xfe (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.32.1-3 of my package xfe. It builds these binary packages: xfe- A lightweight file manager for X11 xfe-i18n - A lightweight file manager for X11 (i18n support) xfe-themes - A lightweight file manager for X11 (themes) The package appears to be lintian clean. The upload would fix this FTBFS bug: 560549 Now xfe can be compiled on GNU/kFreeBSD architectures. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/x/xfe - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/x/xfe/xfe_1.32.1-3.dsc I would be glad if someone uploaded this package for me. Kind regards Joachim Wiedorn signature.asc Description: PGP signature
RFS: r5u87x
Dear mentors, I am looking for a sponsor for my package r5u87x. * Package name: r5u87x Version : 0.2.1+r63+dfsg1-1 Upstream Author : Alexander Hixon a...@alexhixon.com * URL : http://www.bitbucket.org/ahixon/r5u87x/ * License : GPL-2+ Section : contrib/misc It builds these binary packages: r5u87x - firmware loader for cameras based on Ricoh R5U87x chipsets The package appears to be lintian clean. The upload would fix these bugs: 563081 My motivation for maintaining this package: This firmware loader is currently the only way to make cameras based on Ricoh R5U87x chipsets work under Linux. These cameras are used on several Sony Vaio, HP Pavilion and Fujitsu Lifebook laptops. An RFP has been open on Launchpad for more than two and a half years (https://launchpad.net/bugs/120434). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/contrib/r/r5u87x - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/contrib/r/r5u87x/r5u87x_0.2.1+r63+dfsg1-1.dsc I would be glad if someone uploaded this package for me. Please CC me if you reply on-list. Best regards, David Jurenka -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: help with BTS mail interface
Kumar Appaiah a.ku...@alumni.iitm.ac.in writes: Closing with a wontfix tag is something which people do, but I personally don't prefer. wontfix, IMHO, should be reserved for something like a potential problem or misfeature, which you acknowledge, but don't want to fix, at least for now. I can see the logic of this. What, then, should be the tag applied for “not a bug” or otherwise invalid reports? -- \ “A free society is one where it is safe to be unpopular.” | `\—Adlai Ewing Stevenson | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: help with BTS mail interface
Ben Finney ben+deb...@benfinney.id.au writes: Kumar Appaiah a.ku...@alumni.iitm.ac.in writes: Closing with a wontfix tag is something which people do, but I personally don't prefer. wontfix, IMHO, should be reserved for something like a potential problem or misfeature, which you acknowledge, but don't want to fix, at least for now. I can see the logic of this. What, then, should be the tag applied for “not a bug” or otherwise invalid reports? In Debian, the standard practice is to just close them. Some maintainers tag them with wontfix before closing them, but the tags on closed bugs are mostly ignored so it's not clear that this makes much difference. I prefer not to tag such bugs wontfix when closing them because if they're re-opened, usually it's for reasons that would also remove the wontfix tag, so it just requires more effort on both sides. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: xfe (updated package)
On Fri, Jan 29, 2010 at 10:07:59PM +0100, Joachim Wiedorn wrote: I am looking for a sponsor for the new version 1.32.1-3 of my package xfe. The upload would fix this FTBFS bug: 560549 Now xfe can be compiled on GNU/kFreeBSD architectures. Jep builds + works fine on kfreebsd-i386 (build and tested there, now uploading soon-to-hit the archive. Regards Christoph -- /\ ASCII Ribbon : GPG-Key ID: 0xD49AE731 \ /Campaign : CaCert Assurer X against HTML : Debian Maintainer / \ in eMails : http://www.debian.org/ http://www.christoph-egger.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Indicating the resolution of a closed bug report (was: help with BTS mail interface)
Russ Allbery r...@debian.org writes: Ben Finney ben+deb...@benfinney.id.au writes: Kumar Appaiah a.ku...@alumni.iitm.ac.in writes: Closing with a wontfix tag is something which people do, but I personally don't prefer. […] What, then, should be the tag applied for “not a bug” or otherwise invalid reports? In Debian, the standard practice is to just close them. Some maintainers tag them with wontfix before closing them, but the tags on closed bugs are mostly ignored so it's not clear that this makes much difference. I would guess (and in my case, I know) that the people who do this are using it for some standard indication of the “resolution” of the bug report. That is, answering the question “What was the state of the bug when this report was closed?” The usual case would be “fixed”, so that can be assumed in the absence of such information. But for reports closed *without* a “fix”, it would be good to indicate that, probably with standard tags. Do they exist? -- \ “Isn't it enough to see that a garden is beautiful without | `\ having to believe that there are fairies at the bottom of it | _o__) too?” —Douglas Adams | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Indicating the resolution of a closed bug report
Ben Finney ben+deb...@benfinney.id.au writes: I would guess (and in my case, I know) that the people who do this are using it for some standard indication of the “resolution” of the bug report. That is, answering the question “What was the state of the bug when this report was closed?” The usual case would be “fixed”, so that can be assumed in the absence of such information. But for reports closed *without* a “fix”, it would be good to indicate that, probably with standard tags. Do they exist? There are tags, and there is the closed status. They are entirely independent in the Debian BTS, except that you can't set tags on archived bugs. So if a maintainer wishes to use tags for that purpose, there's certainly nothing stopping them. The Debian BTS already distinguishes effectively (IMO) between bug reports that were closed because they were fixed and bug reports that were closed for other reasons, usually because they were invalid. Bug reports that are closed because they were fixed are closed indicating a version of the package in which they were fixed, and the BTS knows that the bug is still present in older versions. I personally therefore don't feel a need to use additional tags to distinguish between various closed states for my packages. My personal experience is that doing more than distinguishing between closing a bug because it was fixed in a particular version or versions and closing a bug for some other reason for all versions is busy-work that I'd rather not bother with. The distinction between WONTFIX, INVALID, and WORKSFORME in Bugzilla, for instance, is a distinction I've never seen much utility in drawing. This is just my personal opinion for my own packages. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Indicating the resolution of a closed bug report
Russ Allbery r...@debian.org writes: Ben Finney ben+deb...@benfinney.id.au writes: The usual case would be “fixed”, so that can be assumed in the absence of such information. But for reports closed *without* a “fix”, it would be good to indicate that, probably with standard tags. Do they exist? […] The Debian BTS already distinguishes effectively (IMO) between bug reports that were closed because they were fixed and bug reports that were closed for other reasons, usually because they were invalid. Bug reports that are closed because they were fixed are closed indicating a version of the package in which they were fixed, and the BTS knows that the bug is still present in older versions. […] That's a good point. Okay, so the “usual case” discussed above is where the bug report has one or more fixed versions indicated. If the bug report is closed, but no fixed versions are indicated, the implication is the bug isn't fixed but doesn't need further work (conflating “works for me”, “not a bug”, and so on). That meets my needs, at least. Thanks for the clarification. -- \ “To have the choice between proprietary software packages, is | `\ being able to choose your master. Freedom means not having a | _o__)master.” —Richard M. Stallman, 2007-05-16 | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: qt-shutdown-p
Dear mentors, I am looking for a sponsor for my package qt-shutdown-p. * Package name: qt-shutdown-p Version : 1.6.31-1 Upstream Author : Christian Metscher hakai...@web.de * URL : http://revu.ubuntuwire.com/p/qt-shutdown-p https://launchpad.net/qt-shutdown-p/+download https://launchpad.net/~hakaishi/+archive/qt-shutdown-p/+packages (sorry, I don't know which one is needed) * License : GPL3 Section : utils It builds these binary packages: qt-shutdown-p - Qt4 program to shutdown the computer The package appears to be lintian clean. My motivation for maintaining this package is: Because my package is good? - Ehrm... no, I think my package is quite useful. It should run on any system and is pretty slim. I know several people that would want so see this package in Debian/Ubuntu/Kubuntu [...]. Well, I don't know what else to say (also because I'm not so used to speak or write in english), so I'll just leave it at that. -^_^- The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qt-shutdown-p - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qt-shutdown-p/qt-shutdown-p_1.6.31-1.dsc I would be glad if someone uploaded this package for me. Kind regards Christian Metscher -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: help with BTS mail interface
Le Fri, Jan 29, 2010 at 02:22:03PM +0100, Ersek, Laszlo a écrit : v To: 567196-d...@bugs.debian.org, Rogério Brito Cc: 563...@bugs.debian.org Subject: alternative accepted by submitter Package: lbzip2 Version: 0.20-1 Tags: wontfix thanks Dear Laszlo, in the above example, you are mixing the use of pseudo-headers and the use of the bug control and manipulation mailserver. With pseudo-headers, you do not need to end the processing with a thanks command, since the email is not sent to cont...@bugs.debian.org. http://www.debian.org/Bugs/Reporting#pseudoheader http://www.debian.org/Bugs/server-control Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
package split
Hi all, Sometimes splits package in this reason [0] usually are 'package' and 'package-data', but how can I fix troubles similar to [1] that upgrading this try to overwrite on 'package' previously installed? (the last version is 'package' and 'package-data', and the previously version just is 'package') Could I fix this with a preinst script to uninstall previously version? or this could be handled in other way [2] (File conflicts should not occur if you upgrade from a ...) [0]http://lintian.debian.org/tags/arch-dep-package-has-big-usr-share.html [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558190 [2]http://www.debian.org/releases/lenny/i386/release-notes/ch-upgrading.en.html#trouble Thank you. Elías Alejandro -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: package split
Le Sat, Jan 30, 2010 at 01:35:26AM -0500, Elías Alejandro a écrit : Sometimes splits package in this reason [0] usually are 'package' and 'package-data', but how can I fix troubles similar to [1] that upgrading this try to overwrite on 'package' previously installed? (the last version is 'package' and 'package-data', and the previously version just is 'package') Could I fix this with a preinst script to uninstall previously version? or this could be handled in other way [2] (File conflicts should not occur if you upgrade from a ...) Dear Elías, there are control fields to inform dpkg that it is acceptable to overwrite another package's files because the installed package replaces it. http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: xfe (updated package)
Hello Christoph, Christoph Egger christ...@debian.org wrote: Jep builds + works fine on kfreebsd-i386 (build and tested there, now uploading soon-to-hit the archive. Thanks for testing and uploading! Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
