Re: Q: Ubuntu PPA induced version ordering mess.
On Monday, July 1, 2024 5:59:00 PM EDT Alec Leamas wrote: > On 01/07/2024 21:51, Andrey Rakhmatullin wrote: > > Hi Andrey. > > Thanks for input. > > > On Mon, Jul 01, 2024 at 09:46:11PM +0200, Alec Leamas wrote: > >> After some thought, I tend to think that adding an epoch is the right > >> thing > >> here. > >> > >> The Policy [1] says: > >> --- > >> Epochs can help when the upstream version numbering scheme changes, but > >> they must be used with care. You should not change the epoch, even in > >> experimental, without getting consensus on debian-devel first. > >> --- > >> > >> With all this said: Is this a case where using a epoch is justified? If > >> not, why? > > > > Adding epochs to work around 3rd-party repo version problems sounds quite > > wrong. We don't even add epochs that Ubuntu itself adds. > > But this is not about third parties, it's about upstream which publishes > PPA packages. So far these are by far the most used Linux packages. > > I also hesitate to add an epoch, after all they are basically considered > evil. But if we should not use them when upstream has a broken > versioning we are about to replace, when should we use it? > > I have good relations with upstream, and they are willing to abandon the > current broken versioning in favor of something sane. But the legacy is > there, and we need to handle it. > > Have considered tricks like adding a 1. prefix to the debian/ubuntu > versions. But to me, this looks even worse. > > Thoughts? Upstream can change the versioning however they want. They are upstream. If they don't care to fix it, then I think we assume they are fine with it and leave it as is. Scott K signature.asc Description: This is a digitally signed message part.
Re: Q: Ubuntu PPA induced version ordering mess.
On July 1, 2024 10:18:07 PM UTC, Alec Leamas wrote: >On 02/07/2024 00:10, Scott Kitterman wrote: > >Hi Scott, > >> Upstream can change the versioning however they want. They are upstream. If >> they don't care to fix it, then I think we assume they are fine with it and >> leave it as is. > > >But here the situation is that upstream do care and wants to fix it. But they >need our help (an epoch) to accomplish this to handle the legacy. > >We could be helpful, or not. Why not give a hand? > No. That's us fixing it. They can bump the version to whatever they want to address the issue. Epochs are forever, so should be a last resort. Scott K
Re: Q: Ubuntu PPA induced version ordering mess.
On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote: > On 02/07/2024 00:31, Scott Kitterman wrote: > > HI again > > > On July 1, 2024 10:18:07 PM UTC, Alec Leamas wrote: > >> But here the situation is that upstream do care and wants to fix it. But > >> they need our help (an epoch) to accomplish this to handle the legacy. > >> > >> We could be helpful, or not. Why not give a hand? > > > > No. That's us fixing it. They can bump the version to whatever they want > > to address the issue. Epochs are forever, so should be a last resort. > Yes, epochs are forever and should not be taken lightly, agreed. > > Expanding on the situation. The current opencpn version is 5.9.x, soon > to be 5.10 in a tick-tock cycle. > > However, the opencpn packages have versions like 8763.x, automatically > generated from a build number. This is not communicated to users, they > just install and update. > > Obviously, upstream should start building packages with versions like > 5.9.x..., 5.10.x... etc. But any such version is lower than the current > build number. > > If you switch hats for a moment: have you any advice for upstream in > this situation? > > --alec 8763.5.10 Next build is: 8763.5.10~8764 Scott K signature.asc Description: This is a digitally signed message part.
Re: Q: Ubuntu PPA induced version ordering mess.
On Monday, July 1, 2024 7:07:16 PM EDT Alec Leamas wrote: > On 02/07/2024 00:54, Scott Kitterman wrote: > > On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote: > >> If you switch hats for a moment: have you any advice for upstream in > >> this situation? > > > > 8763.5.10 > > Yes, I have had a similar idea using 1 instead of 8763 to make it > stand out less. In my eyes, this is worse and will lead to that the > package versions does not match the "public" version like 5.10.2. > > But if the list agrees that this is the correct solution so be it. To be > honest, it might be a hard sell upstream. > > > Next build is: > > > > 8763.5.10~8764 > > Why? > > --alec Because the '~' means less than. It's a way to add the build number to the interim versions in the future without causing the same problem again. I guess it should have been 8763.5.11~8764, if 5.11 is the next 'real' version. Scott K signature.asc Description: This is a digitally signed message part.
Re: Q: Ubuntu PPA induced version ordering mess.
On July 1, 2024 11:25:59 PM UTC, Alec Leamas wrote: >On 02/07/2024 01:19, Alec Leamas wrote: > >> Let's drop this subthread, keeping eyes on the ball: what is a sane version? > >Looking at this from another point of view: is there any situation where an >epoch is appropriate? Yes. I don't think this is it. A sane version is one that's higher than the last one. If upstream wants the last one to include their versioning from non-Debian packages, they can do that. If they don't want to, that's fine, but I don't think we should either then. Scott K
Re: Q: Ubuntu PPA induced version ordering mess.
On July 2, 2024 12:26:49 AM UTC, Soren Stoutner wrote: >Alec, > >On Monday, July 1, 2024 5:19:37 PM MST Alec Leamas wrote: >> For Debian users we backport opencpn which works well. However, the >> Ubuntu backport process is, well, interesting (been there, done that). >> >> The PPA represents a much better way to publish backports to current >> Ubuntu branches. But for this to work we need to reset the versioning so >> it works together with the official stream from Debian. >> >> Anyway, seems we have a emerging conclusion that an epoch is a correct >> solution here. > >That adds some needed clarification. I agree that in that circumstance, >adding >an epoch is the best way forward. It allows you to maintain the current >upstream program version number, while unifying the Debian, Ubuntu, and PPA >version numbers in such a way that packages from those repositories can be >used interchangeably. > I would suggest that you work with upstream on how they will version things in the future, so you aren't bumping the epoch every year. Scott K
Re: Removing more packages from unstable
On August 20, 2024 7:46:05 AM UTC, Andrey Rakhmatullin wrote: >On Tue, Aug 20, 2024 at 07:28:52AM +0200, Helmut Grohne wrote: >> please allow me to open a can of worms. Package removal from unstable. >> Deciding when it is time to remove a package from unstable is difficult. >> There may be users still and it is unclear whether keeping the package >> imposes a cost. In this mail I want to argue for more aggressive package >> removal and seek consensus on a way forward. > >Yes please. > >> What does package removal cost? >> >> Before a package can be removed, it needs to be reviewed for reverse >> dependencies and if there are any, they have to be switched to something >> else or removed as well. > >(leaf packages are much more straightforward to remove because of this) > >> Human readable explanation: >> * Packages in sid >> * not in bookworm or trixie >> * not a key package >> * affected by an RC bug that has been last modified more than a year ago >> * not among a few selected exceptions > >Makes sense, though non-leaf ones can't be processed automatically and so >I'm not sure what can be done with them. > >If we don't want to mass-remove all of these, there are additional >criteria (that I sometimes use to file manual removals) that can be added, >though not all of them are possible to determine automatically: > >* Leaf package >* A "library" (something not useful by itself) >* FTBFS - these can't be binNMUed, NMUed etc. without fixing an unrelated > bug first so they are in a worse condition thatn others in the context > we are discussing >* "Doesn't work at all" - these are not useful to users. >* Orphaned > >> Let us assume that we agree on there being a set of packages to be >> removed. What is a reasonable process? Is it ok to just file a pile of >> RoQA bugs or is more warning warranted? Should we maybe use a process >> similar to salvaging where there is an "ITR" (intent to remove) bug that >> is reassigned to ftp after a reasonable timeout? > >Removing packages that aren't formally orphaned always sounds too bold to >me, though it should be fine if we formalize a process (any process) for >that. > The process currently is file an rm but against ftp.debian.org for removal from unstable using RoQA (remember, we're all QA) explaining the rationale and an FTP Team member will assess it and remove the package if it seems reasonable (the above criteria are quite reasonable in that regard). There are people doing this, we could use more, but it does happen. I've processed lots of these and it's virtually always fine. In the rare case of a mistake, the cost to rectify the mistake is a trip through New. I don't think we need more process. We just need someone to do the work of finding the packages and filing the bugs. Scott K P.S. FTP Team member, but not speaking for the team.
Re: Removing more packages from unstable
On August 20, 2024 12:16:47 PM UTC, Andrey Rakhmatullin wrote: >On Tue, Aug 20, 2024 at 12:12:33PM +0000, Scott Kitterman wrote: >> >Removing packages that aren't formally orphaned always sounds too bold to >> >me, though it should be fine if we formalize a process (any process) for >> >that. >> > >> The process currently is file an rm but against ftp.debian.org for removal >> from unstable using RoQA (remember, we're all QA) explaining the rationale >> and an FTP Team member will assess it and remove the package if it seems >> reasonable (the above criteria are quite reasonable in that regard). >> >> There are people doing this, we could use more, but it does happen. I've >> processed lots of these and it's virtually always fine. In the rare case of >> a mistake, the cost to rectify the mistake is a trip through New. >> >> I don't think we need more process. > >Oh, I'm sure it's fine both for people filing these and the FTP team, I'm >worried about reactions from the maintainers of those packages. > For those cases, the people who have been doing this will sometimes file a bug against the package as a heads up and then as for the removal a bit later. Of course I don't ever see the ones where the maintainer objects and nothing further comes of it, but my impression is it's rare. I do recall, at least once, suggesting an upload to experimental to keep the package in the archive, but get it out of the way in unstable. I think that there have been less than a handful of unhappy maintainers. When someone complains, I ask them to reupload the package and give it a priority review in New (usually I also avoid snark about if you want to maintain the package, then maintain the package). For most of the packages that fall into this category, I don't think maintainer reaction is a major issue. I don't think we ought to take the human out of the loop and fully automate this as that would be more likely to have problematic results. Scott K
Re: Bits from DPL
On Monday, September 2, 2024 11:23:30 AM EDT Andreas Tille wrote: ... > While I’ve read several emails in agreement, Scott Kitterman made a > valid point[ru4]: "I don't think we need more process. We just need > someone to do the work of finding the packages and filing the bugs." I > agree that this is crucial to ensure an automated process doesn’t lead > to unwanted removals. However, I don’t see "someone" stepping up to file > RM bugs against other maintainers' packages. As long as we have strict > ownership of packages, many people are hesitant to touch a package, even > for fixing it. Asking for its removal might be even less well-received. > Therefore, if an automated procedure were to create RM bugs based on > defined criteria, it could help reduce some of the social pressure. ... Interesting perspective. This you? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079816 Scott K
Re: Bits from DPL
On Wednesday, September 4, 2024 6:22:14 PM EDT Pierre-Elliott Bécue wrote: > Scott Kitterman wrote on 04/09/2024 at 06:23:50+0200: > > On Monday, September 2, 2024 11:23:30 AM EDT Andreas Tille wrote: > > ... > > > >> While I’ve read several emails in agreement, Scott Kitterman made a > >> valid point[ru4]: "I don't think we need more process. We just need > >> someone to do the work of finding the packages and filing the bugs." I > >> agree that this is crucial to ensure an automated process doesn’t lead > >> to unwanted removals. However, I don’t see "someone" stepping up to file > >> RM bugs against other maintainers' packages. As long as we have strict > >> ownership of packages, many people are hesitant to touch a package, even > >> for fixing it. Asking for its removal might be even less well-received. > >> Therefore, if an automated procedure were to create RM bugs based on > >> defined criteria, it could help reduce some of the social pressure. > > > > ... > > > > Interesting perspective. This you? > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079816 > > OoC, what is your point, especially considering the quote of your own > opinion Andreas made? > > This just seems passive-aggressive, and the fact he stepped up once > doesn't mean he has the time or will to step up hundreds of times. I think it's odd that he would talk about how hesitant people are to touch other packages when he in fact does it himself. I'm not sure who he thinks he's speaking for, clearly not himself. I don't have statistics, but maintainer filed RM requests a pretty rare. My impression is it's only a small fraction of the total. I processed a lot of requests last night and almost none of the requests for package removal were from maintainers. It probably was a little passive aggressive, but I don't appreciate the DPL using the Bits from DPL message to punch down like that. If he has a point to make to further the discussion, it should be made as part of the discussion. If he's only trying to bring the issue to the wider project's attention, then I don't think picking one person's opinion to disagree with in Bits is very appropriate. FWIW, all an automated process would do is create work for the FTP Team. Those I would feel I have to scrutinize even more closely than ones filed by a human since no one has given it a sanity check before it gets to the FTP Team to process. Scott K
Re: Bits from DPL
On September 5, 2024 3:39:35 PM UTC, Andreas Tille wrote: >Hi, > >Am Wed, Sep 04, 2024 at 11:29:39PM -0400 schrieb Scott Kitterman: >> On Wednesday, September 4, 2024 6:22:14 PM EDT Pierre-Elliott Bécue wrote: >> > >> > OoC, what is your point, especially considering the quote of your own >> > opinion Andreas made? >> > >> > This just seems passive-aggressive, and the fact he stepped up once >> > doesn't mean he has the time or will to step up hundreds of times. >> >> I think it's odd that he would talk about how hesitant people are to touch >> other packages when he in fact does it himself. I'm not sure who he thinks >> he's speaking for, clearly not himself. > >I did it *after* someone with insight into the topic gave the according >hint[1]. >So the sequence was: > 1. I filed ITS > 2. Someone with insight suggested removal > 3. Reassigned ITS to RM >I personally see some difference between this sequence and a straight asking >for >removal. > >> I don't have statistics, but maintainer filed RM requests a pretty rare. My >> impression is it's only a small fraction of the total. I processed a lot of >> requests last night and almost none of the requests for package removal were >> from maintainers. > >You are definitely the expert about package removals. > >> It probably was a little passive aggressive, but I don't appreciate the DPL >> using the Bits from DPL message to punch down like that. If he has a point >> to >> make to further the discussion, it should be made as part of the discussion. >> > >My intention was to highlight interesting contributions to the entire >discussion. If phrases like 'Scott Kitterman made a valid point' and 'I >agree' came across as dismissive, I sincerely apologize—that was not my >intent. I genuinely valued your point, and I added my own suggestion >"based on defined criteria, it could help reduce some of the social >pressure." > >Item 2. above could possibly be such a criterion, since you pointed to >this actual example. > >> If he's only trying to bring the issue to the wider project's attention, >> then >> I don't think picking one person's opinion to disagree with in Bits is very >> appropriate. > >I'm sorry if there was any misunderstanding, but I'm unsure how my >message gave the impression that I disagreed. Could you clarify which >part led you to this conclusion? Also, just to clarify, I avoid using >sarcasm in electronic communication, especially in Bits from the DPL, as >it often doesn't translate well. Thanks for the clarification. I read it as I said something and you disagree (since you proposed something different). I think it's inherently abusive for a person in a position of power (DPL speaking as DPL, e.g. in Bits from the FPL) to leverage that position against someone who is not similarly situated, which is how it came across to me. I'm willing to assume good faith and accept that was not your intention. It's in the past. >> FWIW, all an automated process would do is create work for the FTP Team. >> Those I would feel I have to scrutinize even more closely than ones filed by >> a >> human since no one has given it a sanity check before it gets to the FTP >> Team >> to process. > >I need to trust you here as the one who is doing the work. The >discussion also was about a semi-automatic process which. Do you have >some opinion about this? > I don't have any problem with a process that suggests to people doing QA work in Debian that package removal might be appropriate based on some criteria. I don't think that such a semi-automatic process relives the person filing the RM bug from engaging their brain to decide if it makes sense. I can see how having such a tool that used criteria that has been socialized within the project to some degree might reduce social pressure to not file the bug. More people working on QA is always good. Scott K
Bug#463597: ITP: libdb4.6-ruby -- Interface to Berkeley DB 4.6 for Ruby
Package: wnpp Severity: wishlist Owner: Scott Kitterman <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libdb4.6-ruby Version : 0.6.2 Upstream Author : Guy Decoux <[EMAIL PROTECTED]> * URL : http://moulon.inra.fr/ruby/bdb.html * License : Ruby's Programming Lang: C, Ruby Description : Interface to Berkeley DB 4.6 for Ruby BDB is an interface to Berkeley DB, distributed by Sleepycat (http://www.sleepycat.com/). This package provides BDB for Ruby 1.8 linked to libdb4.6. Ruby's License: http://www.ruby-lang.org/en/LICENSE.txt - -- System Information: Debian Release: lenny/sid APT prefers gutsy-updates APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy') Architecture: i386 (i686) Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHo1vCHajaM93NaGoRAlMFAJ9xfw35iNpy7MGf3jKLgRevP2H54QCgitoQ URypVMCBCxZURerbS6Q0XpM= =OjuT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version
On Sunday 17 February 2008 15:41, Raphael Geissert wrote: > Hello all, > > [Please respect the Reply-To header] > > In order to bring some more QA on the watch files subject I'd like to start > a permanent MBF on packages whose Debian upstream version (the version > string from Version: without the epoch and the Debian revision) is higher > than the latest upstream version found thanks to their watch file. > > Rationale: the watch files are meant to keep track of upstream and if > there's a newer version not being reported by the watch file it means that > it needs to be fixed. > > Please note that this situation often occurs when the maintainer didn't > make the watch file strip some +VCSrevN that was added to the Debian > Version. > > If nobody objects I'll start filling (in an automated way since there are > no false positives) reports on the 307 source packages which report a > Debian upstream version higher than Upstream version by the watch file. I disagree. You list my package: Scott Kitterman <[EMAIL PROTECTED]> pysubnettree The reason this package is in the state it's in is that upstream uploaded a new version of the package without changing the released version number so a fake version number was needed. While suboptimal, there is no bug in the watch file. While this is no doubt a rare condition, I believe that your assertion that there are no false positives is incorrect. Scott K
Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version
On Sunday 17 February 2008 17:22, Raphael Geissert wrote: > Scott Kitterman wrote: > > On Sunday 17 February 2008 15:41, Raphael Geissert wrote: > >> Please note that this situation often occurs when the maintainer didn't > >> make the watch file strip some +VCSrevN that was added to the Debian > >> Version. > >> > >> If nobody objects I'll start filling (in an automated way since there > >> are no false positives) reports on the 307 source packages which report > >> a Debian upstream version higher than Upstream version by the watch > >> file. > > > > I disagree. You list my package: > > > > Scott Kitterman <[EMAIL PROTECTED]> > > pysubnettree > > > > The reason this package is in the state it's in is that upstream uploaded > > a new version of the package without changing the released version number > > so a > > fake version number was needed. While suboptimal, there is no bug in the > > watch file. > > If Debian's 0.11+1-1 is upstream's 0.11 why not just strip the '+1' using > dversionmangle? > That's in my POV the bug. > I think rewriting watch files for one time events is a mistake. If this were a permanent feature of the version numbering I would agree. I suppose the easiest solution for me to not be bothered about this would be to remove the watch file on the next upload. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version
On Sun, 17 Feb 2008 18:55:26 -0600 Raphael Geissert <[EMAIL PROTECTED]> wrote: >Scott Kitterman wrote: >> On Sunday 17 February 2008 17:22, Raphael Geissert wrote: >>> >>> If Debian's 0.11+1-1 is upstream's 0.11 why not just strip the '+1' using >>> dversionmangle? >>> That's in my POV the bug. >>> >> I think rewriting watch files for one time events is a mistake. If this >> were >> a permanent feature of the version numbering I would agree. > >The thing is, when you make such kind of uploads all you have to make sure >is that uscan still says your package is up to date. > >> I suppose the >> easiest solution for me to not be bothered about this would be to remove >> the watch file on the next upload. > >You won't be bothered if you also maintain the watch file. >And as I said in my response to Raphael Hertzog I could skip those where the >Debian version has something like +svn, +cvs, -pre, and also probably skip >those such as yours: +n. Fair enough. >But those I really don't want to exclude are the ones >having 'dsfg', 'ds', 'debian', or ones whose watch file really reports an >older version (e.g. in Debian: 2.3.1, upstream: 2.0.1). > There are also packages where an upstream release is missing entirely. This sounds more reasonable to me, but I think you should publish a revised list and give maintainers a chance to respond. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#466433: ITP: dkfilter -- implements domainKeys message signing and verification
On Mon, 18 Feb 2008 20:14:16 +0100 Yves-Alexis Perez <[EMAIL PROTECTED]> wrote: >On mar, 2008-02-19 at 02:20 +0800, Thomas GOIRAND wrote: >> As Yahoo! requests DomainKeys to be implemented for sending mail to >> them, it's quite urgent that this package reaches SID asap to allow >> people to be able to send email to Yahoo! > >You mean that without this sending mail from a postfix to yahoo mail >accounts will be impossible? This is not correct. Yahoo! will be moving from DK to DKIM 'real soon'. Additionally it's not clear that Yahoo! uses DK/DKIM signatures in their inbound filtering. Last I checked (it's been a few months) they still set the test flag on their outbound signstures. >> Note that this package is NOT to be confused with dk-filter (with a >> dash) that is a package for Sendmail, and that has nothing to do with >> the perl scripts for which I'm doing an ITP (even though both intend >> to implement DomainKeys, one is for Sendmail, while this one is for >> Postfix). Postfix 2.3 and later support Sendmail milters. I've been running dkim-filter (the DKIM equivalent of dk-filter) for nearly a year with Postfix 2.3/2.4 with no problems. Personally, I wouldn't waste any time on DK. It's time is nearly past. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who to contact about pointless Ubuntu differences?
On Wednesday 05 March 2008 03:44, Steve Langasek wrote: > Hi Russ, > > On Tue, Mar 04, 2008 at 11:26:02PM -0800, Russ Allbery wrote: > > Does anyone know the right contact point to ask Ubuntu to stop making > > pointless changes to a Debian package? See: > > > > http://patches.ubuntu.com/x/xfonts-jmk/xfonts-jmk_3.0-16ubuntu1.patch > > > > I mailed the person listed in the changelog entry here and pointed out > > that there's no reason to patch a spec file for an Ubuntu or Debian > > package and didn't get any reply, and then when I uploaded another new > > version of the package, this pointless change was blindly merged again. > > Ugh... > > Well, one of the changes mentioned in the changelog is to "Update > maintainer field in debian/control." Based on the outcome of the poll > conducted on (IIRC) debian-project a while back, any modified package in > Ubuntu is supposed to have a maintainer field that points at the > responsible party in Ubuntu. In this case: > > -Maintainer: Russ Allbery <[EMAIL PROTECTED]> > +Maintainer: Ubuntu MOTU Developers <[EMAIL PROTECTED]> > +XSBC-Original-Maintainer: Russ Allbery <[EMAIL PROTECTED]> > > So I would suggest contacting [EMAIL PROTECTED] Anyone on the > MOTU team can do an upload to clean up this gratuitous diff so that the > next time it comes up for merge it will be more obvious that it should be > synced across instead. > > > It doesn't really matter -- it's not hurting anything -- but it's vaguely > > annoying to have the patch keep showing up on the PTS page when there's > > no useful content (and it obscures any actually useful modifications made > > in Ubuntu). > > When there are gratuitous diffs between Ubuntu and Debian, it wastes time > of both the Debian and Ubuntu developers in tracking the differences and > makes patches.ubuntu.com less useful for everyone. Better to spend the > time now to eliminate the unnecessary diff than to have it show up > repeatedly down the line. Definitely. I'll upload a new revision removing this gratuitous difference and leave a note to make clear it's appropriate to sync the package. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can we remove sylpheed-claws?
On Saturday 19 April 2008 14:46, Michael Meskes wrote: > >From what I read sylpheed-claws has been superseeded by claws-mail. In > > fact the description of the latter says: > > Claws Mail is a powerful and full-featured mail client formerly called > Sylpheed-Claws. > > So is there a need to keep the old one around? It is orphaned, has 32 > open bugs and offers software that is no longer supported by upstream. > The last meaningful maintainer upload was in 2006. > > On top of this sylpheed-claws is the only package needing cryptplug and > gpgme, two packages with no upstream activity since 2003 both of which > have a release goal bug open. FWIW, sylpheed-claws was removed from Ubuntu before the last release for exactly these reasons. AFAIK, there were no user complaints. It really should have been removed shortly after sylpheed-claws-gtk2 was introduced. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New README.source documentation for Debian packages
On Tuesday 29 April 2008 10:31, martin f krafft wrote: > also sprach Benjamin Seidenberg <[EMAIL PROTECTED]> [2008.04.29.1535 +0200]: > > Full ACK. I'd also like to see one for dpatch. Possibly something > > that can just be symlinked too. > > Not sure about just symlinking. I'd rather say it should be: > > To use this package, you need to install dpatch. > > Once installed, please see /usr/share/doc/dpatch/... For common patch systems like dpatch or quilt, I guess I don't see what I learn from this that I can't already learn from a quick glance at the build-dep line in debian/control. For obscure/unique systems, I think it's sensible, but I didn't think this proposal was meant to address neophyte packagers, but people like the security team that are familiar with common/standard tools. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Florent Bayle MIA?
On Saturday 28 June 2008 13:27, Artur R. Czechowski wrote: > Hello, > > It looks like Florent Bayle is MIA - last upload from him is from 2007 Jan. > He sill figures as a sole maintainer for three source packages: cd5, hugin > and libpano12. > Possibly libpano12 could be removed from Debian after taking care about > hugin. > Earlier this year, I contacted him and took over maintaining klamav by an agreed maintainer change. IIRC he is very busy with other things and was happy to have someone take over his package. He did respond to email. Scott K pgpffMHrUIQSB.pgp Description: PGP signature
Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.
On Monday 30 June 2008 01:42, Christian Perrier wrote: > Quoting Charles Plessy ([EMAIL PROTECTED]): > > >> Maybe "Processing triggers" could be replaced by a 2-3 word summary of > > >> what the trigger is really doing? > > > > > > What about "Processing delayed configuration"? > > > > Well, I was originally thinking about someting specific for each > > trigger, but your proposition is probably sufficient and simpler to > > implement. > > We had the same problem when translating to French. > > A "trigger" is indeed pretty tricky to translate. The English word > gives a good feeling of "something that sets an action to be processed > later" so we settled on the french verb "déclencher" and we're using > "déclenchements" (quite word-for-word translation). > > But I indeed feel that few users have a good idea of what this might > be and the same probably stands for "triggers" in English (with the > extra fact that many users of English strings for dpkg are actually > non native speakers). > > I like "Processing delayed configuration". This is probably slightly > less precise but really clear of what this thing "Joe User will never > know about" is. > > We could use "delayed configuration" instead of "triggers" in messages > meant to be displayed to users while we could keep "triggers" in > internal messages. > > Before I mention this in the dpkg development list, are there any > other comments about that wording ? From a "Joe User" perspective, I think delay rather misses the point. The reason for triggers is not to do stuff later, it's to consolidate processing so actions don't need to be done multiple times. Delay is the mechanism chosen for doing this. I think it you substitute delayed with consolidated it, at least in English, is accurate and carries the correct connotation that a user would more likely understand. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#538214: ITP: libio-compress-perl -- IO::Compress modules
Package: wnpp Severity: wishlist Owner: Scott Kitterman * Package name: libio-compress-perl Version : 2.020 Upstream Author : Paul Marquess * URL : http://search.cpan.org/dist/IO-Compress/ * License : "Same terms as Perl" Programming Lang: Perl Description : IO::Compress modules This module contains all IO::Compress and IO::Uncompress modules: .. - Compress-Zlib - IO-Compress-Zlib - IO-Compress-Bzip2 - IO-Compress-Base .. Compress::Zlib is a Perl external module which provides an interface to the info-zip zlib compression library. zlib is a general purpose compression library. .. Some of the features provided by Compress::Zlib include: .. * in-memory compression and decompression * read and write gzip (.gz) files directly. .. IO::Compress::Bunzip2 and IO::Uncompress::Bunzip2 provide a Perl interface that allows transparent reading and writing bzip2 compressed data files or buffers. .. IO::Compress::Bases is the base class for all IO::Compress and IO::Uncompress modules. It is not intended for direct use in application code. Its sole purpose is to be sub-classed by IO::Compress modules. Note: This is due to an upstream merge of libio-compress-bzip2-perl, libcompress-zlib-perl, libio-compress-zlib-perl, and libio-compress-base-perl. I am coordinating this upload with the maintainers of these packages. The resulting package will probably be mainained in pkg-perl. -- System Information: Debian Release: 5.0 APT prefers jaunty-updates APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 'jaunty-backports'), (500, 'jaunty') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#551275: ITP: lazr.restfulclient -- client for lazr.restful-based web services
.. Original Message ... On Fri, 16 Oct 2009 17:38:58 -0400 Jonathan Yu wrote: >Hi Sandro: > >On Fri, Oct 16, 2009 at 5:35 PM, Sandro Tosi wrote: >> On Fri, Oct 16, 2009 at 23:31, Jonathan Yu wrote: >>> Strange, I've never seen a package name with a dot in it prior to the >>> version number. A casual listing from: >>> $ apt-cache search . | cut -d" " -f1 | grep "\." >>> >>> doesn't seem to turn anything up. >> >> $ apt-cache -s=? search . | cut -d" " -f1 | grep "\." | grep -c python- >> 56 >Interesting. Of note, however, is that those packages all begin with >python-. Maybe something like: python-lazr.restfulclient is more >appropriate? >> >> Regards, >> -- >> Sandro Tosi (aka morph, morpheus, matrixhasu) >> My website: http://matrixhasu.altervista.org/ >> Me at Debian: http://wiki.debian.org/SandroTosi >> > > >-- >To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org >with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
On Thu, 03 Dec 2009 15:46:48 +0100 Roland Mas wrote: > The timing of #559206 is probably just an unfortunate coincidence, but >I find it telling nevertheless. If you look, you'll find the equivalent Ubuntu upload had the same bug, so I'm not clear what it's telling you? Scott K P.S. It's been mentioned on IRC, but not in this thread, that Mathiaz is currently ill, so I would suspect reading threads like this isn't currently his highest priority. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Good communication with upstream is good idea
On Sunday 20 July 2008 12:05, Florian Weimer wrote: > * Osamu Aoki: > > I found some of my packages are offered as a part of Ubuntu archive. > > Same here. In my case (debsecan), it's a bit irresponsible because the > package doesn't really work on Ubuntu--but it's not readily apparent to > potential users. Furthermore, it uses server resources provided to > Debian, and not to Ubuntu. > > What's the correct way to get it out of Unbuntu (universe)? I don't > want to relicense it, but if asking politely does not work, it seems to > be my only choice. The preferred way of 'asking politely' is a removal bug. The process is described here: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive?highlight=%28archive%29#head-6a4a4d2ad0cc004c6199f465539e3bbc2239291e or if you don't want to unwrap the long URL: http://preview.tinyurl.com/5ce4jk Other than reading the pacakge description just now, I'm not familiar with the package. Would it make more sense for someone in Ubuntu to adapt the package to work in the Ubuntu context than to remove it? It looks like it would be useful there too. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sunday 20 July 2008 13:33, Neil Williams wrote: > On Sun, 2008-07-20 at 12:16 -0400, Scott Kitterman wrote: > > On Sunday 20 July 2008 12:05, Florian Weimer wrote: > > > * Osamu Aoki: > > > > I found some of my packages are offered as a part of Ubuntu archive. > > > > > > Same here. In my case (debsecan), it's a bit irresponsible because the > > > package doesn't really work on Ubuntu--but it's not readily apparent to > > > potential users. Furthermore, it uses server resources provided to > > > Debian, and not to Ubuntu. > > > > > > What's the correct way to get it out of Unbuntu (universe)? I don't > > > want to relicense it, but if asking politely does not work, it seems to > > > be my only choice. > > > > The preferred way of 'asking politely' is a removal bug. The process is > > described here: > > Which cannot be done without > yet-another-website-login-combo-to-use-once-and-lose-forevermore - > useless Ubuntu bug tracker. :-( > > I do feed info upstream (via yet more website logins), I really can't > add yet another one. > > That was the main point of my original blog entry linked from the > previous post. Having to ask the lazy web to sort out bugs in Ubuntu is > just daft, IMHO, but that's what LP requires. As I say, daft. Agreed. There's a lot of stuff about Launchpad that is daft. If would put together the information requested in the removal bug, I'll file it. That would avoid the need to make an account. Feel free to follow-up offlist. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, 27 Jul 2008 15:58:57 +0100 Neil Williams <[EMAIL PROTECTED]> wrote: >Why force activation in the first place? All the information needed to >"activate" a DD account already exists - our GnuPG fingerprints, our DD >email addresses and full names. If an email is received that is signed >by a known key belonging to a DD, LP should just accept the blasted >thing and stop looking for any other authentication or activation or >login or anything else of any kind, ever. If someone can send an email >to LP signed by my key then I have a lot more to worry about than >whether LP is going to refuse to authenticate that email. Any email >signed by a known key belonging to a DD should be accepted without >question or authentication or activation or anything else. Great idea. Bug filed: https://bugs.launchpad.net/bugs/252368 Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, 27 Jul 2008 14:33:17 -0700 Steve Langasek <[EMAIL PROTECTED]> wrote: >On Sun, Jul 27, 2008 at 03:58:57PM +0100, Neil Williams wrote: >> On Sun, 2008-07-27 at 15:36 +0200, Reinhard Tartler wrote: >> > Eduard Bloch <[EMAIL PROTECTED]> writes: > >> > > #include >> > > * Reinhard Tartler [Wed, Jul 23 2008, 04:36:39PM]: > >> > >> > How about activating it the first time they send a gpg-signed mail to >> > >> > the mail interface? > >> How about simply allowing any DD to send gpg-signed email to add >^^ > >That requires LP to know who is or isn't a DD. Currently it has no such >knowledge, and I think it would require a fair amount of discussion to >decide how best to get such information, with a none-too-elegant outcome >(special-casing Debian out of all the projects in the world that Launchpad >seeks to interface with), which is why I didn't suggest this. Since Debian is (mostly) upstream for Ubuntu and we already implicitly trust code uploaded by DDs and DMs, Debian is a special case. If some other distro with an external upstream were to start using Launchpad, I think it'd be reasonable for them to want something similar. >That doesn't mean that the Launchpad developers won't implement it; perhaps >the bug Scott filed will bear fruit. But I think it's worth considering >other solutions in the meantime. > Agreed. I've asked, but I'm not holding my breath. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, 27 Jul 2008 15:01:46 -0700 Steve Langasek <[EMAIL PROTECTED]> wrote: >On Sun, Jul 27, 2008 at 05:53:28PM -0400, Scott Kitterman wrote: > >> >That requires LP to know who is or isn't a DD. Currently it has no such >> >knowledge, and I think it would require a fair amount of discussion to >> >decide how best to get such information, with a none-too-elegant outcome >> >(special-casing Debian out of all the projects in the world that Launchpad >> >seeks to interface with), which is why I didn't suggest this. > >> Since Debian is (mostly) upstream for Ubuntu and we already implicitly trust code uploaded by >> DDs and DMs, Debian is a special case. > >Practically speaking, though, this doesn't require LP to know *who* has >upload rights in Debian; it only requires trusting the Debian archive key >used to sign the repo that's being pulled from. Yes, but that's an implementation detail. Debian is a special case, so special casing is reasonable. How to accomplsh that special casing is up to them. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502264: ITP: pydkim -- Python module for DKIM signing and verification
Package: wnpp Severity: wishlist Owner: Scott Kitterman <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: pydkim Version : 0.3 Upstream Author : Greg Hewgill <[EMAIL PROTECTED]> * URL : http://hewgill.com/pydkim/ * License : Other (See below) Programming Lang: Python Description : Python module for DKIM signing and verification Python module that implements DKIM (DomainKeys Identified Mail) email signing and verification. It also provides helper scripts for command line signing and verification. Note: I intend to maintain the package in the Debian Python Modules Team. License: This software is provided 'as-is', without any express or implied warranty. In no event will the author be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. Copyright (c) 2008 Greg Hewgill http://hewgill.com - -- System Information: Debian Release: lenny/sid APT prefers intrepid-updates APT policy: (500, 'intrepid-updates'), (500, 'intrepid-security'), (500, 'intrepid') Architecture: i386 (i686) Kernel: Linux 2.6.27-7-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkj1h70ACgkQHajaM93NaGr0eQCdHY17yBm7rGt4G+1VzWGiB4wA GxYAn1MmALEkv/gzGa8tUIifkpmNnWGy =hiP+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why is acroread so popular?
On Mon, 01 Dec 2008 18:16:03 +0100 Florian Weimer <[EMAIL PROTECTED]> wrote: >For the record, I don't want Debian to be associated with Adobe >Reader, even if it's only through non-free. It's very hard to provide >any security support for Adobe software whatsoever because of their >absurd distribution policy (which may not be directly their fault >because they might have patent licenses with per-copy royalties, but >still). This is why it was removed from Ubuntu several releases ago. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Friday 05 December 2008 13:06, Josselin Mouette wrote: > Paul Mangan <[EMAIL PROTECTED]> > sylpheed-gtk1 (U) ... > > Ricardo Mones <[EMAIL PROTECTED]> > sylpheed-gtk1 > => sylpheed-claws sylpheed-gtk1 should be replaced by sylpheed. sylpheed-claws (now claws-mail) is a fork. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#566724: ITP: python-ipaddr -- Python module for working with IP addresses, both IPv4 and IPv6
Package: wnpp Severity: wishlist Owner: Scott Kitterman * Package name: python-ipaddr Version : 2.0.0 Upstream Author : Google * URL : http://code.google.com/p/ipaddr-py/ * License : Apache Programming Lang: Python Description : Python module for working with IP addresses, both IPv4 and IPv6 A fast, lightweight IPv4/IPv6 manipulation library in Python. . This library is used to create/poke/manipulate IPv4 and IPv6 addresses and networks. . This is a pure Python implementation of classes for IPv4/6 addresses and networks. It supports comparisons to determine if IP addressess are contained inside a defined network, conversion of lists of IP addresses into compact CIDR lists, and other IP address manipulation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Let's write a system admin friendly mail server packaging system
"Roberto C. Sánchez" wrote: >On Wed, May 26, 2010 at 06:42:50PM +0200, Michael Banck wrote: >> On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: >> > Mario 'BitKoenig' Holbe wrote: >> > > I'm installing apache2 and have a web server - more or less working, >> > > I'm installing dhelp and ... magic, magic ... it extends the running >> > > web-server to serve the dhelp content as well. I'm installing smb2www >> > > and it extends the running web-server to act as smb client as well. >> > > How do they do this? There is some conf.d directory which contains >> > > config snippets for each of the packages. >> > >> > Yes, which feature I requested from the upstream of postfix. I got a >> > stunning reply that it was a stupid idea, that it would be slow to >> > parse, and that postconf wouldn't work anymore. So forget about having >> > this in postfix, we must find another way. >> >> Eh, Debian can patch upstream software if it thinks it is necessary for >> inter-operation, that's the one of the major points of having a >> distribution. >> >That is true. However, it must be balanced with making the software >different than it is on every other platform. I'm not saying that it >cannot be done. Rather, there needs be a discussion as to whether that >is something that Debian wants to do. It is not as simple as just >patching a high profile package like postfix. > FWIW, dovecot supports config.d too. For postfix, as I understand the design, it would be as non-trivial effort to move to a similar cascading config directory approach. Fortunately it's not needed. In postfix you need to be able to programmatically modify both main.cf and master.cf. I believe that the upstream supported postconf tool supports making all needed changes to main.cf. The Debian package also ships some Debian (and derivative) specific scripts to allow smtp filters and policy services to be added to master.cf by other packages in a policy compliant way. They are simplistic, but should serve this use case (it's the one I wrote them for). Additionally, Ubuntu ships a distro specific binary called dovecot-postfix that implements part of this vision already. We'd love to see it in Debian if the dovecot maintainer is interested. Scott K -- 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/aa1a35fd-a1de-4e9f-b4ac-a8795379b...@email.android.com
Re: Let's write a system admin friendly mail server packaging system
"Jaldhar H. Vyas" wrote: >Scott Kitterman kitterman.com> writes: > >> >> Additionally, Ubuntu ships a distro specific binary called dovecot-postfix >> that implements part of this >> vision already. We'd love to see it in Debian if the dovecot maintainer is >> interested. >> > >The dovecot maintainer might be interested if someone told him about it. Like >with a wishlist bug to the BTS maybe? > Excellent. It's only been recently it's gotten to the point that I think it might be worth looking at for Debian. Scott K -- 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/91519a0b-55e1-4c06-b3b0-4f48c6efa...@email.android.com
Possible Mass Bug Filing: String Exceptions Removed in Python 2.6
As was recently discussed on debian-python: http://lists.debian.org/debian-python/2010/05/msg00111.html String exceptions are no longer supported at all in Python 2.6. Since this is the Python version planned to be the default in Squeeze, packages still using them should be fixed. String exceptions have never worked reliably or been a good idea. It is time for them to go. A couple of weeks ago, Jakub Wilk noticed this issue and prepared both a DD list of affected packages and the grep output that was used to detect potentially affected packages. I know some of these packages have been fixed already. Please reply to debian-python with fix reports or reports of false positives. http://people.debian.org/~jwilk/tmp/string-exceptions.ddlist http://people.debian.org/~jwilk/tmp/string-exceptions.log Without examining each package in detail, it's difficult to know the impact of this error on each package. I expect to file the bugs at normal severity and leave it to maintainers to adjust it up or down. Scott K -- 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/201006052243.28438.deb...@kitterman.com
Re: "Waqf" General Public License in Debian?
"Christoph Anton Mitterer" wrote: >Hey > >Well I guess that it's much easier to judge what's evil and what's not. > >Typically all peoples that took part in the Enlightenment a scientific >development came to similar rules, which you can find things like: >- Universal Declaration of Human Rights >- European Convention on Human Rights >- as well as the human rights found in the constitutions of many western >countries (as well as some others). > >It may sound arrogant, but what ever contradicts such rules or tries to >abolish them is evil. > > >But I guess this discussion leads to nothing so back to this special >case... > > > > >I'm not against religious software in Debian per se, but as with many >other things that we do not accept (see Debian Multimedia) or patented >stuff, it's always a big danger. > >Why don't we then include legally questionable packages like aacskeys or >dumphd in Debian? Their license should be fine, and there are surely >some countries around the world in which they're legal. > >It's always the question where to make the cut. Someone mentioned >pornography as an example. I guess we allow this because it's legal in >most countries. What would we do with a package "child-pornography" in >Debian if the license is GPL? > >Many people feel discriminated even by seeing or living with religious >people (e.g. in Germany and Europe there is the long standing issue of >having the christian cross in schools). Would we e.g. accept it if all >the Desktop wallpaper packages contain the star of david? >Guess that the countries of some that argued here that Debian is for >all, would be the first that completely forbid Debian... > >I think that computing itself an in the end also Debian originates from >and grounds on top of the ideas of what I noted above: Enlightenment, >natural sciences, et cetera. >And all this is not (or should not be) under law of any god, or the >pope, or Sharia or whatever. > >If something obviously fights those idea, it looses (IMHO) the right to >take. >Which leads me to close the circle and come to and end: >If license is clearly against all in what we all (hopefully) believe, >even if it's just the preamble or an upstream who seems to have the >impression that we should bow to some other "rules"... then personally >I'd prefer to close the doors. > >Ah and again, this is definitely not anti-Islamism... if I'd see similar >things from other religions or creationism or e.g. Nazis,... I'd say the >same. > No. It is ignorant anti-religious bigotry. Please take your prejudices elsewhere, they are quite unrelated to Debian development. Scott K Scott K -- 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/50f67b54-8072-44e6-bcf8-b01f0016c...@email.android.com
Re: "Waqf" General Public License in Debian?
"Norbert Preining" wrote: >On Sa, 03 Jul 2010, Scott Kitterman wrote: >> No. It is ignorant anti-religious bigotry. Please take your prejudices >> elsewhere, they are quite unrelated to Debian development. > >Sorry .. please? Either stop insulting fellow people here, or bring >arguments, but the rubbish you wrote is as much as unfounded as >astrology, the creation of the world 4000 years ago, the believe that >only 144000 can enter into heaven, that there actually was a >parthenogenesis about 2000 years ago, that some strange book was >dictated by some god word-for-word, ... (did I forgot one religion or >sect of the bigger ones?) > >Please if you are a pro-religious fanatic, so it be, but don't start >mixing discussions about universal human rights, or politics, or >juridical matters, with religion, or I will call for an ostracism >on your matter! > Go for it. I'm against censorship based on ones personal beliefs. Don't confuse what I consider it acceptable to believe with my actual opinions. The message I replied to was clearly an il-informed anti-religious screed. I gather you are in favor of this view. You're entitled to your opinions, but not to insist everyone in the project must share them. For myself, I'd like to encourage you to take a step back and work on being more comfortable with people whose opinions are not exactly like yours. If you don't like religious software, ignore it. Scott K -- 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/55bf3eb1-5a6f-4a65-a2f4-1aa9401d3...@email.android.com
Bug#588926: ITP: kbackup -- KDE based system backup tool
Package: wnpp Severity: wishlist Owner: Scott Kitterman * Package name: kbackup Version : 0.7 Upstream Author : Martin Koller * URL : http://kde-apps.org/content/download.php?content=44998&id=1&tan=95788587 * License : GPL-2 Programming Lang: C++ Description : KDE based system backup tool Kbackup is a program that lets you back up any directories or files. It uses an easy to use directory tree to select the things to back up and lets you save your settings in "profile" files. These are simple textfiles containing definitions for directories and files to be included or excluded from the backup process. -- 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/20100713134751.19091.75166.report...@scott-laptop
Bug#600311: ITP: python3-ipaddr -- Python3 module for working with IP addresses, both IPv4 and IPv6
Package: wnpp Severity: wishlist Owner: Scott Kitterman * Package name: python3-ipaddr Version : 2.1.5 Upstream Author : Google * URL : http://code.google.com/p/ipaddr-py/ * License : Apache 2.0 Programming Lang: Python 3 Description : Python3 module for working with IP addresses, both IPv4 and IPv6 This library is used to create/poke/manipulate IPv4 and IPv6 addresses and networks in Python3. It is intended to be fast and lightweight. . This is a pure Python3 implementation of classes for IPv4/6 addresses and networks. It supports comparisons to determine if IP addresses are contained inside a defined network, conversion of lists of IP addresses into compact CIDR lists, and other IP address manipulation. Note (not for the description) this is the Python 3 companion to python-ipaddr. -- 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/20101015220206.21405.51137.report...@localhost6.localdomain6
Re: How to close a Ubuntu bug?
"Erik Schanze (Debian)" wrote: >Hi, > >one of my packages (antiword) has an open bug in Ubuntu >https://bugs.launchpad.net/ubuntu/+source/antiword/+bug/237918 >that was fixed for a while in Debian >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464490. > >I'd like to help them and would close it, but did not found how. >(I'm not member of launchpad an I don't want to become one.) > >Is there any mail interface like Debian has? There is, but it still requires an account. I marked it fixed. Scott K -- 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/4a5295cf-a15a-4c56-a91c-6a3904c55...@email.android.com
Re: How to close a Ubuntu bug?
"Kai Wasserbäch" wrote: >Dear Scott, >Scott Kitterman schrieb am 14.02.2011 22:46: >> "Erik Schanze (Debian)" wrote: >>> Is there any mail interface like Debian has? >> >> There is, but it still requires an account. I marked it fixed. > >can Ubuntu that at least open said interface up to Debian Developers >using their >Debian address and sign the message with their key (as available from >keyring.debian.org)? Because this account requirement is really >annoying. I >don't want an account on Launchpad but as long as I'm forced to see bug >reports >on my PTS page (ok I could hide them with Element Hiding Helper or >something) I >want an easy interface like <mailto:cont...@bugs.debian.org>, so I can >at least >close or reassign bugs in case that is needed (an example where I'd >like to have >reassign capabilities: I've one bug showing for Skanlite, that is >certainly not >a bug in Skanlite but one in libksane (if it still exists at all, that >ist), >upstream agrees with me on this). > >Kind regards, >Kai Wasserbäch > >P.S.: I understand that you are not Ubuntu and this is not your >decision, but >maybe you could pass this on to the proper people. ;) It's been brought up with Launchpad developers before. Doing so is technically feasible, but not implemented. Scott K -- 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/bcedfb09-323a-4e40-b720-c198bf943...@email.android.com
Bug#613999: ITP: py3dns -- DNS client module for Python3
Package: wnpp Severity: wishlist Owner: Scott Kitterman * Package name: py3dns Version : 3.0.0 Upstream Author : Stuart D. Gathman * URL : http://http://sourceforge.net/projects/pydns * License : PSF Programming Lang: Python 3 Description : DNS client module for Python 3 This Python 3 module provides an DNS API for looking up DNS entries from within Python 3 modules and applications. This module is a simple, lightweight implementation. It is not as complete as python-dnspython, but is useful for many common applications. ITP Note: Binary will be python3-dns. This is the Python 3 port of python-dns. -- 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/20110218200544.29945.63740.reportbug@localhost6.localdomain6
Re: potential MBF: first alternate depends not available in main
On Monday, February 28, 2011 10:05:22 am Holger Levsen wrote: > Hi, > > piuparts in master-slave mode currently cannot test packages which first > alternate depends is not available in main, ie the secvpn package depends > on "adduser, bc, ssh, ppp, timeout | coreutils (>= 7.5-1), sudo" and > timeout is only available in lenny and etch, thus piuparts cannot test > secvpn in squeeze, wheezy and sid. That's a bug in piuparts. > > Another popular example is a depends on "apache | apache2"... > > So I think it's also a bug in those packages, of which there are more then > 100 but less than 200. > (To my regret I have to admit there is another bug in piuparts and > http://piuparts.debian.org/sid/state-dependency-does-not-exist.html lists a > few packages incorrectly.) > > But, anyway, I believe that the first depends of an alternate depends > relation should be available in main and propose to file bugs about this. > > Do you agree this warrants a mass bug filing? I couldn't find this written > out in policy so these bugs would be wishlist, which probably would make > them not warrant a mass bug filing... > > Comments? It seems to me not worth a mass bug filing. This doesn't seem like something that would affect user's systems. Is there a rationale for imposing this ordering other than puiparts can't deal with it? Scott K -- 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/201103012324.24545.deb...@kitterman.com
Re: potential MBF: first alternate depends not available in main
On Wednesday, March 02, 2011 04:53:46 am Emilio Pozuelo Monfort wrote: > On 02/03/11 04:24, Scott Kitterman wrote: > > It seems to me not worth a mass bug filing. This doesn't seem like > > something that would affect user's systems. Is there a rationale for > > imposing this ordering other than puiparts can't deal with it? > > If you have non-free enabled and install a package from main, it should > install the dependencies from main. So you should have e.g. "rar | > rar-nonfree" instead of the other way round. Why? If the user has made the choice to use non-free and the maintainer concludes that's a more technically capable solution for users that choose to use it, why should the project raise barriers to that choice? Scott K -- 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/201103020941.02177.deb...@kitterman.com
Re: potential MBF: first alternate depends not available in main
Marvin Renich wrote: * Carsten Hey [110304 06:17]: > * Paul Wise [2011-03-04 12:54 +0800]: > > Debian Policy section 2.2.1 already covers this: > > > > ...the package must not declare a "Depends", "Recommends", or > > "Build-Depends" relationship on a non-main package. > > > > http://www.debian.org/doc/debian-policy/ch-archive.html#s-main > > This can be read in different ways: > > * All of the alternatives must be in main. > * The first alternative must be in main. > * One of the alternatives must be in main. >From an English language POV, the quote above (taken out of context) clearly forbids any alternative in a Depends or Recommends from being outside of main. Here is the quote with enough context to show that the intent was otherwise and that other interpretations are reasonable: ...the packages in main • must not require a package outside of main for compilation or execution (thus, the package must not declare a "Depends", "Recommends", or "Build-Depends" relationship on a non-main package) I am not a DD or an expert on policy, but I would interpret the parenthetical to be explanatory rather than normative. Here is a suggested wording to clarify the parenthetical: ...the packages in main • must not require a package outside of main for compilation or execution (thus, all declared "Depends", "Recommends", and "Build-Depends" relationships must be satisfiable with only packages in main) I will file a wishlist bug against policy if there are no objections. ...Marvin -- 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/20110304154535.ga3...@cleo.wdw Seems reasonable to me. Scott K
Re: Disable ZeroConf: how to ?
On Friday, March 04, 2011 02:48:07 pm Adam Borowski wrote: > On Fri, Mar 04, 2011 at 04:09:44PM +0100, Olaf van der Spek wrote: > > On Fri, Mar 4, 2011 at 3:59 PM, Klaus Ethgen wrote: > > > In ancient times debian was packaged the way that the administrator > > > only installed the daemons that he needed. Today many daemons gets > > > installed by dependencies and gets started without any need. > > > > > > If you want to change debian to be ubuntu it would be the time to look > > > for another distribution that can be used on servers. (unfortunately I > > > do not know an alternative.) > > > > Actually "Ubuntu ships with no open ports on public interfaces" (by > > default). > > [~]# netstat -ap|grep avahi > udp0 0 *:mdns*:*1622/avahi-daemon: > udp0 0 *:45282 *:*1622/avahi-daemon: > udp6 0 0 [::]:mdns [::]:* 1622/avahi-daemon: > udp6 0 0 [::]:58036[::]:* 1622/avahi-daemon: > > I admit I didn't notice this before, as I would never expect a _client_ > system to have some crap listening by default. And it is world-reachable > -- am I supposed to ensure the top s1kr3t address > 2001:6a0:118:0:22cf:30ff:fec3:d4b7 never leaks out? (oops...) > > > And why does it open this security hole? To make it slightly easier to > configure link-local instant messages. Who exactly is going to need that > these days? The times of local networks disconnected from the world are > mostly over. You have some non-networked machines here and there, but if > there's a network of some kind, it almost always is globally connected. > These few places that do have airwalled networks definitely don't want to > run link-local chat... > > So, any gain is infinitessimally small, and the risk is real. Even daemons > coded by most security-minded people that have seen a lot of review do have > exploitable holes once in a while, so I expect Avahi to fare no better. > > Like, for example, #614785. This is actually a documented [1] exception to the general policy of no open ports (not one I agree with BTW). The rationale is provided at [2]. [1] https://wiki.ubuntu.com/Security/Features#ports [2] https://wiki.ubuntu.com/ZeroConfPolicySpec What I did was change /etc/avahi/avahi-daemon.conf so it says: use-ipv4=no use-ipv6=no I'm pretty sure that makes it safe (and was easier than dealing with the dependency issues associated with trying to remove it). netstat -ap|grep avahi returns nothing on such a system. Scott K -- 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/201103041535.28090.deb...@kitterman.com
Re: ${python:Breaks}
On Thursday, March 10, 2011 06:15:01 am Raphael Hertzog wrote: > On Thu, 10 Mar 2011, Piotr Ożarowski wrote: > > seriously, THERE WILL BE NO NEW PYTHON 2.X VERSION RELEASED UPSTREAM¹, > > we don't have to worry about 2.X transitions when 2.7 will become the > > only supported one. If you don't like Breaks, I will remove it, it > > really doesn't matter - that's why at the beginning I wasn't generating > > either of these dependencies (in Depends and in Breaks). > > Well, if upstream changes their plans it will to late to fix the > dependencies... The upstream Python position is (I'll paraphrase), "There will not be a Python 2.8. If there is a new feature release of Python 2 it will be because someone forked it - it's Free software, so we can't prevent that". There are a lot of things we need to worry about in the Debian Python world, but I don't think python2.8 is one of them. Scott K signature.asc Description: This is a digitally signed message part.
Bug#618302: ITP: authres -- Python module for RFC 5451 Authentication Results Header manipulation
Package: wnpp Severity: wishlist Owner: Scott Kitterman * Package name: authres Version : 0.1 Upstream Author : Scott Kitterman * URL : https://launchpad.net/authentication-results-python * License : Apache 2.0 Programming Lang: Python Description : Python module for RFC 5451 Authentication Results Header manipulation Python module to create and decode RFC 5451 Authentication Results headers. . The module currently provides a class for creating RFC compliant headers for use in Python applications. Future releases will also provide a class for decoding Authentication Results headers. . http://tools.ietf.org/rfc/rfc5451.txt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110314060747.32032.2119.reportbug@localhost6.localdomain6
Re: potential MBF: first alternate depends not available in main
"Bernhard R. Link" wrote: * Goswin von Brederlow [110317 22:10]: > My metric here is clearly the functionality for the user. Being able to modify it or get help with the package (which needs people being able and willing to look at the source and fix problems) is a very important part of functionality of the user. > If not having free (as in speech) source is a problem then do not add > non-free to your sources.list. That metric should not decide the order > of depends. Just because there is one package confining what you do needs to be installed for whatever reason you no longer have a right to get helpful packages? Bernhard R. Link -- 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/20110318104747.ga28...@pcpool00.mathematik.uni-freiburg.de Not at all, but we should trust maintainers to use their judgement on this and not enforce a one size fits all policy across the project. Scott K
Re: potential MBF: first alternate depends not available in main
On Friday, March 18, 2011 10:10:49 am Bernhard R. Link wrote: > * Goswin von Brederlow [110318 14:38]: > > And as long as it works I see no reason why a maintainer should not be > > allowed to put the non-free dep first in alternatives if there is a good > > reason. > > Debian makes some promises to users. Suprisingly getting non-free > software installed is definitely nothing a maintainer alone should > be able to decide. Since they would have had to enable non-free, suprise would not be an appropriate reaction. Scott K -- 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/201103181029.24107.deb...@kitterman.com
Re: Sponsorship requirements and copyright files
On Wed, 25 Mar 2009 13:22:04 +1100 Ben Finney wrote: ... >Those who don't like the very *idea* of a machine-parseable format for > .debian/copyright apparently exist, but I don't understand their >position yet :-) I'd be one of those. Whenever you add new structural rules on a file it creates more things one needs to know, more things to get wrong, and more work. This is inevitable. To counter this, I see some very minor potential benefit. IANADD, so I don't get a vote, but if I did, I'd be against it. The cost/benefit ratio of the proposal is certainly open to reasonably varying opinions, so I don't expect arguing over different perceptions to have a lot of benefit. I do think it's worth (once) pointing out why I don't like the concept. I'll convert my packages when it's required by policy. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Wed, 25 Mar 2009 15:44:20 +1100 Ben Finney wrote: >Scott Kitterman writes: > >> On Wed, 25 Mar 2009 13:22:04 +1100 Ben Finney >> wrote: >> ... >> >Those who don't like the very *idea* of a machine-parseable format >> >for .debian/copyright ? apparently exist, but I don't understand >> >their position yet :-) >> >> I'd be one of those. > >Thank you for your explanation; after reading it, I would not actually >classify your position as stated above :-) > >> Whenever you add new structural rules on a file it creates more >> things one needs to know, more things to get wrong, and more work. >> This is inevitable. > >Yes. > >> To counter this, I see some very minor potential benefit. IANADD, so >> I don't get a vote, but if I did, I'd be against it. > >Okay, so it's not that you're against having a machine-parseable >format for the file, but that you don't yet see that the benefit >outweighs the cost. Yes. I'm against adding requirements for work with a negative value. >> The cost/benefit ratio of the proposal is certainly open to >> reasonably varying opinions, so I don't expect arguing over >> different perceptions to have a lot of benefit. I do think it's >> worth (once) pointing out why I don't like the concept. > >As I understand your position, it's not the concept that you don't >like, but your perception of the cost:benefit ratio. Is that a fair >restatement? Yes, but given that I see the potential benefit (so far) as close to nil, I'm not particularly expecting this to change. There may be some great use case that really suprises me, but I'm not seeing it so far. >> I'll convert my packages when it's required by policy. > >Okay. Certainly I would hope there will be demonstrable (as opposed to >the merely potential) benefits to such a format, before anyone >considers making it mandatory. There are also inherent negatives to adding more strctural requirments. One that particularly concerns me about this one is that it adds to the mountain of stuff new developers have to learn. It's hard enough to teach people to accurately get all the currently required elements into debian/copyright that I don't relish adding to it "No, that can't be a dash, it has to be a colon" types of issues. In Debian (and Ubuntu) it's not rare for me to see enthusiastic new contributors get discouraged and give up over the existing mountain of requirements. I don't like adding more without a really good reason (yes, I know this isn't required anytime soon, but to be truly effective it will have to be eventually). I hope that clarifies my perspective. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sources licensed under PHP License and not being PHP are not distributable
On Monday, June 30, 2014 14:11:33 Clint Byrum wrote: > Excerpts from md's message of 2014-06-30 13:43:59 -0700: > > On Jun 30, Faidon Liambotis wrote: > > > Can we get an official word from the ftp-masters and have this > > > discussion in public, please? > > > > +1 > > > > I am ready to explore every available option to make sure that the next > > release will not be useless for my customers (hence forcing me to > > install/migrate hundreds of servers to Ubuntu). (And I even hate PHP.) > > Ubuntu would follow suit I think. It would be too much of a burden to > carry all of that without Debian maintainer assistance. As far as I know, the only case where Ubuntu deviates from Debian regarding license policy is that it allows GFDL invariant. I doubt it would be different here. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/200598062.G8jQiMSUga@scott-latitude-e6320
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
On Friday, July 04, 2014 17:28:05 Matthias Urlichs wrote:
> Hi,
>
> Adam Borowski:
> > There was enough trouble when udev needed an in-lockstep upgrade with the
> > kernel a few releases back. If systemd components are going to need such
> > forced reboots on a repeated basis, I don't like where this is going.
>
> systemd and its components can re-exec themselves, that's not the problem.
>
> The problem is that along with systemd we're changing a lot of the
> supporting infrastructure ("we" here is Upstream, for the most part).
Upstream of what?
> Keeping old low-level interfaces around just to avoid logging out or
> rebooting may or may not be something we can do easily. While I'll
> certainly be happy to be able to dist-upgrade without a subsequent reboot,
> if it turns out that this is not going to be easy to achieve then so be it.
>
> For Zurg (Jessie+1), we're likely to switch to Wayland. How do you plan to
> do *that* without forcing at least a re-login?
Just because it can't be avoided completely, doesn't mean it shouldn't be
minimized.
Scott K
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/9964234.g258putz8I@scott-latitude-e6320
Re: let missing-debian-source-format lintian tag be a warning!
On Tuesday, July 15, 2014 15:26:28 Jonathan Dowland wrote: > On Tue, Jul 15, 2014 at 10:43:05AM +0200, Raphael Hertzog wrote: > > Can we have a reasonable discussion based on real arguments and not on > > personal feelings? > > I haven't read any personal feelings yet, apart from personal preferences > about how to handle patches. > > It *is* a shame that the patch-handling aspect of 3.0 (Quilt) is offputting > enough to folks that some are avoiding 3.0 altogether and not benefitting > from the other improvements. However the single-debian-patch workaround is > a pretty good compromise, IMHO, and perhaps just needs wider awareness. It seems to me 3.0 (Quilt) is still applying patches when the package is extracted using dpkg-source. Is there a way to avoid that too? That's been my major objection. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3190289.SmRNKVh7D1@scott-latitude-e6320
Re: let missing-debian-source-format lintian tag be a warning!
On Tuesday, July 15, 2014 18:12:41 Andreas Metzler wrote: > Scott Kitterman wrote: > [...] > > > It seems to me 3.0 (Quilt) is still applying patches when the > > package is extracted using dpkg-source. Is there a way to avoid > > that too? That's been my major objection. > > dpkg-source -x --skip-patches foo.dsc > (Does not work in debian/source/options, though) Not adding debian/source/format gets me the same thing with less typing (although I appreciate knowing about the option, I'd missed that before). If that worked in debian/source/options, then I don't think I'd have a strong reason to avoid 3.0 (Quilt). Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/16345713.7qspDBtfcA@scott-latitude-e6320
Re: let missing-debian-source-format lintian tag be a warning!
On Tuesday, July 15, 2014 21:04:32 Raphael Hertzog wrote: > Hi Scott, > > On Tue, 15 Jul 2014, Scott Kitterman wrote: > > It seems to me 3.0 (Quilt) is still applying patches when the package is > > extracted using dpkg-source. Is there a way to avoid that too? That's > > been my major objection. > > Can you elaborate on your objection? > > Having patches applied by default is one of the main reasons why > people asked for a new source package format. It's very disconcerting for > most people to call dpkg-source -x and then not have the sources as they are > built by Debian. > > Thus I believe that the current approach is the right one: apply by > default and let people with special needs use some options. > > Can you agree with that? If not, can you explain why you don't agree? It's perhaps just my mental model of the way packaging works. You have the upstream part and the Debian part. When you unpack a package, the Debian part is in the Debian directory. The upstream part is not. If patches are applied on extraction, this separation is violated and seems to me fundamentally wrong. If the majority of the project doesn't see it that way and chooses not to care/want patches applied, then I don't seek to overturn that. It would be nice, however, to have a way to specify the alternate behavior in a consistent reliable way (meaning something I can put in the package when I add source/format). Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1484304.9BRKLAu1OC@scott-latitude-e6320
Re: Bug#756082: ITP: librevenge -- base library for writing document import filters
On Saturday, July 26, 2014 01:49:06 Mattia Rizzolo wrote: > Package: wnpp > Severity: wishlist > Owner: Mattia Rizzolo > > * Package name: librevenge > Version : 0.0.1 > Upstream Author : David Tardon (and others) > * URL : > http://sourceforge.net/p/libwpd/librevenge/ci/master/tree/ * License > : MPL2+/LGPGL2.1 > Programming Lang: C++ > Description : base library for writing document import filters > > librevenge is a base library for writing document import filters. It has > interfaces for text documents, vector graphics, spreadsheets and > presentations. > > > librevenge will be a build-dep of the new release of scribus-ng. > I plan to start working on it in early 2014 September. Already packaged: librevenge | 0.0.1-1 | experimental | source Scott K signature.asc Description: This is a digitally signed message part.
Re: possible MBF: automatically detecting unused build dependencies
On Monday, July 28, 2014 12:07:58 Johannes Schauer wrote: > Hi, > > Quoting gregor herrmann (2014-07-28 11:45:14) > > > > ==> libxml-parser-perl_2.41-1.arch-all.unusedbd <== > > > sharutils=1:4.14-2 > > > > Already fixed in 2.41-2. > > thanks! > > > I assume you're planning to do a new run before actually filing the > > bugs? > > I cannot do a new run before September because I'm moving places twice > within the next month and thus do not have a stable always-on machine > available during that time. The only thing that could change this would be > if I found easily accessible compute time elsewhere (I asked at > debian-qa@l.d.o: > http://lists.debian.org/20140726090503.4150.56356@hoothoot ) > > I thought that hardly any build dependencies get removed over time so that > it would still be appropriate to fill bugreports for the June results now. > > If that would not be appreciated then I'll re-run the whole thing once I > settled in at our new place some time in September. It is quite common for people to fix things based on the initial discussion about an impending MBF, so I think it would be less than impolite to not acknowledge that by filing bugs on obsolete data. The two packages that I show up for are fixed as well. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1436982.fj5k9h6aVK@scott-latitude-e6320
Re: possible MBF: automatically detecting unused build dependencies
On Monday, July 28, 2014 08:54:29 Scott Kitterman wrote: > On Monday, July 28, 2014 12:07:58 Johannes Schauer wrote: > > Hi, > > > > Quoting gregor herrmann (2014-07-28 11:45:14) > > > > > > ==> libxml-parser-perl_2.41-1.arch-all.unusedbd <== > > > > sharutils=1:4.14-2 > > > > > > Already fixed in 2.41-2. > > > > thanks! > > > > > I assume you're planning to do a new run before actually filing the > > > bugs? > > > > I cannot do a new run before September because I'm moving places twice > > within the next month and thus do not have a stable always-on machine > > available during that time. The only thing that could change this would be > > if I found easily accessible compute time elsewhere (I asked at > > debian-qa@l.d.o: > > http://lists.debian.org/20140726090503.4150.56356@hoothoot ) > > > > I thought that hardly any build dependencies get removed over time so that > > it would still be appropriate to fill bugreports for the June results now. > > > > If that would not be appreciated then I'll re-run the whole thing once I > > settled in at our new place some time in September. > > It is quite common for people to fix things based on the initial discussion > about an impending MBF, so I think it would be less than impolite to not > acknowledge that by filing bugs on obsolete data. > > The two packages that I show up for are fixed as well. > > Scott K ... less than polite ... That'll teach me to write to -devel while still on the first cup of coffee. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6310597.iGnANyuyd6@scott-latitude-e6320
Re: Standardizing the layout of git packaging repositories
On August 15, 2014 10:16:01 AM EDT, Raphael Hertzog wrote: >Hello, > >while git is the most popular VCS for packaging, there's no clear rules >on what you can expect in a random git packaging repository listed >in Vcs-Git. I would like to fix this so that: >- we can extract more useful data from the git repositories >- we can more easily share our git repositories with upstreams > and downstreams >- we start to converge on some conventions even though we might > continue to use different git helper tools > >I want to use the DEP process for this. But before I can write a first >draft I would like to have your ideas of what we should include >in such a document. > >Some initial questions and possible answers: > >- how do we name the various branches? > >- /master for the main development trunk (aka unstable in >Debian) > - / for alternate versions > >The goal here is to be able to host in the same repository the branches >for > multiple cooperating distributions (at least so that downstream can > clone the debian respository and inject their branches next to the > debian branches). > >- how do we tag the upstream releases? > > - upstream/ > (note: we don't need an "upstream" branch, having the good tag for any > release that the distros are packaging is enough, it can point to a > synthetic commit built with tools like git-import-orig or to a real > upstream commit) > >- how do we tag the package releases? > > - pkg/ >(note: git-buildpackage uses debian/ but I find this confusing >as we then also have the "debian/" prefix for ubuntu or kali uploads, >we > don't need the vendor prefix as the usual versioning rules embed the >downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't >be > any conflict on the namespace, keeping a prefix is important to easily > differentiate tags created by upstream developers from tags created > by packagers) > >- where should the HEAD point to in the public repository? > >- shall we standardize the "pristine-tar" branch? > >- the above layout is for the traditional case of non-native packages, > what would be the layout for native packages? how can be differentiate > between native/non-native layout? > >- encoding (due to git restrictions): >":" -> "%" >"~" -> "_" > >- are there other important things to standardize? We don't even agree on if repositories should be full source or Debian directory only. Not sure how we can even start to discuss the rest if we don't agree on that. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/dd4ca987-e3ca-4304-b8c4-e9afa0e5a...@email.android.com
Re: Python 3.4
On August 15, 2014 1:42:04 PM EDT, Paul Tagliamonte wrote: >On Fri, Aug 15, 2014 at 07:28:06PM +0200, Diogene Laerce wrote: >> Hi, >> >> Does someone have any clue or hint on the upgrade of Debian to >Python3 >> natively ? >> >> Thank you, > >Hey Diogene, > >Python 3.4 is in Jessie, ready for action. I can confirm it works >great, >It's all I use for my personal projects (in fact, I actually complain a >lot when I have to use Python 2 for some reason). > >the /usr/bin/python command is unlikely to change soon; more >information >on how this should be treated on UNIX like systems can be found at PEP >0394. s/soon/ever/ It's more likely /usr/bin/python will someday be removed than someday point to a python3 version. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cb3f3e44-09ec-4e0c-abbf-3c11025b3...@email.android.com
Re: Python 3.4
On August 15, 2014 4:57:19 PM EDT, Diogene Laerce wrote: > > >On 08/15/2014 10:20 PM, Scott Kitterman wrote: >> On August 15, 2014 1:42:04 PM EDT, Paul Tagliamonte > wrote: >>> On Fri, Aug 15, 2014 at 07:28:06PM +0200, Diogene Laerce wrote: > >[...] > >>> >>> the /usr/bin/python command is unlikely to change soon; more >>> information >>> on how this should be treated on UNIX like systems can be found at >PEP >>> 0394. >> >> It's more likely /usr/bin/python will someday be removed than someday >point to a python3 version. > >No python on the OS ? Regard to the number of applications that rely on >python, that's kind of unlikely no ? > >Cheers, Pointing /usr/bin/python at a python3 version is not providing python in that sense. If something uses python3, it should use /usr/bin/python3. Someday, in the distant future, /usr/bin/python should become irrelevant. It should never point at a python3 version. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/831ef6a7-6f9d-4f45-954e-ea30a10ff...@email.android.com
Re: Standardizing the layout of git packaging repositories
On Friday, August 15, 2014 23:04:54 brian m. carlson wrote: > On Fri, Aug 15, 2014 at 08:17:16PM +0200, Marco d'Itri wrote: > > On Aug 15, Raphael Hertzog wrote: > > > - are there other important things to standardize? > > > > Do not try to make other people change their workflows without evident > > benefits (pro tip: "standardization" in itself is not one) or they will > > be annoyed and just ignore your work. > > I send a lot of one-off patches to packages. I like to file a bug and > follow it up with a patch. Unfortunately, everybody doing things a > different way makes it unpleasant to do that. (And yes, I know about > README.source.) > > Right now, I just build the source package repeatedly until it works, > unless the package doesn't build twice in a row, in which case I swear > repeatedly and no patch is sent. If there's a standard workflow, it > makes my life easier and results in a patch that works better for the > maintainer. This gets to why, for teams I work in where full source git branches are used, I really like git-dpm. The output of the git-dpm workflow is a version 3.0 (quilt) package with all the upstream changes in segregated patches per commit so they make logical sense. That way, any third party that needs to address an issue in the package can do so with no reference at all to a VCS repo. They just work on the Debian source package that is available in the most common type that is used in the archive. The packager's VCS is mostly useful for the people who normally work on the package. For others, the source package is the most useful thing. About the only thing I use the VCS of packages that aren't normally ones I work on for is to understand the history of something to try and figure out where it went wrong. Whatever is "standardized" it really, really ought to produce a useful source package as that's the preferred form of modification in the project. Scott K signature.asc Description: This is a digitally signed message part.
Re: Standardizing the layout of git packaging repositories
On August 16, 2014 8:03:18 AM EDT, Raphael Hertzog wrote: >(Please trim the quoted mail when you answer) > >On Fri, 15 Aug 2014, Scott Kitterman wrote: >> >- are there other important things to standardize? >> >> We don't even agree on if repositories should be full source or >Debian >> directory only. Not sure how we can even start to discuss the rest if >we >> don't agree on that. > >I don't know of any git helper tools that work on git repositories with >Debian directory only. > >The vast majority (all?) of git packaging repositories have the >upstream >sources. > >I think this point is not really contentious. > >And given the willingness to make it easier to collaborate with >upstream >using git, it would be silly to not have the upstream sources in our >git >repositories. Silly or not in your opinion, the Qt-KDE team repositories are set up this way. They seem to like it and I don't think the project as a whole ought to try and force them to do work a different way. Additionally, other tools, like git-dpm, have their own requirements for branch naming. That's the one tool that got me using git for packaging, so it would be nice if it kept working. Please send patches so it works with the new scheme as well as conversion scripts for existing repositories. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2b32f568-b3c2-43f8-b465-7e79bdd59...@email.android.com
Re: Standardizing the layout of git packaging repositories
On August 19, 2014 8:08:14 PM EDT, Jeremy Stanley wrote: >On 2014-08-20 02:32:10 +0800 (+0800), Thomas Goirand wrote: >[...] >> Good! For the moment, it has worked nicely, apart from the fact that >> *some* upstream, like Jeremy Stanley, don't like it. I honestly feel >> sorry about that, especially with people like Jeremy and other >OpenStack >> folks which are doing truly awesome work, and for which I have a lot >of >> respect. >> >> And would like to let him understand the reasons that are pushing me >to >> work this way. I also feel like it's mostly a non-issue, for which >> there's no reason to be that picky (just let go, Jeremy? :)). >[...] > >Fair enough! I will admit (having been a devoted Debian user in >personal and large commercial settings for the past 15+ years but >only an occasional packager) that I'm very impressed at how you keep >up with the extreme volume of packaging you do day to day, and >ultimately feel however you manage to maximize your efficiency is >best for everyone. My main upstream takeaway from this is that we >should perhaps be considering tarballs as a target-specific >packaging format (PyPI et al) in and of themselves any longer, >rather than a general release item and stop placing as much focus on >them in release announcements if packagers are mostly just consuming >source directly from our version control systems now. > >Thanks for considering my (apparently outdated) arguments, and keep >up the good work! Don't assume most packagers approach thing like Thomas. I certainly don't. I've no idea what most do, but I don't think the predominant voices in this thread are generally representative. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e9c8c4ea-61ca-462a-8f3b-aca5bae1b...@email.android.com
Re: 2 months and no upload for pkg
On Friday, September 05, 2014 18:21:28 Daniel Pocock wrote: > On 05/09/14 17:48, Ian Jackson wrote: > > It is true that long NEW processing queues is a big problem. But it > > appears that a substantial amount of core team effort is being used to > > deal with poor submissions. If we can fix that, we can fix the long > > queue. > > This is really the root of the problem and I agree that it would be nice > to find ways to help them. A solution is good for the FTP masters and > good for the project. > > Another way to look at your proposal may be to compare it to > alternatives (I'm not suggesting I personally agree with all of these, > but they are just some things that come to mind): > > a) let people self-certify packages when they wrote 100% of the code > themselves. People abusing this privilege would lose it. > > b) offer some facility for upstreams to certify their packages as 100% > free software by completing a DEP-5-like template and signing it with > the same key they use to sign their tags and release announcements. > > c) offer a paid review service. FTP masters and assistants can sell > their time through an auction process. Uploaders and interested third > parties can bid for packages to be reviewed. If they reject a package, > it goes back to its original place in the queue unless somebody pays for > them to spend more time on it. Some people may feel that this will > deter the FTP masters from reviewing packages unless all uploaders start > paying while other people may feel that this funding would give the FTP > masters more time. Maybe the fee could include a surcharge of 33% to > cover regular queue processing, so for every 3 packages that pay, one > package is taken from the front of the queue as well? The rate of the > surcharge could be variable to keep the backlog within a 2 week target > range. > > d) the upload with binary JARs inside it was accepted by the NEW queue > software. Maybe the scripts could be stricter about rejecting such > packages before they reach FTP masters? Do the FTP masters publish > statistics on rejections that could be used to identify the top things > to scan and reject automatically? > > Are there other alternatives that people can think of? e) Stop uploading crap packages to the archive. I know there are lots of ways to go wrong and it's time consuming and annoying and you're busy. Imagine how much more annoying it is to have to deal with all of it. The low quality of package uploads is (at least for me) demotivating. As an FTP Assistant, I want time I invest in reviewing a package to result in something going into the archive. Every time it doesn't I feel like I've had my time wasted. Here's one tip I've given people before: grep -ir copyright * Do that over your source and then compare what you have in debian/copyright. You might be surprised how often that turns up missing stuff. Check your own packages at least as carefully as you expect the FTP Team to check it. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/4113890.BhKOUnD99M@scott-latitude-e6320
Re: Standardizing the layout of git packaging repositories
On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava wrote: >On Sun, Sep 07 2014, Brian May wrote: > > >> In another email by Manoj Srivastava: >> >>> That is really a matter of displaying history. The diagram >> displays Git history, not the patches; when B21 is committed, > there >is no >> patch representing B12, however, that commit is still in >/.git/objects >> since it is a parent of the Node D3. This > is relevant when I am >trying to >> trying to bisect and understand history. git-debcherry has fewer >commits >> being carried around, > which makes it easier on my aging brain. > >> Sorry, I think you have this wrong. (also nitpick: B12 is a parent of >D5, >> not D3). > > I aplogize, I I have not conveyed what is happening correctly, > and you are confused by my diagrams. I shall try to do better. > >> When you commit B21, you have to replace B12 in the git history (e.g. >git >> commit --amend). Otherwise, when the patches are exported, you will >get >> both B12 and B21 appearing as separate patches debian/patches in D6. >dpm >> has no way of knowing that B12 and B21 are part of the same patch and >> should be merged. > >That is the outcome I want. > >I commit B1, and later, B2. git-dpm creates ephemeral branches, > >| I commit | Ephemeral gbranch contains | Master contains | >|--++-| >| A1 | A10| D2 | >| B1 | A10, B11 | D3 | >| U2 | A11. B12 | D5 | > > At this point B11 ans A10 are gone, apart from living in .git/objects. > >| I commit | Ephemeral gbranch contains | Master contains | >|--++-| >| B2 | A11, B12, B21 | D6 | > > There are there nodes in the ephemeral branch, and three patches > are produced -- Corresponding to A1, B1, and B2. > >| I commit | Ephemeral gbranch contains | Master contains | >|--++-| >| A2 | A11, A21, B13, B22| D7 | > > >Four commits on the feature branches, and the ephemeral branch > contains 4 commits -- the older ephemeral branches continue to live in > .git/objects, which bothers the purist in me, > >> Maybe your point that debcherry is better still stands - it appears >to work >> better with your concept of "feature branches", however I find it >hard to >> use your document to compare the two when it contains errors like >this. > > >I think the errors lie in documentation of what the diagram is > and thus the incorrect interpretation, rather than the underlying > analysis. I'll try do document better what the diagrams mean. Has this > helped you understand what the document is trying to say? I'll confess up front that I'm a neophyte when it comes to git. From what I can tell though we've been using git-dpm for feature branches in pkg-clamav and it seems to me to work fine. I'd be curious what you'd find if you had a look at the team repository for clamav to see if what we're doing matches your concept of feature branches? Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/75eaebf4-07c4-4734-b124-f1d0c6a1b...@email.android.com
Re: Trimming priority:standard
On Friday, September 12, 2014 02:43:09 Marco d'Itri wrote: > On Sep 12, Adam Borowski wrote: > > What would you guys say about cutting some cruft from priority:standard? > > I like your plan (even if I have some doubts about telnet). Personally, I use telnet pretty routinely. Generally when I'm acting as a human pretending to be an MTA for troubleshooting purposes. I would find it pretty surprising to find it absent. The rest of the plan seems reasonable to me. Scott K signature.asc Description: This is a digitally signed message part.
Re: New package tracker - old one going?
On September 16, 2014 7:44:36 AM EDT, Raphael Hertzog wrote: >Hi, > >On Tue, 16 Sep 2014, Iain R. Learmonth wrote: >> On Tue, Sep 16, 2014 at 02:54:43PM +0800, Paul Wise wrote: >> > It will go away eventually once the new tracker has equivalent >functionality. >> >> I know it's nothing to be abandoning the new tracker over, but the >new one >> hurts my eyes. The old one is quite pretty. > >That's not a very actionable feedback. The main differences are: >- white background instead of gray one >- more whitespace between panels >- smaller font-size (this has already been reported in #756721 > >What parts are actually problematic in your opinion ? In mine, the top center panel being taken up by information about the new tracker makes it quite difficult to really get a feel for how readable/usable the new site is. Is there some way to make that removable? Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0135d94d-20ae-4a3e-8a9b-fe03b82fb...@email.android.com
Re: Bug#764890: ITP: dk-filter - DomainKeys for Sendmail/SMTP (RFC-4870)
On October 12, 2014 7:18:48 AM EDT, Andrei POPESCU wrote: >Control: reassign -1 wnpp >Control: owner -1 Carlos Gili > >On Sb, 11 oct 14, 17:46:50, Carlos Gili wrote: >> Package: dk-filter >> Priority: whishlist >> >> Section: mail >> Original-Maintainer: Mike Markley >> Description: DomainKeys for Sendmail/SMTP >> Implements a Sendmail/SMTP Mail Filter (Milter) for the >> DomainKeys standard (RFC-4870). DomainKeys provides a way >> for authorized sender mail servers from an specific Domain >> to confirm their identity when sending email by adding a >> cryptographic signature to the headers of the message. The >> dk-filter implements both DomainKeys signing and verification. >> . >> >> Currently, both DKIM (OpenDKIM) and DomainKeys together with SPF >> are requested by servers such as Hotmail or Yahoo to ensure that >> the mail is not forged (spam), otherwise your mail gets send to >> spam folder most of the time, unless you are an already KNOWN >> domain server. >> >> The binary .deb file for amd64 is ready to be uploaded, the i386 >> and source ones will take a little since I'm integrating with GIT, >> and creating a Virtual environment to compile on 32bits, also I'm >> preparing a repository for several things. >> No. DomainKeys is dead. Only DKIM is used. dk-filter was buggy and long dead upstream when it was removed. There's no need for this in 2014. Please don't re-introduce this into the archive. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f0f32e79-bb75-4c72-ab18-e343f6f0c...@kitterman.com
Re: Doxygen and embedded jquery problem, how to solve?
On Wednesday, October 29, 2014 15:59:44 Jonas Smedegaard wrote: > Quoting Gianfranco Costamagna (2014-10-29 15:18:30) > > > >For the source package I believe you should either... > > [...] > > > the documentation is usually regenerated into debian, not ship with > > the source code > > Silly me, you are right, off course. > > >>For the [binary] package I believe you should either... > > [...] > > >>I don't follow why using a symlink is bad - if only you ensure to not > >>have broken symlink, by depending on (not recommending) the jquery > >> > > The problem is: > > vi /usr/share/doc/doxygen/REAMDE.jquery > > > > " > > It is not considered a problem for Doxygen or packages using Doxygen to > > embed jquery. In fact replacing the `jquery.js` file created by Doxygen > > likely results in broken documentation. Packages doing that are buggy. > > Lintian will have to learn that a `jquery.js` embedded by Doxygen is a > > normal thing. " > > > > > > they call it jquery, but in fact is not really jquery. > > > > > > (the solution might be in the doxygen doc file, but unfortunately it > > isn't accepted by all the developers) > > Ahh - sorry I was not addressing your actuall issue at all. Nothing > wrong with your initial explanation, only with me :-/ > > IMO the proper solution is for Debian packaging of doxygen to untangle > jQuery from extensions, depend on + symlink the jQuery part, provide the > extensions as a shared package, and patch doxygen code to generate > docuementation referencing each separately instead of the entangled one. > > ...but seems from that README that maintainers of doxygen have already > reflected on this and disagrees. > > I suggest (but won't drive it myself) to file a bug against doxygen to > kindly reconsider... > > ...and until eventually maybe progress on that front, either a) try > untangle the jquery+extensions code yourself for each and every single > package using doxygen, or b) embrace same attitude as doxygen > maintainers and add lintian suppressions referencing doxygen README as > comment. > > > I suspect there's nothing new in what I write here - that you've already > come to same conclusion yourself before posting do devel - sorry that I > have no better input. :-/ Would another option be to use "built-using" the doxygen version in question. Since effectively this is embedded code from the doxygen package if I understand it correctly. Using doxygen to regenerate things is the preferred form of modification and all the source is available in doxygen. Other than being annoying and causing stuff to have to be rebuilt when doxygen is updated, what's wrong with that? Scott K signature.asc Description: This is a digitally signed message part.
Re: Doxygen and embedded jquery problem, how to solve?
On Wednesday, October 29, 2014 17:44:11 Cyril Brulebois wrote: > Scott Kitterman (2014-10-29): > > Would another option be to use "built-using" the doxygen version in > > question. Since effectively this is embedded code from the doxygen > > package if I understand it correctly. Using doxygen to regenerate > > things is the preferred form of modification and all the source is > > available in doxygen. > > > > Other than being annoying and causing stuff to have to be rebuilt when > > doxygen is updated, what's wrong with that? > > AFAICT Built-Using means "keep the source around", not "things have to > be rebuilt when the source is updated". It does if you want the old source to go away. Scott K signature.asc Description: This is a digitally signed message part.
Re: Let's abandon debian-devel.
On Monday, November 10, 2014 04:55:20 PM David L. Craig wrote: > On 14Nov10:2154+0100, Gergely Nagy wrote: > > You do realize topic lists are public too, right? > > Yes, but most Debian users don't even know about > them nor do they need to since the traditional > lists have been doing their jobs for quite a > while. If you shut them down, I expect most of > the public will not find the topic lists. Except, of course, for the ones reading d-devel now (which includes the claimed problematic group). Ubuntu had to moderate posting rights on their main -devel list years ago and it improved the climate considerably. Might be something to consider that's short of giving up. Scott K signature.asc Description: This is a digitally signed message part.
Re: Let's abandon debian-devel.
On Tuesday, November 11, 2014 12:41:12 PM Neil McGovern wrote: > On Tue, Nov 11, 2014 at 01:30:58PM +0100, Matthias Urlichs wrote: > > Andrey Rahmatullin: > > > > I know. So? If the first email of a non-DD gets delayed for a few > > > > hours, > > > > that's an acceptable price to pay IMHO. > > > > > > Nothing about delays wasn't mentioned in your previous email > > > > Moderating (some) emails to d-d implies delaying those emails until > > a human moderator looks at them. To me at least. Therefore I didn't > > think of explicitly mentioning that; sorry if that was unclear. > > My concern would be around /which/ human moderator does this. The > project passed a GR about declassifying -private, for example, and this > had never been achieved because the people who are willing to put the > work in don't exist. I'd be willing to help out. Scott K signature.asc Description: This is a digitally signed message part.
Re: Should fast-evolving packages be backports-only?
On November 11, 2014 12:22:57 PM EST, Cyril Brulebois wrote: >Rebecca N. Palmer (2014-11-11): >> It has been recently stated [0-1] that backports is enabled by >> default in Jessie. > >Yes, and that's a bug. See #764982. > >> 1. Does that mean that if pkgX is in jessie-backports but not >> jessie, "apt-get install pkgX" will install it from -backports? > >Yes. And that's the reason why I'm going to disable jessie-backports >by default when I process my todo list. As long as apt prefers a version from stable over a version from backports when both are available (unless instructed to install from backports) why is this a problem? It seems more user friendly to me for a package that's been specifically ask for to end up installed rather than not. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e8f87680-99dc-4fa5-8fc2-754d48d57...@kitterman.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tuesday, November 11, 2014 22:26:24 Raphael Hertzog wrote: > Hello, > > following the initial discussion we had in August > (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have > written a first draft of the Debian Enhancement Proposal that I suggested. > It's now online at http://dep.debian.net/deps/dep14 and also attached > below so that you can easily reply and comment. > > I have left one question where I have had conflicting feedback > and I'm not sure what's best. Thus I will welcome a larger set of > opinions on this specific question (search for "QUESTION" in the > text). > > Are there things that are missing? Who's going to do patches to existing tools (e.g. git-dpm is the one I use and care about) so they comply with this and similarly scripts to convert existing git repos to match this recommendation? It doesn't make much sense to have an standard unless there's also a plan to implement using it. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/16276435.4WkQ4eyy62@scott-latitude-e6320
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On November 12, 2014 7:38:25 AM CST, Matthias Urlichs wrote: >Hi, > >Simon McVittie: >> Is it the intention of this DEP to mandate the gbp-pq-like repo >> structure, which basically forbids use of tools whose design does not >> match that? Or is the intention to set some conventions that can be >true >> regardless of whether you are using a more gbp-pq-like or more >> git-dpm-like workflow, in the knowledge that that necessarily makes >> those conventions less strict? >> >IMHO there are two basic approaches which are mostly at odds with each >other. > >One: Treat Upstream's git repository as Source Code; if upstream >doesn't >have one, pretend that it does by importing their tarballs. Use "git >rm" >to remove nondistributable files and generated stuff (if Upstream even >includes them, which if they use git they hopefully don't). > >Apply Debian changes, packaging or not, to a packaging branch. >debian/patches is an auto-generated packaging artefact which I as a >maintainer can basically ignore. Other distributions may share the >common >repository. > >Call this one "integrated". > > >Two: Treat Upstream tarballs as Source Code; if Upstream generates them >from git-or-whatever, that's not our problem. Use a script to mangle >the >upstream tarball if it contains nondistributable files. Keep >autogenerated >Makefiles et al. around. > >Keep Debian packaging completely separate (in a different branch, or >even >in a diffferent archive) and use a quilt-ish workflow which treats the >content of debian/patches as first-class citizens. There's not much >point >for other distros to share our packaging repository, so why plan for >it? > >Let's call this one "divided". > > >This DEP describes an integrated workflow. >This DEP does not say anything about any sort of divided workflow, >other >than to implicitly (un?intentionally?) discourage its use by omission. > >I personally happen to like an integrated workflow, to the point that >the >first thing I do when working on anything packaged in a divided way >I'll run a script that unwraps debian/patches into my upstream archive >clone's debian branch. > >Based on a couple of reactions here, some from people who dislike >integrated workflow at least as intensely as I don't, IMHO there's >not much common ground between the integrated- and the divided- >workflow adherents. > >Thus, please don't try to shoehorn a divided workflow into this DEP. >Write your own. I don't think so. This is about what Debian as a whole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d2ca04-cfc2-4929-8f2b-73083b93c...@kitterman.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On November 12, 2014 8:15:02 AM CST, Scott Kitterman wrote: >On November 12, 2014 7:38:25 AM CST, Matthias Urlichs > wrote: >>Hi, >> >>Simon McVittie: >>> Is it the intention of this DEP to mandate the gbp-pq-like repo >>> structure, which basically forbids use of tools whose design does >not >>> match that? Or is the intention to set some conventions that can be >>true >>> regardless of whether you are using a more gbp-pq-like or more >>> git-dpm-like workflow, in the knowledge that that necessarily makes >>> those conventions less strict? >>> >>IMHO there are two basic approaches which are mostly at odds with each >>other. >> >>One: Treat Upstream's git repository as Source Code; if upstream >>doesn't >>have one, pretend that it does by importing their tarballs. Use "git >>rm" >>to remove nondistributable files and generated stuff (if Upstream even >>includes them, which if they use git they hopefully don't). >> >>Apply Debian changes, packaging or not, to a packaging branch. >>debian/patches is an auto-generated packaging artefact which I as a >>maintainer can basically ignore. Other distributions may share the >>common >>repository. >> >>Call this one "integrated". >> >> >>Two: Treat Upstream tarballs as Source Code; if Upstream generates >them >>from git-or-whatever, that's not our problem. Use a script to mangle >>the >>upstream tarball if it contains nondistributable files. Keep >>autogenerated >>Makefiles et al. around. >> >>Keep Debian packaging completely separate (in a different branch, or >>even >>in a diffferent archive) and use a quilt-ish workflow which treats the >>content of debian/patches as first-class citizens. There's not much >>point >>for other distros to share our packaging repository, so why plan for >>it? >> >>Let's call this one "divided". >> >> >>This DEP describes an integrated workflow. >>This DEP does not say anything about any sort of divided workflow, >>other >>than to implicitly (un?intentionally?) discourage its use by omission. >> >>I personally happen to like an integrated workflow, to the point that >>the >>first thing I do when working on anything packaged in a divided way >>I'll run a script that unwraps debian/patches into my upstream archive >>clone's debian branch. >> >>Based on a couple of reactions here, some from people who dislike >>integrated workflow at least as intensely as I don't, IMHO there's >>not much common ground between the integrated- and the divided- >>workflow adherents. >> >>Thus, please don't try to shoehorn a divided workflow into this DEP. >>Write your own. > >I don't think so. This is about what Debian as a whole Oops. ... as a whole is doing. The DEP should be broad enough to capture at least rough consensus. Let's not make this in another poisonous us versus them issue. We have enough of those already. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e2a648b3-b9b0-4d45-b165-3b0d77cd5...@kitterman.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Thursday, November 13, 2014 01:32:04 Sam Hartman wrote: > Hi. > I've read the original proposal and believe it is generally going in the > right direction. > > things I liked: > > * didn't pick between dgit/git-dpm/git-pq; documented the common parts > > * Seemed to really focus on one clear scope. > > * Discouraged overlay packaging. > I've tried to read the arguments, and I'm unconvinced that should be a > recommended practice. > I'd prefer to simply rule it out of scope: this proposal describes how > to package debian and upstream sources together. It does not apply to > other cases and does not forbid or recommend them. > It doesn't apply to svn. It doesn't apply to overlay packaging. If the scope is narrower than Debian as a whole, then the title of the DEP needs to change. Maybe: Recommended layout for Git packaging repositories which also contain upstream sources Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2509218.QQGvL7qbEk@scott-latitude-e6320
Re: Being part of a community and behaving
On November 16, 2014 9:18:51 AM EST, Shachar Shemesh wrote: >On 13/11/14 18:22, Tobias Frost wrote: >> Sometimes, a joke is just inappropriate, regardless how funny it may >seem. >> Sometimes, a joke is better not made, regardless how funny it is. >> >> We have enough bad karma these days, no need to pour gasoline on the >fires. >Civility ism after all, so important to free speech >(http://www.popehat.com/2014/09/06/u-c-berkeley-chancellor-nicholas-dirks-gets-free-speech-very-wrong/). >I mean, people have the right not to be offended >(http://rationalwiki.org/wiki/Freedom_of_speech#Right_not_to_be_offended). >> I assume we're all adults after all. >Including the ones doing the reading? > >Seriously. You are free to feel the joke was in poor taste. My stake in >this particular game is not deep enough for me to think so, but taste >is >a matter of opinion. > >Which is precisely the point. Taste is a matter of opinion. Limiting >speech to only the things everyone agree are in good taste greatly >limits the speech (see first link for in depth explanation of why). I >don't think I'd like this forum to regress to that point. > >I'd say more, but I just feel like I'm repeating what the two links I >provided are saying. I suggest we do, indeed, act like adults. Please >try to refrain from jokes other will find offending. If you see such a >joke, please try to refrain from stirring the fire by saying it's >wrong. >Just, you know, be adults... The cure for inappropriate speech is more speech. Calling people on things that are inappropriate or that cause problems in the project is exactly the right thing to do. "Refrain from stirring the fire by saying it's wrong" is backwards. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3c9d6bd2-2276-4b57-ac62-17b8854ec...@kitterman.com
New pre-depends: python pre-depends python-minimal
It appears that the appropriate resolution of #769106 [1] is to add a new pre-depends on python-minimal in python. This issue at hand is that at the time python2.7-minimal is configured, python is unpacked, but python-minimal is not. Since python-2.7-minimal doesn't have a direct depends on python-minimal, this is allowable (policy 7.2, Depends). In order for python2.7-minimal to configure, python-minimal needs to be at least unpacked to provide /usr/bin/pycompile. The only way for python to ensure this is the case is to declare a pre-depends relation (also policy 7.2). Since nothing outside python-defaults should depend on python-minimal this should have a minimal impact on upgrade ordering or dependency resolution complexity. One might argue that the python/python-minimal split is obsolete and ought to be dropped, but I think that's a discussion to have (if at all) for Stretch. Adding the pre-depends is the least invasive solution to this RC bug. Comments/concurrence/etc? Scott K [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769106 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2336109.MRqKsDn39K@kitterman-optiplex-9020m
Re: New pre-depends: python pre-depends python-minimal
On Tuesday, November 18, 2014 08:28:29 AM Julien Cristau wrote: > On Mon, Nov 17, 2014 at 18:24:00 -0500, Scott Kitterman wrote: > > It appears that the appropriate resolution of #769106 [1] is to add a new > > pre-depends on python-minimal in python. > > > > This issue at hand is that at the time python2.7-minimal is configured, > > python is unpacked, but python-minimal is not. Since python-2.7-minimal > > doesn't have a direct depends on python-minimal, this is allowable > > (policy 7.2, Depends). > > > > In order for python2.7-minimal to configure, python-minimal needs to be at > > least unpacked to provide /usr/bin/pycompile. The only way for python to > > ensure this is the case is to declare a pre-depends relation (also policy > > 7.2). > > Can you explain why/how the python package enters into the picture here > at all? texlive-music grew a depends on python between wheezy and jessie, so in the upgrade test that led to the the bug it was being freshly installed (test being done in a minimal chroot. python depends (among other things) python2.7 and python-minimal. python- minimal then depends on python2.7-minimal. As part of python2.7-minimal's configuration, /usr/share/python/runtime.d/public_modules.rtinstall gets executed. It's part of the python package. Since the dependency chain was texlive-music -> python -> python2.7-minimal, python is already unpacked, so the script is available. The tricky part is that /usr/share/python/runtime.d/public_modules.rtinstall needs /usr/bin/pycompile in order to work. That's in (you guessed it) python- minimal. It's not available (and there's nothing in policy that says it has to be). Eventually, python-minimal will get unpacked, but it hadn't yet in this test run. Does that clarify it? Scott K signature.asc Description: This is a digitally signed message part.
Re: New pre-depends: python pre-depends python-minimal
On November 18, 2014 6:30:02 PM EST, Jakub Wilk wrote: >* Julien Cristau , 2014-11-18, 23:50: >>>As part of python2.7-minimal's configuration, >>>/usr/share/python/runtime.d/public_modules.rtinstall gets executed. >>>It's part of the python package. Since the dependency chain was >>>texlive-music -> python -> python2.7-minimal, python is already >>>unpacked, so the script is available. >>> >>>The tricky part is that >>>/usr/share/python/runtime.d/public_modules.rtinstall needs >>>/usr/bin/pycompile in order to work. That's in (you guessed it) >>>python-minimal. It's not available (and there's nothing in policy >>>that says it has to be). > >Wouldn't it make more sense to have the *.rtinstall hook in the same >package as pycompile? > >>That sounds broken. > >It is. > >>Why does python2.7-minimal run stuff > >python2.X-minimal runs /usr/share/python/runtime.d/*.rtinstall hooks to > >let Python helpers bytecompile Python files for the newly installed >Python version. > >This kinda made sense in the olden days, when we had multiple supported > >Python versions. But now that we support only 2.7, it doesn't seem >terribly useful. > >>from the python package? > >Because that's where (parts of) the Python helper lives. I agree it's not ideal. If we weren't in freeze, pre-depends isn't how I'd suggest fixing it. Adding the pre-depends fixes the issue without any risk due to shuffling stuff around at the last minute. I'm glad to fix it smarter for Stretch, but I'm very hesitant to change the packages' structure at this point in the release cycle. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f3b47df3-13cd-496a-b9a3-1cfca7520...@kitterman.com
Re: what to do is maintainer is lacking? (was: wine-unstable in Debian)
On Wednesday, April 18, 2012 04:57:14 PM Thomas Goirand wrote: > On 04/18/2012 08:27 AM, Steve McIntyre wrote: > > If a maintainer isn't (capable of) doing the necessary work on a > > package themselves, then after a while the best thing they can do is > > admit that and cede control to others. It's not an easy thing to admit > > "failure" like this, but it's better to do it for the good of our > > users and other developers than to continue blocking people. It's also > > better for the developer involved to get away from the feelings of > > guilt they may be having about not keeping up. There's no shame in > > admitting a lack of time on a big volunteer project, we all understand > > how this works... > > This isn't aimed at the WINE maintainers (I didn't read the bug report, > and I don't really care about this package) but... > > what can we do if the maintainer doesn't admit his lack of time or his > lack of skills/knowledge? My understanding is that in Debian, we are > stuck, right? I believe that was the message of Chris: we don't really > have procedures to take over a package, others than convincing the > maintainer. A couple of times I've said "It looks like you could use some help. Would you like me to co-maintain with you?" and have generally gotten a positive response. If it's put in terms of "Looks like you're busy, I can help" and not "You suck and should be fired so I can take over" people seem to be pretty open to it. Scott K signature.asc Description: This is a digitally signed message part.
Re: Bug#669570: ITP: reviewboard-rbtools -- Command-line tool to create/update ReviewBoard requests
On Friday, April 20, 2012 04:12:56 AM Dmitry Nezhevenko wrote: > Package: wnpp > Severity: wishlist > Owner: Dmitry Nezhevenko > > * Package name: reviewboard-rbtools > Version : 0.4.1 > Upstream Author : Christian Hammond, David Trowbridge > * URL : http://www.reviewboard.org/ > * License : MIT > Programming Lang: Python > Description : Command-line tool to create/update ReviewBoard requests > > ReviewBoard is a web application to handle code reviews. > This package provides post-review command-line utility that simplifies > both creating and updating review requests. It can look at your source > directory, generate a diff, and upload it to a new or existing review > request on an associated Review Board server. > > Upstream releases it as separate source package, so we've separate debian > source pkg too. Isn't this the same as the existing python-rbtools package: http://packages.debian.org/sid/python-rbtools Scott K signature.asc Description: This is a digitally signed message part.
8 bit to 7 bit conversion - was Re: switching from exim to postfix
On Tuesday, May 01, 2012 06:55:20 PM Riku Voipio wrote: ... > Honesstly. my grievance is really just having to convert things to 7bit.. s ... In the future, you're likely to still be stuck doing this for other 'fun' reasons. The one I ran into recently was that 8 bit -> 7 bit conversions will break DKIM signatures, so it's only safe (from a reliability perspective) to sign 8 bit mail if you know the entire path is 8 bit clean. Since there's really no way to know that, now I flatten everything to 7 bit and then sign it. Scott K signature.asc Description: This is a digitally signed message part.
Re: switching from exim to postfix
On Wednesday, May 02, 2012 07:23:13 PM Russell Coker wrote: > On Wed, 2 May 2012, Jon Dowland wrote: > > On Wed, May 02, 2012 at 07:05:14PM +1000, Russell Coker wrote: > > > Having mail be silently corrupted is not acceptable. > > > > Can you expand on "silently corrupted", here? Is that when you re-encode > > the mail and send it on as 7-bit, or when you leave it alone and send it > > as 8 bit to a host that doesn't advertise accepting 8-bit? > > When you send 8 bit mail to a host that only supports 7 bit then it will be > corrupted, usually without any notification of what happened - definitely > silent corruption. > > When you re-encode mail and send it on IFF the message is DKIM signed it > could be considered to be silent corruption as the change will usually > count as breakage. > > It would be possible for a DKIM verification program to re-encode 7bit > messages to 8bit for a second attempt at verification. But if a DKIM milter > author was going to do tricky things then a better first option would be to > try removing anything between [] in the subject line which is the most > common cause of DKIM failures that I see on valid mail. That and mailing list footers. Receivers are, of course, free to manage inbound mail filtering however they want, but if you take a message and try to recode it from 7 bit to 8 bit and see if a DKIM signature passes verification, it's still not a valid DKIM signature in any sense that RFC 4871 or its successors would recognize. Scott K -- 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/1669928.j8eO2yxEKH@scott-latitude-e6320
Re: switching from exim to postfix
Vincent Lefevre wrote: >On 2012-05-02 15:00:36 +0200, Andrew Shadura wrote: >> Hello, >> >> On Wed, 2 May 2012 10:06:31 +0100 >> Jon Dowland wrote: >> >> > On Wed, May 02, 2012 at 08:44:12AM +0200, Andrew Shadura wrote: >> > > No it doesn't if 8BITMIME annouces are turned off! >> >> > If exim receives an 8 bit mail, even if it hadn't announced >8BITMIME >> > in the EHLO response, it will relay that message verbatim to other >> > hosts. >> >> But it won't receive it at all if the sender is standards-compliant. > >True for SMTP. But what if exim received an 8-bit mail by another >mean (e.g. on the command line via the sendmail command)? Then it's irrelevant to the discussion. It's a local system issue and it's up to the local administrator. Internet standards have nothing to do with it. Scott K -- 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/572df31b-7661-487c-8e43-5b150234a...@email.android.com
Re: switching from exim to postfix
On Thursday, May 03, 2012 02:45:06 AM Vincent Lefevre wrote: > On 2012-05-02 20:23:41 -0400, Scott Kitterman wrote: > > Vincent Lefevre wrote: > > >On 2012-05-02 15:00:36 +0200, Andrew Shadura wrote: > > >> Hello, > > >> > > >> On Wed, 2 May 2012 10:06:31 +0100 > > >> > > >> Jon Dowland wrote: > > >> > On Wed, May 02, 2012 at 08:44:12AM +0200, Andrew Shadura wrote: > > >> > > No it doesn't if 8BITMIME annouces are turned off! > > >> > > > >> > If exim receives an 8 bit mail, even if it hadn't announced > > > > > >8BITMIME > > > > > >> > in the EHLO response, it will relay that message verbatim to other > > >> > hosts. > > >> > > >> But it won't receive it at all if the sender is standards-compliant. > > > > > >True for SMTP. But what if exim received an 8-bit mail by another > > >mean (e.g. on the command line via the sendmail command)? > > > > Then it's irrelevant to the discussion. It's a local system issue > > and it's up to the local administrator. Internet standards have > > nothing to do with it. > > Wrong. It's relevant in the sense that Exim will transmit the mail > to a remote MTA. If it doesn't do the 8-bit to 7-bit conversion if > the remote MTA doesn't announce 8BITMIME, then Exim is broken. True, but that's a different bit of brokenness. Scott K -- 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/1402413.fhnghq13dI@scott-latitude-e6320
Re: Making -devel discussions more viable (was: switching from exim to postfix)
On Friday, May 04, 2012 11:17:24 PM Lisandro Damián Nicanor Pérez Meyer wrote: > Not enough information to check signature validity. Show Details > On Jue 03 May 2012 08:23:29 Stefano Zacchiroli escribió: > [snip] > > > 3) public, but contributors-only list > > > > > > > > This has been implemented by other FOSS projects. A notable example is > > Ubuntu who have a split between ubuntu-devel (project members only + > > whitelisting) and ubuntu-devel-discuss (free for all). I've never asked, > > but I have always suspected that they've done so in an attempt to > > improve over the experience of debian-devel participants. > > If you happen to ask, it would also be nice to know how it worked for them. It was implemented because at the time ubuntu-devel had a very low signal to noise ratio and developers were getting frustrated (sound familiar). My opinion is that it worked pretty well. Most of the noise immediately shifted to ubuntu-devel-discuss and a lot of developers never subscribed to it, so they were immediately helped. After some period of high noise, low value existence, the number of Ubuntu developers that subscribed to ubuntu-devel-discuss declined further. It was pointed out to some of the more problematic contributors that if they didn't knock it off and be less abusive and more productive in their list messages, they were going to have no developers left to talk to. Eventually, the situation normalized and ubuntu-devel-discuss is a fairly low volume list and most of the posts, if not particularly consistently well informed, are from people that are trying to be constructive (not, of course, right after controversial decisions get announced). The two lists separated are, in my opinion much higher signal to noise than the old combined ones. Scott K -- 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/6304701.fiE8eoYKvG@scott-latitude-e6320
Re: Bug#675033: ITP: kgraphviewer -- KGraphViewer is a GraphViz dot graph viewer for KDE 4.
On Tuesday, May 29, 2012 02:54:40 PM w.goesgens wrote: ... > Already packaged for ubuntu by Scott Kitterman; compiles on debian wheezy. > https://launchpad.net/ubuntu/+source/kgraphviewer/4:2.1.1-0ubuntu1 For the record, it is already packaged in Ubuntu, but not by me. I touched it there to do some fix ups, but it's most certainly not my package. Scott K signature.asc Description: This is a digitally signed message part.
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thursday, May 31, 2012 03:16:06 PM George Danchev wrote: > On Thursday 31 May 2012 11:47:21 Jonas Smedegaard wrote: > > Hi, > > > > You and a lot of others fail to realize that the *SPONSOR* is > > > responsible for the package. > > > > Huh?!? > > > > What does "Maintainer:" mean if not the entity being responsible for, > > well, maintaining?!? > > Who is responsible for the package maintenance in the case where a non-DD is > listed in "Maintainer:", and the package is obviosuly signed and uploaded > (effectively sponsored) by a DD? I guess it is perfectly reasonable to > expect that DD, being in the role of sponsor, is responsible for the > package quality and further maintenance. Sponsors are full-fledged DDs, and > trying to claim that they are not responsible, or are somehow less > responsible than any other non-sponsoring DDs, for the uploads they have > done, is obviously plain wrong. > > > If the maintainer fails to keep the package in a useful shape it is > > > the sponsor's responsibility to do so. And last but not least it > > > should be the sponsor's decision to orphan a package if the maintainer > > > is MIA or not doing his job properly. It is also the sponsors > > > responsibility to try to figure out if a maintainer is willing to do > > > his job longer than one upload before sponsoring a package at all. > > > > I have heard before the argument of the sponsor having responsibility, > > but in reality I have *never* heard of sponsors actually being held > > responsible for anything but the concrete upload of a specific packaging > > release. > > > > ...which leads to my concern for high risk of drive-by contributions! > > ...hence the Sponsors (who are also a full-fledged DDs) are responsible. It > is that simple. If it's really that simple, one should never sponsor a package one doesn't care to maintain. If this is the case, we should just do away with sponsorship and require the uploader to be either Maintainer or in Uploaders unless it's an NMU (note: I don't think this is what we want). Scott K -- 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/1888095.EXhfyjLExP@scott-latitude-e6320
Re: DUCK -the Debian Url Checker
On Wednesday, June 06, 2012 03:24:50 PM Simon Kainz wrote: > Hi list, > > as I had some problems in the past finding upstream sources and > homepages, I hacked up some scripts to monitor and display the results > of the Upstream Homepage entries in the package control files. > > Please take a look at http://debian.tugraz.at/duck/ > > Currently the job runs once a day and the results are displayed. Maybe > this is of some use for some maintainers and/or developers. > > One can also search for specific maintainers. > > Please tell me what you think about it - I have already some more > features planned. FWIW, it already noticed the homepage for one of my packages was 404. I emailed the upstream and just heard back that they hadn't known the page had gone missing and will fix it. Thanks, Scott K -- 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/5253430.Z2GAZWrkTq@scott-latitude-e6320
Re: Bug#678828: ITP: libticables -- Texas Instruments link cables library
On Sunday, June 24, 2012 10:50:58 AM Albert Huang wrote: > Package: wnpp > Severity: wishlist > Owner: Albert Huang > > * Package name: libticables > Version : 1.3.3 > Upstream Author : Lionel Debroux > * URL : http://lpg.ticalc.org/prj_tilp/ > * License : GPL > Programming Lang: C > Description : Texas Instruments link cables library > > The libticables is a library providing support for operations on Texas > Instruments calculators link cables. All link cables are supported > read/write. Already in the archive: http://packages.qa.debian.org/libt/libticables.html Scott K -- 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/7841464.yB4YEzqQ32@scott-latitude-e6320
Untransitioned Ruby Packages
It looks like there are more than a few Ruby packages that aren't update for the new packaging scheme and still expect Ruby 1.8 as the default. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676092 is an example. If we weren't in freeze, these sorts of things would be easy enough to fix, but since we are ... What's the plan for packages like this? Should they be updated for the new Ruby package policy and sent through New? Should they be removed? Scott K -- 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/83850636.ynXt7Jv9yl@scott-latitude-e6320
Re: Untransitioned Ruby Packages
On Monday, July 09, 2012 11:16:35 PM Antonio Terceiro wrote: > Hello Scott, > > Scott Kitterman escreveu isso aí: > > It looks like there are more than a few Ruby packages that aren't update > > for the new packaging scheme and still expect Ruby 1.8 as the default. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676092 is an example. > > If we weren't in freeze, these sorts of things would be easy enough to > > fix, but since we are ... > > > > What's the plan for packages like this? Should they be updated for the > > new > > Ruby package policy and sent through New? Should they be removed? > > In general, I think untransitioned Ruby packages should be "tolerated" > for Wheezy, but not for Wheezy+1. That is, if a package that was not > transitioned and it's still worthy of being released with Wheezy has RC > bugs, then I think we should fix it without transitioning. If the > package is not useful anymore, then I think it's better to remove it. > > This package in particular is so obsolete that it doesn't even have a > proper Ruby build system, does not have a standard source structure > (e.g. lib/ and friends). It also has very low popcon¹, so it should > probably be removed. > > ¹: not the best metric in the world, that's true, but we don't have a >better one. OK. Thanks. I can file the RM bug for that one. In general though should these be forced to build with ruby 1.8 (since they generally have ruby1.8 in the binary name or should they be coerced into producing a package that works with ruby1.9, but is called ruby1.8? I'm assuming gong through New to fix these kinds of bugs isn't an option. Scott K -- 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/2689094.aqpOrPfCAQ@scott-latitude-e6320
Re: Untransitioned Ruby Packages
On Monday, July 09, 2012 08:08:37 PM Russ Allbery wrote: > Scott Kitterman writes: > > OK. Thanks. I can file the RM bug for that one. > > > > In general though should these be forced to build with ruby 1.8 (since > > they generally have ruby1.8 in the binary name or should they be coerced > > into producing a package that works with ruby1.9, but is called ruby1.8? > > I'm assuming gong through New to fix these kinds of bugs isn't an > > option. > > The Ruby policy for some time (before the recent revision) has been to > build two packages, one for 1.8 and one for 1.9.1 (which actually works > with more than 1.9.1, I think; the naming is confusing), if the package > supports both versions of Ruby (and then a metapackage that depends on the > 1.8 package). For packages that only generate a 1.8 binary package, I > wonder if they even work with 1.9. If they can't that's a much larger > problem. > > If they were broken in such a way as to only build packages for 1.8 even > though they could have also supported 1.9, at this late date I wonder if > it would be best to just leave them only supporting 1.8. wheezy will ship > with both 1.8 and 1.9.1, and if people have a need for that package, they > can install ruby1.8 to use it. > > So, in short, I think coercing them to build with ruby1.8 is the right > move. Makes sense. Thanks. Scott K -- 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/1384804.QMIY1DSZyc@scott-latitude-e6320
Re: Untransitioned Ruby Packages
On Monday, July 09, 2012 11:00:12 PM Scott Kitterman wrote: ... > OK. Thanks. I can file the RM bug for that one. ... For completeness, based on Russ Albrey's advice, that was a one line fix, so I'm just going to fix the FTBFS and I'll let someone who can better explain why it should be removed ask for it. Scott K -- 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/2149860.1gUj0gXRHa@scott-latitude-e6320
