On binary compatibility
I've read a lot about the binary incompatibility concern between Debian and Ubuntu. I have an idea, but I don't have the skill to implement it myself. I figured it would be useful to throw it out there for you all to scrutinize, determine the implementation feasibility, and perhaps run with. First of all, I think it is useful to analyze Ubuntu's motivation -- releasing well-integrated bleeding-edge software. The easiest way to accomplish this goal is by branching from sid. This means that Ubuntu libraries differ from the stable Debian release. Hence, Debian stable (and sid/testing) packages are incompatible with the Ubuntu libraries; thus creating the need for duplicate packaging work by both the Ubuntu and Debian communities. I think that Ubuntu's motivation to provide the latest software is reasonable; however, I think that Debian may be able to help to support that goal while making it possible to maintain binary compatibility. The solution would be to convince Ubuntu to branch from stable instead of sid. The problem is that this creates a lot of work for Ubuntu because they have to backport all of the desired bleeding-edge stuff. However, Debian developers could work with and contribute more to backports.org making it easier for Ubuntu. The most problematic software will be GNOME because it depends on the latest GTK which depends on newer low level libs, which would mean all of the above would need to be backported -- probably quite a significant undertaking. Maybe a solution would be to force the sid GNOME release (and hence the upstream GNOME) to use the Debian stable GTK. Obviously this would have some major political issues. How can we tell upstream what libraries they can and cannot use? Hardware support would be another issue. There would need to be a way to backport support for newer hardware, which may involve backporting newer kernels or backporting support for newer hardware into the stable kernel. The problem is that this solution is hard work for Debian, and I don't think that Ubuntu would take on the backporting challenge itself. It also means making backports.org an official Debian archive. The only way that this would work is if there are Debian folks willing to spend the time to work on backports of their packages. And there would need to be coordination with Ubuntu to determine which packages require backporting, and which can be kept as is. Well, anyway, these are my thoughts. I'm not a developer, and thus cannot see the issues beyond those described, and cannot take on this work myself, but I think that compatibility is a very desirable goal -- not only for Debian and Ubuntu, but for providing a stable platform for external software development on GNU/Linux. All too often I hear about "we don't support Linux because it's a moving platform," and "we can only support one version, so we choose red hat enterprise 3". I think thats rediculous. I think we can make it possible for software developers to create one release that will run on all distributions. One final open-ended question is: which consumes more resources? Duplicate packaging or backporting? I look forward to any insight and contributions. Mike Gilbert
supporting navigation mouse buttons in Debian
Hello, I was recently browsing the web on a windows box and realized that over the last 4 years, I had forgotten how nice it is to be able browse back/forward with a single button click. So I set about enabling this functionality on my Debian box. I found this gentoo doc (http://gentoo-wiki.com/HOWTO_Mouse_Nav_Buttons) very helpful. Now, my question is, would it be possible to work toward supporting nav buttons "out of the box" in Debian? I know that there are probably a lot of issues because there is no hardware standard for the nav buttons, but maybe there would be a way to store configuration for all the hardware. The gentoo doc is geared toward enabling back/forward nav in mozilla only, so there may need to be some thought put into a way to generalize this. Is anyone else interested in making nav buttons work "out of the box", and would it be worthwhile to work on? This would likely involve (hopefully minor) changes to a lot of parts of the distribution. I think this capability is important because I remember when I first switched that I was disappointed that the nav buttons didn't work. I stuck with it, but it could be enough to turn away a significant number of new users who are stuck in the windows mud. One of the gnome HIG is along the lines of provide an interface that the user expects and don't suprise them. I look forward to any thoughts on this matter. Regards, Mike
Re: supporting navigation mouse buttons in Debian
On 3/12/06, David Nusinow wrote: > Please note that the usual way to do this is by > filing a wishlist bug against the package, and I'd appreciate it if you use > this mechanism so I can keep track of it easily. ok, will do. i didn't think that this discussion fit nicely under a single package. i will file as an xserver-xorg wishlist item. i'll see what i can do in terms of making contributions as well. mike
Re: Talk: Reflections of a bigtime Debian bug reporter
On Tue, 15 Sep 2009 13:46:31 +0530, Kartik Mistry wrote: > On Tue, Sep 15, 2009 at 1:39 PM, Petter Reinholdtsen wrote: > > Especially the 'what did you expect' is important, as it often make it > > possible to differentiate between software bugs, documentation bugs > > and plan simple user expectation issues. > > May be 'reportbug' can give more template options like 'Steps to > reproduce 1... 2... 3.. etc' as we see in bugzilla etc. And may be > automatic stact trace etc. hi, i personally hope that this does not happen. one of the virtues of the debian bts is that it is an email-based system where at least a certain level of etiquette and cordiality is expected/commonplace. as soon as you start forcing users to fill in the blanks, it no longer becomes a one-on-one human correspondence, but instead a battle with an unyielding inhuman system. this is why i hate dealing with bugzillas. the answer to the real problem is education. if a user didn't submit sufficient details in their report, politely ask them for more. show them a guide for strace, or bug writing guides, or debian documentation, or whatever may be useful. this may be more work, but as that user gains more skill, they will become less of a burden, and more importantly, more capable of solving problems and writing good reports on their own. if you want to add something useful to reportbug, i would recommend kind opening and closing remarks. for example, i've noticed that a bug starting with 'hi' seems a lot friendlier and gets attention more quickly than one with a 'hello', which seems more drawn out and formal. more importantly, something like this will help guide the submitter's tone, and subsequently the maintainer's response; ultimately leading to a more peaceful coexistence with the people for which your work matters. this is something that debian mentors does well, which makes that system very friendly and productive. mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
On Fri, 18 Sep 2009 19:06:21 +0300, Tom Feiner wrote: > Philipp Kern wrote: > > On 2009-09-18, Tom Feiner wrote: > >> Looks like this method works well for clamav-data and other similar > >> packages > >> which needs to update databases frequently on stable/oldstable. > > > > clamav-data is scheduled for deletion as soon as volatile moves onto > > ftp-master, so that's no precedent. (I.e. there is opposition against > > daily builds entering the archive without real developers signing them.) > > > > Ah, I was not aware of this. So what is the best practice in this case, where > a package needs an updated database on a regular basis (monthly basis in case > of geoip)? i don't think that there is any standard at this point, and maybe the outcome of this discussion should be a standardized solution. my suggestion could potentially be a one-size-fits-all solution for all of the cases mentioned so far: antivirus updates, gps/geographical updates, game data updates (often non-free), printer firmware updates (often non-free), non-free font updates, non-free firmware/driver updates, etc. anything i've missed? however, i think that since these packages are depending on information outside of the debian archive, most (if not all) should be hosted under the contrib section (since users without internet access will encounter reduced/limited functionality). and especially for those scripts depending on non-free external data. mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
On Wed, 14 Oct 2009 21:34:28 +0200, Adam Borowski wrote: > On Wed, Oct 14, 2009 at 07:27:07PM +, Florian Weimer wrote: > > > I could just put up a site with CC porn, then. Aren't we supposed > > > not to discriminate against fields of endeavour? > > > > A software which requires access to non-free documents over the > > network to work at all shouldn't go into main. It seems that gnaughty > > is currently in that category. > > Sure, just remember to file RM bugs for: > gmailfs > googlizer > libwww-google-calculator-perl > opensync-plugin-google-calendar > python-libgmail > akonadi-kde-resource-googledata > clive > gcalcli > gmail-notify > tryton-modules-google-maps > calendar-google-provider > (picking on just Google) the key litmus test is: does the application depend solely on non-free information to function properly. these google applications fail this test because the licensing of the data itself is at the user's discretion. hence, they are permitted in main. mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
On Wed, 14 Oct 2009 21:48:19 +0200, Mehdi Dogguy wrote: > Florian Weimer a écrit : > > > > A software which requires access to non-free documents over the > > network to work at all shouldn't go into main. It seems that gnaughty > > is currently in that category. > > > rtm (from awn-applets-python-extras) is such a program. Should it go out > from main? > tasque lets the user use the service rememberthemilk too, should it go > out too? > and how about tucan? i couldn't find rtm, but tasque and tucan fail my proposed litmus test (does the application depend solely on non-free information to function properly) because the data itself is licensed at the users discretion. hence, these applications are permitted in main. see hannah-foo2zjs, which was split from foo2zjs and put in contrib because it is a script who's sole purpose is to fetch non-free printer firmwares; or ttf-mathmatica whose sole purpose is to fetch non-free fonts. mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
On Wed, 14 Oct 2009 22:27:25 +0200, Yves-Alexis Perez wrote: > On mer, 2009-10-14 at 16:23 -0400, Michael Gilbert wrote: > > the key litmus test is: does the application depend solely on non-free > > information to function properly. these google applications fail > > this test because the licensing of the data itself is at the user's > > discretion. hence, they are permitted in main. > > I don't really think clive use data licensed at the user discretion. i agree, clive only functions properly when it has access to the non-free content on youtube, so it would pass my litmus test, and should be moved to contrib. > This whole thread is just pointless. it is certainly worth pondering and deliberating on the issue since up to this point there is no concrete debian policy on the matter. mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
On Wed, 14 Oct 2009 16:57:19 -0400, James Vega wrote: > On Wed, Oct 14, 2009 at 4:43 PM, Michael Gilbert > wrote: > > On Wed, 14 Oct 2009 22:27:25 +0200, Yves-Alexis Perez wrote: > >> On mer, 2009-10-14 at 16:23 -0400, Michael Gilbert wrote: > >> > the key litmus test is: does the application depend solely on non-free > >> > information to function properly. these google applications fail > >> > this test because the licensing of the data itself is at the user's > >> > discretion. hence, they are permitted in main. > >> > >> I don't really think clive use data licensed at the user discretion. > > > > i agree, clive only functions properly when it has access to the > > non-free content on youtube, so it would pass my litmus test, and should > > be moved to contrib. > > What makes youtube content (or any of the media content from the many > other sites clive supports) automatically non-free? Doesn't it depend > on how the media's author has decided to license their work? if i recall, youtube has a specific usage agreement (i found [0]) applicable to all of its content, which for all intents and purposes would likely be declared non-free if reviewed for dfsg-freeness. hence, access to youtube content through youtube itself would be considered non-free due to that usage agreement; even though dfsg-free content may be hosted there. i've never used clive so i do not know what the usage agreements say for the other supported video sites. mike [0] http://code.google.com/apis/youtube/terms.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
On Wed, 14 Oct 2009 17:13:10 -0400, Michael Gilbert wrote: > On Wed, 14 Oct 2009 16:57:19 -0400, James Vega wrote: > > On Wed, Oct 14, 2009 at 4:43 PM, Michael Gilbert > > wrote: > > > On Wed, 14 Oct 2009 22:27:25 +0200, Yves-Alexis Perez wrote: > > >> On mer, 2009-10-14 at 16:23 -0400, Michael Gilbert wrote: > > >> > the key litmus test is: does the application depend solely on non-free > > >> > information to function properly. these google applications fail > > >> > this test because the licensing of the data itself is at the user's > > >> > discretion. hence, they are permitted in main. > > >> > > >> I don't really think clive use data licensed at the user discretion. > > > > > > i agree, clive only functions properly when it has access to the > > > non-free content on youtube, so it would pass my litmus test, and should > > > be moved to contrib. > > > > What makes youtube content (or any of the media content from the many > > other sites clive supports) automatically non-free? Doesn't it depend > > on how the media's author has decided to license their work? > > if i recall, youtube has a specific usage agreement (i found [0]) > applicable to all of its content, which for all intents and purposes > would likely be declared non-free if reviewed for dfsg-freeness. hence, > access to youtube content through youtube itself would be considered > non-free due to that usage agreement; even though dfsg-free content may > be hosted there. here are the terms of service for youtube [0]. section 4A alone would be sufficient to declare the service non-free. mike [0] http://www.youtube.com/t/terms -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
On Wed, 14 Oct 2009 23:28:14 +0200, Mike Hommey wrote: > On Wed, Oct 14, 2009 at 05:18:33PM -0400, Michael Gilbert wrote: > > On Wed, 14 Oct 2009 17:13:10 -0400, Michael Gilbert wrote: > > > On Wed, 14 Oct 2009 16:57:19 -0400, James Vega wrote: > > > > On Wed, Oct 14, 2009 at 4:43 PM, Michael Gilbert > > > > wrote: > > > > > On Wed, 14 Oct 2009 22:27:25 +0200, Yves-Alexis Perez wrote: > > > > >> On mer, 2009-10-14 at 16:23 -0400, Michael Gilbert wrote: > > > > >> > the key litmus test is: does the application depend solely on > > > > >> > non-free > > > > >> > information to function properly. these google applications fail > > > > >> > this test because the licensing of the data itself is at the user's > > > > >> > discretion. hence, they are permitted in main. > > > > >> > > > > >> I don't really think clive use data licensed at the user discretion. > > > > > > > > > > i agree, clive only functions properly when it has access to the > > > > > non-free content on youtube, so it would pass my litmus test, and > > > > > should > > > > > be moved to contrib. > > > > > > > > What makes youtube content (or any of the media content from the many > > > > other sites clive supports) automatically non-free? Doesn't it depend > > > > on how the media's author has decided to license their work? > > > > > > if i recall, youtube has a specific usage agreement (i found [0]) > > > applicable to all of its content, which for all intents and purposes > > > would likely be declared non-free if reviewed for dfsg-freeness. hence, > > > access to youtube content through youtube itself would be considered > > > non-free due to that usage agreement; even though dfsg-free content may > > > be hosted there. > > > > here are the terms of service for youtube [0]. section 4A alone would > > be sufficient to declare the service non-free. > > Unless there is a clause saying that no youtube user shall license > her work under a free license, I see no problem. IANAL (I Am Not a Lawyer), but from a legal point of view, the rights granted to you by youtube for content available on their site are independent of the rights that could be granted to you directly by the content's copyright holder. these terms of service apply as soon as you access the site and make very clear non-free restrictions on all "User Submissions" regardless of the license choices of the original copyright holder. also, according to term 6C, the original copyright holder gave up a long list of their inherent rights to youtube. hence, the content there does not come with the same set of rights as if you had accessed the content directly from the copyright holder. mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposed mass prototypejs bug filing for multiple security issues
On Mon, 19 Oct 2009 10:02:59 +0800 Paul Wise wrote: > On Mon, Oct 19, 2009 at 8:43 AM, Michael S Gilbert > wrote: > > > Let me know if this is OK, and whether there is anything else I should > > be aware of. > > Excellent, please go ahead. > > See also the lintian warning (you seem to miss a few): > > http://lintian.debian.org/tags/embedded-javascript-library.html > > Based on a cursory glance, your list also misses a few found by > apt-file search -i prototype | grep -iF .js Thanks for the suggestions! I will add these packages to the list. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposed mass prototypejs bug filing for multiple security issues
On Mon, 19 Oct 2009 10:52:18 -0500, Gunnar Wolf wrote: > Michael S Gilbert dijo [Sun, Oct 18, 2009 at 08:43:35PM -0400]: > > Hi, > > > > The prototypejs script has been found to be vulnerable to a couple > > security issues [0],[1]. This script is embedded in about 32 other > > packages and I would like to file bugs against all of those that are > > affected. Since this would probably be considered a mass filing, I am > > running it past -devel first. > > (…) > > Just for the record, I agree with your mass filing (which is not > massive anyway). > > However, I'd also suggest your bugs (and as a matter of general > policy) should invite said maintainers to depend on libjs-prototype > and symlink it instead of shipping the package's own versions, except > if there is a _real_ need to do so (i.e. upstream-modified versions of > prototype or dependance on specific API versions). I think I'll have this covered. As I mentioned in the original message, I am submitting two bugs for each package. The second bug is a request for the maintainer to link to the system prototypejs, which is the source package for libjs-prototype. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposed mass prototypejs bug filing for multiple security issues
On Mon, 26 Oct 2009 14:04:06 -0500, Adam Majer wrote: > On Sun, Oct 18, 2009 at 08:43:35PM -0400, Michael S Gilbert wrote: > > Here are the affected source packages: > > - rails (embed) > > ~$ apt-file list rails | grep prototype.js > rails: > /usr/share/rails/actionpack/test/fixtures/public/javascripts/prototype.js > rails: /usr/share/rails/railties/html/javascripts/prototype.js > > -rw-r--r-- 1 root root 15 2009-09-21 13:03 > /usr/share/rails/actionpack/test/fixtures/public/javascripts/prototype.js > > lrwxrwxrwx 1 root root 45 2009-09-21 13:38 > /usr/share/rails/railties/html/javascripts/prototype.js -> > ../../../../javascript/prototype/prototype.js Thank you very much for the info on the rails package. This makes one less bug to deal with. > This is from rails in testing/sid. In stable the package depends on > the prototype package too. I was hoping that the statement in my original message, "...the only checking done so far is a version comparison...," would be clear. 32 different packages are a lot to deal with, and I am expecting maintainers to do the real legwork since they are responsible for their own code. > I'm not sure how you get the "unfixed" and (embed). Seems a little rushed. That list was taken from the secure-testing tracker's embedded code copies list, which is hard to keep up to date and accurate. It could use some more care and better maintaining; but code copies are plentiful, making it very difficult to track progress on all of them. I have not yet sent any reports because I am still in the process of generating a more accurate list. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Iceweasel and Firefox compatibility
On 11/9/09, John Goerzen wrote: > Here are some sites/apps that break, at least in part, because of our > API claiming to be Iceweasel: > > Zimbra admin console > BlackBoard (used by thousands of universities) > http://browserplus.yahoo.com/ (claims the browser isn't supported) > http://gears.google.com/ (claims browser isn't supported) > hundreds of banks > The conferencing app at dimdim.com > Kerio mail server i know that this may be the "hard" solution, but the best way to solve these problems is to educate the developers of these services individually (primarily via technical service requests, complaints, and threats to take your business elsewhere). mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#559802: CVE-2009-3736 local privilege escalation
On Mon, 07 Dec 2009 08:56:07 +0100, Stefan Hornburg (Racke) wrote: > Michael Gilbert wrote: > > Package: courier-authlib > > Severity: grave > > Tags: security > > > > Hi, > > > > The following CVE (Common Vulnerabilities & Exposures) id was > > published for libtool. I have determined that this package embeds a > > vulnerable copy of the libtool source code. However, since this is a > > mass bug filing (due to so many packages embedding libtool), I have not > > had time to determine whether the vulnerable code is actually present > > in any of the binary packages. Please determine whether this is the > > case. If the package is not affected, please feel free to close the bug > > with a message containing the details of what you did to check. > > > > CVE-2009-3736[0]: > > | ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b, > > | attempts to open a .la file in the current working directory, which > > | allows local users to gain privileges via a Trojan horse file. > > > > Note that this problem also affects etch and lenny, so if your package > > is affected, please coordinate with the security team to release the > > DSA for the affected packages. > > > > If you fix the vulnerability please also make sure to include the > > CVE id in your changelog entry. > > > > Is there a patch available for the vulnerability? Yes, if you follow the link to the mitre page [0], which was included in the original bug report, you will find a link to the patches [1]. Best wishes, Mike [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3736 [1] http://git.savannah.gnu.org/cgit/libtool.git/commit/?h=branch-1-5&id=29b48580df75f0c5baa2962548a4c101ec7ed7ec -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#559802: CVE-2009-3736 local privilege escalation
On Tue, 8 Dec 2009 03:13:06 +1100, Steffen Joeris wrote: > > > > The following CVE (Common Vulnerabilities & Exposures) id was > > > > published for libtool. I have determined that this package embeds a > > > > vulnerable copy of the libtool source code. However, since this is a > > > > mass bug filing (due to so many packages embedding libtool), I have not > > > > had time to determine whether the vulnerable code is actually present > > > > in any of the binary packages. Please determine whether this is the > > > > case. If the package is not affected, please feel free to close the bug > > > > with a message containing the details of what you did to check. > > > > > > > > CVE-2009-3736[0]: > > > > | ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b, > > > > | attempts to open a .la file in the current working directory, which > > > > | allows local users to gain privileges via a Trojan horse file. > > > > > > > > Note that this problem also affects etch and lenny, so if your package > > > > is affected, please coordinate with the security team to release the > > > > DSA for the affected packages. > > Is this different to all these python modules that include the working > directory? When I had a quick look it smelled like these once, in which case > none of the packages probably deserves a DSA and they can all be fixed > through > s-p-u/o-s-p-u (and can be urgency 'slow'), but I thought I'd ask first in > case > I misunderstood the issue. So, as i interpret the issue, the difference here is that libtool will load any and all .la and .a file available on the LD_LOAD_LIBRARY path; whereas python will load modules in the current directory only if they are specifically called from the script. I have just recently realized that LD_LOAD_LIBRARY has a relatively safe default that does not include the current working directory. Given this fact, I believe that the impact is rather limited (only users that have modified that LD_LOAD_LIBRARY path are affected; and i'm sure there are those who have done this, but it is a minor subset of all debian users). Hence, I think that for any package embedding libtool, updates should be pushed in stable-proposed-updates, rather than DSAs. As for libtool itself, it may still make sense to issue a DSA. If there is concurrence on this assessment, I will send a message along these lines to all of the bugs that I submitted. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: unzip.h and unzip.c files in source packages.
On Tue, 15 Dec 2009 23:50:43 +0900, Charles Plessy wrote: > Dear all, > > while reviewing an Ubuntu package that we are considering to submit to the NEW > queue for inclusion in Debian, I found a copy of source files from the > ‘minizip’ package, that was not mentionned in debian/copyright. [...] > The conclusion is that we should either change our policy on copyright > documentation (that goes further than what is required by some licenses), > or double-check our packages. The technically robust solution here would be to add embedded code copy checks to lintian. However, at best those checks would only be able to produce a "confidence level" that the code checked may contain an embed. This is because code copies tend to be of various versions, and a direct code comparison would not be sufficient. The security-tracker's known embedded code copies list [0] would be a good resource of reference source code that should be searched in these lintian checks. Anyway, implementing this could involve some significant work, and I personally do not have the time for it, but it would be incredibly useful; especially from a security standpoint since dealing with embedded code is very tedious and time-consuming. Best wishes, Mike [0] http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Suggested improvements to the release-critical bug tracker
Hello, I've noticed that most issues tracked on the release-critical bug tracker [1] are actually already fixed in unstable. This is leading to the perception there are an enormous number of unfixed release-critical issues for lenny (298 currently). And it makes it harder to figure out which issues actually need attention (you have to look at each bug report separately to figure which do and do not have fixed versions in unstable). Currently, there are probably less than 50 unfixed bugs, but it appears that there are six times that many. The other 250 are already fixed in unstable, and waiting to migrate to testing. I suggest that, by default, the release-critical tracker page list only those bugs that do not have a fix uploaded yet (make it optional to list all current RC issues). Also, I suggest that the page tracks the "Number concerning the next release with no fix currently uploaded" and "Number that have already been fixed in unstable that are currently waiting to migrate to testing" rather than just "Number concerning the next release". Also, I suggest that these two curves get added to the graph on the main RC bug tracker page. Another suggestion: some of the bug titles on the detailed RC bug tracker page [2] have a green or orange font, meaning patch (+) or help (H). It would be useful for that to be explained on the page, or have the explaination for + and H colored at the top. And another suggestion: I suggest that the the lists of opened and closed bugs be relative to midnight starting the current 24 hour day, rather than relative to the most recent update of the tracker page, which is every couple hours. The current way makes it seem that not much is going on every day, when really, a lot of progress is happening. Thank you for your consideration, Mike P.S. Please CC me on any replies as I am not subscribed to this list. [1] http://bugs.debian.org/release-critical [2] http://bugs.debian.org/release-critical/debian/all.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Direction on foo2zjs and web fetching scripts
Dear release team, Thank you for making a decision on the direction for bug #449497 in foo2zjs [1]. I believe that this is a reasonable choice for now due to the impending release. However, I would really like to see an honest and consructive conversation on the issue. I believe that there are some major security and functionality problems with fetching scripts, and there should be clear direction from the members of the debian project on the matter. I would like to be able to completely trust main, so it is my hope that developers would do everything in their power to keep main as clean and safe as possible. I am just a user, so I feel powerless to do anything, and my experience dealing with the foo2zjs maintainers was not exactly constructive [2],[3],[4] (primarily because of apathy, over-reactiveness, and hyper sensitivity on their part and perhaps a lack of appreciation for the bug severity command and control authority [5] on my part). Where do we go from here to make sure the issue gets the appropriate level of thought and consideration that it deserves (after lenny gets released of course)? Best wishes, Michael Gilbert [1] http://lists.debian.org/debian-release/2008/11/msg00106.html [2] http://bugs.debian.org/449497 [3] http://bugs.debian.org/503813 [4] http://bugs.debian.org/503814 [5] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Direction on foo2zjs and web fetching scripts
Dear release team, Thank you for making a decision on the direction for bug #449497 in foo2zjs [1]. I believe that this is a reasonable choice for now due to the impending release. However, I would really like to see an honest and consructive conversation on the issue. I believe that there are some major security and functionality problems with fetching scripts, and there should be clear direction from the members of the debian project on the matter. I would like to be able to completely trust main, so it is my hope that developers would do everything in their power to keep main as clean and safe as possible. I am just a user, so I feel powerless to do anything, and my experience dealing with this issue through the foo2zjs maintainers was not exactly constructive [2],[3],[4] (primarily because of over-reactiveness and hyper sensitivity on their part and perhaps a lack of appreciation for debian's bug command and control authority [5] on my part -- and of course some good old misunderstanding and misinterpretation). Where do I go from here to make sure the issue gets the appropriate level of thought and consideration that it deserves (after lenny gets released of course)? Best wishes, Michael Gilbert [1] http://lists.debian.org/debian-release/2008/11/msg00106.html [2] http://bugs.debian.org/449497 [3] http://bugs.debian.org/503813 [4] http://bugs.debian.org/503814 [5] http://lists.debian.org/debian-ctte/2008/10/msg6.html P.S. Please CC me on any responses since I am not subscribed to these lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Direction on foo2zjs and web fetching scripts
I appologize for the double post. Please disregard the first message, which was send mid-thought due to an errant click. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440607: ITP: steam-powered -- Valve's steam game content delivery system
Package: wnpp Severity: wishlist Owner: Michael Gilbert <[EMAIL PROTECTED]> * Package name: steam-powered Version : 6 Upstream Author : Michael Gilbert * URL : no website * License : GPL Programming Lang: shell Description : Valve's steam game content delivery system This package is a wrapper that makes it easy to install and run Valve's Steam program via wine. The intent will be for this package to be a part of the contrib archive. A preliminary version of the package has been uploaded to debian-mentors for review and testing, [1]. There has already been some interesting discussion on the mentors list. Please read [2], [3], and [4] to get up to speed. I am looking forward to the discussion and getting this package added to the archive. Steam (www.steampowered.com) is a game content delivery system developed by Valve software (http://www.valvesoftware.com). This is a windows application, which is supported on your Debian system via wine (http://www.winehq.org). Not all steam games work at this time, but many do. Games that work very well include half-life, counter-strike, half-life 2, and counter-strike: source. More information about steam can be found at http://www.steampowered.com. [1] http://mentors.debian.net/debian/pool/contrib/s/steam-powered/ [2] http://lists.debian.org/debian-mentors/2007/08/msg00592.html [3] http://lists.debian.org/debian-mentors/2007/08/msg00599.html [4] http://lists.debian.org/debian-mentors/2007/08/msg00601.html Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Switch on compiler hardening defaults
On Wed, 6 Jan 2010 11:01:01 +0800 Paul Wise wrote: > On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook wrote: > > > There is a maintained (by RedHat) patch for dealing with PIE. I already > > maintain a delta for this in Ubuntu, but as you can see in the gdb bug, > > the gdb maintainer doesn't want it until it's in upstream. I, obviously, > > think that's ridiculous. PIE works and is useful. Blocking its rollout > > because gdb's support for it isn't upstream just furthers the catch-22. > > It is perfectly reasonable to reject patches until they are upstream. > I personally will never add patches to Debian without either > committing them upstream myself or some indication that they already > have been or will be accepted upstream. IIRC the Debian kernel team > has similar policies. Why hasn't RedHat upstreamed the patch? They are > usually good about doing that. Perhaps you could push them to do so. While normally I would agree with your logic, when it comes to security I think a more cautious logic must prevail. Remember that item 4 of the social contract states that: "Our priorities are our users and free software." An aspect of that guidance is providing high quality security for those users. Hence, when a feature improves security (or provides additional harding) the convenience factor of not differing from upstream should be considered a lower priority than normal. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: #560778 apt-listchanges: depends on things in optional, which depend on things in extra
On Tue, 26 Jan 2010 13:33:32 +0100, Stefano Zacchiroli wrote: > All in all (and unless I've missed something), the choice seems to be > relatively self contained. We would "just" need to promote to standard > python-support and python-apt. For reference, on amd64 the total > installed-size of the 2 is about 4 MB (not considering the *.pyc which > will be compiled on the fly by python-support, which I don't know how to > evaluate). you can use "sys.dont_write_bytecode = True" in python >= 2.6 to disable writing of pyc files to conserve disk space. however, startup will always be slower due to the missing precompiled bytecode. mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: correct/ideal way to obtain root from a shell script
On Sat, 30 Jan 2010 22:58:20 + Jon Dowland wrote: > Hi folks, > > I need to run a command as the superuser inside > game-data-packager (gdp). Up until now, I've been > hardcoding a sudo invocation and depending on sudo. maybe packaging isn't the best solution to the underlying problem? wouldn't it be much more straightforward (from a user's perspective) if the game data files were automagically loaded into an appropriate location in their home dir rather packaged and installed into the root file system? perhaps an additional utility could be provided (runnable with elevated priviledge via user's method of choice) that packages the data from their home dir and installs it to the root file system (that is if they want it to be available for multiple users)? anyway, just a thought. mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Downgrading a package to get it into upcoming release
On Tue, 16 Feb 2010 18:23:39 +0100 Jean-Christophe Dubacq wrote: > On 16/02/2010 17:04, Antonin Kral wrote: > > Hi all, > > > > I am looking for some advise / opinions. I am working with guys from > > MongoDB project to get stable package in Debian. We have currently > > version 1.3.1 in unstable, this is considered as development branch > > which is not very stable. > > > > Is there any way how to reasonably push older version (1.2.x which is > > considered stable), which has not been in Debian before to enable its > > inclusion in upcoming Debian freeze/stable release? > > 1) Can the two programs be installed together? > > If yes, simply build a MongoDB1.2 and a MongoDB1.3. > > If not, then you should use epochs: upload MongoDB 1:1.2 to unstable, > and MongoDB 1:1.3 to experimental. all of these seem like rather complicated solutions. wouldn't it be a bit simpler to ask for removal from both testing and unstable, then once that happens, upload the old (known stable) version of the package? mike -- 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/20100216125234.203850ce.michael.s.gilb...@gmail.com
Re: Downgrading a package to get it into upcoming release
On Tue, 16 Feb 2010 12:52:34 -0500 Michael Gilbert wrote: > On Tue, 16 Feb 2010 18:23:39 +0100 Jean-Christophe Dubacq wrote: > > > On 16/02/2010 17:04, Antonin Kral wrote: > > > Hi all, > > > > > > I am looking for some advise / opinions. I am working with guys from > > > MongoDB project to get stable package in Debian. We have currently > > > version 1.3.1 in unstable, this is considered as development branch > > > which is not very stable. > > > > > > Is there any way how to reasonably push older version (1.2.x which is > > > considered stable), which has not been in Debian before to enable its > > > inclusion in upcoming Debian freeze/stable release? > > > > 1) Can the two programs be installed together? > > > > If yes, simply build a MongoDB1.2 and a MongoDB1.3. > > > > If not, then you should use epochs: upload MongoDB 1:1.2 to unstable, > > and MongoDB 1:1.3 to experimental. > > all of these seem like rather complicated solutions. wouldn't it be a > bit simpler to ask for removal from both testing and unstable, then once > that happens, upload the old (known stable) version of the package? oh, you would probably need a conflicts with the newer version and a README.Debian to explain what to do for users with the new version already installed. mike -- 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/20100216125516.a68441f8.michael.s.gilb...@gmail.com
Re: Downgrading a package to get it into upcoming release
On 2/16/10, Sven Joachim wrote: > On 2010-02-16 18:55 +0100, Michael Gilbert wrote: > >>> all of these seem like rather complicated solutions. wouldn't it be a >>> bit simpler to ask for removal from both testing and unstable, then once >>> that happens, upload the old (known stable) version of the package? >> >> oh, you would probably need a conflicts with the newer version and a >> README.Debian to explain what to do for users with the new version >> already installed. > > Except that these users will never even see it if the version in the > archive is lower than the one they have installed. Your proposal seems > like a non-starter to me. how about versioning it something like 1.3.1-1+reverted1.2.1? mike -- 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/8e2a98be1002161021p25e2a651kb6866337a0123...@mail.gmail.com
Re: md5sums files
On Wed, 03 Mar 2010 21:58:11 +0100, Frank Lin PIAT wrote: > On Tue, 2010-03-02 at 18:21 -0800, Russ Allbery wrote: > > Wouter Verhelst writes: > > > > > Or is it useful to be able to say "if it doesn't check out, it's > > > certainly corrupt, and if it does check out, it may be corrupt"? Didn't > > > think so. > > > > I don't understand why you say this. Cryptographic attacks on MD5 aren't > > going to happen as a result of random file corruption. The MD5 checksums > > are still very effective at finding file corruption or modification from > > what's in the Debian package unless that modification was done by a > > sophisticated attacker (MD5 preimage attacks are still not exactly easy). > > Detecting compromises is useful, but only a small part of what the MD5 > > checksums are useful for. I'd more frequently use them to detect > > well-intentioned but misguided meddling by a local sysadmin. > > > > I certainly don't object to replacing them with SHA1 hashes, although > > signed deb packages would still be my preferred solution to this problem. > > Signed debs may introduce a fake sense of security (Only apt repository > provide security updates). By signing packages, user may assume that a > package is safe when it isn't. it should actually be possible to do this securely. dpkg could be made to work like apt where it only blindly trusts packages signed by keys in /etc/apt/trusted.gpg. the downfall is that there is nothing stopping the user from adding additional (potentially less than trustworthy keys), but that isn't really solvable without destroying freedom, and it isn't any different from the current state for apt. mike -- 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/20100303162036.dbf12e05.michael.s.gilb...@gmail.com
Re: including full package source code in the debian release
On Sat, 06 Mar 2010 19:29:22 -0800 Jamie Morken wrote: > so including compressed package source code would have a very minor impact on > the overall file size of the debian release. you can achieve your goal by burning the isos and having them on hand. or you can create less physical waste by loop mounting the isos. mike -- 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/20100306225243.5b36de6c.michael.s.gilb...@gmail.com
source.debian.net
Does anyone know who maintains source.debian.net? It's a really great service, but its been down for about a month now. I would like to to make sure they're aware of the problem. Thanks. Best wishes, Mike -- 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/20100313142838.563aefce.michael.s.gilb...@gmail.com
Re: Preparing a Debian "e500" port/derivative (ABI-incompatible PowerPC variant)
On Tue, 23 Mar 2010 13:04:04 -0500, Moffett, Kyle D wrote: > [Note: I'm not authorized to speak "on behalf of" my employer, but this > represents (to the best of my knowledge) our current plans and goals] > > Please maintain the CC list, all of us here at eXMeritus are interested in > comments and advice. > > On 2010/03/23 13:40, "Moritz Muehlenhoff" wrote: > > On 2010-03-23, Moffett, Kyle D wrote: > >> * Regarding software security updates, I am aware that most vendors of OS > >> distributions participate in coordinated-disclosure and embargo agreements > >> in order to receive advance notice of certain vulnerabilities. My employer > >> is currently considering what we would need to do in order to get access to > >> those notifications; on the other hand we would much rather participate > >> directly in the Debian security release process. Would it be possible for > >> us as a third-party corporation to be a part of that process? > > > > The easiest approach for all parties involved would be if e500 becomes an > > official port. In that case you don't need to do anything on the security > > side, all security updates are autobuilt and if there's an embargoed > > security issue targeted for a specific release date it's automatically > > available for e500 on the release day. But even if e500 starts unofficially > > we can discuss/evaluate the possibilities to hook a e500 autobuild system > > into the security buildd network. > > This would be wonderful from the official-Debian-port side of things, but we > would still like to get our company into the security process. If at all > possible, we would like to be able to participate in the Debian security > release process enough to identify which security updates pertain to our > specific configurations and provide our clients with release-day updates. > > Specifically, we are going to be distributing a derivative/fork of Debian > that has been patched-and-hardened for our specific use-case (as a network > security appliance on aircraft). We certainly plan to collaborate with the > general Debian (and other open-source) communities as we build this product, > including releasing all the open-source debs and source packages. On the > other hand, the very strictly locked-down and feature-neutered environment > that actually gets installed on the aircraft will be unlikely to be > interesting on general-purpose servers or desktops. hi, if you are interested in security, your best bet is to become familiar with the debian security tracker [0] and its database [1],[2]. debian strives to work out in the open, so most, but not all, known issues are tracked there. if you want to make active contributions, you can join the alioth project [3]. there are private issues every now and then, and you can try to join vendor-sec [4], but you may not qualify. those issues are eventually disclosed anyway on an agreed date, and then they're tracked in the public database. best wishes, mike [0] http://security-tracker.debian.org [1] http://svn.debian.org/wsvn/secure-testing (secure-testing-comm...@lists.alioth.debian.org) [2] http://svn.debian.org/wsvn/secure-testing/doc/narrative_introduction [3] https://alioth.debian.org/projects/secure-testing/ [4] http://oss-security.openwall.org/wiki/mailing-lists/vendor-sec -- 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/20100323151714.520ed283.michael.s.gilb...@gmail.com
Re: A Look In the Mirror: Attacks on Package Managers
On Sun, 6 Jun 2010 12:28:27 +1000 Erik de Castro Lopo wrote: > Hi All, > > Did anyone see this paper: > > A Look In the Mirror: Attacks on Package Managers > http://www.cs.arizona.edu/~jhh/papers/ccs08.pdf > > It suggests that anyone who has control of a mirror can cause client > machines to install software created by the attacker or install an > outdated version of a package with a vulnerability the attacker knows > how to exploit. All of the issues raised in this paper can be mitigated by a "proactive" user. Malicious mirror activity can be detected by paying attention to debsecan and the security tracker [0]. debsecan displays all known vulnerable packages on a particular system, and the security tracker displays all known vulnerable packages. Differences between the two for a period longer than about a week would be a sign that the mirror is intentionally holding back vulnerable packages. Of course the major flaw with this statement is that there aren't a whole these "proactive" users. However, if there are enough, some will spot the activity, and raise concern, which will ultimately protect others when the evil mirror is shut down. Mike [0] http://security-tracker.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100606003753.f701e457.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Mon, 28 Jun 2010 13:54:28 +0200 Mike Hommey wrote: > On Mon, Jun 28, 2010 at 05:36:11AM -0600, Aaron Toponce wrote: > > Ah yes, Iceape. Their releases are so few and far between, this could > > possibly mean that we won't see Iceweasel 3.6 or Icedove 3.1 for some > > time, correct? Upstream Seamonkey 2.1 will be build against gecko 1.9.3, > > but its release date is TBD. Upstream Firefox 4 is due the end of the > > year, based on 1.9.3, and will likely be ahead of Seamonkey. So where > > does that put us? Seems trying to keep the two projects aligned is some > > task. :) > > (note 1.9.3 is apparently going to be reversioned to 2.0) > > > Will Iceweasel 4 go into Sid when Iceape 2.1 goes into Sid? > > 3.6 will go into sid when squeeze is released. It will remain in > experimental until then, except if the plans change. > 4.0 betas will go into experimental then. In the meanwhile, they will > probably be provided somewhere on mozilla.debian.net. > 4.0 will go into sid when it is released. > > > > First, TB 3.1 has just been released, and as such hasn't been widely > > > tested in Debian. It usually isn't very wise, that close to the expected > > > freeze time, to upload a new major release of a not exactly small and > > > trivial software. > > > > I can understand this, but I would imagine the release of Squeeze is at > > least 8-10 months out. We still have a good deal of RC bugs to get > > through. Of course, packages this size will add to the count. > > Supposedly, the freeze is somewhen in august. After that, getting a new > major version in the archive is a no-go. > > > > Second, for the reasons given earlier, releasing with iceweasel 3.6 and > > > icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not > > > be a huge problem, as we already didn't release lenny with iceape, but > > > see below. > > > > Iceape is a beautiful piece of software, and I have run it in the past. > > But market share shows that Seamonkey/Iceape users are the minority, > > with Firefox/Iceweasel and Thunderbird/Icedove the vast majority. > > Releasing Lenny without Iceape was the best move, IMO. > > If Debian accounted for market share, it would dump a whole lot of > packages. There are a lot of packages with less users than iceape. > > > > All in all, I still think releasing squeeze with iceape 2.0, iceweasel > > > 3.5 and icedove 3.0 is the best course of action. > > > > Is this really the best move? With Firefox 4 due the end of the year, > > and 3.6 will be a year old already, the security team will be supporting > > 3.5 after Mozilla stops it's support. Same might be the case with > > Icedove 3.0. > > Choosing between 3.5 and 3.6 on that alone is not enough. > As I said, Mozilla will also stop supporting 3.6 way before squeeze > security support ends. This discussion brings up an opportunity to debate the merrit of continuing to suffer the chilling effects of a self-interested upstream (i.e. mozilla no longer attempts to play well in the open source ecosystem since it has no impact on 90% of their marketshare). Based on their latest decision to go to a 6-month only support cycle, it will be impossible to support their package for the 3+ year lifetime of a stable release (especially since since they purposely leave out patch information in their advisories, which is needed to independently solve their problems). In fact, at the current rate, 3.5 will be end-of-lifed before squeeze gets out the door. Chilling affects have already been felt: etch had to drop support for iceweasel 6 months before its end-of-life as well. Also since 3.0 is already end-of-lifed, support for iceweasel in lenny will need to end soon (a year or more before the end of that release). There are a couple solutions to this problem. In light of the new upstream support timeframe, Ubuntu has decided to sacrifice stability (opting to push new major upstream releases into their stable versions) and engage in poor supportability/secuirity practices (using embedded code copies instead of system libraries) [0]. This path is unnacceptable for Debian. In my personal opinion, the only viable option left is to drop all mozilla and mozilla-depending packages from main, and provide them in backports (as suggested already in another message in this thread). Backports' rolling release model makes it the perfect avenue to adhere to mozilla's dictated treadmill. It may take quite a bit of work to excise the offending packages, but there is still quite a bit of time before the squeeze freeze; so it should be doable. With respect to upgrades from lenny, perhaps the iceweasel packages could upgrade to epiphany or chromium and provide a message about using backports informing the user about how to continue using iceweasel if that's really what they want. Losing mozilla wouldn't be that significant of an loss since there are plenty of other good options nowadays (webkit, konquerer, chromium, etc.), which wasn't the case a year or so a
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 11:57:20 +0200, Adam Borowski wrote: > On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote: > > and engage in poor supportability/secuirity practices (using embedded > > code copies instead of system libraries) [0]. This path is > > unnacceptable for Debian. > > > > In my personal opinion, the only viable option left is to drop all > > mozilla and mozilla-depending packages from main > > [...] > > Losing mozilla wouldn't be that significant of an loss since there > > are plenty of other good options nowadays (webkit, konquerer, chromium, > > etc.), which wasn't the case a year or so ago. > > Wait, wait... you promote webkit-based browsers, every single of which > embeds the complete webkit codebase -- while you name exactly that issue as > the reason why Ubuntu's approach to xulrunner is unacceptable. Hmm... > Yeah, indeed that approach is bad, but that's a reason to remove chromium > and konqueror which do use it, not iceweasel which doesn't. Like I said, that is hopefully just a temporary problem and will be fixed following the squeeze release. To clarify my point, it will be easier to support six forks of the same codebase rather than six forks of the same codebase plus a completely separate codebase as well (especially when those six forks are roughly feature-equivalent to the separate codebase). > Also, Chromium doesn't support even the base essentials, like working > AdBlock[1] or sane cookie handling[2]. And Konqueror is just a bad joke, > barely better than Dillo or Amaya (no, not the DD). It's open source (and in rapid development); if these are features interest you then them or pay someone to do it for you. > So your proposal would remove the only reasonably featured browser from > Debian. No, my proposal is to move the package to a better home: backports. Best wishes, Mike -- 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/20100629112400.b276dc06.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 09:37:46 +0200, Mike Hommey wrote: > On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote: > > Mozilla actively makes it hard to stay up to date > > (by providing as little information as possible in their advisories); > > webkit (for the most part except for Apple announcements) makes it > > easy. This means security fixes are going to happen a lot faster since > > there is a lot less downtime waiting for patches to by disclosed. > > Actually, that's not true. It's pretty easy to track the security > related changes in mercurial now (that was indeed a problem when mozilla > was still using CVS), and security bugs are as documented as Webkit's. > The only difference, for now, is that we have access to the Webkit bugs > while we (still) don't have access to the Mozilla ones. But that should > happen some day. > > IOW, your point is void ;) OK, point taken (I don't have any perspective on mozilla's inner workings, so I didn't know this). However, do you want to continue suffering with the workload required to support the mozilla packages? The core problem I see is that there are two very vulnerable codebases currently planned to be supported, and manpower could be roughly halved if the codebases were reduced to one. Best wishes, Mike -- 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/20100629113528.d113c16d.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 17:39:57 +0200, Mike Hommey wrote: > On Tue, Jun 29, 2010 at 11:35:28AM -0400, Michael Gilbert wrote: > > On Tue, 29 Jun 2010 09:37:46 +0200, Mike Hommey wrote: > > > On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote: > > > > Mozilla actively makes it hard to stay up to date > > > > (by providing as little information as possible in their advisories); > > > > webkit (for the most part except for Apple announcements) makes it > > > > easy. This means security fixes are going to happen a lot faster since > > > > there is a lot less downtime waiting for patches to by disclosed. > > > > > > Actually, that's not true. It's pretty easy to track the security > > > related changes in mercurial now (that was indeed a problem when mozilla > > > was still using CVS), and security bugs are as documented as Webkit's. > > > The only difference, for now, is that we have access to the Webkit bugs > > > while we (still) don't have access to the Mozilla ones. But that should > > > happen some day. > > > > > > IOW, your point is void ;) > > > > OK, point taken (I don't have any perspective on mozilla's inner > > workings, so I didn't know this). However, do you want to continue > > suffering with the workload required to support the mozilla packages? > > The core problem I see is that there are two very vulnerable codebases > > currently planned to be supported, and manpower could be roughly halved > > if the codebases were reduced to one. > > The point in releasing squeeze with 3.5/1.9.1 is precisely to only have > to support one codebase for all mozilla based software in debian... The point I was trying to make in that paragraph is that there are two browser codebases (webkit and mozilla) that need to be supported, which could be halved by dropping one. On the current path, there will be three mozilla versions that need to be supported; lenny, squeeze, and unstable (which is of course quasi-supported). On the new path, this could be reduced to one version; backports. Mike -- 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/20100629115147.3b6364df.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 17:29:20 +0200, Mike Hommey wrote: > On Tue, Jun 29, 2010 at 11:24:00AM -0400, Michael Gilbert wrote: > > No, my proposal is to move the package to a better home: backports. > > Same question as for Md with volatile: > > apt-cache rdepends xulrunner-1.9.1 libmozjs2d libwebkit-1.0-2 > > What do you do with these packages ? backports too ? Do you realize some > of these are part of the core of the GNOME desktop ? Yes, I would say drop them all. The maintainer should be free to choose whether they want to continue to support the package in backports, convert the backend to use webkit, or to drop the package altogether. Which of those are gnome core packages? Only liferea, galeon, evolution-rss, and yelp stick out to me, but I don't use gnome. Yelp has a webkit backend, so the mozilla backend could be disabled. > Also, using backports doesn't magically solve the issue that all these > package need to be updated when there is a new ABI/API (which basically is > the case with major xulrunner versions) I agree, anyone planning to maintain those packages in backports will indeed have to suffer through that, but it's just the fact of life with mozilla. Mike -- 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/20100629120604.6d8a7462.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 11:03:19 +0200, Josselin Mouette wrote: > Le mardi 29 juin 2010 à 02:57 -0400, Michael Gilbert a écrit : > > Losing mozilla wouldn't be that significant of an loss since there > > are plenty of other good options nowadays (webkit, konquerer, chromium, > > etc.), which wasn't the case a year or so ago. > > I would love to get rid of it, but unfortunately there is still a way > too large number of broken websites that won’t work without Firefox. I've only encounter three or four websites in the last year that didn't work quite right with webkit (I've been using midori for at least that long as my primary browser), and upstream has been surprisingly responsive to fixing those issues very quickly. Best wishes, Mike -- 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/20100629121745.bfdac139.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 18:31:09 +0200, Mike Hommey wrote: > On Tue, Jun 29, 2010 at 12:06:04PM -0400, Michael Gilbert wrote: > > On Tue, 29 Jun 2010 17:29:20 +0200, Mike Hommey wrote: > > > On Tue, Jun 29, 2010 at 11:24:00AM -0400, Michael Gilbert wrote: > > > > No, my proposal is to move the package to a better home: backports. > > > > > > Same question as for Md with volatile: > > > > > > apt-cache rdepends xulrunner-1.9.1 libmozjs2d libwebkit-1.0-2 > > > > > > What do you do with these packages ? backports too ? Do you realize some > > > of these are part of the core of the GNOME desktop ? > > > > Yes, I would say drop them all. The maintainer should be free to > > choose whether they want to continue to support the package in > > backports, convert the backend to use webkit, or to drop the package > > altogether. > > > > Which of those are gnome core packages? Only liferea, galeon, > > evolution-rss, and yelp stick out to me, but I don't use gnome. Yelp > > has a webkit backend, so the mozilla backend could be disabled. > > > > > Also, using backports doesn't magically solve the issue that all these > > > package need to be updated when there is a new ABI/API (which basically is > > > the case with major xulrunner versions) > > > > I agree, anyone planning to maintain those packages in backports will > > indeed have to suffer through that, but it's just the fact of life > > with mozilla. > > Seeing how many problems there still are with webkit backed GNOME > applications, that sure is only a mozilla problem... Apologies, I should have said that was a "fact of life for any abi/api transition", so there is nothing special about a mozilla transition (except that it touches a lot of packages) whether or not its in backports or elsewhere. Mike -- 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/20100629123520.5a7dcd17.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 12:35:19 -0400, Joey Hess wrote: > Mike Hommey wrote: > > On Tue, Jun 29, 2010 at 11:51:47AM -0400, Michael Gilbert wrote: > > > The point I was trying to make in that paragraph is that there are two > > > browser codebases (webkit and mozilla) that need to be supported, which > > > could be halved by dropping one. > > > > As long as there are people to support both, why drop one? I mean, > > you're not involved in mozilla security support, why do you even > > care? > > FWIW, this does not seem to be limited to one person, or one codebase. > This apparently well-meaning idea that we can improve Debian's security > etc by talking people out of doing jobs that they have volunteered to > do, and are doing, is a recent trend that I really don't understand. I really hope I haven't come across this way. It was certainly not my intention. Like I said in my first post to this discussion, I think a debate on the merit of the status quo with respect to the mozilla packages is greatly needed right now. If the result of this debate is maintaining the status quo, then that's just fine with me, but at least all of the dirty laundry has been aired, and an informed decision made. I also stated that I did't want to diminish Mike's work in any way. He's done a great job, and I hope the package will continue to be maintained. I just think that a more appropriate home is in backports. This is the same solution that has been implemented for clamav due to its short upstream support time frame. As for my non-involvement in mozilla security, that actually isn't true. I actually spent a great deal of effort to triage all of the mozilla issues in the security tracker about a year ago, and submitted bugs for the open ones. However, as a user, I have no access to mozilla patches, so I could go no further. I did what I could to improve mozilla security, then I just simply lost interest because I found webkit to be actually tractable. Anyway, I think debate is healthy, and hopefully a broadly beneficial solution can be reached. Best wishes, Mike -- 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/20100629133446.a1f3e0e4.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote: > Hi! > > Am 29.06.2010 17:24, schrieb Michael Gilbert: > > > No, my proposal is to move the package to a better home: backports. > > You don't know the current policies WRT packages in backports and about > their reasoning, do you? I believe I do. Backports are for recompilations of unstable packages for the stable releases. Hence, that's why it seems like a good solution here. volatile seems like it has a much more restrictive set of criteria, but I suppose it would also be a good solution if its allowable. I just realized that clamav actually went into volatile, and it was flasplugin-nonfree that went to backports. Anyway those two show the two roads already traveled. It's a matter of debating the best one for this case. Honestly, the ideal solution would be for either backports or volatile to become officially supported (which from what I can tell has been in discussion for a long time now). In fact, if one or the other did become official, there would be no need for both. Best wishes, Mike -- 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/20100629155031.80bc198d.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 22:25:06 +0200, Gerfried Fuchs wrote: > Hi! > > * Michael Gilbert [2010-06-29 21:50:31 CEST]: > > On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote: > > > Am 29.06.2010 17:24, schrieb Michael Gilbert: > > > > > > > No, my proposal is to move the package to a better home: backports. > > > > > > You don't know the current policies WRT packages in backports and about > > > their reasoning, do you? > > > > I believe I do. Backports are for recompilations of unstable packages > > for the stable releases. > > Thanks for excellently stating that you do *not* know about what is > backports about and for, you couldn't have done that better. The second paragraph on the front page of backports.org says pretty much the same exact thing in different words. > Also, weren't it you who responded to a mail about getting the security > tracker informations straight that it is too much of trouble for you to > check backports informations, too? I fail to see how that would get > better if you want to push more stuff into backports? Yes, and I also stated that if backports were to become an officially supported release, I would adapt my workflow to support it. But until then, it doesn't make sense. Best wishes, Mike -- 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/20100629165216.a3e20b7d.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 22:26:04 +0200, Stefano Zacchiroli wrote: > On Tue, Jun 29, 2010 at 12:35:19PM -0400, Joey Hess wrote: > > This apparently well-meaning idea that we can improve Debian's > > security etc by talking people out of doing jobs that they have > > volunteered to do, and are doing, is a recent trend that I really > > don't understand. > > Amen. > > > On Tue, Jun 29, 2010 at 01:34:46PM -0400, Michael Gilbert wrote: > > I really hope I haven't come across this way. It was certainly not > > my intention. Like I said in my first post to this discussion, I think > > a debate on the merit of the status quo with respect to the mozilla > > packages is greatly needed right now. If the result of this debate is > > maintaining the status quo, then that's just fine with me, but at least > > all of the dirty laundry has been aired, and an informed decision made. > > Well, I confess that it did come across that way also to me, and > probably to many others. The impression was something like: “someone not > working on iceweasel security in Debian is trying to convince someone > else which is working on that, not only to stop, but also to throw out > of the Debian main archive iceweasel all together”. > > Try looking at it that way for a minute and you surely understand how > surreal the debate looked like from the outside :-) I can certainly see that perspective, and I can see now that I've chosen my words poorly, which has lead to a major communication breakdown. Hopefully restating clearly this time: my proposal is to no longer distribute mozilla packages in the main stable repository; instead they can be maintained in backports (or volatile) at the choosing of the maintainers of those packages (or converted to webkit to remain in stable main). I propose no changes to the mozilla packages in unstable or experimental. > > As for my non-involvement in mozilla security, that actually isn't > > true. I actually spent a great deal of effort to triage all of the > > mozilla issues in the security tracker about a year ago, and submitted > > bugs for the open ones. However, as a user, I have no access to > > mozilla patches, so I could go no further. I did what I could to > > improve mozilla security, then I just simply lost interest because I > > found webkit to be actually tractable. > > To the risk of repeating myself, Debian is a do-ocracy: who does the > work and does it well (as in this case!) gets the right to decide. If > you stopped working on iceweasel security, you kind of gave up your > rights of directly affecting the course of the package. Understood; however, ill-conceived security disclosure policies impede this process. I would fix the issues myself, but I am restricted from doing so because of upstream mozilla disclosure policy. That policy is the primary reason that I am no longer interested in mozilla. I don't really see my interests changing without changes happening upstream first. Best wishes, Mike -- 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/20100629170727.3d70722d.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 17:07:27 -0400 Michael Gilbert wrote: > Hopefully restating clearly this time: my proposal is to no longer > distribute mozilla packages in the main stable repository; instead they > can be maintained in backports (or volatile) at the choosing of the > maintainers of those packages (or converted to webkit to remain in > stable main). I propose no changes to the mozilla packages in unstable > or experimental. I'm going to make one more attempt at assembling a sound argument supporting this proposal. Note that my only vested interest in the outcome of any decision is reducing the burden on the security team. I understand that Mike Hommey is ultimately responsible for any decision that may be made, and the consequences of that decision primarily only affect the mozilla maintainers' future workload (with some fallout on the security team). In the following lists, I break down the advantages and disadvantages of each approach. If there are other thoughts, I would be happy to see them included. Advantages of switching to backports: - very simple for the maintainers to keep up to date with respect to security updates (a matter of just recompiling the unstable/testing package for stable) - one (or almost the same) code base across backports and testing/unstable (and potentially oldstable-backports). Disadvantages of switching to backports: - no official security support. - potential confusing for users since the mozilla packages will not be available in a default install. Advantages of maintaining the status quo: - continue to provide a highly demanded packages where users expect to find it. Disadvantages of maintaining the status quo: - part way through the release, security support will end and many users won't even notice (unless they're subscribed to debian-security); leaving a lot of the Debian user base vulnerable. - this will be a lot more work for the maintainers due to manual backports of mozilla patches - three different code bases to support: stable, testing/unstable, and oldstable (when that is supported) Anyway, I hope I've done a better job of clearly defining the scope of the problem. I look forward to some constructive debate. Best wishes, Mike -- 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/20100629203125.af7af9af.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Wed, 30 Jun 2010 09:08:36 +0200 Mike Hommey wrote: > > Disadvantages of maintaining the status quo: > > - part way through the release, security support will end and many > > users won't even notice (unless they're subscribed to > > debian-security); leaving a lot of the Debian user base vulnerable. > > That surely can be arranged with a special security upload of the > package displaying a message to the user in some way (which, IMHO, > should be done with any package which security support is dropped) I think that's a great solution. > > Anyway, I hope I've done a better job of clearly defining the scope of > > the problem. I look forward to some constructive debate. > > Your debate is pointless. Why do you care ? What is your agenda ? Do you > want me to list the same kind of problems webkit gives ? IMHO, webkit > gives more headaches than mozilla. Simply because despite all you can > say, you have several codebases for each debian suite. Each of which may > or may not have some of the security issues. This is in no way any > better than with mozilla. > > As for access to the security bugs information, relying on the public > information is not enough anyway if you want to provide *timely* > security updates. The current webkit support in debian is way after > the facts. The current mozilla support in debian is only a few days > off, merely because the CVE and MFSA information is not available to me > until upstream releases its security update. > > Also, speaking of upstream security support, I have yet to see an > upstream "stable" release of webkit that includes security fixes. I > don't remember there was any for the GTK port, despite a promise for > some, and I don't think there was any for the QT port either. > At least, Mozilla continues to support older releases for some months > after a new major release. So far, that doesn't appear to have been > true for webkit. Actually, apart from Chromium, I don't think there are > releases with security fixes in webkit at all. And even then, I don't > think Chromium upstream releases security fixes for older major > releases. > > The best you can do is actually to go through the CVEs and webkit > security bugs, and find the relevant patches in svn, hoping they are not > dependent on changes in the codebase between the moment it was fixed in > svn, and the codebase you're trying to patch. And then, you have to > account for the fact that you have several codebases in each debian > suite. How exactly is that supposed to be better ? So, why exactly would > we have to chose webkit over mozilla ? Because it's the new cool kid on > the block ? > > Finally, the security team hasn't been involved in patching mozilla for > years. AFAIK, patching is what makes most of the work in security > support. Except this work is done by the mozilla maintainers and has > been for a while. What exactly are you trying to get off the security > team shoulders ? Handling a security build and issuing a DSA ? Following > the advisories for mozilla ? I completely concur. Webkit has some growing pains and poses its own set of unique issues that need to be addressed; which I plan to work. > All in all, will you just do something really constructive and stop this > crusade of yours ? As stated previously, my intent was simply to debate the consequences of mozilla's new extremely short support timeframe; certainly no crusade, and certainly no reason to turn the heat up. Since you're content with the amount of work involved with security backports, and as long as users are loudly informed when suppport gets terminated, then all of my concerns are addressed. At this point I'm perfectly content with the outcome. Thanks for taking the time to resolve the issues. Best wishes, Mike -- 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/20100704162015.e6f72ea5.michael.s.gilb...@gmail.com
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
On Thu, 22 Jul 2010 15:30:36 +0100, Steve McIntyre wrote: > On Thu, Jul 22, 2010 at 04:25:34PM +0200, Alexander Reichle-Schmehl wrote: > >Hi! > > > >Am 22.07.2010 09:21, schrieb Josselin Mouette: > > > >>> I think with our next release, we will have got less users. Why? > >>> We stripped out all binary only firmware images from Linux and put them > >>> mostly into the non-free linux-firmware image. > >> If you think this is a problem, you could help with providing non-free > >> enabled installation images instead of whining. > > > >I might remember incorrectly, but isn't that already implemented? > > Yes. We have parallel versions of the netinst images that include > firmware packages. That's a great start. However, Patrick is advocating images that autodetect and install drivers/packages for non-free hardware as well (not just firmware). That could probably be solved straightforwardly if someone were to just go ahead implement it; perhaps by someone already expressing interest in it??? BTW, where are the non-free images at? They don't appear to be available from cdimage.debian.org [0] or from the debian-installer page. Best wishes, Mike [0] http://cdimage.debian.org/cdimage/squeeze_di_alpha1/i386/iso-cd/ -- 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/20100722161315.47967e86.michael.s.gilb...@gmail.com
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
On Mon, 26 Jul 2010 12:49:00 +0100, Ian Jackson wrote:
> Brian May writes ("Re: How to make Debian more attractive for users, was: Re:
> The number of popcon.debian.org-submissions is falling"):
> > I would really like to see a HTML/HTTP browser based interface for the
> > BTS. I would have several advantages:
>
> I would strongly resist any such suggestion, for the reasons I have
> already explained.
>
> In summary: We don't have a lack of bug reports, we have a lack of
> developer time. Increasing the number of bug reports will take away
> developer time for triage, for no benefit.
>
> Simply, we do not need to, and should not, make reporting bugs easier.
As a point of reference, Ubuntu disabled their easy-to-find http bug
submission page because of this very problem. Although it is still
possible to submit bugs via http, you need to know the url scheme;
something like http://launchpad.net/bugs//+submit.
I think detailed bug submission instructions (including philosophy on
why bugs are useful, how Debian is different/good WRT bug fixing, and
how to write a good report) in the default browser home pages would go a
lot further toward educating users and improving bug reports than
anything else. A reportbug-ng quicklaunch icon by default on all of the
desktop environments may be useful as well.
Best wishes,
Mike
--
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/20100726112350.65da7d58.michael.s.gilb...@gmail.com
Re: How to make Debian more attractive for users
On Mon, 26 Jul 2010 17:05:19 +0100, Russell Gadd wrote: > I spotted this topic in Debian Project News. I am a non-technical Debian > user (Lenny AMD 64 bit) - I have tried Ubuntu a couple of times but came > back to Debian because of its stability. The main problem I have is lack of > up to date Flash in the browser (Iceweasel) and I think this is a common > problem with other users. I have to resort to using Microsoft Windows > sometimes as Flash is being used more and more by websites. Maybe it's a > Linux problem not just Debian - I don't know, but it is frustrating. This is a bit off-topic for debian-devel, and should probably be posted as a question to debian-u...@lists.debian.org. Please send replies there. Up-to-date flash support is provided by the flashplugin-nonfree package available from Debian's unofficial backports.org [0]. There is no gnash backport available, but that would be something nice to have if someone were interested in that (each backport needs an interested maintainer). Best wishes, Mike [0] http://backports.org/dokuwiki/doku.php?id=instructions -- 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/20100726123116.0aea9dd8.michael.s.gilb...@gmail.com
Re: Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files
On Fri, 13 Aug 2010 09:58:07 -0700, Russ Allbery wrote: > Raphael Hertzog writes: > > > As suggested by Ian on -devel (see attachment), it would be nice to have > > a way to remove files during unpack of a source package to hide non-free > > files from our users without stripping them from the original tarball. > > > I also prefer this approach over repacking upstream files so let's > > implement this feature. > > I'm pretty sure ftp-master isn't going to allow source packages with > non-free content in the main archive regardless of whether that content is > hidden on unpack (I certainly wouldn't if I were them), so implementing > this is kind of pointless for Debian. What if the list of binary components was part of the watch file instead; so that new upstream sources could be automatically stripped of those non-free bits by uscan right after download. Best wishes, Mike -- 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/20100813130134.ba42fd33.michael.s.gilb...@gmail.com
Re: Bugs in Backported Packages
On Tue, 7 Sep 2010 21:56:21 +0200, Sebastian Harl wrote: > Hi, > > On Tue, Sep 07, 2010 at 12:46:12PM -0700, Don Armstrong wrote: > > An alternative solution is to just have reportbug mail the backport > > bug reporting mailing list, and have people bounce messages as > > appropriate to the BTS. > > Imho, this is the most sensible approach for now. The number of bugs > reported to backports-users was rather low in the past, so there is not > much benefit from spending a lot of time on something that's gonna safe > a bit of time only. If this happens to change at some point in the > future, we can still think about more "advanced" ways of handling this. Doing a quick look at the backports mailing list archive, there are less than 10 bugs reported per month on average. That is for hundreds of packages. Doing some fuzzy math, if you have a package that got backported, you may see an additional 10/100 = 0.1 bug reports per month (or roughly one bug per year). I don't see how that could be remotely considered overburdensome. Backports has now been declared "officially" supported by the project as a whole. That made it the collective responsibility of all Debian Developers whether or not individuals in particular like it or not. Best wishes, Mike -- 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/20100907161848.5ead8268.michael.s.gilb...@gmail.com
Re: Bugs in Backported Packages
On Tue, 7 Sep 2010 22:27:47 +0200, Sebastian Harl wrote: > Hi, > > On Tue, Sep 07, 2010 at 04:18:48PM -0400, Michael Gilbert wrote: > > On Tue, 7 Sep 2010 21:56:21 +0200, Sebastian Harl wrote: > > > On Tue, Sep 07, 2010 at 12:46:12PM -0700, Don Armstrong wrote: > > > > An alternative solution is to just have reportbug mail the backport > > > > bug reporting mailing list, and have people bounce messages as > > > > appropriate to the BTS. > > > > > > Imho, this is the most sensible approach for now. The number of bugs > > > reported to backports-users was rather low in the past, so there is not > > > much benefit from spending a lot of time on something that's gonna safe > > > a bit of time only. If this happens to change at some point in the > > > future, we can still think about more "advanced" ways of handling this. > > > > Doing a quick look at the backports mailing list archive, there are less > > than 10 bugs reported per month on average. That is for hundreds of > > packages. Doing some fuzzy math, if you have a package that got > > backported, you may see an additional 10/100 = 0.1 bug reports per > > month (or roughly one bug per year). I don't see how that could be > > remotely considered overburdensome. > > Just to make that clear: I did not talk about any burden for the package > maintainers My response was directed toward the complaints about mail/bug overload elsewhere in this thread. Best wishes, Mike -- 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/20100907163212.a8d5fa25.michael.s.gilb...@gmail.com
Re: Bugs in Backported Packages
On Tue, 7 Sep 2010 13:48:09 -0700, Steve Langasek wrote: > On Tue, Sep 07, 2010 at 04:18:48PM -0400, Michael Gilbert wrote: > > Doing a quick look at the backports mailing list archive, there are less > > than 10 bugs reported per month on average. That is for hundreds of > > packages. Doing some fuzzy math, if you have a package that got > > backported, you may see an additional 10/100 = 0.1 bug reports per > > month (or roughly one bug per year). I don't see how that could be > > remotely considered overburdensome. > > A single package I'm comaintainer of that has a backports.org backport has > received at least 12 bug reports to the BTS over the past year referencing > bpo versions (not counting any that might have been retargeted using > found/notfound after being filed). The reason there are few bug reports on > the mailing list is because these *already* come to the BTS. > > For the package in question, the backports are done by a fellow > comaintainer, so I'm not complaining about the bug traffic; but that doesn't > mean it's *right* for that traffic to be going to the BTS by default. > > > Backports has now been declared "officially" supported by the project > > as a whole. That made it the collective responsibility of all > > Debian Developers whether or not individuals in particular like it or > > not. > > False. So you're saying that a move to debian.org actually does not make it officially part of Debian (even though a lot of blogs are claiming just that)? If that's the case then I agree that there is no collective responsibility. That's good since it eliminates what was going to be a significant additional burden for the security team. What would be required to finally declare it "officially" supported? A vote? Best wishes, Mike -- 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/20100907171314.55c860c5.michael.s.gilb...@gmail.com
Re: Bugs in Backported Packages
On Tue, 7 Sep 2010 15:03:56 -0700 Steve Langasek wrote: > On Tue, Sep 07, 2010 at 05:13:14PM -0400, Michael Gilbert wrote: > > > > Backports has now been declared "officially" supported by the project > > > > as a whole. That made it the collective responsibility of all > > > > Debian Developers whether or not individuals in particular like it or > > > > not. > > > > False. > > > So you're saying that a move to debian.org actually does not make it > > officially part of Debian (even though a lot of blogs are claiming just > > that)? If that's the case then I agree that there is no collective > > responsibility. That's good since it eliminates what was going to be a > > significant additional burden for the security team. > > No, I'm saying that being "officially part of Debian" does not make it > "officially supported by the project as a whole" or "the cllective > responsibility of all Debian Developers". You're missing my point. My concern is the stonewalling of the collective effort of those working to make backports a well-supported, user-friendly part of the Debian ecosystem. And all of in the name of a solved problem: email management. I just don't get it. Your campaign was effective against the useful package emails, and I don't really want to see that happen again. Let the collective do its work without interference. Please :) Best wishes, Mike -- 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/20100907205756.5406657b.michael.s.gilb...@gmail.com
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
On Thu, 23 Sep 2010 14:30:30 +0200, Raphael Hertzog wrote: > Personally I would like to have snapshots every 2 or 3 months. Colin > Watson pointed out in an LWN comment (http://lwn.net/Articles/406597/): > | There's a good chance that CUT could serve a dual purpose of making it > | easier to prepare new stable releases. As many projects have found, if you > | have more-or-less releaseable checkpoints every so often then it's easier > | to prepare a better-than-usual one for your gold release. > > And I agree with him in general. By officially endorsing a constantly > usable rolling distribution, it's clear to everybody that what goes in > unstable should always be in a releasable state. There are of course a couple large downsides to this. It becomes next to impossible to make big/interesting changes across the distribution, and developers will be forced (due to the short time frame) into being very conservative with their uploads. Today, maintainers have the important freedom to make big changes at the beginning of the release cycle knowing that they have over a year to fix any resulting problems, and I think it would be a shame to take that away. I view testing snapshots more as a preview for a very limited subset of users; the type that are looking for rather fresh software and would be perfect candidates for testing, but they aren't willing to deal with the daily upgrade treadmill. Again, I think this is a rather small group of users. Mosts users that fall into the "I need the latest shiny" category are served fairly well by the existing testing. They just need a constantly working installer. Best wishes, Mike -- 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/20100923135023.b45d5e7e.michael.s.gilb...@gmail.com
Re: Bits from the Security Team (for those that care about bits)
On Wed, 26 Jan 2011 14:47:52 +0100, Goswin von Brederlow wrote: > Thijs Kinkhorst writes: > > > * Issues in specific packages > > > > We further discussed some specific problematic packages. One example is > > ia32-libs, which is difficult because it includes 100+ other source > > packages. This will be handled better for Squeeze: we'll have to ensure > > it's as up to date as possible at time of release, and will keep > > updating it in stable point updates to include newer package versions > > from the security archive (or the stable release itself). > > A while back I looked into making the detection of security bugs in > ia32-libs (which is all just code duplication of other packages) > automatic. But the config for that detection would have needed 100+ > config entries, which would ahve become verry ugly to maintain. > > Has there been any change for this? I think it will be easier to just track the issues in the security tracker manually. I'm already tracking all of the packages in ia32-libs as embedded code copies, and I wrote a script that inserts code copy info into the CVE list automatically. Anyway, I think this can be left up to the security team. Best wishes, Mike -- 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/20110126114757.aab379fd.michael.s.gilb...@gmail.com
Re: Upstream "stable" branches and Debian freeze
On Mon, 31 Jan 2011 15:25:11 +0100, Max Kellermann wrote: > Hi, > > I'm the upstream maintainer of the Music Player Daemon project, and > receive a number of support requests / bug reports from Debian users > who use the outdated version 0.15.12 of "mpd", currently in testing. > These bugs were already fixed in newer maintenance releases. > > I know that Debian does not upgrade upstream versions at this point. > However, I would like to know if upgrading within an upstream "stable" > branch like MPD's v0.15.x would be acceptable. > > It seems common practice to cherry-pick upstream patches, and apply > them to the old Debian package. That however seems like a waste of > time, since all commits in our stable branch are bug fixes which would > need to be picked, and in the end, you would essentially have version > 0.15.15 which prints "0.15.12" on --version, just to fulfill Debian's > policy. > > For me personally, this boils down to the question: shall I continue > to maintain the old branch v0.15.x? (there is also v0.16.x which is > also in maintenance mode) It's too late now to make any changes for the initial squeeze release, but you (or the Debian maintainer) can propose an update for 6.0.1, which will be reviewed by the release team. If the changes have a low chance of breaking things, which it sounds like in this case, they will usually accept it. Best wishes, Mike -- 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/20110131105511.73108247.michael.s.gilb...@gmail.com
Re: The future of m-a and dkms
On Sun, 13 Feb 2011 23:52:22 +0100 Christoph Anton Mitterer wrote: > On Sun, 2011-02-13 at 23:21 +0100, Patrick Matthäi wrote: > > since we have got a stable release with dkms now, I am asking myself, if > > it is still necessary to support module-assistant. > > dkms is IMHO the better system and maintaining two different systems for > > kernel modules is a bit bloated. > With dkms, can you also create packages of the modules? > > At least I found it always very useful, to create modules with m-a, or > via make-kpkg, and provide them via local archives to all my Debian > boxes. Can save quite some compilation time, and one doesn't need kernel > header + build packages etc. on all nodes. Yes, there is the "mkdeb" command-line option, but I suppose that doesn't get as much testing as it should. Best wishes, Mike -- 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/20110213180010.7463399d.michael.s.gilb...@gmail.com
Re: Release file changes
On Mon, 21 Feb 2011 18:55:13 +0100, Florian Weimer wrote: > * Joerg Jaspert: > > > I additionally opened a bug with apt to add support for SHA512SUM, so > > we can start using them. As soon as that is possible I intend to drop > > SHA256 and end up with SHA1/SHA512 only. > > Please don't. I have more faith in SHA-256 than SHA-512. What indications are there that SHA-512 is weak? Best wishes, Mike -- 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/20110221130502.dfb4c885.michael.s.gilb...@gmail.com
Re: Release file changes
On Mon, Feb 21, 2011 at 3:05 PM, Joerg Jaspert wrote: > On 12398 March 1977, Joey Hess wrote: > >>> until today our Release files included 3 Hashes for all their entries: >>> MD5SUM, SHA1, SHA256. I just modified the code to no longer include >>> MD5SUM in *all* newly generated Release files. >> When will that affect Release files for stable? Next point release? >> Because that unfortunatly completly breaks debmirror.. > Yep. debmirror, reprepro, debootstrap and cdebootstrap seem to be the > tools that can't deal with this. The latter two are serious enough to > keep the change away from oldstable forever, and stable at least until > after next point release, should they get updated there. Can we get this reverted at least until the major tools can actually cope with the change (i.e. for the next point release)? The fact that this causes a regression in stable's debootstrap is rather unfortunate. Stable is called "stable" because its functionality isn't supposed to suddenly change. Best wishes, Mike -- 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/aanlktinkmmpqjigr3tmgzurozl5izbjx0rwue+35f...@mail.gmail.com
Re: maintainer ignores bug
On Sat, 26 Feb 2011 17:52:02 +0200 Dmitry Baryshev wrote: > Hello guys. > > I've filed a bug on reportbug, but its maintainer ignores it, and continues > to close it without any troubleshooting or debug. I did a simple > troubleshooting by myself, but maintainer ignored it and closed the bug > again. With whom I can talk about this strange situation? The bug itself: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599476 > > Please CC any comments. Thanks! It looks like its an issue with your choice of .gtkrc files. Tahoma is a microsoft font and will not be on a debian system by default, so that may be the problem itself. You can just remove or back up those files, and you should be fine. Mike -- 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/20110226114546.146f5aa9.michael.s.gilb...@gmail.com
Call for Testing: Unofficial Debian Monthly Testing Snapshot Release Candidate (version 2011.03rc1)
Hello world, I am pleased to announce the very first unofficial Debian monthly testing snapshot release candidate (version 2011.03rc1). This release is currently available in two flavors, i386 and amd64, as mini iso images (16 MiB each) downloadable from: http://alioth.debian.org/~gilbert-guest/snapshots/debian-testing-snapshot-2011.03rc1-i386-mini.iso http://alioth.debian.org/~gilbert-guest/snapshots/debian-testing-snapshot-2011.03rc1-amd64-mini.iso These files can be written to CD or DVD media or directly to a USB stick. Instructions for USB installation can be found here: http://www.debian.org/releases/squeeze/i386/ch04s03.html.en The testing period will be 5 days, and if no showstoppers are found in that time frame, this will be the 2011.03 final release, which is currently targeted for March 6th. Since this is not a stable release, a much reduced subset of bugs will be considered showstopping (a different criteria than stable's release critical bugs). These only include: 1. Failure to install from scratch using default/common options 2. Failure to boot into a graphical environment There may be more criteria identified in the future. If you think an issue qualifies as a showstopping bug, please send a message to cut-t...@lists.alioth.debian.org, and we will determine whether it is worth delaying the release. If showstopper bugs are indeed found, then the previous month's nightly generated media will be bisected to find the one prior to introduction of the bug. That will be the second release candidate, and there will be another announcement and 5 day testing period for that. Note that these monthly snapshot releases will be guaranteed to be upgradable (all new releases will have >= package versions compared to the previous release). However, there is no guarantee that there won't be breakages or regressions in particular packages between upgrades. This may be somewhat solvable via automated piuparts upgrade testing in the future. This will need someone interested to work on this particular problem. IMPORTANT: release candidates will not necessarily be upgradable since subsequent versions may include packages that are older than those in the previous version. Please consider this carefully before installing from release candidate media on important machines. Note also that there will be no inherent security support for these snapshot releases. The images do automatically set up testing-security as an apt source during installation, so any DTSA's (Debian Testing Security Advisories) will be automatically applied to snapshot installations. However, the security team does not issue many updates this way anymore (optioning instead to primarily use unstable uploads as a means to fix testing). This is another area that could potentially be improved if there are volunteers interested in this problem. For more information on current testing security processes, see: http://svn.debian.org/wsvn/secure-testing/doc/narrative_introduction Ideally for those wishing to have a mostly security supported system, the snapshot media will simply be a reliable stepping stone for installation followed by an upgrade to testing proper, which does receive quasi-official support from the security team (i.e. uploads to unstable that transition to testing). Note that this is an unofficial project since it does not come with the backing or support from Debian as a team, but hopefully that will change in the future as the concept is proven out. This message is being limited only to the debian-devel list to (hopefully) keep the load on existing resources small for now, and to determine whether a more robust hosting solution will be necessary for future releases. This also provides a chance for feedback and contributions from the devel community before attempting to target a wider audience. Please keep in mind that this is an unofficial test/development release before spreading the word too much. Anyway, enjoy! And send feedback to cut-t...@lists.alioth.debian.org. Best wishes, Mike Gilbert -- 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/20110228233607.51da8370.michael.s.gilb...@gmail.com
Unofficial Debian Monthly Testing Snapshot Release (version 2011.03 final)
Hi all, I am pleased to announce the very first unofficial Debian monthly testing snapshot release (version 2011.03). It is currently available in two flavors as mini iso images (for i386 and amd64 at 16 MiB each) downloadable from: http://alioth.debian.org/~gilbert-guest/snapshots/2011.03/debian-testing-snapshot-2011.03-i386-mini.iso http://alioth.debian.org/~gilbert-guest/snapshots/2011.03/debian-testing-snapshot-2011.03-amd64-mini.iso These files can be written to CD or DVD media or directly to a USB stick. Instructions for USB installation can be found here: http://www.debian.org/releases/squeeze/i386/ch04s03.html.en IMPORTANT: There will be no inherent security support for these snapshot releases. The images do automatically set up testing-security as an apt source during installation, so any DTSA's (Debian Testing Security Advisories) will be automatically applied to snapshot installations. However, the security team does not issue many updates this way anymore (optioning instead to primarily use unstable uploads as a means to fix testing). This is an area that could potentially be improved if there are volunteers interested in this problem. For more information on current testing security processes, see: http://svn.debian.org/wsvn/secure-testing/doc/narrative_introduction Ideally for those wishing to have a mostly security supported system, the snapshot media will simply be a reliable stepping stone for installation followed by an upgrade to testing proper, which does receive quasi-official support from the security team (i.e. uploads to unstable that transition to testing). Note that this is an unofficial project since it does not come with the backing or support from Debian as a team, but hopefully that will change in the future as the concept is proven out. This message is being limited only to the debian-devel list to (hopefully) keep the load on existing resources small for now, and to determine whether a more robust hosting solution will be necessary for future releases. This also provides a chance for feedback and contributions from the devel community before attempting to target a wider audience. Please keep in mind that this is an unofficial test/development release before spreading the word too much. Anyway, enjoy! And send feedback to cut-t...@lists.alioth.debian.org. Best wishes, -- 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/20110306180627.f8229658.michael.s.gilb...@gmail.com
Re: let missing-debian-source-format lintian tag be a warning!
On Tue, Jul 15, 2014 at 3:50 PM, Scott Kitterman wrote: > It would be nice, however, to have a way to specify the alternate behavior in > a consistent reliable way (meaning something I can put in the package when I > add source/format). Archive consistency is far more important than individual maintainer preference about this behavior. People that work on lots of different packages deserve dpkg-source to act consistently across the entire archive. This would be far better solved with a system conffile of some sort like /etc/dpkg/dpkg-source.cfg, which admittedly doesn't exist yet. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MPWsRUi0Lw29s3H7Vh1+_4p=c2kovlge81ytcb8yv9...@mail.gmail.com
Re: Reintroducing FFmpeg to Debian
On Tue, Aug 5, 2014 at 11:45 AM, Wookey wrote: > I really don't see sufficient reasons why we shouldn't at least put it > experimental so that maintainers can easily test this stuff. The problem is an undermanned ftpmaster team [0], so help there is probably appreciated and the obvious way to bring this thread to conclusion. Best wishes, Mike [0] https://ftp-master.debian.org/stat.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MOzT7ArtYbDwnWUxtvWVkcTO34=adwl5jadremt-ru...@mail.gmail.com
Re: Reverting to GNOME for jessie's default desktop
On Fri, Aug 8, 2014 at 12:41 AM, Joey Hess wrote: >> Hardware: GNOME 3.12 will be one of the few desktop environments to support >> HiDPI displays, now very common on some laptop models. Lack of support for >> HiDPI means non-technical users will get an unreadable desktop by default, >> and >> no hints on how to fix that. > > I think the above are fairly big points. > > It would be helpful to see a pointer to a bug report about how xfce > fails when the DPI is higher than usual. (Also, perhaps worth noting > that 3.12 is quite a few versions ahead of the gnome currently in > unstable..) This is a pretty common misconception and also pretty easy to workaround. xsettings->Xft can be set to a large value like 180 in xfce4-settings-editor (xfce's gconf). That's a usability issue and could definitely be improved with a widget in one of the more user-oriented xfce settings tools. > Another one I've become aware of, but not investigated is that xfce's > compositor may not do as good a job at eliminating tearing (with eg, > Intel graphics) as gnome's does. (Also, I think xfce doesn't enable > compositing by default.) Further investigation of this would be appreciated. > >> Popularity: One of the metrics discussed by the tasksel change proponents >> mentioned popcon numbers. 8 months after the desktop change, Xfce does not >> seem >> to have made a dent on install numbers. > > fwiw > https://qa.debian.org/popcon-graph.php?packages=task-gnome-desktop+task-xfce-desktop+gnome+xfce4&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=2014-01-25&date_fmt=%25Y-%25m&beenhere=1 Popcon data is actually very useful when interpreted relatively. Those curves pretty clearly show user desktop selections going toward whatever the default is, and growth in desktop installs continuing to increase overall at a pretty similar rate to the historical trend. It would be reasonable to conclude that the default actually doesn't matter much, and the majority of users will just adapt to whatever it is (and those that don't are capable of installing task-gnome-desktop). The better question is whether the xfce switch had or has any influence on slowing the general debian growth rate [0]? Is the slight downtick over the last few months due to the default desktop, or some other change that users aren't liking (maybe systemd), or just a random fluctuation? Best wishes, Mike [0] https://qa.debian.org/popcon.php?package=base-files -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=moyyck-isvrpg1v0gqse1q+kt5prt5yg7nscvbgwsv...@mail.gmail.com
Re: Reverting to GNOME for jessie's default desktop
On Fri, Aug 8, 2014 at 1:52 AM, Michael Gilbert wrote: > The better question is whether the xfce switch had or has any > influence on slowing the general debian growth rate [0]? Is the > slight downtick over the last few months due to the default desktop, > or some other change that users aren't liking (maybe systemd), or just > a random fluctuation? Here's a really interesting view showing the downward trend starting somewhere in April [0]. Note that the xfce trend was consistently growing prior to and past January (when the default was changed), but slowed a lot in April. At the same time, gnome and base-files started losing users. I've chosen to highlight April 26th, which is the date systemd 204-9 was uploaded to unstable [1]. It was around that time that the systemd packages introduced dependency changes that casual users were forced to think about. Anyway, nothing conclusive since correlation != causation, but something definitely worth pondering about systemd's potential cause and effect. Best wishes, Mike [0] https://qa.debian.org/popcon-graph.php?packages=base-files+task-gnome-desktop+task-xfce-desktop+gnome+xfce4&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=2014-04-26&date_fmt=%25Y-%25m&beenhere=1 [1] https://packages.qa.debian.org/s/systemd/news/20140426T230007Z.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MPm7-Dms7Qnw+rQ0Tn_7uJ-x1D8gFuVQG3-D60=acm...@mail.gmail.com
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
On Fri, Aug 8, 2014 at 12:00 PM, Marco d'Itri wrote: >> If the xfce iso didn't exist, people in these situtations would >> not be able to install a usable Debian system. > I see a solution that would satisfy everybody: whoever is interested in > supporting this kind of situations could build CD images appropriate for > them, and everybody else who does not live in the worst connected parts > of the third world can continue using a modern desktop as usual. The default has no bearing whatsoever on whether well-connected users can or can't install one of the shiny desktops if they so choose. Best wishes, MIke -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mn9qkocd0k+3d4hlbhveptm7539-rzahaq5tz6g37z...@mail.gmail.com
Re: Bug#729203: Reintroducing FFmpeg to Debian
On Sat, Aug 9, 2014 at 7:34 AM, Andreas Cadhalpun wrote: > It's probably not necessary to make a new upload to the NEW queue for this > change. In the repository is a new upstream version anyway and it will be > uploaded, once the current version gets accepted. Based on the license review, you should anticipate a REJECT of the first upload, so you'll need to upload the second one anyway. You might as well do the second one now and save everyone time. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MOM1R6_Gw32qNAA_x1W9Ku093XDH=okyiztwwgbfyn...@mail.gmail.com
Re: Bug#757555: pam: CVE-2014-2583 pam_timestamp directory traversal issues
control: tag -1 patch
On Sat, Aug 9, 2014 at 9:46 PM, Steve Langasek wrote:
> Which according to elsewhere in my mailbox, you've dealt with by uploading a
> 10-day delayed NMU. This is unacceptable
Sorry for not getting the nmu mail out in a timely manner, but real
life got in the way.
What is not acceptable is the assumed bad faith and the misguided
attempt at public shaming (after only half a day) without considering
the possibility of RL events or other benign possibilities. A simple
"hey, what's going on with this thing I'm seeing in deferred" mail
directed at me would have been the kind thing to do.
> I have removed pam_1.1.3-8.1_amd64.changes from the delayed queue. If you
> have changes that you would like to see included in this package, please
> send them to the BTS where they belong.
The proposed patch is now attached. I plan to upload that to
delayed/5 after about a week or so to give you lots of additional time
for review (way more than the normal nmu process requires).
Best wishes,
Mike
diff -u pam-1.1.8/debian/changelog pam-1.1.8/debian/changelog
--- pam-1.1.8/debian/changelog
+++ pam-1.1.8/debian/changelog
@@ -1,3 +1,13 @@
+pam (1.1.8-3.1) unstable; urgency=high
+
+ * Non-maintainer upload by the Security Team.
+ * Fix CVE-2013-7041: case-insensitive comparison used for verifying
+passwords in the pam_userdb module (closes: #731368).
+ * Fix CVE-2014-2583: multiple directory traversal issues in the
+pam_timestamp module (closes: 757555)
+
+ -- Michael Gilbert Sat, 09 Aug 2014 09:50:42 +
+
pam (1.1.8-3) unstable; urgency=low
* debian/rules: On hurd, link libpam explicitly with -lpthread since glibc
diff -u pam-1.1.8/debian/patches-applied/series pam-1.1.8/debian/patches-applied/series
--- pam-1.1.8/debian/patches-applied/series
+++ pam-1.1.8/debian/patches-applied/series
@@ -23,0 +24,2 @@
+cve-2013-7041.patch
+cve-2014-2583.patch
only in patch2:
unchanged:
--- pam-1.1.8.orig/debian/patches-applied/cve-2013-7041.patch
+++ pam-1.1.8/debian/patches-applied/cve-2013-7041.patch
@@ -0,0 +1,44 @@
+From 57a1e2b274d0a6376d92ada9926e5c5741e7da20 Mon Sep 17 00:00:00 2001
+From: "Dmitry V. Levin"
+Date: Fri, 24 Jan 2014 22:18:32 +
+Subject: pam_userdb: fix password hash comparison
+
+Starting with commit Linux-PAM-0-77-28-g0b3e583 that introduced hashed
+passwords support in pam_userdb, hashes are compared case-insensitively.
+This bug leads to accepting hashes for completely different passwords in
+addition to those that should be accepted.
+
+Additionally, commit Linux-PAM-1_1_6-13-ge2a8187 that added support for
+modern password hashes with different lengths and settings, did not
+update the hash comparison accordingly, which leads to accepting
+computed hashes longer than stored hashes when the latter is a prefix
+of the former.
+
+* modules/pam_userdb/pam_userdb.c (user_lookup): Reject the computed
+hash whose length differs from the stored hash length.
+Compare computed and stored hashes case-sensitively.
+Fixes CVE-2013-7041.
+
+Bug-Debian: http://bugs.debian.org/731368
+
+--- a/modules/pam_userdb/pam_userdb.c
b/modules/pam_userdb/pam_userdb.c
+@@ -222,12 +222,15 @@ user_lookup (pam_handle_t *pamh, const char *database, const char *cryptmode,
+ } else {
+ cryptpw = crypt (pass, data.dptr);
+
+- if (cryptpw) {
+- compare = strncasecmp (data.dptr, cryptpw, data.dsize);
++ if (cryptpw && strlen(cryptpw) == (size_t)data.dsize) {
++ compare = memcmp(data.dptr, cryptpw, data.dsize);
+ } else {
+ compare = -2;
+ if (ctrl & PAM_DEBUG_ARG) {
+- pam_syslog(pamh, LOG_INFO, "crypt() returned NULL");
++ if (cryptpw)
++ pam_syslog(pamh, LOG_INFO, "lengths of computed and stored hashes differ");
++ else
++ pam_syslog(pamh, LOG_INFO, "crypt() returned NULL");
+ }
+ };
+
only in patch2:
unchanged:
--- pam-1.1.8.orig/debian/patches-applied/cve-2014-2583.patch
+++ pam-1.1.8/debian/patches-applied/cve-2014-2583.patch
@@ -0,0 +1,47 @@
+From 9dcead87e6d7f66d34e7a56d11a30daca367dffb Mon Sep 17 00:00:00 2001
+From: "Dmitry V. Levin"
+Date: Wed, 26 Mar 2014 22:17:23 +
+Subject: pam_timestamp: fix potential directory traversal issue (ticket #27)
+
+pam_timestamp uses values of PAM_RUSER and PAM_TTY as components of
+the timestamp pathname it creates, so extra care should be taken to
+avoid potential directory traversal issues.
+
+* modules/pam_timestamp/pam_timestamp.c (check_tty): Treat
+"." and ".." tty values as invalid.
+(get_ruser): Treat "." and ".." ruser values, as well as any ruser
+value containing '/', as invalid.
+
+Fixes CVE-2014-2583.
+
+Reported-by: Sebastian Krahmer
+
+--- a/modules/pam_timestamp/pam_timestamp.c
b/modules/pam_timestamp/pam_timestamp.c
+@@ -158,7 +158,7 @@ check_tty(const char *tty)
+ tty = strrchr(tty, '/
Re: Can a leaf package require SSE2 on i386?
On Sun, Sep 14, 2014 at 2:47 AM, Sébastien Villemot wrote: > The bottom line is that julia needs SSE2 (and porting it to the x87 FPU > requires changes that are beyond what I am willing/able to do, see [1] > for more details). And the presence of SSE2 is not guaranteed on the > i386 architecture. chromium upstream decided to go SSE2-only, but I've reverted that in the Debian packages for now. I would prefer to not diverge, and would do so if there were a convenient way to detect and prompt users about the problem (rather than segfault). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MPZr2suB3DBN7jvADJpG2CWz8NECtnc_epe4hoe...@mail.gmail.com
Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
On Thu, Oct 30, 2014 at 12:09 AM, Christoph Anton Mitterer wrote: > On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote: >> Packages appearing on mirrors is not how we notify Debian users of >> security updates. We do that by issuing a security advisory. > Aha,... well... sounds like nitpicking,... I guess the least of the > users have subscribed the respective mailing list or look regularly at > https://www.debian.org/security/. There is also LWN as a mechanism for independent verification. Although there is often more than a day long delay on that, and more on weekends, it can be used as reliable indicator if has different information than expected from the DSA mail. That is a retroactive process, so sure it isn't a preventative measure, but when something does differ, at least you know that the events you observed for the prior day were suspect. > And apart from that: > with respect to mail: > - the mails seem to often lag behind the actual release of a fix, so > there is the same problem that users may not be notified as fast as they > could be The mail and dak install are manual and independent actions, so the timing difference is the human in the loop, and is rarely more than a few minutes. Maybe the two could be tied together, but someone needs to volunteer to do that. > - while mails can be secured, there is no guarantee at all that mails > arrive the subscribers > > with respect to web: > - that uses GANDI CA certs, so this is not really a secure way to be > informed about that either. > > >> Yes, it's >> nice to protect against archive downgrade attacks, but validity periods >> are not our primary defense against that. Our primary defense is that we >> send out a DSA telling people exactly what package versions they need. If >> those package versions aren't available, that should raise red flags. > See above, both means of distributing DSAs seem not to protect against > downgard/blocking attacks. Why wouldn't a once per every TIME debsecan cron job not solve the entire automation problem? >> Teams that run Debian servers in production should be checking that all >> packages on their hosts are upgraded to the necessary versions. > Even apart from the above problems, I doubt that mail is the appropriate > mean for many admins to get notified about security upgrades. > People may deploy security upgrades automated or at least check for them > via Nagios and friends, rather than reading mails, which they get for > *all* DSAs and not just the packages they actually use. If the problem really is the lack of a nagios plugin, then that seems like a straightforward problem to solve, and a potentially positive direction to focus this energy. > To be honest, it's really awkward to see how much all this is apparently > fought against. It sure is awkward to see so much fight continuing with so little action. >> It seems to me that if you want to lower the chances of a downgrade attack >> for your systems, setting the validity period on your systems is exactly >> the tool that you need. There's no need for anything to change on the >> server side for you to get that protection. > Well I don't think it would work, would it? > The Release file contains e.g.: > Date: Thu, 30 Oct 2014 02:54:04 UTC > Valid-Until: Thu, 06 Nov 2014 02:54:04 UTC > > When I now lower the validity to something very small, e.g. 4 hours, > than beginning with 30 Oct 2014 06:54:04 UTC everything will fail for me > unless a resigning mechanism was in place like such that was discussed > in #752450. I think ftpmaster said they would consider signing more often, but they were not willing to consider reducing validity time (in case something does go down). And that change would obviously be useful, but has been entirely lost in the noise (particularly the finger pointing and misguided public shaming attempts). Debian is about meritocracy. If you're unwilling to do any of this (or to have figured) it out yourself, then there is no reason forcibly attempt to make others do it for you. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MN92pqz2bSrU=vljk-ct5vmctawdttqh36qi1vqqtq...@mail.gmail.com
Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
On Thu, Oct 30, 2014 at 1:12 AM, Russell Stuart wrote: > On Wed, 2014-10-29 at 21:58 -0700, Russ Allbery wrote: >> Also, this means that you completely miss security advisories that *don't* >> involve changing a package in the archive, like "this thing is a disaster, >> so we're pulling it from the archive entirely and suggest you stop using >> it." > > If it is so that much of a disaster that it warrants pulling a package > from stable, surely a little more notification than an email to a list > most people don't monitor would be warranted? Something like replacing > it with an package that sends email daily to root explaining the > situation would be the very least you could do. Just upgrading a package is not enough. Often enough services need restarted, and that information can be stated in the DSA. There are also end-of-life announcements, which maybe the debian-security-support package now addresses in a somewhat automated fashion. Anyway, it is entirely understandable that reading can be hard, but at a minimum the truly security-conscious need to be to do so. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mo0dlhaotao7vjqnrluc5jaxqjrwcqr1f4vyrwyevz...@mail.gmail.com
Please more fish (was: so long and thanks for all the fish)
On Sat, Nov 8, 2014 at 8:08 PM, Russ Allbery wrote: > zlatan writes: > >> In advance sorry for all spelling mistake that I will write as I am >> writing from my phone and I am not a native English speaker. > > [...] > > And yet, I don't see how it could have been said better. Thank you so > much for putting this into words. How can you possibly think no more need said? You are one of four complicit in the act that finally pushed Joey over the edge [0]. The fire bell is ringing, and no one is getting out of bed. The legitimacy of the technical committee has been entirely destroyed by misguided acts over the last year. The sad part is that this all would have been avoided if the composition were more mindfulness of potential consequence to their actions, especially in the face of some observers stating exactly that during the process. For the technical committee to regain any stasis of legitimacy, the composition must change. All those involved (both explicitly and complicity) in the vote that caused Joey's suicide from Debian should consider resigning in shame. Even then,we need to reconsider the implicit danger of imbuing power that can do so much damage to a potentially non-representative subset of project members. Best wishes, Mike [0] https://lists.debian.org/debian-ctte/2014/11/msg00045.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MO52GAMLEayYX5w6T2+uQqh4uqaopRsj220_kdT=yz...@mail.gmail.com
Re: Please more fish
On Sat, Nov 8, 2014 at 10:53 PM, Russ Allbery wrote: > I don't want this to be taken as asking for criticism to be shut down, so > I'm not asking this of anyone who wants to agree with Michael. If you > want to do that in public or private, please go ahead. But I would > greatly appreciate not being the cause or motivation for another heated > argument on debian-devel, with anyone in the project, and I don't need the > public defense. My message is intentional, and intentionally harsh. The damage caused to the project by alienating Joey is astounding, and the inability to recognize that even more so. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mp2--k_x3ffqm7dn1azjufb0nxsm0vjl37qhszdsk3...@mail.gmail.com
Re: Please more fish (was: so long and thanks for all the fish)
On Sat, Nov 8, 2014 at 10:57 PM, Christoph Anton Mitterer wrote: > On Sat, 2014-11-08 at 22:32 -0500, Michael Gilbert wrote: >> You are one of four >> complicit in the act that finally pushed Joey over the edge [0]. > > Don't you think it goes a bit far to personally accusing some people of > this? No accusation, just a statement of fact. Four ctte members were complicit in the vote [0] that catalyzed Joey's resignation. >> The fire bell is ringing, and no one is getting out of bed. > > Well that's probably a different topic, isn't it? As the recent > discussions have shown, there are many people who feel Debian goes the > wrong way in some fields - but I wouldn't make this all up to systemd. No, the fire is not systemd, it is the politicization of the project via ctte and GR rather than patient evolution of the best technical solution. >> The legitimacy of the technical committee has been entirely destroyed >> by misguided acts over the last year. > > Well others would say that decisions had to be made, and the best that > was possible might have been done? Sometimes the best decision is none at all. It can sometimes take a lot of time for the right solution to evolve, but that requires patience, and the project seems to have lost that quality. That is why Joey is gone. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MP6-eb9_b3Q1E2kh+BJW7J_L+81Bz8o=mpaeav8bcx...@mail.gmail.com
Re: Please more fish (was: so long and thanks for all the fish)
On Sun, Nov 9, 2014 at 12:01 AM, Christoph Anton Mitterer wrote: > On Sat, 2014-11-08 at 23:30 -0500, Michael Gilbert wrote: >> No accusation, just a statement of fact. Four ctte members were >> complicit in the vote [0] > > Well maybe I read that ruling wrong, but didn't it more or less say > "we're not deciding anything right now"? > > And even if that decision would be the sole reason for Joey to leave Please actually read Joey's message to understand his concern, which is not at all about content or systemd, but the harmful actions of some project members and the complicity of others in those actions over some significant time now. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mmlzugz44byvimaog9c4j-0prqfz_i6tksgzqacogs...@mail.gmail.com
Re: Please more fish (was: so long and thanks for all the fish)
On Sun, Nov 9, 2014 at 10:10 AM, Ralf Jung wrote: > I read Joey's message over and over without getting any more clues. He > said the CTTE has "Decided it should make a decision", which it seems to > me it did not. So I probably misunderstood something more fundamental here. Read all of #762194 very carefully. Note that no technical disagreement existed between project members, it was initiated by a committee member pushing a particular agenda with no consideration about his own conflict of interest, a technical solution that would have avoided mediation by the committee was in progress, no substantive thought or discussion occurred, and finally rubber stamping without any forethought to potential consequence (except from Steve). Yes, the Debian constitution right now allows the TC to misbehave like that. That is part of the constitutional crisis at hand. The TC power needs to be reigned in. Their actions should be limited solely to disagreement mediation, and only when that doesn't involve a conflict of interest pertaining to one of the TC members, and only when all other attempts at reconciliation have tried and failed. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MMpLLnnekz8c2w35sc=rzudvvg+9ytxvt_qni797is...@mail.gmail.com
Re: state of security hardening build flag efforts
On Sat, Apr 7, 2012 at 5:50 AM, Julien Cristau wrote: > On Sat, Apr 7, 2012 at 11:27:46 +0200, Raphael Hertzog wrote: > > > Hi, > > > > On Sat, 07 Apr 2012, Julien Cristau wrote: > > > On Sat, Apr 7, 2012 at 02:17:21 +0200, Kurt Roeckx wrote: > > > > > > > However, I wonder why bindnow isn't on by default. I thought we had > > > > a discussion about this, and didn't really see any negative > > > > performance from that? > > > > > > It makes stuff stop working. > > > > I think you're mixing up with PIE. > > > No I'm not. bindnow changes how e.g. dlopen works, so it breaks stuff > relying on RTLD_LAZY. Like, say, your X server. > Here is where philosophy matters. Yes, bindnow and pie can cause problems or slowdowns in certain (fortunately rare) cases. Now, even though that is possible, that fact should not have any relevance on the choices for the defaults: on noticing that the flags have caused a problem, they can simply be disabled. For xorg, -pie,-bindnow certainly makes sense, but for the vast majority of other packages +all would be a far better default. Best wishes, Mike
Re: what to do is maintainer is lacking? (was: wine-unstable in Debian)
On Wed, Apr 18, 2012 at 10:21 AM, Stefano Zacchiroli wrote: > On Wed, Apr 18, 2012 at 10:00:43AM -0400, Chris Knadle wrote: >> Debian has NMUs (Non-Maintainer Uploads) -- however this is mainly meant for >> uploading critical bug fixes without having to resort to hijacking the >> package, and AFAIK not to be used to upload new versions of the software. > > Before making this kind of claims, I suggest (re-)reading section 5.11.1 > of the Debian Developers Reference, i.e. the section about NMUs: > > http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-guidelines > > it is in fact quite more liberal than what you seem to imply. And it has > been so for quite a few years now. Is it reasonable to do an NMU that has a debdiff equivilent of around 500 upstream git commits (the size of ever new upstream wine release)? Now, the existing NMU guidelines do not mention diff size at all, but I think everyone that intuitively concludes that a very large NMU diff is wrong (i.e. how is the maintainer supposed to manage that kind of mess later). This common knowledge is what leads to the reasonable conclusion that upstream NMUs are by de facto disallowed. Best wishes, Mike -- 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/CANTw=mprg2ni6xsx8pfbl4ysinjmwdhtgtggwqzkbvbtvoa...@mail.gmail.com
Volunteer-initiated team maintenance as a solution for packages with low activity
Hi, I would like to throw out an idea for constructively combating low activity in strongly maintained packages. Across the Debian package ecosystem team maintainership has been seen as the strongest antidote for package stagnation. This process "just works" because as one team member becomes less active, others tend to pick up the slack, and the package continues on with a healthy life cycle. However, certain areas of the archive remain strongly maintained, and when those packages enter this kind of low activity state, there is no clear or established remedy; thus problems ensue. After time, those packages stagnate, and absent a healthy team spirit, no one can fix it. In fact, often enough potentially helpful volunteers get caught in a type of thermal discouragement beam when trying to contribute. Needless to say, this situation is unfortunate for many. The potentially helpful volunteer gets a dose of negativity and potentially loses interest in the package and after enough of these cases probably Debian altogether, the package stagnates, the existing maintainer takes on a certain level of guilt and frustration, and potential Debian users are lost because of resulting package out-of-dateness qualms. So anyway, enough explanation, on to my proposed solution. Seeing as team spirit has been a quite effective antidote to stagnation, lets go ahead and use that again. Here is my suggested process: 1. An interested volunteer notices that an upstream version of a package has been out for a time frame (perhaps 3 months), but hasn't been packaged by the existing team or maintainer. This defines the low activity state. 2. The interested volunteer files a bug report against the package stating their intent to contribute 3. If an alioth team already exists, the interested volunteer sends an email to ad...@alioth.debian.org with the following information a. Link to upstream release and date b. Link to info on latest maintainer activity on package 4. If an alioth team does not exist, the maintainer creates a collab-maint project 5. The volunteer adds a link to the vcs in their intent to contribute bug report 6. The volunteer adds him or herself as an uploader, makes their other changes (bug fixes, new upstreams, etc.) and pushes to alioth 7. The volunteer either uploads their package (and future updates) directly to the archive (if they're a DD) or seeks a sponsor (if they're not a DD) 8. Continue step 6 and 7 as needed 9. After 6 months of steps 6 and 7, the interested volunteer can send a message to ad...@alioth.debian.org including links and information about their work over those 6 months requesting to become a project admin Note that in step 3, if the existing maintainer disagrees with the alioth admin approval of the volunteer, he should not be allowed to directly override that. He or she would need to make a case to the alioth admins that the new volunteer has been doing problematic things and deserves to be removed; otherwise he or she could continue to block work on the package. Of course all of this is necessary only if the maintainer is not supportive (or reactive) in terms of adding team members him or herself. Importantly this process avoids the negativity of the MIA process (that doesn't apply in these cases anyway since low activity is not zero activity). In the long-term, the MIA process may just go away as instead packages gradually/organically become team-maintained, and the new contributors become established and eventually take over full responsibility as project admins for the packages that they're working on. I know processes within Debian are often seen as bad, but I believe this one is good (or at least better) because it replaces an existing negatively perceived top-down process with a self-directed organic one (i.e. may the best work win). Best wishes, Mike -- 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/CANTw=mo-xocbyp11+we0xyyv2wqy7vkhypa8jh4gu+gyrbd...@mail.gmail.com
Re: Volunteer-initiated team maintenance as a solution for packages with low activity
On Wed, Apr 18, 2012 at 2:12 PM, Moray Allan wrote: > On Wed, 2012-04-18 at 13:10 -0400, Michael Gilbert wrote: >> So anyway, enough explanation, on to my proposed solution. Seeing as >> team spirit has been a quite effective antidote to stagnation, lets go >> ahead and use that again. > > I agree with the general intention, but not with the details of the > proposed process. Indeed, I'm unconvinced we need to formulate a > process of any kind, especially not one that makes a specific group (in > this case, the Alioth admins) responsible for policing it. I would > rather simply see a stronger consensus on what is reasonable behaviour. So I failed to state this, but implicit in the goals is that the new volunteer's work should be readily available in a user-friendly form to the existing maintainer for when/if they return from their low activity state. I'm reluctant to do a 500 commit NMU because its just so unwieldy (and seems wrong), but if I can become a team member and commit those changes to the vcs, then its in a nice form for the maintainer when they return. Plus I don't have to find hosting for my work elsewhere, which is kind of a pain and unwanted. So, currently the only way to add a new alioth project in cases where the maintainer does not do it him or herself is via the alioth admins, so that is why they have to be involved. In most cases it will be a quick check on their part to see that the package needs help. All-in-all these cases should be rather rare, and should not require much work on their part. But if it does, more admins can be added to distribute the workload. Note that the collab-maint case requires no oversight (alioth or otherwise). > If we need a process at all, I would initially suggest something like > the following, which I think would be enough to solve many cases: > > - Where there are problems with a package that are not being dealt with > by the maintainer, it is acceptable for others to NMU. This includes > when a package is significantly out of date compared to upstream, though > in this case it is recommended that the DELAYED queue be used. This is already appropriately handled by the existing NMU process, which helps fix on-off bugs. The new process is for those willing to make a long term commitment of fixing continuing issues in the package. > - Where several NMUs for a package enter the archive over an extended > period without the maintainer acknowledging them in a new maintainer > upload, it is acceptable for others to add themselves as maintainers for > the package, even without the permission of the current maintainer. This could certainly be another condition where a volunteer-initiated team join would be allowed/encouraged. Best wishes, Mike -- 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/CANTw=mpdmmgo15gcn2vbf_xoe6ahmrtvqw2qmrw4q9rvx2m...@mail.gmail.com
Re: Volunteer-initiated team maintenance as a solution for packages with low activity
On Wed, Apr 18, 2012 at 2:51 PM, Colin Watson wrote: > Nowhere in this process seems to be the notion that you should > contribute actual effort first before adding yourself as an uploader. I > think that's important, particularly in the many situations where it's > not lack of packaging of a new upstream in question, but some other > problem. I had thought about that, but forgot to write it. Add a subsection to Step 3 that states "c. A brief listing of the volunteer's contributions to the package" > alioth is just a Debian-specific hosting site, not a general gateway to > package maintenance. We're not set up for them to be dispute resolution > for the whole of Debian, and they have no constitutional authority to do > that anyway. De-emphasising the role of alioth administration in the > whole of this would be a good thing, I think; ownership of the alioth > project is often not that desperately important in practice. The requirement could be to include a link to a clone of the existing vcs with the volunteer's changes. Then it would be the existing maintainers responsibility to sync from that vcs when they return, which could be quite problematic if the repos get out of sync. Another problem that I see with this is that of an additional volunteer becoming interested. In that case, the alioth vcs is out of sync with the package. >> I know processes within Debian are often seen as bad, but I believe >> this one is good (or at least better) because it replaces an existing >> negatively perceived top-down process with a self-directed organic one >> (i.e. may the best work win). > > OK, so remove the top-down bit where admin@alioth has to decide stuff > about who gets to be a maintainer. There really is no dispute resolution required on the part of the alioth admins. Their roles would be to check that the package does indeed need help as suggested by the volunteer (plus with your suggestion that the volunteer has demonstrated aptitude on the package), and to listen to maintainers that detect possibly problematic behavior of the team members that they're personally not allowed to remove. Given that these case should be incredibly rare anyway, this should really amount to very little additional work. But if it really is, there could be a call for a volunteer interested in doing that specific task. Best wishes, Mike -- 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/CANTw=MNnqH=ycu0o6-sv2at_gkshcqqyvxuomhyv5olmfkt...@mail.gmail.com
Re: wine-unstable in Debian
On Wed, Apr 25, 2012 at 5:27 AM, Goswin von Brederlow wrote: > Jonas Smedegaard writes: > >> On 12-04-18 at 07:17pm, Simon McVittie wrote: >>> I hesitate to suggest this if there's a possibility that the main wine >>> package can come up to date before we freeze, but one way to have Wine >>> 1.4 (and/or 1.2) in the distribution without NMUs/hijacks would be a >>> parallel wine-1.4 source package and set of binary packages. >> >> That's hijacking in disguise. Don't do it! > > I only sporadically read this thread. But isn't one of the problems with > wine that different things run with different wine versions? > > Under that assumption I would think having wine-x.y packages would be a > good thing and that they should be coinstallable. They can share an > alternative for wine. > >> Use the tech-committee if you run out of normal procedures. That's its >> purpose. >> >> >> - Jonas > > As a side note: One problem with wine is that it needs 32bit libraries > on amd64 and the state of ia32-libs. Ia32-libs does have some bugs open > concerning wine, specifically it doesn't allow building wine from source > (again) and some version skews between libraries. All of those bugs were reported by people trying to build upstream wine from source (which may be what you meant). But otherwise, they are all normal bugs that have already been corrected via NMUs in the Debian package: http://packages.debian.org/changelogs/pool/main/w/wine/wine_1.0.1-3.5/changelog.txt So this isn't something worth worrying about. > Since we now have multiarch this isn't going to get fixed in ia32-libs > and the wine package should no longer build on amd64 but instead > wine:i386 should be used. It does no harm to continue to build wine with -m32 on amd64, but if ia32-libs does go away, then all of wine's i386 multiarch dependencies will need to be in place. Best wishes, Mike -- 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/CANTw=mofwjcbf4qouwf0pyegnd5hvciwbv7f9p4__vpwl92...@mail.gmail.com
Re: Licenses not in /usr/share/common-licenses
On Mon, May 7, 2012 at 6:33 AM, Andrea Veri wrote: > Hi, > > while packaging a few extensions (mainly licensed under the MPL) > within the pkg-mozext team we received a few rejects from the FTP Team > having the following rationale: > > "the MPL license is not installed under /usr/share/common-licenses, > thus the full text has to be added into debian/copyright." > > Since the MPL is not a short license [1], we decided to handle the > current situation by linking the license to a static file included in > the /usr/share/doc/xul-ext-packagename directory this way: > > "License: MPL-1.1 > The complete text of the Mozilla Public License can be found in > the `MPL' file in the same directory as this file." > > We, then, received another reject. So, what's the working solution for > these kind of cases? is it including the full text of the license a > bit of a non-sense when we can directly link back to a static file? > what's the rationale behind including the full license? why the > relevant bug report [2] has been started back in 2008 but as of today, > has still no decision? Would it be unreasonable if someone were to start an "uncommon-licenses" package? Then any package depending on that could use a reference to the license instead of including the full text in debian/copyright. Best wishes, Mike -- 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/CANTw=moj44ovpw4xhjmrcnl+pkyek30-ckfepuonu+k0z4t...@mail.gmail.com
Re: Licenses not in /usr/share/common-licenses
On Mon, May 7, 2012 at 11:55 AM, Michael Gilbert wrote: > Would it be unreasonable if someone were to start an > "uncommon-licenses" package? Then any package depending on that could > use a reference to the license instead of including the full text in > debian/copyright. I realize that this misses a certain aspect of interpreting the legalize of licenses, which is that many believe the full text of a license needs to accompany all source and binary files. So then an additional aspect of this solution could be a helper that takes a copyright.in containing license file references and replaces that with the appropriate full text. Best wishes, Mike -- 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/CANTw=MN-xwqpVCOW0r_XUptzc�a7nkySKxysSdaKqAAag=u...@mail.gmail.com
Re: Licenses not in /usr/share/common-licenses
On Tue, May 8, 2012 at 1:49 PM, Matthew Woodcraft wrote: > Russ Allbery wrote: >> I think the core question is: why is base-files special? Yes, it's >> essential and all, but that doesn't address the case of packages being >> downloaded separate from Debian, or unpacked by hand, in which case we >> don't include a license. If we're legally fine with that, I'm having a >> hard time seeing the clear distinction between that and a dependency >> on another package including the license. > >> Surely this has been discussed before? I don't remember seeing it on >> the debian-policy list since I started working on Policy. > > There's a fairly lengthy discussion starting at > http://lists.debian.org/debian-policy/2000/11/msg00235.html So, I think [0] is the most astute message in that thread. Succinctly, the copyright file itself is irrelevant in the source package since the upstream source should have all of that information already, and at least for the GPL you can distribute source packages as is. Thus, the issue is reduced to the need for full license texts only in all binary packages. That doesn't seem to be a current requirement and copyright file symlinks are often used today, so perhaps a first step would be to make that a part of the Debian policy? Secondly, since the copyright file in the source package doesn't actually need full license text, license file references should be allowable there; as long as appropriate helpers are written that can take those (reference only) source copyright files and fill in the appropriate full license texts for the binary files that it generates. Eliminating the tedium of copying, pasting, and reformatting license texts would be a wonderful simplification and time reducer. Best wishes, Mike [0] http://lists.debian.org/debian-policy/2000/11/msg00251.html -- 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/CANTw=morcraz-_5bi0bfo82e6ekhdkpp_g1cyoedcpgs_qh...@mail.gmail.com
Re: Wheezy release: CDs are not big enough any more...
On Sat, May 12, 2012 at 12:04 PM, Steve McIntyre wrote: > Hey folks, > > Remembering the fun that we had during the Squeeze release with trying > to make single-CD installations work well, it's time to consider what > we're going to *claim* to support in Wheezy. We've had a history of > supporting the following single-CD installations: > > * Gnome desktop from CD#1 > * KDE desktop from "KDE CD#1" > * XFCE desktop from "light CD#1" > * LXDE desktop from "light CD#1" > * base system only from netinst CD > > At this point, I'm skeptical that either of the first two are going to > work acceptably with Wheezy. If that's the case, then we should warn > people that they will need to use at least one of: > > * more CDs > * a DVD > * a network mirror > > to get a useful/useable installation. What about supporting only the smaller/lighter desktop environments (maybe even making one of the the default environment)? Then there wouldn't be the need for multiple CD #1's. Anyone that wants gnome/kde after installation will need to grab those from the mirrors (or use DVD or greater media). Best wishes, Mike -- 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/CANTw=mp7zmd16g325awdxrxvdzfetz_zxjfwhqg+zviqj2j...@mail.gmail.com
Re: Licenses not in /usr/share/common-licenses
On Fri, May 11, 2012 at 10:25 PM, Russ Allbery: >> So, I think [0] is the most astute message in that thread. > >> [0] http://lists.debian.org/debian-policy/2000/11/msg00251.html > > I thought that too when I first read it, but later in the thread are very > cogent arguments for why it's wrong and providing a complete copy of the > GPL with binaries is required. Hmmm, I really meant that I found point 1 to be quite astute. I agree, the conclusion is quite off. The copyright file is very important in binary packages, and should have full-text licenses. The important aspect of point 1 is the conclusion that at least with the GPL you can distribute any source release as is; meaning that our additional work on the full-text copyright file in the source package is unnecessary. I think this distinction between the needs of the source package copyright file and binary package copyright file is very useful, and can help steer towards a much simplified source copyright file, and yet still satisfy the requirement for full-text binary copyright files. Best wishes, Mike -- 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/CANTw=mpvcms97vy5z9auazykewxkye4ae8shnfnmeqxw5to...@mail.gmail.com
Re: Wheezy release: CDs are not big enough any more...
On Mon, May 14, 2012 at 6:39 AM, Michael Biebl wrote: > On 14.05.2012 12:30, Jonas Smedegaard wrote: >> Let's keep providing CDs as install medium, because it is still relevant >> for some (and, I vaguely feel, not only exotically few) real use cases >> to install non-bloated desktop at places with flaky/expensive Internet. > > Having different default desktops installed depending on which install > media you download, sucks. A new default would of course be universal (i.e. it would be common across any installation method). The other desktop environments would be available as options in the boot menu (given that the user has the additional CDs, a network mirror, or a DVD). Best wishes, Mike -- 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/CANTw=MO8-80EF7xfKUK+J5f5OfCy4Oq=2+m_w3r+4nf3tq-...@mail.gmail.com
Re: this bug .. bugs me
On Tue, Jun 5, 2012 at 11:52 AM, Joey Hess wrote: > 10 Jun 2010 a bug was filed wanting wine 1.2 packaged in time for squeeze. > 12 Aug 2010 packages of 1.2 were available .. but not in Debian. > 6 Feb 2011 squeeze shipped with the same wine version that shipped in lenny. > 7 Mar 2012 wine 1.4 was released as the new upstream stable release > 25 May 2012 wine 1.2 was finally made available in unstable > > I've read over this entire bug, and while there are clearly some hard > problems and a lot of good work shown here, I'm seeing a concerning > trend throughout it. > > We seem to have a problem with being willing to trade off simple > solutions that will greatly benefit users, for doing things "right", > even when doing things "right" benefits users *less*. > > Examples of that seen in this bug include: > > * An idea that every old release of wine needs to be packaged in sequence, > so it'll be available in snapshots, so users can pull down an old > version as needed for maximal ability to find one that works. That's > the theory, the actual end result is that users had no modern > wine version at all to use, for many years. > > This is a simple tradeoff of benefits to sets of users, > and the set of users who know how to use snapshot.debian.org, need > a two year old version of wine there, and can find the right version is > clearly much smaller than the set of users who would like the latest > wine to see if it runs some program. > > * Wanting to support multiarch coinstallability, plus wine and > wine-unstable coinstallability. Nice goal, but again it prioritises > some small set of users who need 2 or even 4 versions of wine > coinstalled over the larger set of users who just want the newest wine > version. > > * Not using existing Ubuntu packages of wine despite them being > available for a long time at newer versions. > > * People doing work allowing themselves to be blocked for a long time on > some minor procedural point, like whether they have commit access to a > particular git repository, or are not being added as a member of some > particular team, or whether infrequent and apologetic posts by a package > maintainer are enough to keep them from being considered MIA. > > This bug is a textbook example of making the perfect the enemy of the good. > It's disconcerting that we, or our users, are willing to put up with this. Not sure what to say other than when I became a DD and gained the power to NMU, I started fixing this. Before that, Ove's contributor rejections blocked myself and many other non-DDs from effectively helping. Anyway, we've had recent threads on the continuing issues with strong package maintenance, and from what I can tell, there is no clear direction. The solution I'm pursuing is a liberal application of NMUs, and it seems to be working (albeit a bit slowly). Do you have ideas on other more effective solutions? Best wishes, Mike -- 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/CANTw=mmqh9wd7nsye8vzslrhux1f+wo-cjnkhqgjc2hzho4...@mail.gmail.com
Re: this bug .. bugs me
On Tue, Jun 5, 2012 at 1:25 PM, Andrey Rahmatullin wrote: > On Tue, Jun 05, 2012 at 12:46:46PM -0400, Michael Gilbert wrote: >> Not sure what to say other than when I became a DD and gained the >> power to NMU, I started fixing this. Before that, Ove's contributor >> rejections blocked myself and many other non-DDs from effectively >> helping. > I would also be glad to hear opinions on whether regularly NMUing a > package with a formally active maintainer is acceptable and whether it can > be called a takeover. We are announcing our deferred uploads at least 10 days in advance (unless RC) with git commit references, so Ove can review and/or cancel/reject our work at any point. Thus, we haven't taken any of his power away and it really can't be viewed as a "takeover". A few of us are choosing to do the necessary work and review while Ove doesn't have the time to do either himself. Best wishes, Mike -- 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/CANTw=mo+kfpk9756z7qoe+cjvw+_kp176wqfb28yhctu0qq...@mail.gmail.com
Re: this bug .. bugs me
On Tue, Jun 5, 2012 at 1:17 PM, Christian PERRIER wrote: > You mean, besides completely hijacking the package? > > The last maintainer upload is dated 2010/05/23. > > So, from my POV, you (Michael) and Hilko Bengen seem to be the real > package maintainers for wine. > > My suggestion: do a maintainer upload of 1.4 in unstable, unless it > would affect some transition. And do it now. I prefer cordiality. I would rather give Ove a fairly significant amount of time before pursuing any such change. And even then, I plan to defer the matter to the tech committee because I believe initiating a takeover on my own is a conflict of interest, and again I am one for cordiality. Best wishes, Mike -- 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/CANTw=moyq6g5dsqbm81+9iodumhvh7e7nggngemsupk0bwf...@mail.gmail.com
Re: this bug .. bugs me
> They are members of pkg-wine already, so I think they can make changes > that can improve the status but not limited to minimal changes for > NMU. If Mike don't want to "hijack" at least for now, team upload is > good enough. Hopefully this will make some people happy: I pushed the first team upload of the 1.4 series to unstable about a half-an-hour ago :) Best wishes, Mike -- 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/CANTw=MPow3FdboOcfm7okJVz7eM3fZu-rOX16_ZZ--XBP=z...@mail.gmail.com
Migration path for 'Multi-Arch:allowed' packages
Hi, We've been getting a few bug reports from users attempting to install multiarch wine who have yet to manually enable multiarch itself. Obviously that is a failure on their part, and is easily correctable. However, I wonder if we can't make such migrations a bit more straightforward? In particular, I filed a bug against dpkg requesting that it produce more informative error messages in these cases [0], but I wonder if a part of the solution shouldn't be more automated or at least presented at a higher level through apt/aptitude, etc? Also, limitations in the existing testing migration tools are making wine not considered for wheezy, since those tools don't check whether dependencies for 'Multi-Arch: allowed' packages are satisfied by packages on other architectures. Best wishes, Mike [0] http://bugs.debian.org/676822 [1] http://packages.qa.debian.org/w/wine.html -- 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/CANTw=mp3emp7idyp1dskpx3i4uytum-th42g3ufwwa5bjej...@mail.gmail.com
Re: Migration path for 'Multi-Arch:allowed' packages
On Tue, Jun 12, 2012 at 11:45 AM, David Kalnischkies wrote: > On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert wrote: >> In particular, I filed a bug against dpkg requesting that it produce >> more informative error messages in these cases [0], but I wonder if a >> part of the solution shouldn't be more automated or at least presented >> at a higher level through apt/aptitude, etc? > > Chicken or the egg? > > You need to upgrade to support MultiArch, > but you need MultiArch to upgrade… > (beside, how would the detection for such a message look like?) A squeeze-proposed-update could help that along, right? So, it appears that "allowed" is the wrong flag (although the Ubuntu wine package also uses "allowed" in that sense). The algorithm would look something like: if package depends on a missing native package if package is set with some new "Multi-Arch: no-native" flag present multiarch instructions else present missing package error Although that may not be necessary. I'm implementing a wine-bin | wine64-bin solution where the wine64-bin package simply presents multiarch instructions. It's not very elegant or ideal, but it will in fact help users along. Best wishes, Mike -- 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/CANTw=MPhLfc52RwY=6psoesqmrxtqym6mob8dgpm-ucxosu...@mail.gmail.com
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
On Wed, Jun 13, 2012 at 1:35 PM, Arno Töll wrote: > Hi, > > as a clarification, because I was pointed to it: > > On 13.06.2012 18:54, Arno Töll wrote: >> Drive-by sponsoring makes this even more complicated and is not helping >> anybody. We should stop advocating drive-by sponsoring at all. > > ... with the exception of evident cases like RC bug fixes, emergency > uploads or any other kind of upload where an urgent fix is needed. > > That's clearly not what I meant to address. I am merely addressing the > phenomenon of mass drive-by sponsoring of random packages. > > Yes, that happens quite regularly and I do not think this is how > sponsoring should work at all. Is that worse than the package being completely ignored? I'm really not sure what your definition of drive-by is. Sometimes I'll make time to look at a package interesting me, I'll communicate with the sponsoree, upload it if they address my concerns, then follow it for a little while to make sure nothing bad happened. Is that a drive-by? Best wishes, Mike -- 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/CANTw=mpor0iogzapdsltdjhhq8v6bywgnsg4p4pzeqkhfdd...@mail.gmail.com
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Fri, Jun 8, 2012 at 6:17 PM, Philipp Kern wrote: > On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote: >> Does this mean M-A:same packages should be prevented from being >> binNMUed, but only source upload can be accepted? > > You cannot deprive the Release Team of this tool. Also multiarch bugs are IMHO > at most important, not serious. Possibly we could allow one last sourceful > upload when the transitions all settled, but it would again increase the > review > load on the release team. > > IMHO it's on the "if it works, fine, if not, sorry about that" part of the > list, given that it was finalized so late, with that critical piece missing. Wouldn't the ideal solution be non-architecture-specific changelogs? So, a normal binnmu changelog looks like this now: package (version) sid; urgency=low * Binary-only non-maintainer upload for amd64; no source changes. -- amd64 Builddd Daemon (barber) Tue, 05 Jun 2012 16:33:05 + which could be changed to something like this instead: package (version) sid; urgency=low * Binary-only non-maintainer upload; no source changes. -- Debian Release Team Tue, 05 Jun 2012 16:33:05 + or some other appropriate binnmu mailing address. This would also mean rebuilding all of the other architectures for multi-arch same packages so that they all get the same changelog. Best wishes, Mike -- 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/CANTw=mpzr8wmwtrg4geqe5tscxhavcbiceny1wnp0zutf_c...@mail.gmail.com
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Thu, Jun 14, 2012 at 12:40 PM, Cyril Brulebois wrote: > Michael Gilbert (14/06/2012): >> package (version) sid; urgency=low >> >> * Binary-only non-maintainer upload; no source changes. >> >> -- Debian Release Team Tue, 05 Jun >> 2012 16:33:05 + >> >> or some other appropriate binnmu mailing address. This would also >> mean rebuilding all of the other architectures for multi-arch same >> packages so that they all get the same changelog. > > No, binNMUs numbers can be different, along with timestamps (even with: > “wb nmu foo . ALL . -m 'Rebuild for foo.'”, architectures are processed > one after each other). Also, reasons can be different. Right, I imagine it will involving reworking of quite a few steps in the process, and again this would be only for 'multi-arch: same'. So, instead of the buildd (or wherever that is done now) creating the changelog/timestamp, instead create one 'multi-arch: same' changelog before passing it off to the buildds, and then after the build is done, replace the automatically architecture-specific changelog with the 'multi-arch: same' one. The reason for rebuilding a 'multi-arch: same' package by definition should be for the same reason on all architectures, right? Non 'multi-arch: same' binnmus would not need to change. Best wishes, Mike -- 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/CANTw=mpnlz6gvczq2scfyzvzu_qvtn_s9ab7+i9kbjozled...@mail.gmail.com
