Re: Supporting alternative zlib implementations
On Wed, Sep 25, 2024 at 01:55:17AM +0200, Guillem Jover wrote: > The problem though is, that because the compressed stream is going to > change, that can make certain test suites fail if we perform this > switch, which I think would be the main fallout that we'd see from > this and would need manual fixing, although I assume Fedora has probably > handled most of these already. For example when I added explicit > zlib-ng support to dpkg, I had to fix its test suite to parametrize > sizes for test artifacts. I guess this is also a risk for zlib upgrades, seems a bit fragile. signature.asc Description: PGP signature
Re: Supporting alternative zlib implementations
On Tue, Sep 24, 2024 at 05:45:49PM +0200, Guillem Jover wrote: > On Tue, 2024-09-24 at 15:58:10 +0200, Mark Brown wrote: > > Obviously it's far too late to do anything with the default for trixie, > > we might want to evaluate doing something after the release but for now > > it's too late. > Personally I don't think it's too late, there should be several months > until the freeze, and I think if we wanted to switch we could perhaps > do a staged transition and see how it goes and only do the final > replacement if everything seems fine. We do OTOH package more software than most distros on more architectures so we got a lot more exposure for testing coverage, and the revert would involve switching the entire implementation which complicates things a bit compared to a risky patch within a package. I'm not totally opposed, and if everything goes smoothly we could definitely implement it within the timeframe, but it feels like an impactful change to introduce now not having considered it sooner. > (perhaps) exceeding changed circumstances. But given your mail, I'm > happy to work on this again and start with say uploading some initial > stuff into experimental for example, after this thread settles a bit? > (I'll start by refreshing the packaging first though.) Sure. > > Does anyone have thoughts on this? > Personally, I think fully migrating from zlib to zlib-ng would sound > great (even for trixie), but I guess we can take it slow if you do not > feel confident or have concerns over this. > Also if you'd prefer to take over the zlib-ng ITP, as a continuation > of zlib, that'd seem fine with me too. I'm fine with you carrying on with it (actually there is some slight non-technical complication for me with doing it myself), or we could also consider a packaging team. I think there was some other interest in helping out but ICBW. If you're packaging it I'm also more confident in letting you worry about how risky it is to transition and deal with any fallout! :P signature.asc Description: PGP signature
Re: Supporting alternative zlib implementations
On Wed, Sep 25, 2024 at 09:36:31AM +0900, Charles Plessy wrote: > Le Tue, Sep 24, 2024 at 03:58:10PM +0200, Mark Brown a écrit : > >zlib-ng: https://github.com/zlib-ng/zlib-ng > Hi Mark, just out of curiosity, would the carbon footprint of Debian be > lower or higher after replacing zlib with zlib-ng? You could probably calculate it either way depending on how you want to make up the numbers; running faster will take less time but larger outputs might take more storage. signature.asc Description: PGP signature
Supporting alternative zlib implementations
A recurrning question with the zlib package in Debian is interest in the various alternative zlib implementations that are out there. There was a long period where upstream zlib development seemed very stalled, during that period people who wanted improvements started forking their own projects. The main ones I'm aware of are: zlib-ng: https://github.com/zlib-ng/zlib-ng chromium: https://chromium.googlesource.com/chromium/src/third_party/zlib zlib-ng seems pretty healthy, the chromium fork is less generally active but is used by Chrome/ChromeOS which is a big userbase. The main thing people seem excited about is performance work for modern platforms though both projects have been doing other work on the code. Unfortunately it looks like there is little interest in bringing these forks together in spite of zlib's upstream development having picked up a bit again. Fedora did a transition to zlib-ng relatively recently, in version 40: https://fedoraproject.org/wiki/Changes/ZlibNGTransition https://packages.fedoraproject.org/pkgs/zlib/zlib/ https://packages.fedoraproject.org/pkgs/zlib-ng/zlib-ng/ In the past I've pushed back on doing anything here since zlib is essential and it seemed better to be consistent over the ecosystem than to use a more niche implementation, and some of the early optimisation efforts had not worked well on CPUs other than their immediate targets. However given the user feedback and looking at the Fedora experience I think it might be time to reevaluate that. Obviously it's far too late to do anything with the default for trixie, we might want to evaluate doing something after the release but for now it's too late. There's been some ongoing discussion (which sadly I wasn't looped into most of) of zlib-ng in WNPP: https://bugs.debian.org/1002056 with some packaging done, but not AIUI building the zlib compatible ABI for zlib-ng yet which would allow it to be used as a replacement. Adding support for the compatible ABI allowing it to be an alternative for standard zlib seems to me like an obvious step we could take, it would need a lot of care given that zlib is essentially but would let people get zlib-ng if they wanted, and if there are problems it can be held in unstable (or experimental) to avoid impact on trixie. This would allow people to kick the tires. Does anyone have thoughts on this? signature.asc Description: PGP signature
Re: Thinking about a "jessie and a half" release
On Tue, Jul 05, 2016 at 10:52:37AM +0200, Ben Hutchings wrote: > On Tue, 2016-07-05 at 10:07 +0200, Mark Brown wrote: > > We're getting to the point where there's a fairly pressing need for > > arm64 - the more useful hardware is starting to get a wider distribution > > and we don't really have anything for people who want to run Debian > > that gets them a supported system with an upgrade path. > I'm not questioning whether it would be good to have this now. But we > don't have it now and won't have it for some time. So long as it's substantially before the next release it shuld still be useful. signature.asc Description: PGP signature
Re: Thinking about a "jessie and a half" release
On Mon, Jul 04, 2016 at 07:05:42PM +0200, Ben Hutchings wrote: > On Mon, 2016-07-04 at 14:01 +0100, Steve McIntyre wrote: > > A lot of arm64 machine users would benefit from this, and maybe owners > > of very recent amd64 machines too, with better support for things on > > the Skylake platform. Those are the only two architectures I'm > > thinking of supporting at this point. > > Is anybody else interested in helping? Thoughts/comments? > When do you anticipate this would be releasable? Would it really be > long enough before stretch, to be worthwhile? We're getting to the point where there's a fairly pressing need for arm64 - the more useful hardware is starting to get a wider distribution and we don't really have anything for people who want to run Debian that gets them a supported system with an upgrade path. signature.asc Description: PGP signature
Re: Unauthorised activity surrounding tbb package
On Sun, Jan 18, 2015 at 10:09:34AM +0100, Andreas Tille wrote: > On Fri, Jan 16, 2015 at 04:48:33PM +, Steven Capper wrote: > > we have had no discussion > > over #773359; your response is effectively placing words in my mouth > > and I will not tolerate that. To confound matters, I wasn't even CC'ed > > in on the response! > Usually it is expected that the maintainer receives every posting to the > bugs of the package he maintains. So there was no real point to add an > additional CC. The followups were sent to -submitter which unfortunately explicitly doesn't CC the maintainer (I guess the main intended use case is for the maintainer to talk to the submitter), an extra CC needs to be added to include the maintainer. signature.asc Description: Digital signature
Bug#731349: ITP: sparse -- Semantic parser for C
Package: wnpp Severity: wishlist Owner: Mark Brown * Package name: sparse Version : 0.4.5 Upstream Author : Christopher Li * URL : https://sparse.wiki.kernel.org/index.php/Main_Page * License : MIT Programming Lang: C Description : Semantic parser for C Sparse, the semantic parser, provides a compiler frontend capable of parsing most of ANSI C as well as many GCC extensions, and a collection of sample compiler backends, including a static analyzer also called "sparse". Sparse provides a set of annotations designed to convey semantic information about types, such as what address space pointers point to, or what locks a function acquires or releases. Sparse used to be licensed under a non-free license but has recently been relicensed under a MIT license. -- 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/20131204140344.27569.70359.report...@debutante.sirena.org.uk
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Sat, Nov 16, 2013 at 11:37:00AM -0800, Russ Allbery wrote: > Emacs vs. XEmacs is a little like the perpetual vim vs. nvi argument. > They work differently. Which is "better" can be a matter of opinion, > speaking as an nvi user who can't stand vim despite the fact that vim > clearly does more and nvi is in deep-freeze maintenance mode. If you're > used to one of them, switching to the other one is painful. > If someone proposed to remove nvi from the archive because vim is better, > I would be quite annoyed. If it ever did get removed from the archive, I > would probably adopt it and reintroduce it, because nvi is the editor that > I'm used to for small files and for root editing tasks, I want to keep > using it, and none of the things that are wrong with it are fatal for that > usage. The above pretty much exactly encapsulates what made me do this, the release critical bugs in XEmacs seem easier to deal with than the effort of changing and the other bugs aren't an issue for me (and seem to be coming in at a very low rate). It's possible that at some point Wayland will mean that I'll need to bite the bullet and find another editor, but not today. signature.asc Description: Digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Sat, Nov 16, 2013 at 07:07:21PM +0100, Andreas Tille wrote: > This is what Paul did: When writing just a single sentence it might be > reasonable to derive from a role which is good in general but not > helpful in specific cases. Please try to make reasonable > top-posting-bashings if necessary, not in every case to people who are > known to behave correctly. Generally people who do do the right thing but have some reason not to will mention their reason when they > > Technically, there are no outstanding RC bugs, all bugs were closed when > > it was removed. > Nice trick to wait for removal of a package to let a bucket of bugs > vanish and start from scratch. This is wasting the time of previous bug > reporters. There was a lot of time to fix those long standing bugs if > there would have been any interest in the package and I perfectly share > Paul's point. Had I been aware that there was a problem with the package prior to it being removed I'd probably have done something about it, ideally prior to the wheezy release or at least prior to removal from sid. This would have enabled me to skip this thread, delightful though it is. As it was it was sitting running quite happily and rc-alert doesn't seem to work for me so I had no idea there was a problem. > > Furthermore, is it not usual practice for ftp master to comment on > > actual packages, rather than theoretical ones? an ITP is "intent to > > package". There's no package to critique yet! > Ftpmaster had just work to do on the removal (probably not much work) > and if I would be ftpmaster and see an ITP of a just removed package I > would be seriously wondering if people want to play some not so funny > game with me. Our processes for advertising the pending removal of packages aren't that great, sadly - this isn't the first time I've noticed something had a problem only because it vansihed. signature.asc Description: Digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Sat, Nov 16, 2013 at 01:30:01PM +0100, John Paul Adrian Glaubitz wrote: > On 11/16/2013 01:10 PM, Mark Brown wrote: > > Your assertations here both seem rather strong and unsupported, > > especially the idea that people don't use Emacs in graphical mode - it > I have yet to see someone who does. I'm a long-time emacs user > and so are many of other developers I work together with and everyone > I know of who uses emacs as their primary editor doesn't use X11 > support, you just don't need it in most cases. emacs is powerful through > it's keyboard shortcuts and you are much more efficient and > faster when using them as opposed to navigating through the > menus with your mouse. There are other users who do use graphical mode, indeed I was reminded at the mini-Debconf today that the main reason XEmacs got forked was that GNU Emacs was too resistant to implementing a GUI. I guess some people use menus or whatever but I expect you'll find it's mostly just to make it look pretty and smoother interaction with other programs. > Well, as I said, if you're really using emacs for what it's renown > for, you don't care about the X11 user interface and the looks > because you use non-windowed mode anyway. There's no cause and effect there, and if the GUI really was inessential for editors we ought to disable it for them in Debian since it's at best a waste of time to compile it and a potential source of bugs. > If someone is so keen to actually prefer XEmacs over emacs, they > can just download and build the package from source. This does apply to most of the software in Debian of course... Debian has always had a kitchen sink approach to including things, we do have quite a few architectures as well for example and I'm not sure that our position as the leading platform for languages such as brainfuck is considered critical by many. > > At the end of the day if you're not interested in a leaf package just > > ignore it, work on something you do care about instead. > No, I do care about the whole of Debian and not just about my particular > packages and honestly, it bothers me to no end when I see packages which > have dozens or hundreds of bugs unanswered because no one is stepping > in to fix that. And I think Paul feels the same. I rather prefer to > have a package removed than it being full of bugs, no matter whether > it's a leaf package or not. Well, there do seem to be a lot of bugs open against the Linux kernel... > A constant quality control of Debian as a whole is important as a whole > for being able to reduce the freeze time as we have learnt in the past. The things that make a meaningful difference to the freeze time are (or should be) the packages that we can't get rid of for whatever reason and the packages that sit in the middle of dependency chains. signature.asc Description: Digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Sat, Nov 16, 2013 at 12:01:48PM +0100, John Paul Adrian Glaubitz wrote: > On 11/16/2013 11:43 AM, Mark Brown wrote: > > It's a package that we've carried since forever and which has a > > userbase. > That's not really an argument. We've also had uae and e-uae It is an argument; it might be one with which you disagree but that's not the same thing at all. > Your first mail came with the argument that you think that > xemacs is more visually appealing than emacs. Honestly, emacs > is primarily a tool and not an optical gimmick. Visual > appearance does not bother most users, I'd guess. Most emacs > users use the terminal (-nw) mode anyway. Your assertations here both seem rather strong and unsupported, especially the idea that people don't use Emacs in graphical mode - it would be enormously surprising to me if people had abandoned X11 support en masse. As for people not caring about the appearence... if you're going to be looking at something for the best part of the day it seems strange that you'd not be interested in how it looks, it's a factor in usability. > And the beef I have with xemacs is that it's development > has factually ceased. Looking at the changes over the past > months, I see only marginal changes [1] but no real development. > I never think that's a good idea to upload packages to Debian > where virtually no upstream development is taking place. The > risk of RC bugs not getting fixed in time is simply too high. > I remember fixing RC bugs in several packages in Wheezy during > the freeze where upstream was no longer available and we had > to dig through the code and fix the bugs ourselves. I want > to avoid such situations in the future! We can always drop packages if they're too buggy; indeed it turns out we did that for XEmacs in the last release (which I only noticed after release sadly, much to my distress when I installed a new desktop recently). Besides, the risk here seems low, it's not a package that's using bleeding edge or rapidly developed interfaces that are likely to change underneath it and obviously Debian's tendency to work with older versions of software for extended periods means that we have to accept that even an active upstream might not care about supporting us. At the end of the day if you're not interested in a leaf package just ignore it, work on something you do care about instead. signature.asc Description: Digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 09:49:49PM +, Dmitrijs Ledkovs wrote: > Why should Debian carry this package? It's a package that we've carried since forever and which has a userbase. > Which virtual packages are you planning to provide? The same set as the package previously did: emacsen, info-browser, mail-reader, news-reader, www-browser. signature.asc Description: Digital signature
Bug#729717: ITP: xemacs21-support -- highly customizable text editor -- architecture independent support files
Package: wnpp Severity: wishlist Owner: Mark Brown Package name: xemacs21-support Version : 21.4.22 Upstream Author : XEmacs team URL : http://www.xemacs.org/ License : GPL and others Programming Lang: elisp Description : highly customizable text editor -- architecture independent support files XEmacs is a full fledged programming language with a mail reader, news reader, info browser, web browser, calendar, specialized editor for more programming languages and other formats than most people encounter in a lifetime, and much more. . Support and architecture independent files for XEmacs 21.4.22. This includes the files found in etc and all required elisp library files (mostly compiled (.elc files), but a few uncompiled (.el files)). -- 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/20131115175016.27342.78922.reportbug@finisterre
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 05:05:31PM +, Jonathan Dowland wrote: > Furthermore, is it not usual practice for ftp master to comment on > actual packages, rather than theoretical ones? an ITP is "intent to > package". There's no package to critique yet! Actually I'm starting from the previous packaging so I'll inherit any issues - there's quite a few things I want to change but it seems the simplest way to start is to do that and work incrementally to fix the stuff that doesn't need fixing immediately. signature.asc Description: Digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 10:39:46AM -0500, Paul Tagliamonte wrote: > On Fri, Nov 15, 2013 at 03:25:16PM +0000, Mark Brown wrote: > > On Fri, Nov 15, 2013 at 10:06:37AM -0500, Paul Tagliamonte wrote: > > > Before you put this in NEW, how do you plan on fixing the outstanding RC > > > bugs? > > By making changes to the software. > No need to CC me, I'm subscribed. Seems to be due to you setting Reply-To. > This doesn't fill me with confidence that any of the reasons that it was > removed will be fixed. > I'd have to look at the RC bugs, but it's not out of the question that > would get xemacs a REJECT from NEW if they're not handled. At first > glance, #695799 appears to be one such bug. That's a bug in a different package which I didn't ITP (or look at) yet, it's just GFDL docs so the simple fix would obviously be to remove the offending files. There's only one RC bug in xemacs21 itself which I've been able to see (a build fail with texinfo5) which is just a matter of typing to fix. > so, again, how will you fix the open bugs before you upload to > NEW? Which bugs are you planning to fix? > I'm looking for a hard commitment here, Mark. My general approach to these things is to fix bugs as I go. I don't have any particular plan for how I'm going to fix things I've not even looked at or looked for yet but given the lack of either development or massive changes in the underlying platform I would be astonished if there were anything insurmountable - the thing that was causing issues before was that Ohura-san wasn't spending time on the package. It's going to be quicker and simpler to actually fix the problems than to go through and make an exhaustive list and analyse them, as Lars suggested please do assume I'm going to make some reasonable effort to not upload obviously broken stuff. signature.asc Description: Digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 10:06:37AM -0500, Paul Tagliamonte wrote: > Before you put this in NEW, how do you plan on fixing the outstanding RC > bugs? By making changes to the software. signature.asc Description: Digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 09:17:34AM -0500, Paul R. Tagliamonte wrote: Don't top post. > Out of curiosity, how do you plan on solving it's six rc bugs? Yes, of course. Well, the one that was there when I looked is fixed, I'll see if the BTS tells me about any open ones after the reupload. signature.asc Description: Digital signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Fri, Nov 15, 2013 at 01:29:50PM +0100, Alberto Garcia wrote: > On Fri, Nov 15, 2013 at 12:02:18PM +0000, Mark Brown wrote: > > * Package name: xemacs21 > > Version : 21.4.22 > Wasn't this removed just one month ago? Yes, this is why I'm ITPing it. signature.asc Description: Digital signature
Bug#729660: ITP: xemacs21 -- highly customizable text editor
Package: wnpp Severity: wishlist Owner: Mark Brown * Package name: xemacs21 Version : 21.4.22 Upstream Author : XEmacs development team URL : http://www.xemacs.org/ License : GPL Programming Lang: C, elisp Description : highly customizable text editor XEmacs is a full fledged programming language with a mail reader, news reader, info browser, web browser, calendar, specialized editor for more programming languages and other formats than most people encounter in a lifetime, and much more. While develoment on xemacs is very slow these days I find it much more visually pleasing than GNU emacs. -- 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/20131115120218.16184.65842.reportbug@finisterre
Re: EFI in Debian
On Sun, Jul 08, 2012 at 07:30:48PM -0400, Ted Ts'o wrote: > So in answer to your question, there are plenty of Android devices > which are trivially unlockable. (And once a Nexus phone is unlocked, > it's you can get a root shell trivially; no jail-breaking necessary. > Of course this is true for an attacker/thief who has managed to steal > your phone, but if you want to unlock the phone, it's easily doable on > many Android devices.) Note that the unlock process wipes the data on the phone which does provide some security here. -- 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/20120717162018.ga8...@sirena.org.uk
Re: zlib and biarch/triarch
On Tue, May 22, 2012 at 12:14:49PM +, Thorsten Glaser wrote: > Seeing the trouble broonie has with zlib, why are those > packages still built anyway? Can???t they please go away? The biarch packages really aren't any bother, the issue with s390x has been having to jump through hoops due to the fail with using -m31 and with the naming of the architecture. -- 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/20120528162617.ge27...@sirena.org.uk
Re: zlib and biarch/triarch
On Tue, May 22, 2012 at 05:06:25PM -0700, Steve Langasek wrote: > Of course, all of these packages appear to be specific to amd64, so I don't > know why Mark would be adding new biarch packages for s390. You should > probably ask him. Ask the s390x folks, they asked for them. Though what on earth inspired them to name the new architecture such that the old architecture name is a substring of the new name is beyond me... As far as I can tell nobody is really using the biarch packages on most architectures, it's a check box feature for the architectures - a couple use them to build some of the bootloaders but not many. Aside from this sillyness with the s390x architecture name they're generally zero effort so it's not a big deal. -- 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/20120528162456.gd27...@sirena.org.uk
Re: Why is help so hard to find?
On Fri, Jan 14, 2011 at 04:52:13PM -0800, Russ Allbery wrote: > Roger Leigh writes: > > Yes, and this is what I did. It's just rather tedious to (IIRC) > > repeatedly run "dpkg-reconfigure sysv-rc" and then find out which file > > is offending, run "dpkg -S $file", and then purge it. > I've not looked at the mechanism involved at all, but it does seem like we > should be able to print out all of the files that would cause failures. > Maybe it's hard to continue from an error long enough to find additional > files? It'd also be *much* nicer if it were possible to do the checks outside of dpkg-reconfigure, especially if you're using a frontend that doesn't make cut'n'paste easy. -- 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/20110117115818.ga3...@sirena.org.uk
Bug#606493: gnome-screensaver: Fails to authenticate users with NIS on amd64
On Thu, Dec 09, 2010 at 09:16:05PM +0100, Josselin Mouette wrote: > Le jeudi 09 d??cembre 2010 ?? 19:38 +0000, Mark Brown a ??crit : > > I'm not sure why you believe this is an issue in NIS? > I???m not sure why you believe this is an issue in gnome-screensaver > either. It's the root of the pam configuration here, and it's also where the bug was reassigned from. -- 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/20101209203500.ga30...@sirena.org.uk
Re: Squeeze Artwork: selection of default theme
On Sat, Nov 13, 2010 at 11:22:51AM +0100, Petter Reinholdtsen wrote: > [Mark Brown] > > Honestly I'd have expected something like this to show up on -devel, > > or at least -devel-announce, at some point. > And I do not expect it, I must admit. Everyone do not get a say on > most decisions made in Debian, and this is a good thing to speed up > development and keep the overhead of decisions low. This time you > (and I) did not get to provide input on the visual profile for > Squeeze, but a lot of people were involved in the process and I trust > them to do good work. I see no need for a rematch, nor any need to > try to overrule those doing this work. I believe it is well within > the scope and authority of the desktop group to make such decision, > and am happy there are people working on the visual profile in Debian. It's something that's apparently controversial within the team working on it, has a rather noticable impact on the distribution and is getting changed when we're considerably into the freeze. All of these things point to being cautious about changes and consulting widely, especially the late in the freeze bit - this is going to make it extremely difficult to deal with any issues that might be noticed. -- 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/20101115141626.gd3...@sirena.org.uk
Re: Squeeze Artwork: selection of default theme
On Fri, Nov 12, 2010 at 12:26:01PM +0100, Yves-Alexis Perez wrote: > On ven., 2010-11-12 at 10:37 +, Steve McIntyre wrote: > > In terms of the artwork choice itself (SpaceFun), I've seen a lot of > > comments along the lines of "looks like something even my kids would > > reject for looking too childish". I wouldn't go quite that far myself, > > but I can understand the sentiment. :-( > > Please check again with a wider audience. > I really think things could have done better. I think things could have > done better since 3 releases, to be honest. Now nobody hide the fact > that Debian artwork work is done on debian-desktop list (since 3 > releases at least). Everybody could have sent his opinion *before*. This is the first time I've heard of the -desktop list. > We're running out of time since quite some time already, we need to get > this done *now*. This is the first time I became aware that there was a need for a new theme; I've never personally had much problem with our current theme (I use it unmodified on most systems, or sometimes change the background) or heard any grumbling about it. > But, once again, I don't think ???a wider audience??? is needed. In my > opinion, interested people *need* to take part in the work, give some > time, give some interest in the long run and not just in the final word > (a bit like everything else in Debian). And (again) those people are > really welcome on -desktop list and packaging team. Honestly I'd have expected something like this to show up on -devel, or at least -devel-announce, at some point. -- 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/20101112132848.gb28...@sirena.org.uk
Re: About new source formats for packages without patches
On Sun, Mar 28, 2010 at 09:02:24AM +0200, Christian PERRIER wrote: > I'm surprised by the resistance I see to these changes. I see the > approach pushed by dpkg maintainers as fairly conservative with very > progressive changes to existing packages and much respect for people > who don't want to adopt the "new" source format. > The currently debated change is to kindly suggest to maintainers who > prefer sticking with 1.0 source format to mention this explicitely in > their source tree. I really fail to see what is the burden in this. Part of the issue here is that this was a default enabled lintian warning (it's not any more, but it was). Since a lot of people like to keep their packages lintian clean this comes over as somewhat more urgent than what you're suggesting above. -- 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/20100329094514.ga13...@sirena.org.uk
Re: About new source formats for packages without patches
On Thu, Mar 25, 2010 at 11:13:01AM -0700, Russ Allbery wrote: > The long tag description probably could be improved to make it clearer > that the intention isn't to be a cudgel. Unfortunately pretty much any lintian warning ends up being a cudgel if it's enabled by default since zero lintian warnings is such a common goal. -- 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/20100326103221.gb27...@sirena.org.uk
Re: About new source formats for packages without patches
On Thu, Mar 25, 2010 at 05:19:41PM +0100, Benjamin Drung wrote: > Why is there no dak and wanna-build package? Are there plans to create > such packages? There used to be a dak package but it ended up lagging very badly behind the actual dak code because it needed some database schema upgrades as time went on and these are very difficult to manage in a robust fashion in a package. Nobody ever had the time to do the updates and the package was so bitrotted that it was felt safer to remove it rather than mislead people into doing new installations with it. -- 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/20100326102549.ga27...@sirena.org.uk
Re: About new source formats for packages without patches
On Thu, Mar 25, 2010 at 04:07:59PM +0100, Raphael Hertzog wrote: > For zless, people seem to open the debian.tar with vim or similar but I > can understand that it's less usable than a simple pager view of the > relevant files. Maybe it's a good idea to provide a debreview/debinspect > command in devscripts that would show the files in debian/ in a > standardized order that facilitates the review? This is only really helpful on systems with Debian tools installed - speaking personally my one of my most common use cases for inspecting the Debian diff with less is to do so on random systems I don't admin (or ask other people who don't have anything to do with Debian to do so). -- 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/20100325151308.gb7...@sirena.org.uk
Re: Xen, Squeeze, and Beyond
On Fri, Feb 26, 2010 at 11:18:41AM +0100, Goswin von Brederlow wrote: > But the pv-ops xen kernel is shaping up well and that is what Bastian > Banks is working on. They have a proper upstream and follow the latest > vanilla kernel well enough. According to the wiki the plan is to have > pv-ops merge into vanilla with 2.6.34. I just took a quick look at linux-next (which *should* have everything for 2.6.34 in it) doesn't show anything that looks obviously like this, though I only looked briefly. -- 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/20100226103536.gb31...@sirena.org.uk
Re: Debian Mobile -- Debian GNU/Linux for mobile devices
On Wed, Feb 17, 2010 at 07:13:41PM +0100, Julian Andres Klode wrote: > Am Mittwoch, den 17.02.2010, 16:13 +0100 schrieb Bastian Blank: > > On Wed, Feb 17, 2010 at 03:53:32PM +0100, Julian Andres Klode wrote: > > > Is anyone interested in starting a Debian Mobile project, probably as a > > > Debian Pure Blend? > > You want to start with em-debian. > MeeGo is not really embedded, having a netbook UI and a handheld UI. The > devices also have multiple GB of storage. My phones and (even more so) MP3 players have had that sort of storage space for some considerable time; form factor is probably more of a useful distinction here than any performance specs. -- 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/20100217184202.gh2...@sirena.org.uk
Re: why are the watchdog drivers blacklisted?
On Tue, Feb 09, 2010 at 12:57:29PM -0200, Henrique de Moraes Holschuh wrote: > On Tue, 09 Feb 2010, Michael Meskes wrote: > > This looks like a workaround for some other problem to me. Patting at 0.1Hz > > should be sufficient if the kernel expects a change at 0.016 Hz. I don't > > have > > any report about a spurious reboot, but if you do have some I'd like to > > learn > > more about it to see where this problem stems from. > The kernel drivers don't always expect pats at 0.016Hz by default. Some > drivers have different defaults, and as far as I recall, some of them > default to whatever the BIOS or BMC programmed in the watchdog. This is definitely the case for embedded drivers, they'll generally inherit the configuration that the hardware has. For many devices a timeout as long as 10s may not even be possible in the hardware. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why are the watchdog drivers blacklisted?
On Mon, Feb 08, 2010 at 03:51:24PM +0100, Michael Meskes wrote: > On Mon, Feb 08, 2010 at 04:45:53AM +0100, Marco d'Itri wrote: > > (BTW, is there any other watchdog daemon? The watchdog package reliably > > fails to detect when the system is half-killed by OOM.) > How about explaing your problem a little bit better and, if it's really a > failure in watchdog, reporting a bug? What exactly did you do? And how did you > configure watchdog? The core problem with watchdog WRT stuff like that that is that it's a fairly small program and doesn't monitor the state of the rest of userspace so there's error conditions like being deep into swap which make the actual application unusable but don't stop watchdog soldiering on. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why are the watchdog drivers blacklisted?
On Fri, Feb 05, 2010 at 10:11:25AM +0100, Petter Reinholdtsen wrote: > [Marco d'Itri] > > I maintain the package providing it, but I fear it is the result of > > cargo cult sysadmining. A driver will not engage the watchdog > > anyway until /dev/watchdog is opened. > If I remember correctly, the reason is that the observed behaviour is > that a driver sometimes will engage the watchdog without /dev/watchdog > is opened, triggered by one driver starting without anyone touching > /dev/watchdog. This caused the installer to stop after 1 minute. I > do not remember any more details. This was discovered a few years > ago, and I hope that crazy driver has been fixed in the mean time. That's just a buggy watchdog driver, though (unless the problem was really that the watchdog was already enabled by the hardware prior to startup, but then not loading the driver isn't going to help anything). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Apparent portmap to rpcbind transition?
On Mon, Jan 04, 2010 at 02:45:27PM +, Mark Brown wrote: > As discussed by a number of people in bug #562757 it appears that > nfs-kernel-server has kicked off a transition to the use of rpcbind - at > least, nfs-kernel-server has switched to needing rpcbind and we can't > have two things claiming the portmap port. Since a number of packages > currently rely on portmap (list based on rdepends below) this is likely > to require a transition of some kind. > I've not seen any discussion of how this is supposed to work, or any > mention of the planned transition before it broke my systems. There's > quite a few bugs in ONCRPC related packages related to the current state > but none of them seem to have a summary of what the intention is - does > anyone have any information here? Any updates on this? Are we switching portmappers, and if we are how are we doing so? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Apparent portmap to rpcbind transition?
On Thu, Jan 07, 2010 at 07:17:16PM +0100, Alexander Wirt wrote: > Ehm, the reason was a bug. nfs-common was broken, if connecting to localhost > it was only trying ::1, but without a fallback on 127.0.0.1. > There wasn't any indication in the package that this breakage was on purpose. > I guess it was just bad testing. > The NMU is in delayed/1 and should hit unstable in a few hours. Sure, but my main point is that looking at the package meant I noticed that it's now added rpcbind as an alternative portmapper. That's something which we should be doing over the entire distribution rather than in a few packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Apparent portmap to rpcbind transition?
On Thu, Jan 07, 2010 at 01:52:43PM +0100, Guus Sliepen wrote: > I see that nfs-common depends on portmap | rpcbind. However, nis only depends > on portmap, and can therefore not be installed at the same time as rpcbind. Yes, this is the root of the issue - if we're changing what we're doing with portmappers what's the plan for managing this. What should be the default, is the old portmap going away and so on. At the minute there's been no coordination at all, the first time I heard of rpcbind was when I was resolving the NFS breakage. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Apparent portmap to rpcbind transition?
As discussed by a number of people in bug #562757 it appears that nfs-kernel-server has kicked off a transition to the use of rpcbind - at least, nfs-kernel-server has switched to needing rpcbind and we can't have two things claiming the portmap port. Since a number of packages currently rely on portmap (list based on rdepends below) this is likely to require a transition of some kind. I've not seen any discussion of how this is supposed to work, or any mention of the planned transition before it broke my systems. There's quite a few bugs in ONCRPC related packages related to the current state but none of them seem to have a summary of what the intention is - does anyone have any information here? Daniel Baumann doodle (U) Mark Brown nis Tim Cutts am-utils Debian QA Group unfs3 Alberto Gonzalez Iniesta netkit-bootparamd netkit-rusers netkit-rwall No??l K??the drac Chuan-kai Lin fam Robert Luberda rlinetd Ola Lundqvist harden Debian GNUnet Maintainers doodle Michael Meskes quota Anibal Monsalve Salazar nfs-utils rstatd Miquel van Smoorenburg nis (U) Geert Stappers p3nfs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Xen support on Squeeze
On Sun, Jan 03, 2010 at 09:42:53PM +0300, William Pitcock wrote: > > That was opposed quite strongly by the kernel folks last time it was > > attempted. Were there any fundamental changes in the Xen dom0 patches > > since then? > Only by the kernel folks which believe all of the crap that the KVM > guys say about Xen. There are plenty of kernel developers willing > to see the patches merged. That didn't seem massively clear the last time I looked at one of those threads - the primary issue was the invasiveness of the patches which most people would be able to assess for themselves. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the kernel team
On Mon, Dec 21, 2009 at 01:56:05AM +, Ben Hutchings wrote: > On Mon, 2009-12-21 at 09:24 +0800, Paul Wise wrote: > > I guess oss4-dkms will be enough to take care of these users, > > hopefully it will reach squeeze in time. > Hopefully not. OSS4 on Linux is part of the problem, not part of the > solution. Linux applications should not use /dev/dsp any more. Those > that do may be handled by some kind of bridge to ALSA, which was what Something CUSE based, for example, or one of the existing LD_PRELOAD hacks. Replacing the OSS emulation with something that throws the data back out to userspace would also work, I guess. > this item refers to. (The existing snd-pcm-oss and snd-mixer-oss don't > seem to be good enough.) Specifically since they are in kernel they don't (and can't really) play at all with any userspace ALSA stuff such as DSP, PulseAudio or the various network and wireless I/O drivers that are implemented in userspace. They also cause pain for the standard ALSA drivers since the mismatch between the OSS and ALSA configuration APIs results in ALSA drivers having to jump through hoops for the benefit of the OSS emulation, and the OSS configuration model is just too limited to express the control available on many modern systems. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian as open project
On Fri, Dec 04, 2009 at 07:54:51AM +0100, Luk Claes wrote: > Stefano Zacchiroli wrote: > > First of all an objection to the basic principle: the fact that the > > project "does not seem" to be able to have constructive discussion is > > not an argument for not having them. I believe that given your role you > > should show *how* to have such (public) constructive discussions, using > > all mean necessaries, instead of avoid trying. > Sorry, but trying to have a constructive discussion in between > complaints, hijack scenarios and ill informed suggestions does not look > very tempting to me and quite frankly I don't know how to make such a > discussion constructive. On the other hand part of the reason things are so heated is that there's no visible progress on resolving these issues and hasn't been for quite some time. This is a problem which we've run into before in Debian and so far the only thing I can think of that's had some sort of success in reducing the heat in the discussion is visible activity on resolving things. This may mean that we just have to put up with the heat, of course. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On Wed, Nov 18, 2009 at 11:40:52PM +0900, Charles Plessy wrote: > If we mean to attract such users, I do not think that the best strategy would > necessarly be having a pre-existing MIPS support of bioinformatics, which I > think is completely beyond our reach and expertise. I think that what would > matter would be to have a healthy MIPS port on one side, and be the best > distro > for bioinformatics on mainstream platforms on the other side. This would be a > solid basis to start a collaboration to become a good bioinformatics distro on > MIPS. Just because we can build packages is not the best indicator: most of > them > have no regression tests yet, and a significant number of the build failures > I experienced on my packages happen during such tests??? It's a bit worrying that the software requires noticable porting effort in the first place - often that's a sign of general fragility which will also manifiest itself on supported arches sooner or later. > So in conclusion (like a broken disk), with a simple modification of > dpkg-gencontrol, we can stop building on some architectures some packages > which > bring them no added value. For new packages, that seems to be enough. For > existing packages, maintainers who want to opt-out of some architectures would > need to submit a patch against the packages-arch-specific file and sumbit a > bunch of dak commands to the release file. This could be consolidated in > batches and I can help for this, so that the work load is minimum, compared to > the gain for everybody. The flip side of this is that it's just inviting maintainers to decide they can't be bothered with porting effort and leaving ports as second class citizens. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Oct 27, 2009 at 05:51:12PM -0700, Ryan Niebur wrote: > I prefer "Author(s)". Less text to update when a new author is > added. It does no harm and affects nothing in the end result. I'm > curious as to why you think "Author(s)" is a bad thing? It's the sort of thing you get in automatically generated text where the programmer hasn't bothered to figure out if something is a plural or not. Like I say, I don't think it's serious in itself but it seems wishlist. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Oct 27, 2009 at 03:59:52PM -0700, Ryan Niebur wrote: > I completely disagree with this lintian warning and prefer to use > "Author(s)". I do agree that rejecting on this is probably excessive but I'm curious as to why you think it's incorrect? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Explicitely Cc bug reporters
On Thu, Sep 10, 2009 at 05:08:00PM +0200, Pierre Habouzit wrote: > Not the reverse. This is a major (if not _THE_ major) annoyance with the > BTS. FWIW this is a long discussed issue, and the BTS maintainers do not > share this opinion (that mailing @ should also mail the submitter) > so we're basically stuck. Incidentally, this also results in breakage with things like WNPP (which aren't really idiomatic uses of the BTS but anyway). Mostly the person who filed an ITP/RFA should get notified about activity since they are effectively the maintainer but currently that doesn't happen. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Explicitely Cc bug reporters
On Thu, Sep 10, 2009 at 10:04:19AM -0500, Kumar Appaiah wrote: > On Thu, Sep 10, 2009 at 03:43:16PM +0100, Mark Brown wrote: > > What would be really useful here is the ability to set up the BTS to > > subscribe you to bugs you've filed by default. That avoids the issue > > with confusing less technical users. > To be more specific, we should have a pseudo-header like > Subscribe: yes > which would allow me to subscribe to the bug during submission. This > way, we avoid all issues of forcing users to see the BTS mail > exchanges, and allow the brave ones to participate without explicit > subscription. It'd be nicer to be able to store this server side - having to set it up on each system would be a pain. Obviously more work for the BTS, though. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Explicitely Cc bug reporters
On Thu, Sep 10, 2009 at 09:32:55AM -0500, Kumar Appaiah wrote: > On Thu, Sep 10, 2009 at 04:21:50PM +0200, Bernhard R. Link wrote: > > But reporters are sacrifing some of their time to help us make our > > distribution better. Do you really think we should scare them away > > by rewarding bug reports by pulling the reporters in lengthy > > discussions how the bug is best fixed? > This is subjective. I know of several bug reporters who would either > be happy to see that their bug is being dicussed/attended to, or even > be able to pariticipate in the fixing efforts if their technical > knowledge falls in the category of that bug. > Just my view, I try to remember to Cc the reporter, but I'd much > rather prefer being subscribed to bugs as I report them. What would be really useful here is the ability to set up the BTS to subscribe you to bugs you've filed by default. That avoids the issue with confusing less technical users. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
On Tue, Jun 30, 2009 at 06:56:11PM +0200, Goswin von Brederlow wrote: > Mark Brown writes: > > Then bring that up and try to move the discussion forward (as now seems > > to be happening). The approach that's currently being pused seems like > > a blind alley. > People really do seem to confuse this. ia32-apt-get is not an > alternative to multiarch. Never has been, never will be. It looks awfully like a bodged version of multiarch - doing what you're doing and installing i386 packages on amd64 appears to be one of the biggest use cases for multiarch, after all. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
On Mon, Jun 29, 2009 at 09:31:24PM +0200, Goswin von Brederlow wrote: > Mark Brown writes: > > There seems to be at least some crossover between the people who were > > looking at multiarch and the people doing this stuff. > But not the people blocking the inclusion of patches for multiarch > already present in the BTS. Then bring that up and try to move the discussion forward (as now seems to be happening). The approach that's currently being pused seems like a blind alley. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
On Mon, Jun 29, 2009 at 06:12:20PM +0200, Norbert Preining wrote: > On Mo, 29 Jun 2009, Mark Brown wrote: > > Multiarch was mentioned in the original thread. > Not that I was happy with the original situation (filing myself a bug), > but all that "multiarch" blabla and nothing is going forward in this > direction, so this is not a reasonable solution until nobody steps > forward and does the work for that. There seems to be at least some crossover between the people who were looking at multiarch and the people doing this stuff. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
On Mon, Jun 29, 2009 at 05:59:32PM +0200, Julien Cristau wrote: > On Mon, Jun 29, 2009 at 17:30:35 +0200, Goswin von Brederlow wrote: > > So strike option 1 and 2 and what are you left with? > Figure out an acceptable option 4. Multiarch was mentioned in the original thread. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Sat, Jun 20, 2009 at 12:44:12PM -0500, Raphael Geissert wrote: > Raphael Hertzog wrote: > * debian/patches/fix_typo.patch: > Fix typo in the main menu: s/setings/settings > I would actually be duplicating the description (the patch name being the > short description, and the changelog entry the long description). > The only piece of information that is missing is the forwarded field; hence > my proposed simplification. Part of the problem here is that the changelog isn't a particularly good place to document the source of the package - it's roughly similar to the situation with normal source code where you'd expect the code to be readable without the changelog to explain it. > All I see here is that the tools should be able to extract the information > from the changelog, which often includes a bug number and other bits of > information. This would work adequately for trivial patches but is likely to have issues if the patch is more involved and needs revisions (for things like upstream changes or as part of making it mergeable). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Wed, Jun 17, 2009 at 12:40:01PM +0200, Raphael Hertzog wrote: > On Mon, 15 Jun 2009, Mark Brown wrote: > > On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote: > > > * `Signed-off-by` (optional) > > For the avoidance of confusion I would suggest that this be changed to > > Reviewed-by - the normal Linux/git Signed-off-by has a specific meaning > > that needn't include actually doing a code review. > I started first with "Reviewed-by" and then thought that it was stupid to > not reuse the name that is already vastly used for a similar purpose. What > do other people think? I'm fine with both names. My point here is that Signed-off-by is widely used for a *different* purpose. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Tue, Jun 16, 2009 at 11:23:17AM +0200, Reinhard Tartler wrote: > "Thijs Kinkhorst" writes: > > above the patch? That works fine for me. Every formalisation has a cost > > and I'm not sure here that it's offset by the (which?) benefits. > Possible benefits (partly mentioned in the spec) > - tools can be adapted/crafted to maintain these fields > - streamline development practice to faciliate team communication > - (web)tools can analyse and produce statistics > I'm looking forward to see prototype implementations of tools that use > patch files formatted this way. I'd also add that having something like this often encourages people to record the information that's standardised by virtue of providing a blank to be filled in. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 11:31:51PM +0200, Carsten Hey wrote: > On Mon, Jun 15, 2009 at 10:15:16PM +0100, Mark Brown wrote: > > On Mon, Jun 15, 2009 at 11:10:14PM +0200, Carsten Hey wrote: > > > I currently don't see a relevant benefit in this above just using the > > > changelog entry, which you need to write anyway. Additional information > > Putting the information in the changelog makes it much harder to find > Yes, putting the information _only_ in the changelog make it much harder > to find, but that is not what I did nor what I proposed. As you can > see, my patch header is a copy of the changelog entry, so you don't even > need to open the changelog file to get all relevant information. You might've wanted to make that more explicit in the message - saying "just use[ing] the changelog entry" gives a different impression. > If an integration of the information in the patch headers into UDD would > be planned which could be used to query patches not applied upstream or > similar, I would at least see a benefit in using a standard header > format. That's the idea - make the data available for software. I'd also expect to see the standard headers encourage the recording of information that gets a standard header, it's certainly helped that in Linux. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 11:10:14PM +0200, Carsten Hey wrote: > I currently don't see a relevant benefit in this above just using the > changelog entry, which you need to write anyway. Additional information Putting the information in the changelog makes it much harder to find when looking at a package source than if it's right there in the patch file - you need to look the patch up in the changelog and if the patch is revised or otherwise changes state over time you need to figure out what the current state is somehow. It's a similar idea to saying that code should be adequately commented - the revision control history should say what's going on too but it shouldn't be essential to reading the code. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote: > * `Signed-off-by` (optional) > > This field can be used to document the fact that the patch has been > reviewed by one or more persons. It should list their names and > emails in the standard format (similar to the example given for > the `Origin` field), separated by commas if needed. For the avoidance of confusion I would suggest that this be changed to Reviewed-by - the normal Linux/git Signed-off-by has a specific meaning that needn't include actually doing a code review. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DEP-5: Please clarify the meaning of "same licence and share copyright holders"
On Sun, Jun 14, 2009 at 04:16:48PM +0100, Noah Slater wrote: > On Sun, Jun 14, 2009 at 04:02:49PM +0100, Mark Brown wrote: > > I think you're missing the point here; my point is that one of the goals of > > pushing this through as a DEP comes over as being about greatly increasing > > the > > pressure on people to adopt it. > I don't know what gives you that impression. At various points, each DEP > driver > has made it explicit that we would like to make the format as broadly useful > as > possible, without suggesting it be mandatory at this stage. Like I say, it's about the impression you're creating. You say these things but the fact that you're using this formal Debian-wide process says something different. The whole thing comes over very differently to "here's something you might find useful". -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DEP-5: Please clarify the meaning of "same licence and share copyright holders"
On Sat, Jun 13, 2009 at 03:03:28PM +0200, Michael Banck wrote: > On Sat, Jun 13, 2009 at 12:28:59PM +0100, Mark Brown wrote: > > It feels like half the problem here is that making it a DEP feels much > > more like something that's being pushed to everyone. If it were going > > through a similar process to debhelper people would probably feel more > > comfortable about ignoring it. > You're a Debian Developer - you have the right to ignore about > everything except release critical bugs in your packages. *sigh* I think you're missing the point here; my point is that one of the goals of pushing this through as a DEP comes over as being about greatly increasing the pressure on people to adopt it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DEP-5: Please clarify the meaning of "same licence and share copyright holders"
On Fri, Jun 12, 2009 at 07:03:40PM -0700, Steve Langasek wrote: > And after all, debhelper didn't need a DEP at all in order to come into > widespread use, so your worst case scenario could equally well come to pass > without ever going through a public discussion process - there are already a > fair number of formatted debian/copyright files in the wild based on nothing > more than a pretty bad wiki draft... It feels like half the problem here is that making it a DEP feels much more like something that's being pushed to everyone. If it were going through a similar process to debhelper people would probably feel more comfortable about ignoring it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff? (was: Re: phyml_20081203-1_powerpc.changes REJECTED)
On Mon, Apr 27, 2009 at 03:03:10PM +0200, Holger Levsen wrote: > On Montag, 27. April 2009, Noah Slater wrote: > > * The Debian lists do not have a Reply-To header, > does someone know why? http://www.unicom.com/pw/reply-to-harmful.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Linux-libre for Debian Lenny
On Mon, Apr 27, 2009 at 01:48:27AM +0100, Ben Hutchings wrote: > On Sun, 2009-04-26 at 21:41 +0200, Robert Millan wrote: > > #494120 and #494122. > [...] > I disagree with these as the tables in question are easily small enough > to be a plausible preferred form for modification. Indeed; this is a *very* common way of expressing register values, especially when working with large numbers of them at once. I've no idea what Robert believes the preferred form of modification is. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: packages' config scripts creating files, chroots and buildds.
On Wed, Mar 25, 2009 at 08:50:29AM -0700, Russ Allbery wrote: > Personally, my first instinct would be to call that an RC bug, but I may > be missing some case where config needs to modify the file system. Given that one of the original goals of all this was to allow the config to be done on a different system to the one the package is being installed on I'd expect not. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: OSS-only applications
On Wed, Mar 04, 2009 at 03:43:47PM +, brian m. carlson wrote: > Yes. Nevertheless, there is a libsalsa that provides a libasound2 > emulation layer for OSS. I'm not aware of whether it has been packaged > or even whether it is suitable, since I don't run GNU/kFreeBSD anymore. It should do the job fine if it works - the application interface for ALSA on Linux is library-only, applications never have any dealings with the ALSA drivers that aren't mediated via libasound2. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Making some tags mandatory
On Fri, Feb 27, 2009 at 11:48:30AM +, Enrico Zini wrote: > - For packages with no tags in the control file, take the tags from the >review tag set as we have now Are packages supposed to do this? If they are it'd probably be worth announcing more generally to let people know it's OK to do this. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should 32-bit apps work with a 64-bit kernel?
On Thu, Feb 26, 2009 at 10:48:35AM +, Roger Leigh wrote: > Agreed. If we can identify all libraries (perhaps with a simple grep over > the lintian lab?) containing these types, and make sure LFS is enabled in > all of them, it should then be possible to switch once all dependencies > are rebuilt. I guess this would need the library packages renaming due to > altering the ABI. Some of these libraries provide ABIs which support both LFS and non-LFS versions - we'd also need to check for those and make sure they can handle being built with LFS defined by default. I do worry that we may end up causing compatibility issues here by surprsing people with changed defaults. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 04:20:28PM +0100, Mike Hommey wrote: > On Mon, Dec 29, 2008 at 09:11:01AM -0500, Theodore Tso wrote: > > FSF), Dynebolic, Musix GNU+Linux, BLAG, and Trisquel. So not only is > > there one such distribution that takes free software of cardinal > > importance, there are six in the world already. Does Debian really > > need to be the seventh such distribution? > Except that none of these distros existed when Debian set the "100% free" > goal. Should it drop this goal now there are others such distros ? I don't > think so. Should it make it less important than in the past ? I don't > think either. Debian has always had a more relaxed view on these matters than the free software purists would like - things like providing contrib and non-free aren't entirely acceptable to them and are one of the reasons why people go to these other distributions with their stronger political focus. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote: > Steve McIntyre schrieb: > > I'm curious about that myself. We've tried that in the past, and a > > 3-year release cycle was what happened. Experience tells us that we > > have much too big a system to suddenly one day declare "release" > > without a lot of preparation beforehand. > Actually, I don't know since I'm not long enough involved to know what > happened "back then". Did testing at some point in time fork from > unstable and developed slowly into stable while unstable was still Pretty much. What used to happen was that at some point the release manager decided to freeze unstable, creating a new distribution called frozen. This was a straight fork of unstable, there was no technical link between them once the fork was done. > developing concurrently? Did uploads go directly to testing or to > something before testing (like the current frozen unstable)? What was Uploads were done directly to frozen. Uploads could be done simultaneously to both (ie, you could upload to "frozen unstable" - you'll see such uploads in older changelogs) or to one distribution only. > the problem that lead to a slow development back then? Was it that it > was still possible to upload into unstable and so noone was actually > interested in fixing RC bugs? Well, one of the problems was that you could end up with substantial divergence between the two distributions which tended to end up causing breakage so there was still some attempt to keep things broadly in sync. A search through the list archives from the time AJ introduced testing and after the first release using it should turn up plenty of discussion around the issue. > What I see *now* is that the freezes during the last two and the current > release are getting longer and longer (~1,5 months, ~4 months and for > Lenny at least 5 months). For me this seems to be a serious problem we > should not ignore. Important software is outdated in unstable and > current hardware doesn't work anymore without resorting to grab packages > from experimental or unofficial sources. Of course, these problems would all also apply to a frozen distribution like we used to have. My recollection of those times is that the long freezes we had back then had pretty similar effects on general development - the win from testing is in theory that testing should be in much better shape at any given moment than a random snapshot of unstable would be so we should have much more chance of getting the freeze over quickly. I certainly agree that we should be looking at ways of reducing the freeze time but I'm not sure that the freeze mechanism is an important factor in this. In terms of reducing the freeze time I think things like the availability of people willing to work on core packages is more of a limiting factor than anything else. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages still depending on GTK+ 1.2
On Thu, Dec 11, 2008 at 02:12:04PM +0100, Josselin Mouette wrote: > Le jeudi 11 d??cembre 2008 ?? 11:46 +0100, Tim Dijkstra a ??crit : > > It still works, some people still use it... so I do not see any need > > to remove it now. If the time comes to remove gtk+1.2, digitaldj can > > go too IYAM. I'm not using it anymore, and certainly do not have the > > time to port it. > As this reaction is quite common, maybe I should make things more clear. > * Yes, GTK+ 1.2 is going away before the squeeze release. * > If everyone says ???I???m going to remove my pet package when it is the last > one???, it is obvious that we are never going to remove it. I don't see any conflict here - all people are saying is that they'd rather do the removal of the dependant packages when GTK+ 1.2 is actually being removed from the archive. There appears to be relatively little opposition to the idea of removing GTK+ 1.2 itself. Possibly a good way to proceed here is to just remove GTK+ 1.2 shortly after lenny is released, unless we do actually identify any critical packages that still depend on it? -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Sat, Dec 06, 2008 at 04:25:17AM +0100, Josselin Mouette wrote: > Le vendredi 05 d?cembre 2008 ? 22:49 +0000, Mark Brown a ?crit : > > It's nothing to do with power management. I'd rather let it stay until > > lenny is released, though if it were the only thing keeping GTK 1.2 in > > it should go. > Does it even work? The description says it needs a /dev/cpu/ tree. Yes; as the description says the /dev/cpu stuff is only required by some of the features. If it were required for the package to work the package wouldn't be availible for so many architectures. Like I say, it can wait until we're actually removing GTK 1.2. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Fri, Dec 05, 2008 at 07:06:26PM +0100, Josselin Mouette wrote: > Mark Brown <[EMAIL PROTECTED]> >powertweak > => Is that still relevant with modern power management policies? It's nothing to do with power management. I'd rather let it stay until lenny is released, though if it were the only thing keeping GTK 1.2 in it should go. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW processing
On Wed, Dec 03, 2008 at 06:18:59PM +0100, Lucas Nussbaum wrote: > I'm not advocating that we just stop doing reviews. But IMHO, NEW > processing should be about the legal problems, not about the random > lintian warning/errors, and the various other packaging malpractices. At least package namespacing issues also seem rather relevant here. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW processing
On Wed, Dec 03, 2008 at 03:41:29PM +0200, Kalle Kivimaa wrote: > Lucas Nussbaum <[EMAIL PROTECTED]> writes: > > I don't think that we should drop the legal review (that would probably > > be dangerous). However, NEW reviews seem to cover a lot of other > > aspects currently, which might explain why it takes so much time. > These things are the major slowdowns, at least for me, when doing NEW > processing: I'm guessing that many of the other checks that Lucas mentions fall out of the examination you have to do for the licensing anyway? -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Mon, Oct 27, 2008 at 10:10:19AM +, Neil Williams wrote: > On Mon, 2008-10-27 at 18:31 +1100, Ben Finney wrote: > > Because that's how the hardware works. If you are making a widget and > > you need a fpga or hybrid chip of any sort, then you generate a binary > > blob using the chip manufacturers tools. > Are these "chip manufacturer tools" physical tools/machines or software > programs? (i.e. something I need to pick up in my hands or something I > need to execute?) Is there any way that someone else can use the same or Software. > similar tools to modify the blob (even if it is only useful to do so on > a different board / with a different chipset)? Ish. Someone else should be able to use the same tools (barring development environment issues) but modern FPGAs provide encryption mechanisms which mean that only someone posessing a security key blown into the hardware during the manufacturing process can generate an image that will be accepted. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, Oct 21, 2008 at 02:17:37PM -0700, Thomas Bushnell BSG wrote: > On Tue, 2008-10-21 at 22:47 +0200, Frans Pop wrote: > > Doing so would be a violation of basic NMU policy. > The claim was, hey, nobody is stopping anyone from fixing it, if it's > not fixed, it's lame for people to complain, they should have fixed it. There's a difference between randomly charging around without making any effort to work with or coordinate with anyone else and working constructively as part of a large organisation. You appear to only be considering one of these options. > You can either blame people for not uploading their own fix or prohibit > them from doing so, but you can't do both at the same time. It appears that the rest of the world is meeting you at least half way here by, for example, producing patches which implement a solution that is more acceptable to upstream. Perhaps there are other, similarly low effort, things which you could to to contribute to getting those patches integrated? -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Mon, Oct 20, 2008 at 03:49:40PM -0700, Thomas Bushnell BSG wrote: > On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote: > > If they were actively stopping people working on these issues then that > > would be different but I have not seen them doing this. > Great, so since there won't be any active attempts to stop, I can just > go ahead with the work, right? Providing you work in a constructive fashion I really don't see why this should be a problem. This would involve efforts to work with the kernel maintainers and release team, of course, rather than working with no coordination at all. As it turns out Ben has already been actively working on this within Debian so I'd suggest that the most constructive way forward would be to fill in the bits that are missing there, most of which looked like testing. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Mon, Oct 20, 2008 at 12:22:25PM -0700, Thomas Bushnell BSG wrote: > On Mon, 2008-10-20 at 19:11 +0100, Mark Brown wrote: > > On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote: > > > We need the relevant maintainers to be told "your unwillingness to fix > > > this means we will not be able to release". > > I don't think that's a particularly constructive approach to take, > > especially not in a volunteer project. > I think that it is singularly non-constructive to see the maintainers of > packages regard compliance with our foundational documents as wishlist > items, and the release team regard such things as anything other than > show-stoppers. No, really. The kernel team are volunteers. Ordering them to do things doesn't help at all; one could equally well send the same message to everyone working on Debian (or, indeed, the wider community) since they could also step up to the plate and help fix this issue. If they were actively stopping people working on these issues then that would be different but I have not seen them doing this. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote: > I object to a second round of this. I was ok with it once, as a > compromise, but the understanding I had then was that it was a one-time > thing, to give time to actually *fix* the problem. Note that there is currently active upstream work to allow us to address these issues - some of the patches are present in 2.6.27, others are still in flight. This is a vast step forward on where we were with etch if we do decide to go down the route of releasing with exceptions again. > We need the relevant maintainers to be told "your unwillingness to fix > this means we will not be able to release". I don't think that's a particularly constructive approach to take, especially not in a volunteer project. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Spam-Problem with linux.debian.user.german
On Mon, Sep 29, 2008 at 04:46:11PM +0100, Klaus Ethgen wrote: > I had posted a followup to linux.debian.user.german. Now I got a very > strange mail from a italian host telling me that the post was canceled > and that I have to subscribe a mailing list. > What the hell is that about? I did not post to any mailing list. I did The linux.debian.user.german is a version of the debian-user-german mailing list gatewayed to news, it's not a newsgroup as such. This applies to most (if not all) of the linux.* groups. > post to a nntp group. I do not want to subscribe to one another mailing > list when there is a nntp group available. Mailing lists are as bad as > this forum stuff. For all and ever a new account with a new password.[0] The Debian mailing list infrastructure doesn't have per-list passwords (it's pretty much only mailman that does that) and doesn't require that you be subscribed to post so hopefully it will be easier for you to use than most mailing lists are. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Change the format of /usr/share/bug/*/script
On Thu, Sep 11, 2008 at 07:21:30PM +0200, Josselin Mouette wrote: > Come on, we are not trying to imitate Vista. Why do you need to ask tons > of questions just to report a bug? Their only purpose is to confuse the > guy reporting a bug and who doesn???t know what this /etc/apt/sources.list > file is. The prompts about configuration files could probably be handled by having something like a new /usr/share/bug file listing configuration that may be desirable. The frontend can then do something sensible with the information, at the very least collapsing multiple prompts into a single warning. > The thing that is broken is allowing bug scripts to ask questions. We > were able to fix maintainer scripts so that they can run in > non-interactive mode, let???s do the same for those bug scripts. Well, we've not quite done that. We've provided a rather nice pluggable way of prompting which allows complete non-interaction. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting marked not-for-us
On Thu, Aug 07, 2008 at 04:06:50PM -0400, Roberto C. S?nchez wrote: > On Thu, Aug 07, 2008 at 09:57:49PM +0200, Petter Reinholdtsen wrote: > > I would rather have maintainers spend time improving their packages > > instead of wasting it trying to figure out why some architecture > > fail/refuses to build their package. > In some (many?) cases that leads to direct improvement of the package. > I have had a package quit building on a particular architecture and it > ended revealing itself as a problem with something in the build system All of which would go a lot better if the maintainer were told about whatever issue caused the buildd to be configured not to build the package rather than having to discover that this has happened and infer the reasoning for the decision. Also note that this discussion is about the buildds being configured to not even try compiling a package, not about build failures encountered on the buildds. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting marked not-for-us
On Tue, Aug 05, 2008 at 12:21:52PM -0500, John Goerzen wrote: > This seems to happen to me most often on the s390 build daemon, and has > happened with at least 3 to 5 different packages now. (Current example > is hpodder). In fact, I don't think I've ever seen it happen elsewhere. > It seems to happen when build-deps don't get satisfied, or where there > is some problem installing the build-deps. This is quite common with the s390 buildd - it tends to happen when it appears that the package may not be useful on s390 (eg, due to apparing to require hardware not available on s390), apparently based on the package description. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help: Strange 64bit issue
On Fri, Jul 11, 2008 at 02:40:17PM +0200, Andreas Tille wrote: > On Fri, 11 Jul 2008, Manuel Prinz wrote: > >With these fixes it still did not build on my system. I needed to change > >the Build-Depends on lib64z1-dev into zlib1g-dev to get it to build in a > >clean pbuilder chroot. > Well, I guess that lib64z1-dev will not exist for amd64 and that this > whole mess is just caused by the multiarch stuff. It's the first time It doesn't exist for AMD64 - it is 64 bit native so there is no need to produce a 64 bit cross verson of anything. There is lib32z1 on amd64, allowing 32 bit binaries to be built in an amd64 environment. > that I have to deal with this and I have the impression that I try to > add just problems with no real profit for the user of the program. > Probably I should just exclude the -m64 switch when building for i386 > and everything will work fine. That is almost certainly what you want to do. If you build with -m64 you will produce an amd64 binary. This can be run on i386 systems with an appropriate processor, kernel and runtime environment but won't run on systems where one or more of those isn't available and shouldn't be the standard thing for the Debian port. Depending on the needs of the package it may make sense to provide both an i386 native and a cross-built amd64 binary in the i386 port. > >I cannot reproduce this on my amd64 machine. With the change mentioned > >above it builds fine and I'm able to run /usr/bin/maq on both lenny and > >sid. Some output: > I expect this in 64bit machines - but Charles had problems on hie PowerPC > as well ... PowerPC also supports mixed 64/32 bit environments so the situation is similar to that on x86 and x86-64. When running on a G5 or other 64 bit processor with an appropriate kernel it is possible to execute 64 bit PowerPC programs, even using the 32 bit PowerPC port. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Wed, Jul 02, 2008 at 08:34:31PM +1000, Ben Finney wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > The real issue is not that you [Francesco Poli] were posting without > > disclaimers. > The issue that led to those disclaimers was *exactly* that some > thought Francesco should make it clear he is not speaking officially. Well, it's the same thing really - adding the disclaimers is one (poor) way of addressing... > > When someone posts to debian-legal asking for help figuring out if a > > license is ok for Debian main, and you respond saying that it isn't > > because of license feature X; and you are well aware that the > > ftpmasters have previously and consciously accepted other licenses > > into main with that same feature, and have not been swayed by your > > arguments; that's not appropriate. ...the problems with him making statements that sound more authorative than they should be. > Perhaps so. But that's not the issue that led to Francesco habitually > appending disclaimers to his messages. Ideally there'd be no need for such disclaimers because the content of posts wouldn't create misleading impressions. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Generated changes and patch systems
On Tue, May 27, 2008 at 06:06:28PM -0700, Russ Allbery wrote: > Neil Williams <[EMAIL PROTECTED]> writes: > > With these gtk-doc files, it's not so much that the tmpl/*.sgml files > > are generated but that a tool essential to the build modifies them in a > > way that cannot be patched because the results of the patches are > > variable according to that third party tool. > If the tool behaves and only behaves in that way (I haven't checked), that > tool is broken and we should fix that tool. I've run into a similar situation before with a vaugely borked upstream build system - it was straightforward enough to work around the problem by moving the files out of the way and then replacing them if there was a backup present when clean was run. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Generated files and patch systems
On Sun, May 25, 2008 at 01:07:56PM +0100, Neil Williams wrote: > So I am running the relevant autotools at build time but I still get the > warning. If you run autotools at build time you should also ensure that the changes which autotools makes are reverted in the clean target. This means that your diff doesn't get cluttered with automatically generated things and ensures that repeated builds of the package produce the same diff.gz. This is the same idea as patch systems reverting the changes they make in the clean target. > Do I have to move aclocal.m4 aside in debian/rules and move it back? How > does that help? - it'll still be in the .diff.gz under a different > filename. That doesn't help the build-twice release goal issue. Yes, the > package meets the letter of the release goal by building twice in a row > but not without either spurious lintian overrides or spurious lintian > warnings. If you actually move it back in the clean target (rather than just copying it back) then it won't appear in the diff.gz. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mailing lsit code of conduct, again
On Mon, May 19, 2008 at 01:23:25PM +1000, Hamish Moffatt wrote: > On Sun, May 18, 2008 at 07:21:29PM +0100, Mark Brown wrote: > > Of course, MFT brings up the whole "it's not a standard, why should I > > follow it, my MUA never heard of it" thing... You can't win. > Our code of conduct has the same problem - ours is different to many > other communities where CCs are fine or even welcome, eg the kernel > communities. That's a separate problem - with the CCs it's just that there's no agreement in general about how to handle CCs, and no real prospect of ever getting global agreement. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mailing lsit code of conduct, again
On Sun, May 18, 2008 at 06:08:23PM +0200, Raphael Hertzog wrote: > public list that end up in their main INBOX. If those can't make the > effort to setup Mail-Followup-To, they should post less and not _more_ > just for the sake of complaining about the copies. Of course, MFT brings up the whole "it's not a standard, why should I follow it, my MUA never heard of it" thing... You can't win. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mailing lsit code of conduct, again
On Sun, May 18, 2008 at 07:14:10AM -0700, Russ Allbery wrote: > The solution to this problem is to fix the mailing list code of conduct to > stop creating this expectation. We don't enforce it anyway, and all this > provision seems to do in practice is create these annoying arguments > periodically. In my experience it's helpful to have a convention - there always seems to be some exchange of ideas on the issue but if there's a convention then at least you can point at it and say "that's the way we do things round here". -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is master unsuitable to receive mail from lists.debian.org?
On Mon, May 05, 2008 at 07:41:52PM +0100, Simon Huggins wrote: > On Mon, May 05, 2008 at 11:30:45AM -0700, Don Armstrong wrote: > > When we see spam getting through to the lists, we already adjust the > > spam filters. If you think you can do a better job, the spamassassin > > rules are all publicly available, and we gladly accept patches. > I can't find the bit in there that stops you sending the contentless > bounce message? Can you point me at it so I can send a patch to include > how close to the threshold I am and also patch it so that DDs can > disable it? Seconded. I don't really mind that I'm dropping mail from the lists (since I don't seem to be getting any false positives) and I'm not particularly worried about the quality of the filtering on lists - I find the notification messages *much* more annoying than the spam itself. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: intend to hijack GnuPG
On Sat, Apr 19, 2008 at 10:37:57PM +0530, Kartik Mistry wrote: > gnupg is important package. PTS says: > "The package is of priority standard or higher, you should really find some > co-maintainers." > Suggestion: Can we replace 'should' with 'must'? Wrong problem - we don't need more maintainers for packages, we need responsive maintainers who stay on top of things. Chances are that anything you can enforce automatically probably isn't going to deal with that problem. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to manage security issues when the maintainer is not the developer
On Wed, Apr 16, 2008 at 01:55:51PM +0200, Andrea De Iacovo wrote: > How do you think a maintainer should manage security issues when he is > not the package developer? Should he/she either work alone to make > patches or wait for the upstream patches/relases that solve the bug? As ever, the best thing tends to be to work with upstream. If the issue is an upstream one then upstream really needs to be involved in getting the fix released. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: file path length in .deb package.
On Wed, Apr 02, 2008 at 08:43:47PM +0200, Mathieu Malaterre wrote: > Could you *please* give me the bug number, If you can't find a relevant bug you should report a new one (anyone can do so). See: http://www.debian.org/Bugs/Reporting for instructions on how to do this manually or there is a tool called 'reportbug' in the reportbug package which will automate the process. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package upload rejected - no email
On Sat, Mar 15, 2008 at 04:26:56PM -0400, Kevin Coyner wrote: > Question: how do I get the newer, correct version of the > .orig.tar.gz into the archives (replacing the earlier version > uploaded previously that does not match upstream's)? You need to give it a new version number - it is not possible to replace an existing orig.tar.gz. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg with triggers support (again)
On Thu, Mar 13, 2008 at 01:12:41PM +0100, Florian Weimer wrote: > * John Goerzen: > >> Some of the official, published GIT trees are constantly rebased. > >> Apparently, the rule is not set in stone. > > Which ones? > The pu and (less often) the next branches in the main GIT repository. Right, but note that these are branches that are explicitly advertised as being regularly rebased and therefore not suitable for doing things like branching off. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Fri, Feb 29, 2008 at 05:11:17PM +0100, Raphael Hertzog wrote: > But Guillem wants to review and understand the code. In this process, > he will rearrange the changes in smaller logical chunks. Ah, the impression that has been created on the lists is more that the patches were being NACKed and wouldn't be looked at until the logs had been rewritten. I guess that's a bit less of a bad situation. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Thu, Feb 28, 2008 at 08:51:41PM +0100, Raphael Hertzog wrote: > On Thu, 28 Feb 2008, Ian Jackson wrote: > > Does this not also suffer from the problem that branches made from my > > triggers branch become unuseable or difficult to merge ? > git merge --squash is more or less equivalent to applying the patch > corresponding to the whole branch. So it will also break merging from > other branches based on the merged branch. Well, they'd need to be squashed down too or similar were they merged but it just reduces to the same problem as you've got with keeping the history of the triggers branch out of mainline. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Tue, Feb 26, 2008 at 07:09:46PM +, Ian Jackson wrote: > I will then merge mainline into my branch, do any conflict resolution > necessary, and give it a quick test to make sure nothing seems to have > been broken in the meantime. Then merging my branch back into > mainline is, as you say, just a fast forward - so I will simply do > that, and push the result. I've no idea if anyone involved would consider it acceptable but might merging the triggers branch into the mainline with --squash be a suitable comprimise? This would give a single commit discarding the branch history which isn't ideal but would avoid having the history from your branch in the main history. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
