Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?
Mike Hommey a écrit : On Tue, Apr 28, 2009 at 08:12:22PM +1000, Ben Finney wrote: Brett Parker idu...@sommitrealweird.co.uk writes: On 27 Apr 18:55, Noah Slater wrote: Unfortunately, I don't use folders so I don't think this will work for me. *boggle* - you claim to be on multiple lists and yet you don't use server side filtering and folders?! OK - now that's just plain odd. Folders aren't the only way to manage lots of messages sanely; ask any Google Mail user. Since I wouldn't dream of recommending anyone use a proprietary data silo like Google Mail, I invite you instead to look at the ‘sup’ package for a folder-less approach to organising email messages that many say is superior. Description: Software Upgrade Protocol implementation ? sup-mail - thread-centric mailer with tagging and fast search -- Mehdi Dogguy مهدي الدقي http://www.pps.jussieu.fr/~dogguy Tel.: (+33).1.44.27.28.38 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Josselin Mouette wrote: Hi, as the topic says, I noticed the new ia32-libs package depends on ia32-apt-get. I searched the list archive and found only one thread[1] related to ia32-apt-get. Correct me if I'm wrong but it was clear for me, when reading comments, that the solution was not acceptable and no consensus was reached. So why was it uploaded without further discussions on the list? Shouldn't be uploaded into experimental instead of unstable? … Do you consider it as a “releasable” solution? How would aptitude users do now? [1] http://lists.debian.org/debian-devel/2009/03/msg01849.html Cheers, -- Mehdi Dogguy مهدي الدڤي http://www.pps.jussieu.fr/~dogguy Tel.: (+33).1.44.27.28.38 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
Martin Wuertele wrote: If you want to test packages not yet ready for debian you can upload them to universe. What's universe ? You mean experimental ? -- Mehdi Dogguy مهدي الدقي http://www.pps.jussieu.fr/~dogguy Tel.: (+33).1.44.27.28.38 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#515617: ITP: laby -- Laby is a small program to learn how to program with ants and spider webs.
Package: wnpp Severity: wishlist Owner: Mehdi Dogguy dog...@pps.jussieu.fr * Package name: laby Version : 20080818 Upstream Author : Stéphane Gimenez gime...@pps.jussieu.fr * URL : http://www/~gimenez/enseignement.html * License : GPLv3 Programming Lang: OCaml Description : A small program to learn how to program with ants and spider webs. Laby is a small program to learn how to program with ants and spider webs. You have to move an ant out of a labyrinth. You have to avoid spider webs, move rocks, etc. .. Using Laby, you can learn OCaml, C and Java. Other bindings can be added later to support new programming languages. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#515617: ITP: laby -- Laby is a small program to learn how to program with ants and spider webs.
Brett Parker wrote: On 16 Feb 16:15, Mehdi Dogguy wrote: Package: wnpp Severity: wishlist Owner: Mehdi Dogguy dog...@pps.jussieu.fr * Package name: laby Version : 20080818 Upstream Author : Stéphane Gimenez gime...@pps.jussieu.fr * URL : http://www/~gimenez/enseignement.html That's fine if you have pps.jussieu.fr as the first thing in your search path, I, err, don't. So: http://www.pps.jussieu.fr/~gimenez/enseignement.html Yes. Sorry for that. I've already sent the correct url to #515617 Maybe, I had to add de...@lists.d.o ... (Sounded like fun, looks fun... might have a look at some point :) -- Mehdi Dogguy مهدي الدقي http://www.pps.jussieu.fr/~dogguy Tel.: (+33).1.44.27.28.38 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PlayOnLinux in contrib
Bertrand Marc wrote: The PlayOnLinux program itself is written under the GPL2+ so I (and my sponsor) think it could be uploaded to contrib. Do you think such a program which allows to easily install proprietary softs in a Debian system would be acceptable in contrib and would not be a policy violation ? If it's GPLv2+ and doesn't depend on proprietary software, why it cannot be in main? Does it depend on proprietary things? Regards, -- Mehdi Dogguy مهدي الدقي http://www.pps.jussieu.fr/~dogguy Tel.: (+33).1.44.27.28.38 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Squeeze can't fit on 512MiB
On 12/15/2010 07:02 PM, Joey Hess wrote: Samuel Thibault wrote: - Gnome grew from 1830MiB to 2409MiB, still can't fit on just CD1. This should fix itself once both tasksel 2.88 and gnome-core 1:2.30+7 reach testing. Should happen by monday, would appreciate any testing you can do. Both migrated during yesterday's britney run, fwiw. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4d09d911.9080...@dogguy.org
Re: Question: How is debian-policy during freeze?
On 12/24/2010 03:45 PM, Hans-J. Ullrich wrote: Am Freitag, 24. Dezember 2010 schrieb Olaf van der Spek: On Fri, Dec 24, 2010 at 3:05 PM, Hans-J. Ullrich hans.ullr...@loop.de wrote: Yeah, the bug was reported, the bug was fixed, but the version with the fix is not beein updated in testing. Link to bug report? Olaf This is the link: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562560 FTR, it has been unblocked by Julien. It will migrate during next britney's run. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4d14b6ad.5070...@debian.org
Re: Release Update: deep freeze, remaining bugs, schedule, themes and Wheezy
On 12/26/2010 09:15 PM, Steve M. Robbins wrote: Hi, This release update announced: As hinted in the previous release update, now is the time to decide exactly what is going in to squeeze and what isn't. Here's what we're going to propose regarding the remaining RC bugs. We'll be working against the list of RC bugs affecting Squeeze that are not fixed in unstable: http://udd.debian.org/bugs.cgi?release=squeezenotsqueeze=ignmerged=ignrc=1sortby=idsorto=asc Members of the Release Team will be considering bugs in that list, in the form: Squeeze: can-defer Squeeze: will-remove Squeeze: is-blocker Has this work started? Yes. You can see [1] for what has been tagged already. [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=release.debian@packages.debian.org;tag=squeeze-can-defer;tag=squeeze-will-remove;tag=squeeze-is-blocker;ordering=squeeze-sort I ask because there seem to be bugs on that list that can easily be deferred -- for example 147832 -- that are not so tagged. I'll have a look at it. Is the tagging to be done by anyone or only by the release team? The latter. Do you want suggestions sent to you? Feel free to send us suggestions at debian-rele...@lists.debian.org Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4d17a4c1.5050...@debian.org
Re: new scripts and patches for devscripts
On 08/03/2011 23:01, Benjamin Drung wrote: check-symbols I always hated programs that do sudo (and even more those doing it *twice*). And, isn't just unpacking the .deb and checking for .so there enough? You could have undefined symbols… but that may not be an issue most of the time, IMO. (when diffing like in this case). pbuilder-dist cowbuilder-dist mk-sbuild Those could be integrated in pbuilder/cowbuilder/sbuild as examples, IMHO. get-build-deps Is this an alias for apt-get build-dep $1? pull-debian-source (?) apt-get source $src ? reverse-build-depends This is build-rdeps, already in devscripts, afaik. suspicious-source what-patch I thought that the reason for this script to exist is to be used by other scripts (like edit-patch, or add-patch) but it seems like it's not. I'm not even sure that it helps beginners since it hides some very basic information that every new maintainer should learn. Am I wrong here? Encouraging people to document how they patch their package could be a better initiative, IMHO. Most of the script are written in Python. Rewriting them to get them included in devscripts is too much work without benefit. devscripts would depend on python then. I suspect that the number of scripts to be moved is quite low. Moreover, most of them are very simple and can be rewritten very easily. Is rewriting them not an option? Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4d790b2c.2000...@dogguy.org
Re: new scripts and patches for devscripts
On 03/10/2011 10:32 PM, Steve Langasek wrote: On Thu, Mar 10, 2011 at 09:50:57PM +0100, gregor herrmann wrote: On Thu, 10 Mar 2011 10:51:50 -0800, Steve Langasek wrote: get-build-deps Is this an alias for apt-get build-dep $1? No, it's a tool that's been long missing from a Debian as a standard interface - install the build-dependencies for the package in my current directory. Sounds similar to 'mk-build-deps -i debian/control'. Note that you don't have to say debian/control there. It's the default. I wonder why -i and -r aren't activated by default though. That's not a vote for get-build-deps is useless but an encouragement for merging similar efforts and combining forces. Certainly, I agree that efforts should be merged. In a sense, that's what this request to take u-d-t scripts into devscripts is about. :) FWIW, mk-build-deps is close, but not exactly what I'm looking for personally. I really want a command that, without needing to specify any extra options, does 'mk-build-deps -i -r debian/control', because I think this is the common case. I also think we're missing as a standard interface a tool that *tells* us what build-dependencies need to be installed (and what build-conflicts need to be removed), in a form that's automatically consumable by other tools including, but not limited to, apt-get. dpkg-checkbuilddeps fails this because it only tells which b-d's are unsatisfied, in a form that has to be further processed. I hope that this poney^W two-lines script won't use sudo (again). Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4d7949d6.6090...@dogguy.org
Re: new scripts and patches for devscripts
On 11/03/2011 11:11, Joachim Breitner wrote:
There is also this in haskell-debian-utils, although not very widely
advocated:
* apt-get-build-depends:
Tool which will parse the Build-Depends{-Indep} lines from debian/control
and apt-get install the required packages
see http://packages.debian.org/sid/haskell-debian-utils
But it doesn't create a meta packages, which is (IMHO) one of the key
features of mk-build-deps. The information is then exposed quite clearly
by several tools as you'll see that meta-package as local/obsolete… very
handy when cleaning up the system.
pbuilder-satisfydepends has the same feature, but it always uses
pbuilder-satisfydepends-dummy as a name for the meta-package. So, it's
not possible to track build-depends of two different source packages… which
is possible using mk-build-deps. I didn't see this feature implemented in
other mentioned tools.
Regards,
--
Mehdi Dogguy مهدي الدڤي
http://dogguy.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/4d7a0fd5.7060...@dogguy.org
Re: new scripts and patches for devscripts
On 12/03/2011 12:51, Benjamin Drung wrote: pull-debian-source (?) apt-get source $src ? Not really, because for apt-get source $src you need an entry in your sources.list. With pull-debian-source $src experimental you get the experimental package, with pull-debian-source $src lenny you get the lenny package, and so on. ok, looks useful indeed. suspicious-source what-patch I thought that the reason for this script to exist is to be used by other scripts (like edit-patch, or add-patch) but it seems like it's not. I'm not even sure that it helps beginners since it hides some very basic information that every new maintainer should learn. Am I wrong here? suspicious-source is a tool to find pre-generated files (files not in the preferred form for editing). Yeah. My comment was about what-patch only, but due to bad line wrapping, they ended up on the same line :) Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4d7e0ce6.6080...@dogguy.org
Re: Cross compiler ITP (armel)
On 23/03/2011 11:59, Goswin von Brederlow wrote: Philipp Kerntr...@philkern.de writes: On 2011-03-23, Goswin von Brederlowgoswin-...@web.de wrote: Also does the testing transition consider the Built-Using? If I specify 'Built-Using: gcc-4.5 (= 4.5.2-5)' will the package be blocked from entering testing until gcc-4.5 (= 4.5.2-5) has entered and block gcc-4.5 (= 4.5.2-5) from being replaced from testing? It doesn't need to. All we want is compliance on the archive side so that the sources are not expired away, as long as that binary is carried in a suite. No need to involve britney at that point. Kind regards Philipp Kern Not quite. For ia32-libs it would be nice if ia32-libs could be blocked from testing as long as the source packages it includes aren't in testing. Currently that is solved by building against testing in the first palce. But that is something we can live with. It's correct that there is no need to consider Built-Using when migrating packages from one distribution to another, because the information there is too strict. Instead, we could check that Build-Depends are fulfilled when migrating the package. But, this is a long standing known issue (#145257). Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4d89d34f.8060...@dogguy.org
Re: plan to clean up unstable
On 04/10/2011 06:45 PM, Torsten Werner wrote: I plan to remove very old source packages from unstable. The actual algorithm will be: from all source packages that have more than 1 versions in unstable: remove all of them that have version newest_version and that have been uploaded before 2009. can't this limit to 2009 be pushed further? what would be the difference if we consider 2010, or 2011? (Just want to see the impact). Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4da1ebb7.9020...@dogguy.org
Re: network-manager as default? No!
On 13/04/2011 10:53, Bernd Zeimetz wrote: On 04/04/2011 12:56 PM, Jon Dowland wrote: On Sun, Apr 03, 2011 at 07:22:47PM +0300, Faidon Liambotis wrote: It also can't do VLANs (.1q), bridges, bonds and all possible permutations of the above. I'd speculate that it also wouldn't be able to do things like 1k (or more) interfaces. It also doesn't support hooks to be able to do more advanced setups, such as multihoming, policy routing, QoS, etc. Is it necessary for the distribution's *default* network-management solution to handle all of these? Yes. For a distribution which is targeted to support servers properly, yes, definitely. For everything else there is Ubuntu. I sincerely hope that you're joking… At least, the rest of the project doesn't share this view. It's like saying that Desktop users are second class citizens, which is plain wrong! Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4da58c33.8060...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 13/04/2011 14:21, Raphael Hertzog wrote:
On Wed, 13 Apr 2011, sean finney wrote:
I don't think I've heard anything back from anyone who's actually on
the release team regarding this, but if they were at least non-comittedly
open to the idea, I'd be willing to throw my hat into the ring to help
put something together.
Yeah, it would be great to have some feedback from RT team members. I
tried to get some indirectly when I interviewed Meddi Dogguy and Adam D.
Barratt:
http://raphaelhertzog.com/2011/04/07/people-behind-debian-adam-d-barratt-release-manager/
http://raphaelhertzog.com/2010/12/23/people-behind-debian-mehdi-dogguy-release-assistant/
Funny… reading your recent blogpost, you seem to not understand yet what
you want to put into Rolling (and how). So, how can we comment on
something that's not set or clearly described yet? Make a plan first, ask
for questions later, please.
There are certainly some ideas flowing here and there… but I can't find a
document that describes clearly what that suite is!
For example: What would be Rolling's content right after a release?
(comparing to testing, which starts from the stable just released). I
guess you cannot merge because testng will be lagging behind a bit. You
cannot just get what's in testing and restart from fresh, because there
might be users that won't like it. If you continue, there will be no
relation with testing anymore. The two suites will have their own set of
problems, I guess.
Again, I don't know yet how Rolling is supposed to be run. So, I might be
wrong.
Regards,
--
Mehdi Dogguy مهدي الدڤي
mehdi@{dogguy.org,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/4db83d36.2070...@debian.org
Re: Bits from the Release Team - Kicking off Wheezy
On 28/04/2011 11:48, Simon McVittie wrote: On Thu, 28 Apr 2011 at 11:29:28 +0200, Raphael Hertzog wrote: - at freeze time, instead of freezing rolling, we make a snapshot of rolling (I call it testing) and this is where we do the work left to make it ready for release So your testing is essentially the pre-2000 frozen distribution [1], and your rolling is basically the current testing without the need to freeze? If that's the case, calling the distributions unstable/testing/frozen/stable might make everyone less confused :-) uh… thanks! that's more clear, indeed. [1] Announcement of 'testing': http://lists.debian.org/debian-devel/2000/08/msg00906.html Regards, S -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4db94926.2010...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 28/04/2011 09:06, Stefano Zacchiroli wrote: On Wed, Apr 27, 2011 at 05:58:46PM +0200, Mehdi Dogguy wrote: Funny… reading your recent blogpost, (FWIW, the blog post Mehdi is referring to is, I guess, at [1]) you seem to not understand yet what you want to put into Rolling (and how). So, how can we comment on something that's not set or clearly described yet? While your criticism are sound and the issue of how to merge back rolling after releases seems a difficult one to solve, I don't think your comment on how can we comment? is fair. […] Don't get me wrong here! I find his survey useful too… but, no one has a clear idea on what rolling will look like yet. That was my point. That's it. Hopefully, raphael sent something in this thread that will make things more clear. (at least to me). Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4db949b4.6010...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 28/04/2011 12:03, Raphael Hertzog wrote: On Thu, 28 Apr 2011, Simon McVittie wrote: On Thu, 28 Apr 2011 at 11:29:28 +0200, Raphael Hertzog wrote: - at freeze time, instead of freezing rolling, we make a snapshot of rolling (I call it testing) and this is where we do the work left to make it ready for release So your testing is essentially the pre-2000 frozen distribution [1], and your rolling is basically the current testing without the need to freeze? Yes. If that's the case, calling the distributions unstable/testing/frozen/stable might make everyone less confused :-) +1 Might be, except that I don't want to keep the name testing due to its connotation that doesn't reflect well the goal of something that's constantly usable. Except that it's lying to our users to name it rolling because packages from rolling won't be rc-bug free. For this reason, I think that testing is a very well choosen name, more honest about its state. If people think that testing (as a suite) is broken, then we should try to change that idea, instead of just changing its name. (IMO) Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4db94b3e.8080...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 28/04/2011 11:29, Raphael Hertzog wrote:
On Wed, 27 Apr 2011, Mehdi Dogguy wrote:
For example: What would be Rolling's content right after a release?
(comparing to testing, which starts from the stable just released).
I
Rolling doesn't magically change after a release. It's still the result
of the migration of packages from unstable into it.
I said in my blog post[1] that testing is branched-off from rolling.
This means: - rolling is the long-lasting distribution where packages
migrate from unstable - at freeze time, instead of freezing rolling, we
make a snapshot of rolling (I call it testing) and this is where we do
the work left to make it ready for release - testing is really a
temporary distribution that has a purpose only during freeze, if you
use testing when there's no freeze you're just using stable because
the testing symlink is still pointing to the distribution that has been
released now
Thanks! This made it clear to me. So, aiui, this is different from the
initial plan. CUT folks said that testing has some problems such as
removal of pacakges. They wanted to do regular snapshots of testing, etc…
But, aiui, this new rolling plan has nothing to do with the original
proposal. And, it doesn't solve the problem of removals (well, or only
during a freeze).
So, the workflows (old and new) can be described as follows:
(Note that I use testing and frozen in the table below to not add
confusion and to make clear what will be new, and what already exists and
works… If we want to change names, okay, but let's describe the process
with what we have *now*.).
| before| during | release
| freeze| freeze | day+1
| dev period | |
———
|sid |sid |sid
before | testing| testing (frozen) | testing==stable
| stable | stable | stable
———
|sid | sid |sid
after | testing| testing| testing
| stable|frozen| frozen (new stable now)
| |stable| oldstable
———
Is this what you have in mind? (just checking since I think that I didn't
get it right yet, sorry!). How's rolling different from testing? (except
that testing freezes from time to time… yes, I know, that's the main point
of the proposal, but still, I want to know if there are other changes).
Regards,
--
Mehdi Dogguy مهدي الدڤي
mehdi@{dogguy.org,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/4db967a7.8090...@debian.org
Re: Bits from the Release Team - Kicking off Wheezy
On 28/04/2011 15:52, Raphael Hertzog wrote: On Thu, 28 Apr 2011, Mehdi Dogguy wrote: | before| during | release | freeze| freeze | day+1 | dev period | | ——— |sid |sid |sid before | testing| testing (frozen) | testing==stable | stable | stable | stable ——— |sid | sid |sid after | testing| testing | testing | stable|frozen| frozen (new stable now) | |stable| oldstable ——— Is this what you have in mind? Yes (except you missed oldstable in the cell before / release day+1). Right. It's not important for our discussion though. But, you're are right. How's rolling different from testing? (except that testing freezes from time to time… yes, I know, that's the main point of the proposal, but still, I want to know if there are other changes). It's not different. Then I have a few remarks. I wrote them earlier today, but then wondered if my table was correct… So, I kept them in a private draft: Philip mentioned some problems with this approach, which are listed below. There are other issues I want to mention here (you may judge them as minor, but let's see): 1) At the beginning of the developement cycle, (with the new plan) you start from testing, and not the new stable. So, you don't start with a base that's rc-bug free, or at least, as polished as the new stable is. 2) During the freeze, you're killing an important step in the Release process which is the testing. Packages that move from sid to testing are tested by a huge user base (sid users), and then double-tested by testing users. Problems are seen in sid first and stopped from migrating if there are issues. During the freeze, we try to avoid using testing-proposed-updates as much as possible, because fixes that are pushed through t-p-u are not tested enough. We really try to use it when it's really not possible to go through sid. And, it's too late when the t-p-u fix lands in testing because it might require some work to get things fixed again (if it has some regressions ; if it breaks other packages ; etc…). 3) All updates to frozen have to be made through $codename-proposed-updates. That isn't great because we don't test fixes uploaded there hard enough. Now, IMHO, #1 is a sad thing and a pity. #2 is crucial during the freeze period. and #2 and #3 might imply longer freeze period. The fact that we start the dev cycle with the new stable and that sid and testing are used to test the future stable is what makes the quality of our stable releases outstanding! (IMHO). So, your proposal isn't really about rolling, that's just changing the name of something that exists already. It's not new. What's new is frozen! The fact that testing will never freeze is just a by-product of frozen being used to create the future stable. And as Phil said, it requires adding a *lot* of people on frozen to make this viable. I *think* that advertising your proposal as frozen will make things clearer for everyone, and reflects better where change is done. Having that said, I do agree with Zack when he says that advertising it as rolling might have a positive effect on our users. But, okay, that's a matter of asking FTP-folks to add a symlink rolling → testing. But, let's go back to the original problem. We want something to use for everyday, that works, that's mostly stable (not in the sense of stable release but rather doesn't have much issues), etc… Testing works¹, and works great (IMHO). A lot of people want a testing suite that never freezes. And your proposal is one way to get that done. There are other ideas though. The real problem (and the obvious one) isn't the freeze… but rather its duration! We have to try to make freeze periods shorter. If the freeze lasts² two or threee months, it's not a big deal… the freeze becomes quite a burden when it lasts six months. We don't care (almost) about the number of RC-bugs during the dev cycle… and that's one of the issues that cause longer freeze periods. Why not working on this side? ¹: Well, you can't say no since rolling *is* testing :) ²: No, 3 months isn't 25% of $dev-cylce 1y. There are other possible changes but I want to discuss them separately because even without those changes, the testing without freeze is a worthwhile goal in itself. Still, since you seem to insist, here are ideas I'd like to investigate: Well, you asked us to comment on your proposal… - reduce the set of architectures required for migration to testing to i386/amd64/armel and have buildd of other architectures prioritize missing builds in testing over missing builds in unstable (freeze should be enough time even for slow arches to catch up and FTBFS on already
Re: Bits from the Release Team - Kicking off Wheezy
On 28/04/2011 17:30, Raphael Hertzog wrote:
See
http://raphaelhertzog.com/2011/04/28/no-freeze-of-debian-development-what-does-it-entail/
for a more detailed answer and related suggestions to limit this problem.
I'm still reading and thinking… so, don't have an answer yet. But, it
you'd like me to read your ideas, you're going to put some efforts and
post them here, instead of pointing me to your blog. really.
--
Mehdi Dogguy مهدي الدڤي
mehdi@{dogguy.org,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/4db9891a.8030...@debian.org
Re: Bits from the Release Team - Kicking off Wheezy
On 28/04/2011 17:25, Lucas Nussbaum wrote: On 28/04/11 at 16:52 +0200, Mehdi Dogguy wrote: 1) At the beginning of the developement cycle, (with the new plan) you start from testing, and not the new stable. So, you don't start with a base that's rc-bug free, or at least, as polished as the new stable is. That's true. But the counter-argument to that is that, since new packages will get some testing in rolling, all the new and broken stuff will not land in unstable at the same time, and we won't end up with 800 new rolling? (and you seem to use testing in the next sentence). (I really think that we should forget about rolling for now… since it's confusing even for you) RC bugs in testing 3 months after the release like we have currently. Also, with more users of testing/rolling, there will be: - more pressure to keep testing/rolling in an usable state at all times having it usable and having a low number of RC-bugs are completely two different things. (IMO) - more bug reporters *iff* we get more users of testing/rolling. If you add more suites, you'll get less bugreports in one of them¹. Then, you may argue that we are more interested on a subset and not all of them. But, we try to keep the same level of quality for *all* of them. ¹: It's the same kind of assumptions that we will get more users. Yes, I can also say we will get less bugreports for frozen. 2) During the freeze, you're killing an important step in the Release process which is the testing. Packages that move from sid to testing are tested by a huge user base (sid users), and then double-tested by testing users. Problems are seen in sid first and stopped from migrating if there are issues. During the freeze, we try to avoid using testing-proposed-updates as much as possible, because fixes that are pushed through t-p-u are not tested enough. That is based on the assumption that the sid users base is larger than the testing user base. Do you have hard numbers about that? I've often seen obvious important bugs only get reported when the package reaches testing, while the bug could easily have been found in unstable. It's based on the assumption (if we consider that the proposal has been accepted and applied) that we won't have a big number of users of frozen… which is quite a problem. That would be true at least for the beginning of the cycle. We really try to use it when it's really not possible to go through sid. And, it's too late when the t-p-u fix lands in testing because it might require some work to get things fixed again (if it has some regressions ; if it breaks other packages ; etc…). 3) All updates to frozen have to be made through $codename-proposed-updates. That isn't great because we don't test fixes uploaded there hard enough. ... but they are tested once they reach testing. In the new scenario, they'll be testing when they reach frozen. What I'm arguing here is that we will have less users of frozen, than we used to have for testing. To rephrase your points, I think that they boil down to Users that currently use testing during freezes will be tempted to use rolling during freezes, so frozen will get less testing. or using rolling everytime. why should they use frozen if rolling still fits their needs? I agree that it's a problem. However: - we are likely to get more rolling+unstable users than the current testing+sid users, so rolling release will get more testing until the freeze. rolling release? do you mean rolling suite? - even at the beginning of a freeze, frozen is likely to be of higher quality than testing at the beginning of a freeze. We might encourage users to upgrade from stable on non-critical machines earlier. at the beginning of a freeze, frozen is created from rolling. How's that different from testing? That's based on the assumption that we will have more rolling users, more bug reporters, more… and poneys. - we could encourage rolling users to switch to frozen at least for some time, since it's a good way to help get a better Debian stable release. We encourage the contributors to do a lot of things during the freeze. I never saw those recommandations followed. tbh. Do you intend that users are better citizens than contributors? (ok, semi-joking :)) Do you think that users follow closely what's happening in Debian? TBH, Until last January, I had some friends that were not aware that we were frozen. (fwiw, they are testing and stable users). So, your proposal isn't really about rolling, that's just changing the name of something that exists already. It's not new. What's new is frozen! The fact that testing will never freeze is just a by-product of frozen being used to create the future stable. And as Phil said, it requires adding a *lot* of people on frozen to make this viable. I *think* that advertising your proposal as frozen will make things clearer for everyone, and reflects
Re: Bits from the Release Team - Kicking off Wheezy
On 28/04/2011 17:30, Raphael Hertzog wrote:
On Thu, 28 Apr 2011, Mehdi Dogguy wrote:
1) At the beginning of the developement cycle, (with the new plan) you
start from testing, and not the new stable. So, you don't start with a
base that's rc-bug free, or at least, as polished as the new stable is.
First, the beginning of the development cycle is no longer so clear cut.
You take the release, but we could just as well consider the freeze as the
start of the new developement cycle because development can continue and
won't end up in the next stable release.
It's clear that testing will have higher number of RC bugs than the new
stable but they should not be the same. Because any RC bug fixed in frozen
should really be fixed in unstable at the same time (and the BTS version
tracking ensures we don't miss them).
It just means that we already see RC bugs that we would have only
discovered a few months later if testing/unstable had been frozen.
So in the end it means we have more time to discover and fix RC bugs
that are going to affect the version of Debian.
That's not really guaranteed. I don't know on which fact this is based on.
3) All updates to frozen have to be made through
$codename-proposed-updates. That isn't great because we don't test fixes
uploaded there hard enough.
No, only updates of packages which have been affected by a transition or
packages which have had a newer upstream version in unstable will have to
go through that route. The percentage of affected packages start at 0%
the day of the freeze and grows slowly during the freeze. (You can still
use britney on top of unstable during the freeze)
So, we will have a britney running between testing and frozen. (I guess).
Also, we try to accept only packages with a small diff during the freeze.
If the rolling idea is implemented, contributors would be concentrating on
introducing new stuff in unstable, that's really *new*. I'm pretty sure
that the diff won't be as small as we require it to be during a freeze.
So, all in all, we will have to use t-p-u really more often.
And even when $codename-proposed-updates has to be used, there are cases
where it's possible to take the fixed source package in unstable and just
rebuild it in $codename (packages without new upstream versions but which
have fixes and have been entangled in a transition). Even if it's
recompiled in a different environment, it's still better than receiving a
completely untested package.
Again, with rolling implemented, I'm not sure you'll be able to do it à la
Ubuntu way. You'll have to select a patch from the whole diff, and apply
it and then upload to t-p-u. In this case, it really depends on what kind
of changes were introduced. You might see funny stuff happen with that
patch applied, without the rest of the diff. Remember that we live in the
Rolling world, where contributors continue to do their developement during
the freeze, where new versions are introduced, where it's not obvious that
you'll find manpower of motivation to fix an old version when you're in
the middle of a transition happening…
That said, I would gladly also experiment other ways to reduce the length
of the freeze. Do you have ideas?
You want a constantly usable testing, but are you working these days on
fixing RC bugs affecting testing? Don't get me wrong. I'm not
finger-printing. I didn't find time to do that myself. But, if we all try
to do that, things will be much more simpler (welcome in bisounours world).
Last bits of the Release Team announced a perpetual 0-day NMU policy. I
think that it's a good move to encourage contributors to fix more RC-bugs,
even if we are not frozen (yet). I have the feeling that no-one read that
announcement…
[1] http://lists.debian.org/debian-devel-announce/2011/03/msg00016.html
Mine is that officially supporting testing means that more maintainers
will start to care about RC bugs in testing and will fix them sooner (i.e.
not wait for the freeze to do it).
We really don't need to wait for that to encourage contributors to care
about RC bugs in testing. Zack did a great job with his “Release Critical
Bugs of the Week” (RCBW) [2]. That's another great idea that could enhance
testing's state. Why not start to fix RC-bugs today? until the next
freeze! Why adding a new suite to force people to fix RC-bugs in testing?
(Uh, yes… it's the pretty matches what you said, but expressed explicitely).
[2] http://upsilon.cc/~zack/hacking/debian/rcbw/
To summarize, You can start fixing RC-bugs that affect testing right now!
What are you waiting for?
Regards,
--
Mehdi Dogguy مهدي الدڤي
mehdi@{dogguy.org,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/4db99bc8.4030...@debian.org
Re: Bits from the Release Team - Kicking off Wheezy
On 04/28/2011 07:15 PM, Lucas Nussbaum wrote: Could we try to stay on focus and constructive, and avoid bringing poneys in the discussion? Yes. I'm sorry! I always write a first stupid version and then change it to something reasonable (or drop it), but I forgot to change that sentence. It was really not meant to be sent. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4db9e0fa.8070...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 29/04/2011 14:21, Stefano Zacchiroli wrote: On Thu, Apr 28, 2011 at 10:55:01PM +, Philipp Kern wrote: On 2011-04-28, Raphael Hertzog hert...@debian.org wrote: But I don't plan to work on any of those if the project does not agree to promote testing to something that can be advertised as usable by end-users and as something that we strive to support on a best-effort basis. It's already the case that you can go and send a mail to debian-release@ that package X needs to be put into testing more quickly than the set urgency or asking for permission to upload to t-p-u to fix bugs if the upload is entangled. And apart from that it's supported on a best-effort basis already with bug fixes trickling from unstable into it and critical stuff being fixed faster. Sure. But the procedures you mention above all require work from the maintainer + the release team, while they would require work only from the maintainer in the (hypothetical) rolling scenario. Under heavy load periods for the release team---not only freezes, but also periods with a huge stack of transitions to be completed---the presence of an extra participant might easily become a bottleneck inducing more work (and stress) on everybody shoulders and more delays. In the (hypothetical) rolling scenario¹, one should still follow the same procedure to get the package speedy-migrated (or uploaded to r-p-u, if applicable). So, I don't see where you're winning. I could be missing something here though. ¹: which has, still, to be defined clearly. […] So yes, you're right that _technically_ we can achieve the same with current procedures, but I argue that the underlying procedure doesn't scale (which is unsurprising, given it's been designed for a different purpose). It doesn't mean that it's a problem. Well, yes, it can be enhanced… but I'd say we didn't see periods where all Release Team members were really that busy to not be able to add an age-days hint or approve a t-p-u upload. I'm not sure we will see that day. And the same issue remains true with rolling scenario (existence of that bottleneck). Having that said, avoiding bottlenecks when possible is better. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbab79a.1010...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 04/30/2011 09:14 AM, Raphael Hertzog wrote: That said, we're lacking man power to fix bugs, I don't think that it changes much whether the bug is fixed via unstable or via frozen. Once we are to the point where we have been able to fix a bug in unstable, it's usually not very difficult to fix it in frozen too (unless the fix is in a new upstream version, but that would not help in the current scheme either). I'm not so sure. Contributors will introduce new versions… as we've seen with Chromium, sometimes it's just impossible to fix the old version (because it requires much time and manpower), and we will be forced to accept the new version. We did it _once_ for Chromium, it's not said that we will do that again! So this argument doesn't stand either. It's making a big assumptions on various things. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbbd0ac.3050...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 04/30/2011 09:45 AM, Raphael Hertzog wrote: Who is going to install a rolling release instead of testing? If we change our documentation to say that rolling can be used by anyone who likes a constantly evolving distribution (and can live with the occasionnal hiccup) and that we will do our best to support it, then the public of testing/rolling will be larger. And a larger public, in particular in that set of users who likes bleeding edge stuff, is likely to mean more efficient testing of packages and possibly more contributors. Your proposal if full of optimism and good intentions, and I appreciate that. But, I really think that: 1) it's going to kill stable for reasons already mentioned. 2) you won't be able to bring as much users as you tend to think because one the big problems of testing right now is not the freeze but the lack of installer. If you want to get more users for testing, please do contribute to d-i. We need a lot of manpower and new ideas to implement there. (I'm a big fan of d-i team already because they're doing much work, but they do need help). Users are not interested in installing stable and then upgrade to testing. Why should they bother? there are other distros out there that offer much better installers¹ (in terms of user interface and ease of use). Not to say that we don't even have official llive-cds yet… ¹: although, I do personally prefer Debian's installer. rolling won't fix those problems. And, saying that it'll be supported on a 'best-effort basis', it doesn't ring any bell to me, tbh. We all already do that, except a few (I don't even know who they are). Those won't change their behavior because it's already 'on best-effort basis' for them too :) Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbbea12.8080...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 04/30/2011 12:28 PM, Stefano Zacchiroli wrote: Debian is perfectly good at holding the status quo - it's a well-integrated, stable, mostly state of the art distribution suited for almost anything you can come up with. Trying to repaint one of the existing bikesheds with your new rolling color will not attract the developers (nor users) interested in making it a hip place again. And how do you know that? The first point is confirmed by the number of derivatives of Debian. The second can be argued, IMHO, by the fact that there won't be releases of rolling. They won't be working installers at all times. It's supported on 'best-effort' basis… we *already* try to do that. Advertising that won't change anything for developers (we are not evil), but only for users! Well, some of them, those reading planet, d-d-a, or $whatever_news_media that will explain clearly and in a faithful way the change. In fact, I'm even happy to see becoming manifest the various disagreement and different expectations we have around testing: on such vague aspects it's hard to have upfront agreements. But both you and Raphael are taking guesses on the number of users / developers / effects of a thing which does not exist yet. At this point, it can only be speculation. You might disagree how much as you please, but there is only one way to know who is right: build the thing. And you can do that right now, without waiting. Go book rolling.debian.net and set up a britney instance there. It's not a difficult task. It will help us to know who actually uses it, when, how much, etc… Please do prove us wrong! Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbbec8d.3010...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 04/28/2011 08:20 PM, Lucas Nussbaum wrote: The sooner we get the big transitions done, the sooner we can focus on fixing the remaining bugs. There will be always new transitions… you're gonna to wait for ever. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbc0132.9050...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 04/30/2011 03:16 PM, Arno Töll wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30.04.2011 14:36, Andreas Barth wrote: Feel free to use rolling.debian.net, set it up and have success. Like aj did with setting up testing (after frozen has burned IIRC three release managers without an release). Perhaps that's a not a particular fair demand. See, crucial for Raphaels idea as I read it is official support to users using a rolling distribution. For both, user support and bug fixing of course. In this particular case, the official bit won't change anything for developers. It's only a buzz word to attract more users, IMHO. How could he ever succeed if he can't be sure people involved into Debian development would at least partially support his approach then? Imagine people would ask for help on various d-u lists or in the Debian IRC support channels and all they get is Sorry, we don't support rolling.debian.net, get lost and bother $r_d_n_people; rolling won't have its own set of packages with source modified. It will use packages from unstable, as testing does right now. So, if a bug is found in a package provided by rolling, it's very likely to be found in sid as well. documentation suggests don't use anything but stable and maintainer don't care about fixing bugs which could improve r.d.n stability. Who said that? which documentation are you talking about? Whoever told you that is wrong. Show that it works is the Debian principle, and it works pretty well. I agree. This does not imply others should sabotage his efforts actively. Sorry, but there is no sabotage at all! Everyone if free to set up a rolling.d.n, and it doesn't anything else than manpower and time. All tools and data are already published and free software. And, if he needs assistance to set up one of the needed tools, I'm sure he'll find some. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbc0da3.4080...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 04/30/2011 03:24 PM, Lucas Nussbaum wrote: On 30/04/11 at 14:31 +0200, Mehdi Dogguy wrote: On 04/28/2011 08:20 PM, Lucas Nussbaum wrote: The sooner we get the big transitions done, the sooner we can focus on fixing the remaining bugs. There will be always new transitions… you're gonna to wait for ever. OK, but I'm under the impression that in the first 6 months of a release cycle, we usually have a lot more transitions than during the next 6 months. True. But, big transitions are announced (fortunately), and long time before they start, generally. So, you can see what RC is likely to be fixed by a new upstream release that will be part of a transition, and which won't. YMMV and I can understand that. Also, the fact that we don't have a clear release schedule with a freeze date fixed in advance probably encourages people to start new transition when the reasonable thing to do would be to stop there and stabilize. Quite honestly, we did announce a transition freeze before the big freeze for Squeeze… and it didn't really worked out. We can hope that it'll get better for Wheezy, but we are not there yet. We will have a time-based freeze for Wheezy, let's hope that this will address your concerns (including those mentioned in the next paragraph). One thing that I really enjoyed when I was more active in Ubuntu was the clearly defined release schedules, split into the time when you can break the world, and the time when everybody works towards stabilizing (long before the final freeze). I do agree on this. There is one difference though: they don't care about fixing packages not in main, it's not a release blocker for them (almost). We do have to fix much more than the subset they care about before being able to release. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbc102b.7000...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 04/30/2011 03:47 PM, Arno Töll wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30.04.2011 15:24, Mehdi Dogguy wrote: On 04/30/2011 03:16 PM, Arno Töll wrote: Perhaps that's a not a particular fair demand. See, crucial for Raphaels idea as I read it is official support to users using a rolling distribution. For both, user support and bug fixing of course. In this particular case, the official bit won't change anything for developers. It's only a buzz word to attract more users, IMHO. But an important one, since the whole rolling concept is based on the fact to attract users. They can do it. Let me recall you that Backports was not official until recently and they proven to the project that it was very useful and needed. Then, it got integrated officially into Debian and was advertised as such. rolling can follow the same route to start as well. It will use packages from unstable, as testing does right now. So, if a bug is found in a package provided by rolling, it's very likely to be found in sid as well. Right, maybe I should have been more precise. Read it as: Encourage maintainers to fix (important) bugs in a (more) timely manner (if possible). I admit this is the most important objection most of you seem to have, opposing the idea. I don't care much about the name, etc… I think that advertising testing as ready to users, while we don't have an installer for it is the big problem. The second problem is the frozen (temporary) suite. Some assume that frozen is part of rolling. Some others argue that rolling is just about advertising about a new name for testing. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbc14fb.8080...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 04/30/2011 04:24 PM, George Danchev wrote: - add a new 'frozen' suite, used only during freezes, to prepare the next stable release So, if I need to fix an RC bug during the freeze, I'll upload to unstable, then release managers wait for it to enter rolling and cherry-pick it from there; or do they cherry-pick directly from unstable, skipping rolling; or do they cherry-pick from as they find fit in a mixed fashion. Better. Quite rapidly, we won't be able to cherry-pick from rolling (which is what we used to do up to now). And, the proposal is to ask maintainers to upload the fixed package to $codename-proposed-updates. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbc1e59.5030...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 04/30/2011 05:46 PM, Arno Töll wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30.04.2011 16:48, Andreas Barth wrote: Actually, it worked quite well for both volatile and backports to start as a non-official service. As well as building packages in non-free. And lots of other stuff which was implemented. Why shouldn't it work for rolling.d.n? I didn't say r.d.n should start as official service immediately, I said one should give interested people the possibility to provide a reliable service to prove their idea works. This is a bit different than backports.d.o, which is a pure optional service extension to traditional repositories. If there is a backport for a certain package good, if not: no problem neither from a conceptual perspective. However for a rolling distribution one would not provide some packages in addition to those regularly available through repositories, but provide official maintainer uploads from unstable after a while /and support them/. At least the latter calls the original maintainer to account again, even outside of freeze periods and perhaps in a more timely manner as Sid requires this by people by now. Don't get me wrong, I don't claim this wouldn't be case by now already and many maintainers do a great job anyway. My point is that Raphaels approach needs itself a certain service level in order to provide the same service level to rolling users itself. This is, in turn what you call from him in order to accept a potential rolling branch. How should he though, if people are not willing to help at least passively which gives him a chance to provide a good service? Testing was implemented outside Debian's infrastructure before becoming official too. I don't think it's different from rolling, especially when all the work is already done (migration scripts, etc…) Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbc30ff.8000...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 05/01/2011 08:02 PM, Lucas Nussbaum wrote: There are compromise solutions, too: [Plan C -- freeze rolling before forking frozen:] - do plan A. - But When the release team decides to do a general freeze, rolling is frozen for a few months to maximize user testing and developer attention. After two to four months, 'frozen' is forked from 'rolling', and the normal 'rolling' process resumes. That still means starting the dev cycle with something that's not the just released stable. It looks like a problem, to me. I also think that trying to reduce freeze's duration is the way to go. (and I think I already said so). Some blockers during the freeze have been mentioned on IRC (by Julien, iirc) that ought to be mentioned here (IMHO) just to keep them in mind: 1) someone manpower needed to work on release notes 2) not enough contributors fixing RC-bugs 3) people working on upgrade tests and fixing upgrade issues 4) d-i releases are not frequent and take too long, that really slows down things a bit. It has direct impact on 3). If we can enhance some of them (hopefully, all of them), we will be able to reduce freeze's duration, IMHO. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbdbcba.6020...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 05/02/2011 12:10 AM, Lucas Nussbaum wrote: On 01/05/11 at 23:46 +0200, Pierre Habouzit wrote: Benefits for Debian: - attract users who think that testing is only a development branch, and want newer software than what one finds in stable. Those users are likely to be rather advanced users (developers, free software contributors), thus interesting to work with. Some of them could become Debian contributors. And even if they don't, more users of testing/rolling means more testers of the next stable release [remember how the bug reporting rate of Ubuntu is higher than Debian's -- some areas of Debian could use more testers]. I think those can use unstable, But unstable is a development branch not targeted at being used by 'standard' users. I can also say exactly the same about testing ;) I don't think we can go too far with this argument. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbe55f1.9070...@dogguy.org
Re: Reporting same bug in different packages
On 05/02/2011 10:46 PM, Amaya wrote: Patrick Strasser wrote: I want to report a bug, which occurs in two packages (okular, xpdf) exactly the same way. It's a problem with rendering PDFs. Thanks for spotting this bug. Your contribution to Debian is appreciated. What would be the right way: * File two bugs and refer to each other in a additional message I was curious and took a look at these packages' Depends: field, and they do not share many dependencies. I was suspecting a library would be culprit in the bad rendering, but this doesn't seem the case, so, IMHO, I would file a bug with each viewer, so that each code gets fixed. Well, both do use libpoppler5… which is a PDF rendering library. My 2cents, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbf1a33.7010...@dogguy.org
Re: Perl 5.12 transition in progress; uninstallable packages
) libsub-current-perl (U) libxml-bare-perl (U) AGOSTINI Yves agost...@univ-metz.fr libfilehandle-fmode-perl (U) libyaml-syck-perl (U) Bernd Zeimetz b...@debian.org rrdtool (U) zbar Enrico Zini enr...@debian.org libbuffy-bindings Bas Zoetekouw b...@debian.org libcompress-raw-bzip2-perl (U) libtext-bibtex-perl prima [1] http://release.debian.org/~jcristau/perl5.12-binNMUs-source-all.txt Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbfe402.3080...@dogguy.org
Re: Bits from the Release Team - Kicking off Wheezy
On 03/05/2011 11:41, Lucas Nussbaum wrote:
It is clear from the discussion that there would be consequences. Some
would be negative, some positive. I think that we have now a pretty good
understanding of the possibilities and their consequences. The remaining
problem is to count DDs heads in the two camps:
- Let's focus on stable releases. A rolling release should not be
provided officially by Debian.
- Let's see what we can do about rolling, provided we find a way to do it
without diminishing the quality of our stable releases.
I hope my message will be clear here. But, I find your message quite
subjective. Without reading your message or knowing your opinion on the
subject, we can very easily guess that you prefer the second option.
I don't think that putting people in camps would resolve anything here.
The first option is not about making it not officially provided by Debian,
but there are people that are not convinced yet by the idea and some of
them think that sacrificing stable for the sake of a hype is not a good
idea especially with no evidence that it'll work. There are other
arguments against and your two options really can't summarize all opinions
and looks to me an easy way to diminish what has been said during all this
thread.
And, no, I don't agree when you say I think that we have now a pretty
good understanding of the possibilities and their consequences. All this
thread is about this issue particularly. We don't know yet the
consequences that rolling would have on our stable releases. But, we can't
simply adopt it without having any guarantee on its success. Because if it
turns out that users still prefer $other, then we gained nothing but some
burden within Debian and some bad consequences for Wheezy.
So, please do not use such simplistic conclusions.
Regards,
--
Mehdi Dogguy مهدي الدڤي
mehdi@{dogguy.org,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/4dbfe7a5.60...@debian.org
Re: Bits from the Release Team - Kicking off Wheezy
On 03/05/2011 14:54, Lucas Nussbaum wrote:
What kind of guarantees are you looking for, exactly? Can you suggest
ways to acquire them?
- That it won't affect stable in bad ways.
- preventing removals from testing is a no-go.
Quite honestly, I see no reason to continue feeding this thread because
I realized (maybe quite late) that there were good arguments against
frozen and not much for it apart of hand-waving. It seems that those
who want to have rolling in Debian didn't even try to summarize what
made the success of other rolling distros, and what their users liked
there. We do need this kind of survey before even thinking about how to
do rolling in Debian… and we don't have this kind of data yet.
I don't know (yet) what other rolling distros Debian based offer to its
users that we don't. I don't know what made aptosid so popular. I don't
know what made Mint Debian popular? (and there are others). Did you even
try to gather those informations before even mentioning rolling for
Debian? How can we discuss about rolling in Debian if we don't have
that kind of data? You are always mentioning potential users, but those
potential users might be today-users of aptosid or Mint Debian. So, we
should start from there, instead of just saying No, but you'll see,
rolling will be cool, it will make maintainers care about their
pacakges, it won't affect stable because bla bla bla…
So, I'll start document myself on this and I'll be back when I know enough
about this story. Sadly, I don't have much time to do this these days and
it might take some time. I'd be glad if others start to gather such
informations and put them somewhere so that we don't understand why is it
so important, and why users don't just use testing today.
I can't find the answers here and it seems that you're not able to give
them, because otherwise you would have used them already to say why
rolling will bring users, or what do rolling users like?
(The survey we need should rolling-topic specific, not about Debian in
general).
Regards,
--
Mehdi Dogguy مهدي الدڤي
mehdi@{dogguy.org,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/4dc01f93.2010...@debian.org
Re: Alioth status update, take 3
On 25/05/2011 00:17, Francesco Poli wrote: However the gitweb interface seems to have lost its fancy style sheet that used to be consistent with the Debian web site http://www.debian.org/ which is not a big loss, if you ask me :) Now, it's consistent with Alioth's setup… Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4ddcbc08.9010...@dogguy.org
Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]
On 25/05/2011 13:20, James Vega wrote: On Wed, May 25, 2011 at 12:46:11PM +0200, Bernd Zeimetz wrote: On 05/24/2011 01:00 AM, Michael Biebl wrote: Am 23.05.2011 22:35, schrieb Roland Mas: - anonymous read-only access to the repositories is available by HTTP from wagner, at URLs that look like http://anonscm.debian.org/$scm/$project for $scm in arch bzr darcs git hg; Please provide a proper gitweb instance or at least a proxy at that url to the anonscm gitweb instanace. The old URLs now redirect to the new ones, so nothing should be broken. User-repositories are still broken though (take src:kino as an example). Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4ddce6c5.4040...@dogguy.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
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'm sure there are a lot of other examples) Cheers, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Can quilt delete files?
Thomas Koch wrote: Hi, I'm triing to package a little java library, which contains its own .jar and some pregenerated docs. These files should be regenerated on build time. So I'd like to have them removed by diff.gz Trying to generate an appropriate quilt patch failed. The only thing I came up with, was a patch that contains the whole content of the removed files with - before every line. Anybody more clever then me? What about repackaging? (I assume you are subscribed to the list) -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Can quilt delete files?
Benjamin Drung wrote: Putting 'find . -name *.jar -delete' in you clean rule should do the same job for you. The *.jar files should not be present in the tarball. -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Can quilt delete files?
Thomas Koch wrote: As long as the jar file is the one created by the sourcecode in the tarball, I don't see a reason, that it needs to be removed and thus the upstream tarball repackaged. Right. I missed that from your initial post. -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Key signing
Nicolas wrote: Hi all, I search for a Debian Member to sign my gpg key. I work in Paris. I live in Seine-et-Marne (77). See https://nm.debian.org/gpg_offer.php#FR -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Allow package bug scripts to unconditionally stop reportbug
Joerg Jaspert wrote:
But now I'm wondering if there could be a use case of allowing the
scripts to unconditionally stop reportbug, for example using a
special exit code (140 f.e.) .
42 would be nicer.
Besides, does that mean I just have to put a bugscript in all my
packages exiting 42 and those bugs stop flowing in?
It would certainly shorten the freeze period :)
--
Mehdi Dogguy مهدي الدڤي
me...@{dogguy.org,debian.org}
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About new source formats for packages without patches
Mike Hommey wrote: On Thu, Mar 25, 2010 at 12:49:55PM +0100, Raphael Hertzog wrote: 2/ You explain that you have no reason to switch to the new formats. Fine. I have explained you that I believe there are good reasons for switching (I won't repeat the wiki page). Why are you insisting to not switch when the effort to change is so low in packages without patches? Do you have technical reasons to explicitly avoid the new formats? Why are you insisting that all DDs should switch when switching is an effort for no benefit[1] and not switching is no effort at all ? I don't think that Raphael's mail was meant to insist on you all have to use the new source format but rather to correct/try to understand Niel's blogpost. Even if you don't like the new source format, I find that insisting on not using it with no reason¹ and saying that out loud is quite counterproductive. Besides, may I remind you the existence of this page http://wiki.debian.org/ReleaseGoals/NewDebFormats ? ¹: I didn't find any real reason in the mentioned blogpost. Cheers, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4bab55f1.7040...@dogguy.org
Re: About new source formats for packages without patches
Mike Hommey wrote: On Thu, Mar 25, 2010 at 01:24:17PM +0100, Mehdi Dogguy wrote: […] Besides, may I remind you the existence of this page http://wiki.debian.org/ReleaseGoals/NewDebFormats ? May I remind that several persons pointed out this was not a good goal ? This is not a reason to diminish someone else's work, IMHO. And whether this is a good goal or not is not the subject of this thread. -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4bab597f.6040...@dogguy.org
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
Paul Wise wrote:
On Wed, Mar 31, 2010 at 1:03 AM, Julian Andres Klode j...@debian.org wrote:
Description : debhelper add-on to call autoreconf and clean up after
the build
Package: dh-autoreconf
I'd suggest just putting this into debhelper rather than making it a
separate package.
Is there any advantage to have it packaged?
AIUI, you have to add a build-dependency anyway and change at least one
line in the debian/rules to call dh-autoreconf. Well, that line could
simply call autoreconf (or whatever) which even makes debian/rules clearer.
Cheers,
--
Mehdi Dogguy مهدي الدڤي
me...@{dogguy.org,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/4bb34a6a.3050...@debian.org
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
Julian Andres Klode wrote: On Wed, Mar 31, 2010 at 03:13:14PM +0200, Mehdi Dogguy wrote: Paul Wise wrote: On Wed, Mar 31, 2010 at 1:03 AM, Julian Andres Klode j...@debian.org wrote: Description : debhelper add-on to call autoreconf and clean up after the build Package: dh-autoreconf I'd suggest just putting this into debhelper rather than making it a separate package. Is there any advantage to have it packaged? AIUI, you have to add a build-dependency anyway and change at least one line in the debian/rules to call dh-autoreconf. Well, that line could simply call autoreconf (or whatever) which even makes debian/rules clearer. The difference is that dh_autoreconf calls autoreconf and stores a list of the changes and the changed files are then removed in the clean target. If you just call autoreconf, the changes end up in the diff; and this is not what we want. I do use autoreconf and I don't have these changes in my diff. IMO, a backup/restore script (where you specify the list of files to backup) may be more useful. It would be called before build and when cleaning. Cheers, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4bb351ea.3000...@dogguy.org
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
Julian Andres Klode wrote: A 'debuild; debuild' should have a different result than a single debuild then. If you build from a clean directory, the first build will contain no changes. But after the build, the directory is not clean anymore and debian/rules clean does not do enough to keep the changes from appearing in the source package if you build again. I should have done that earlier (but didn't see the git repo, only now). I had a look at dh-autoreconf's code and the difference between what I do and what your script does is that I manually specify a list of files to monitor while you monitor all files. IMO, dh-autoreconf may be not specific to autoreconf but all same kind of tools and thus, can be enhanced by making, for example, the command to execute an argument which could be the command true (and keep autoreconf as a default) because, sometimes, it may be needed to make debian/autoreconf.after a bit later than just after executing autoreconf. Hopefully, we can do that by overriding the file. If you have these options, dh-autoreconf becomes nothing more than a call to autoreconf if we have dh_backup (name proposed by buxy in the same thread). dh_backup can be integrated to debhelper and all that remains to be done is a call to autoreconf (depending on the implementation of dh_backup). -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4bb36028.7020...@dogguy.org
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
Julian Andres Klode wrote: A backup and restore approach is a completely different and more complicated (in I/O sense) way than just deleting the files; e.g. for a single file: … except that they do not operate on the same set of files. dh_backup's list would be a lot smaller than dh_autoreconf's one. Besides, dh_backup (or whatever its name is) could also delete files upon request (dh_backup --remove would then be dh_autoreconf minus autoreconf). dh_backup: 1. mkdir() - Create the backup directory you can use then debian/ directory here (provided you add a suffix to backup's name). And, dh_autoreconf also creates a directory for excluded files (if any). So, I don't think that this part is really relevant for the comparison. I think that all arguments in favour or against have been mentioned. I don't have anything to add. If it really makes you happy to have this package, then so be it :) Cheers, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4bb37759.3070...@dogguy.org
RFC: ubuntudiff.debian.net
Hi all,
Sometimes, I need to see what happens to my packages in Ubuntu. To see
quickly the changes of a given package, I open its PTS page, search for
the Ubuntu box, and then click on Patches….
I find this really painful and not really helpful when you want to inspect
a set of packages (but I do appreciate the work done on that). What I
really missed was a way to see quickly the list of changes for a given
package. The best way to see that is to extract from Ubuntu's changelog
only the relevant part.
I'm aware of other solutions like [0] and [-1] but they have the same
drawbacks as the Ubuntu box.
[0] http://people.debian.org/~bartm/borg/outdated.html : Utnubu provides
other kind of informations, but for other matters.
[-1] http://qa.ubuntuwire.org/multidistrotools/ : not really configurable…
e.g. they don't list changes for OCaml packages and I don't know how to
add that. In any case, it doesn't show the changelog diff.
So, I tried to come up with a solution and wrote a small program that
generates a nice website: http://ubuntudiff.debian.net
(In case you want to dig into the source code, the program that generates
the website is called Maddie and it's main source file and is maddie.ml…
yes, it's written in OCaml :)).
So, to see Ubuntu differences wrt. to Debian, you have to write down a
grep-dctrl query¹ identifying the packages you're interested in and then
click on the Search button. In case you have a very simple query (using
a single filter), you can use the following shortcut:
- http://ubuntudiff.debian.net/q/package/linux-ntfs
- http://ubuntudiff.debian.net/q/maintainer/pkg-java
- or, http://ubuntudiff.debian.net/q/$field_name/$filter_argument
You can also perform quick exact queries by replacing the q by x
(like -X grep-dctrl's option):
- http://ubuntudiff.debian.net/x/package/linux-ntfs
- http://ubuntudiff.debian.net/x/maintainer/pkg-java
- or, http://ubuntudiff.debian.net/x/$field_name/$filter_argument
When it says no changes found, it means that no package satisfying the
query has changes in Ubuntu.
Maddie could also generate a static html page like:
http://ubuntudiff.debian.net/java.html
That could be used (e.g.) within a team or for your own set of packages.
Now that I explained what it's about and how it works, I have a couple of
questions:
- Do you think that such a service is interesting?
- Do you have any ideas on how to improve the tool?
- Any other comments are also welcome…
(If you observe some bug, I'll be happy to fix it).
Possible integration with the PTS:
==
The links listed above could be added directly to the Ubuntu box. [1]
lists all modified packages that ubuntudiff is aware of, and can be used
to see if some changes are available and pick them from [2].
[1] http://ubuntudiff.debian.net/packages/list.txt
[2] http://ubuntudiff.debian.net/packages/$source_package.html
But, one could think of a tighter integration: You can imagine a big
Ubuntu box which shows all these informations like in the following example:
http://ubuntudiff.debian.net/linux-ntfs.html
(Of course, that box would be visible *only* when there are changes).
Let me repeat slowly here:
It's only an idea. Don't scream too loud! Wait… wait… don't run away!
:)
¹: Any empty query or a query containing ; or \ or / or or
--help (and similar) is nor processed.
Regards,
--
Mehdi Dogguy مهدي الدڤي
me...@{dogguy.org,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/4be040f6.1040...@debian.org
Re: Bug#585125: ITP: build -- script to build .rpm and .deb packages
On 06/09/2010 01:50 PM, Fathi Boudra wrote: It enhances osc package and make 'osc build' command available. Isn't osc-build a better name then? (less generic) -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4c0f82e8.7010...@dogguy.org
Re: Waqf General Public License in Debian?
On 07/02/2010 12:34 AM, Patrick Matthäi wrote: Am 02.07.2010 00:21, schrieb Christoph Anton Mitterer: 4) The license is extremely anti-American, and I guess also anti-European/anti-Western. IMHO I think it does not comply with the DFSG, but it is still in NEW and I trust the ftp-masters, that it will be rejected. The software is meant for non-free. Why it should be rejected? Even non-free stuff has to pass NEW for the first upload… -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4c2d190d.4080...@dogguy.org
Re: Waqf General Public License in Debian?
On 07/02/2010 12:53 AM, Christoph Anton Mitterer wrote: On Fri, 2010-07-02 at 00:39 +0200, Mehdi Dogguy wrote: The software is meant for non-free. Why it should be rejected? Even non-free stuff has to pass NEW for the first upload… See points (1-4) from my original post, which are not change at all by using non-free. You seem to have missed some funny licenses already used in the non-free area. As an example, did you read http://lists.debian.org/debian-legal/2010/03/msg00064.html ? Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4c2d99bb.4080...@dogguy.org
Re: Bug#594672: ITP: dhcpcd5 -- a DHCP client
On 08/28/2010 12:44 PM, Julien Cristau wrote: On Sat, Aug 28, 2010 at 09:35:29 +0100, Roy Marples wrote: * Package name: dhcpcd5 Version : 5.2.7 Upstream Author : Roy Marples r...@marples.name * URL : http://roy.marples.name/projects/dhcpcd * License : BSD-2 Programming Lang: C, Shell Description : dhcpcd5 - a DHCP client What's the difference with the existing dhcpcd package? It's the same project (according to [1]). [1] http://packages.debian.org/changelogs/pool/main/d/dhcpcd/current/copyright Cheers, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4c78ef53.6040...@dogguy.org
Re: Is a bug RC relevant if it has an influence on the health of a person
On 09/09/2010 16:11, Thibaut Paumard wrote: You have a bug that could potentially kill people? Fix it, upload ASAP and contact the security and release teams. And I don't care if it's not the normal procedure and if it can piss off people, it's not nearly as important as Doing What You Have To Do (TM). By the way, I don't think it will piss anybody off. Right. I was wondering why Andreas didn't contact the Release Team to have our opinion on the subject. IMO, it qualifies as an RC bug and the diff (0.7.8 → 0.7.9) doesn't look huge. It's even reasonable and acceptable, once documentation changes are ignored. So, if you prepare a package and upload it to unstable, I would unblock it (only if the diff is strictly updating to this new version + any other change matching the criterias described in [1]). [1] http://lists.debian.org/debian-devel-announce/2010/09/msg0.html Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4c88f2a9.4000...@dogguy.org
Re: Is a bug RC relevant if it has an influence on the health of a person
On 09/09/2010 08:38 PM, Andreas Tille wrote: On Thu, Sep 09, 2010 at 04:43:53PM +0200, Mehdi Dogguy wrote: Right. I was wondering why Andreas didn't contact the Release Team to have our opinion on the subject. IMO, it qualifies as an RC bug and the diff (0.7.8 ??? 0.7.9) doesn't look huge. It's even reasonable and acceptable, once documentation changes are ignored. Because I think we had about 12 hours to discuss the issue in a general way before somebody really is in danger. As I said: This issue is *very* unlikely to happen and there is no reason to overreact. It's not about overreacting. It's about deciding on RC severity, which is the Release Team's job. So, if you prepare a package and upload it to unstable, I would unblock it (only if the diff is strictly updating to this new version + any other change matching the criterias described in [1]). It's just uploaded to t-p-u. and approved. Kind regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4c893287.7070...@dogguy.org
Re: Bug#597571: nodejs: non common executable name
On 21/09/2010 14:48, Ian Jackson wrote: Carl Fürstenberg writes (Re: Bug#597571: nodejs: non common executable name): Policy only states The maintainers should report this to the debian-devel mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, both programs must be renamed.; I don't see any consensus in the thread you linked to, so technically both must change at the moment :) I wrote that bit of the policy and my intent was to try to punish people for picking stupid names. Yes, both binaries should be renamed. node is a ridiculous name for a specific-purpose executable. Wrong. nodejs still provides the binary nodejs and not _node_. So, nodejs can stay as is. The rename would be necessary if both packages provide the same binary (same filename), which is not the case here. Please read again the bit of the policy you wrote. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4c98b921.1080...@dogguy.org
Re: Bug#597571: nodejs: non common executable name
On 21/09/2010 16:02, Patrick Ouellette wrote: On Tue, Sep 21, 2010 at 03:54:41PM +0200, Mehdi Dogguy wrote: Wrong. nodejs still provides the binary nodejs and not _node_. So, nodejs can stay as is. The rename would be necessary if both packages provide the same binary (same filename), which is not the case here. Actually, from the discussion in debian-hams, nodejs provides a binary named node - otherwise we would not need to have the discussion at all since there would be no conflict. Wrong. nodejs's maintainer wants to rename bin/nodejs to bin/node… that's why there was the discussion on debian-hams. (But then, whether the rename is appropriate is another story… IMO, it's not appropriate because the name is too generic. And as Ian already pointed out, even node should be renamed). $ dpkg -L nodejs | grep bin/ /usr/bin/nodejs Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4c98ca3b.3000...@dogguy.org
Re: Bug#597571: nodejs: non common executable name
On 21/09/2010 17:22, Patrick Ouellette wrote: You are quick with the wrong button. It's my new toy :) The UPSTREAM nodejs is /usr/bin/node. The Debian package renamed it to nodejs. Did you say that before? I don't think so. Personally, I care about the Debian package only because the original bugreport (from where this discussion started) was against the Debian package and for a Debian specificity, not about the genericity of the name used for the shipped binary. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4c98cea6.8080...@dogguy.org
Re: unstable/testing/[pending/frozen/]stable
On 09/22/2010 08:47 AM, Mike Hommey wrote: On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote: Then unstable/testing would roll further as usual How does a major, disruptive, transition get done? I think his proposal boils down to this: we *always* have unstable and testing to upload whatever we want and handle transitions when we like. Then, parallel to unstable/testing, there would be the pending/frozen suites to work on the release. Saying it a bit differently, we would *also* already be working on release+1 while release is being frozen. I kind of like the idea. To give an example with package names, I would already upload iceweasel 3.6 to unstable, thus breaking all xulrunner-dev reverse dependencies until they are fixed to use xulrunner 1.9.2, while keeping updates for iceweasel 3.5 in pending/frozen. It would also allow me to push iceweasel 4.0 betas to experimental, where they would be better suited than their current location, where they are not even built on non x86/x86-64. It means that the Release Team will have to handle transitions in unstable, migrations to testing, as well as the ongoing freeze in frozen. I don't think we have enough manpower for that. And, during a freeze, we need each one to concentrate on fixing things (while there is still experimental to test things). If we add a play-forever-suite, we will loose some manpower without any doubt and it will make releases harder to acheive, imho. Besides, how de we merge things after a release? unstable would be something quite different from released frozen. Some bugfixes might have been applied only for frozen or pending, some other package will have new versions in unstable (and their rev-deps rebuilt)… I think it could be a nightmare to manage, imho. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4c99b1b2.5040...@dogguy.org
Re: unstable/testing/[pending/frozen/]stable
On 22/09/2010 15:01, Raphael Hertzog wrote: I think that if you concentrate on preparing the next release like you do, volunteers that are not interested in the stable release (except for their own package) will show up and deal with migrations to rolling. It won't happen but I'd be happy to be proven wrong though. It's always the same story, you can't force people to care about stable simply by not having a play-forever-suite. We are not trying to force people, but rather trying to give them a bit of responsibility during the release process. « Releasing is a shared responsibility, not only release team's »… And we do have people working on derivative distributions that rely on testing's constant freshness, maybe some of them would be interested to help as well. Nice plan! Please let me know what it happens. Anyway, I'd like to ask you all to hold off the discussion for a few hours until everybody can read the summary of the CUT discussions and have a clearer ideas of the proposals and the implications. Ack. Cheers, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4c9a0f00.70...@dogguy.org
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
On 09/23/2010 09:00 AM, Lucas Nussbaum wrote: Raphael's article is now published, and is probably a good basis for discussing CUT on -de...@. Free link: http://lwn.net/SubscriberLink/406301/bd522adc828b3461/ It's still looks weired to me to have to read this article there (I mean, _only_ there). Can't it just be on CUT's website, or on the wiki? -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4c9b1280.3040...@dogguy.org
Re: [RFC] disabled root account / distinct group for users with administrative privileges
On 20/10/2010 11:18, Petter Reinholdtsen wrote: So I would suggest to use a name that is more likely to be unique. unique wrt. what? admin seems unique since not used in Debian yet. Happy hacking, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4cbec179.6030...@dogguy.org
Re: Bug#601691: ITP: idiocy -- a warning shot to people browsing the internet insecurely
On 28/10/2010 16:34, Juan Angulo Moreno wrote: Upstream Author: Jonty Wareing URL: http://github.com/jonty/idiocy License: Public Domain Description: A warning shot to people browsing the internet insecurely. Idiocy quietly watches for people insecurely visiting twitter on public wifi networks, then hijacks their session to post a tweet warning them about the dangers. It was written in response to the release of Firesheep, which will result in a huge increase in session stealing attacks, with no defence other than forcing people to use SSL. Do we really need a package for this? -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4cc98f67.4000...@dogguy.org
Re: Misc Developer News (#24)
A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? On 11/07/2010 05:38 AM, Simon Ruggier wrote: Hi all, please CC me on any responses, I'm not subscribed to debian-devel. Has anyone considered patching the screenshot tools of GNOME or KDE to include support for automating the process of submitting to screenshots.debian.org? It would almost certainly cause a big increase in the number of submissions. On Sat, Nov 6, 2010 at 11:45 PM, Paul Wise p...@debian.org wrote: The news are collected on http://wiki.debian.org/DeveloperNews Please contribute short news about your work/plans/subproject. In this issue: + Screenshots on packages.d.o + BTS version tracking explained + Latest features of dpkg-dev + Searching for bugs using Ultimate Debian Database + Re-evaluate the state of backported packages [snip] -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4cd6ac5c.30...@dogguy.org
Re: Minutes of the Debian linux-2.6 Group Meeting
On 11/11/2010 04:26 PM, Cyril Brulebois wrote: maximilian attems m...@stro.at (11/11/2010): Radeon KMS is a known regression from UMS (can't change backlight, and can't suspend/resume at least on powerpc). xorg should currently remove modeset on these archs. Done in 1:6.13.1-2+squeeze1, needs an unblock (#603165). Unblocked now. Cheers, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4cdc0f29.5040...@dogguy.org
Bug#603306: ITP: f-sharp -- Microsoft F# programming language
Package: wnpp Severity: wishlist Owner: Mehdi Dogguy me...@debian.org * Package name: f-sharp Version : 2.0 Upstream Author : Microsoft * URL : http://www.fsharp.net/ * License : Apache 2.0 License Programming Lang: F# Description : Microsoft F# programming language F# is a programming language that provides support for functional programming in addition to traditional object-oriented and imperative (procedural) programming. The Visual F# product provides support for developing F# applications and extending other .NET Framework applications by using F# code. F# is a first-class member of the .NET Framework languages and retains a strong resemblance to the ML family of functional languages. -- 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/20101112200530.15451.83032.report...@localhost.localdomain
Bugs against packages from BPO
Hi. For now users of packages from BPO have to send a mail to debian-backports mailing-list, according to [1]. I don't know how you handle those bugs, but they seem very easy to miss (even if d-b@l.d.o isn't a high traffic list). I was wondering if it makes sense to ask (kindly) debbugs's maintainer to add new special tags (e.g. “squeeze-backports”, “lenny-backports”) that would work exactly like “sid”, “squeeze”, … tags that we already have. It would help to have a better integration of BPO and makes bugreporting less confusing for users. When implemented in debbugs, reportbug could automatically add those tags if the package comes from BPO. From a maintainer point of view, this could mean more burden. But, if ever implemented, debbugs can send a copy of the bugreport to the backporter only, and avoid sending it to the usual maintainer of the package. What do you think? - from debbugs POV, is it feasible? - from maintainers POV, would you accept that? - from backports FTP masters POV, do you think it's a good idea? If we can't agree on this proposal, can somebody tell me why we didn't try to have a BTS for backports? I personally think that we could have those bugreports on bugs.d.o directly and that there is no need for another instance of debbugs, because their number isn't insane, as most of us tend to think. [1] http://backports.debian.org/FAQ/ Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dee3d9a.3080...@dogguy.org
Re: Bugs against packages from BPO
On 07/06/2011 17:35, Gerfried Fuchs wrote: I think you misinterpret these release tags: No. Setting them on a bug means that the bug affects only that specific release. It happens though quite regularly that bugs in backports aren't backport specific but also affect testing/unstable, and through such an approach you would be hiding the bugs from that view. Yes. But, one can still check and remove those tags when appropriate. My approach was just to avoid as much as possible to send false bugreports to the usual maintainer. The reporter can remove those tags if he's sure that it also applies to testing/unstable. Thanks for your other answers on debugs. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dee46c5.5090...@dogguy.org
Re: build self-contained repository for offline use
On 05/07/2011 09:59, Hamish Moffatt wrote:
I need to build a repository to allow some specified packages to be
installed on computers without internet access. It needs to contain the
specified packages plus any dependencies (new packages and new versions)
from squeeze plus other repositories such as squeeze backports and some
local ones.
I want to include everything beyond a basic squeeze install. (Ideally I
can feed in a list of stuff to be excluded.)
Does anyone know a tool/process for doing this?
http://aptoncd.sourceforge.net/ might be what you are looking for.
HTH,
--
Mehdi Dogguy مهدي الدڤي
mehdi@{dogguy.org,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/4e12d80a.3060...@debian.org
Re: Orphaning some packages...
On 07/07/2011 07:13 PM, Xavier Oswald wrote: Take this announce as a come back with new motivation :) Im incrementaly managing my time for getting back to a normal debian activity. Welcome back! :) -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4e16bb65.4060...@dogguy.org
Removal of systemtap from testing
Hello, Systemtap seems in pretty bad shape. Its removal from testing has been requested (See #635543) and will be effective by Saturday if still not fixed. It you still care about systemtap, please step up and offer your help to fix it. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4e2fdd92.7000...@dogguy.org
Re: Removal of systemtap from testing
On 07/27/2011 11:42 AM, Mehdi Dogguy wrote: Systemtap seems in pretty bad shape. Its removal from testing has been requested (See #635543) and will be effective by Saturday if still not fixed. hum, Julien already put a hint for it and it is now removed from testing. It is always possible to have it back as soon as it gets fixed. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4e304347.5050...@dogguy.org
Bug#643736: ITP: ocaml-zarith -- arithmetic and logical operations over arbitrary-precision integers
Package: wnpp Severity: wishlist Owner: Mehdi Dogguy me...@debian.org * Package name: ocaml-zarith Version : 1.0 Upstream Author : Xavier Leroy and Antoine Mine * Url : https://forge.ocamlcore.org/projects/zarith/ * License : LGPL 2 with special linking exception Programming Lang: OCaml, C, ASM Description : arithmetic and logical operations over arbitrary-precision integers The Zarith library implements arithmetic and logical operations over arbitrary-precision integers. It uses GMP to efficiently implement arithmetic over big integers. Small integers are represented as Caml unboxed integers, for speed and space economy. -- 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/20110929052550.31728.72253.report...@potassium.pps.jussieu.fr
Re: Announcing derivatives patches and call for help and feedback
On 25/10/2011 09:50, Paul Wise wrote: For the presentation side of things I am thinking one approach might be to move UbuntuDiff[8] to the QA infrastructure, generalise it and enhance it for this purpose. This will necessarily include mechanisms to mark patches as having been dealt with or ignorable. 8. http://ubuntudiff.debian.net/ I'm glad you liked it. ubuntudiff¹ was made exactly to show this kind of data. Currently, all ubuntudiff needs to produce html pages in some file listing source package names and associated patches. So, nothing is really bound to patches.ubuntu.com, except the syntax of (the equivalent of) sources.patches. It is easy to set up an ubuntudiff instance for each set of derivative patches, but I guess some changes have to be implemented to have a unified interface for all those derivatives (i.e. all patches accessible from a single place). Current ubunutdiff uses grep-dctrl to select a list of packages. I think that people don't like that much, and they usually find it not easy to use. We will have to think about a better interface. About source code, it is written in OCaml. I realize that OCaml is not the best candidate if we want people to contribute patches (or even have a look at the code) :) It depends on who wants to contribute here. I'm open to suggestions… A nice feature that I'd like to keep is visualisation of patches by hunk… this will require a parser to read unified diffs. In any case, I'd be happy to help here to implement and setup this new service. ¹: btw, the tool's name is “maddie”. -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4ea6a420.3090...@dogguy.org
Re: [Pkg-scala-maint] Binary blobs in source packages
On 12/13/2011 01:23 PM, Thomas Koch wrote: So is it ok to ship binaries in the source package that are only required during build? Can I do the same with simple-build-tool, which requires itself to build? Depends on the need. It is quite common for compilers to have some binaries to do the bootstrapping. Scala uses that since some parts of the compiler are written in scala. And, of course, I make sure that I ship new binaries only in the Debian package. Another example is OCaml which needs an ocamlc to bootstrap itself. I'm not sure yet if it is really justified for simple-build-tool. I was planning to have a look at it, but didn't find time to actually do that. IIRC, another issue is that simple-build-tool requires network access during the build… I guess it can be fooled somehow but didn't check yet. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4ee7938b.2000...@dogguy.org
Re: [Pkg-scala-maint] Binary blobs in source packages
On 12/13/2011 07:26 PM, Steve Langasek wrote: On Tue, Dec 13, 2011 at 07:03:55PM +0100, Mehdi Dogguy wrote: On 12/13/2011 01:23 PM, Thomas Koch wrote: So is it ok to ship binaries in the source package that are only required during build? Can I do the same with simple-build-tool, which requires itself to build? Depends on the need. It is quite common for compilers to have some binaries to do the bootstrapping. Scala uses that since some parts of the compiler are written in scala. And, of course, I make sure that I ship new binaries only in the Debian package. Another example is OCaml which needs an ocamlc to bootstrap itself. I think the traditional expectation here is that compilers will do their initial bootstrap using an out-of-archive binary, and that once in the archive, they'll be maintained using a self-build-depends instead. You mean having a circular build-dependency? That isn't great :/ I've seen some packages doing that (don't recall which right now) but didn't like it, tbh. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4ee79983.2040...@dogguy.org
Re: [Pkg-scala-maint] Binary blobs in source packages
On 12/13/2011 07:26 PM, Steve Langasek wrote: On Tue, Dec 13, 2011 at 07:03:55PM +0100, Mehdi Dogguy wrote: On 12/13/2011 01:23 PM, Thomas Koch wrote: So is it ok to ship binaries in the source package that are only required during build? Can I do the same with simple-build-tool, which requires itself to build? Depends on the need. It is quite common for compilers to have some binaries to do the bootstrapping. Scala uses that since some parts of the compiler are written in scala. And, of course, I make sure that I ship new binaries only in the Debian package. Another example is OCaml which needs an ocamlc to bootstrap itself. I think the traditional expectation here is that compilers will do their initial bootstrap using an out-of-archive binary, and that once in the archive, they'll be maintained using a self-build-depends instead. oh, and actually, this is not guaranteed to always work… this is at least the case with OCaml which performs rather strict checks during compilation. (This happened already in the past where some core type changed). Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4ee7abdb.5020...@dogguy.org
Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status
On 16/01/12 18:33, Thomas Goirand wrote: Also, does this mean that you've patched the policy, that lintian would soon more aggressively complain about lacks of patch comments, and that we'll have a new Standard-Version? Lintian already complains when a quilt patch doesn't contain a description, fwiw. See http://lintian.debian.org/tags/quilt-patch-missing-description.html Regards, -- Mehdi -- 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/4f1464df.5000...@dogguy.org
Re: dpkg-source again broken wrt to 3.0 (quilt)???
On 18/01/12 03:08, Norbert Preining wrote: On Mi, 18 Jan 2012, Jakub Wilk wrote: Wait, are you patching files inside debian/? That won't fly. Umpf, and, is that so evil? Esp for a NMU this is *very* good as it allows to see what the changes of the NMU are ... You're supposed to send a debdiff when NMUing. That's even better to see what the changes of the NMU are (See devref §5.11.1). Personally, I find patching files under debian/ directory makes things more difficult to track (probably because I don't expect to find those changes there). Regards, -- Mehdi Dogguy -- 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/4f168bbb.3040...@dogguy.org
Re: MATE Desktop Environment in Debian
On 08/02/12 09:55, Josselin Mouette wrote: Le mercredi 08 février 2012 à 00:53 +0100, Stefano Karapetsas a écrit : Many users are using it well. Now that this is enough stable, I begun the process for ask the inclusion in Debian. The first package is mate-common. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658783 (ITP) http://lists.debian.org/debian-mentors/2012/02/msg00115.html (RFS) With this mail I wish to have opinions and suggestions about our work from Debian Developers. MATE introduces a lot of code duplication, which is considered bad in Debian, and is based on obsolete technologies - not just GTK2, which will of course remain for a long time, but also things like Bonobo which very few people really understand, and which are the cause of a lot of not-well-understood bugs. Maybe this could benefit to both parties if MATE team tries to reduce usage of obsolete libraries to a bare minimum, and avoid using bug monsters (like Bonobo and others). I guess this means a lot of work, but that's the price to pay to ease its maintainability on the long term and having it packaged within Debian. Did MATE team consider such a plan? If yes, what was the outcome of the discussion? Regards, -- Mehdi -- 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/4f325217.8050...@dogguy.org
Re: MATE Desktop Environment in Debian
On 08/02/12 14:05, Stefano Karapetsas wrote: I saw some gnome design team mockups of all applications, and I find its far from GNOME2. Then, why don't you help them? (It is easier than re-packaging and maintaining Gnome2). Regards, -- Mehdi -- 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/4f327766.4010...@dogguy.org
Re: Wheezy release: CDs are not big enough any more...
On 16/05/12 13:41, Wookey wrote: is there any reason not to just upload this to Debian? There are ITPs filed for it: - http://bugs.debian.org/582884 - http://bugs.debian.org/576359 Regards, -- Mehdi -- 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/4fb3b89b.2030...@debian.org
Re: Moving /tmp to tmpfs makes it useless
On 25/05/12 11:08, Thomas Goirand wrote: On 05/25/2012 03:22 PM, Jon Dowland wrote: How much RAM do you have / how big is your /tmp(fs)? The fact this caused you trouble suggests to me that they must be very small. What if we're installing Debian on a very small system, and that we need operations with big files in /tmp? Increase your swap? If it is not possible, then your RAM won't help much neither. If you really have many RAM and less disk, then this is very a specific case and we shouldn't bother making it a general case. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4fbf51d6.4070...@dogguy.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 31/05/12 16:40, Thomas Goirand wrote: On 05/31/2012 08:43 PM, Jonas Smedegaard wrote: I have no intention of spreading or amplifying wrong information. Do I understand it correctly that your intention in your original post was to have the package orphaned and then have a team take over maintainance? I was also pointing out that the package was anyway badly maintained, and that in such case, we have to do something about it. Please note that badly maintained is something quite different from not maintained. AFAICS, the package we are talking about is not affected by severe or critical bugs. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4fc785ae.40...@dogguy.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 31/05/12 15:11, Bernd Zeimetz wrote: On 05/31/2012 03:03 AM, Steve Langasek wrote: [...] A hijack is, by definition, a declaration by the hijacker that they believe they are not answerable to the project's processes for how package maintenance is decided. It is antisocial vigilanteism and it is not acceptable. So asking people who want to work actively on a package to wait for months or years because it is not compltely clear if the original maintainer is MIA or not, or just nobody had the time to look at the MIA status, is social? It does not help Debian at all. As a sitting member of the Technical Committee, I encourage anyone who sees a package being hijacked to immediately bring it to the attention of the TC. I will without hesitation vote to have the hijacker barred from being made the maintainer of the package. From a member of the TC I would expect some useful input on how to fix an obviously broken (since years!) process instead of trying to forcibly trying to choke down people who actively want to improve Debian. Welcome to the dictatorship of the TC. I think what Steve wanted to say is that we have procedures for theses situations and we should follow those procedures because they exist and we have concensus. The procedures in question might not be perfect or completely disfunctional but that is another topic. You may very well try to change these procedures and discuss new rules or the needed changes to apply on -devel, but you should not ignore them and force your own (which was, aiui, what the original submitter of this thread wanted to do) just because $foo. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4fc786e9.6020...@dogguy.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 31/05/12 18:15, Bernd Zeimetz wrote: Part of the common and established procedure is to mail d-devel if you intend to hijack a package True, but it is _not_ common (nor acceptable) to let only 2-3 days for the maintainer to reply. The rest of the thread raised other questions such as the responsibility of a sponsor, but it seems OT wrt. the original request. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4fc79b62.2000...@dogguy.org
Re: The future (or non-future) of ia32-libs
On 06/23/2012 08:23 AM, Thomas Goirand wrote: Unfortunately, we never require that our users upgrade to the latest point release before upgrading to stable+1. http://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#system-status -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4fe56bce.7010...@dogguy.org
Bug#679547: ITP: ben -- toolbox for Debian maintainers
Package: wnpp Severity: wishlist Owner: Mehdi Dogguy me...@debian.org * Package name: ben Version : 0.6 Upstream Author : Mehdi Dogguy and Stéphane Glondu * URL : http://ben.debian.net/ * License : AGPL-3+ Programming Lang: C, OCaml Description : toolbox for Debian maintainers This is a collection of useful tools that Debian maintainers can use to make their packaging work easier. They all work with regular Debian package list files, and should be useful for Debian derivatives as well. This package ships a single executable, ben, with the following subcommands: * download: download a set of package list files from a mirror * monitor: monitor the status of a set of packages across several architectures (useful for transitions) * query: query packages using their metadata (similar to grep-dctrl, but uses a dedicated query language) * tracker: frontend to multiple monitors -- 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/20120629172121.30372.23030.reportbug@potassium
Re: Bug#679547: ITP: ben -- toolbox for Debian maintainers
On 29/06/12 19:36, Benjamin Drung wrote: What does ben stand for? Is this just a short name for me? ;) Very long story¹. :) Would it be useful to have ben in devscripts instead of a separate package? No. I beleive devscripts maintainers will not be happy as it requires OCaml and a few OCaml libs to build. It also builds an OCaml library that it is meant to grow considerably in future. I don't think it is a good idea to put it in devscripts. ¹: This has to do with Britney. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4fedec83.5000...@dogguy.org
Re: Bug#679547: ITP: ben -- toolbox for Debian maintainers
On 06/29/2012 09:15 PM, Ralf Treinen wrote: On Fri, Jun 29, 2012 at 07:21:21PM +0200, Mehdi Dogguy wrote: Package: wnpp Severity: wishlist Owner: Mehdi Dogguy me...@debian.org * Package name: ben Version : 0.6 Upstream Author : Mehdi Dogguy and Stéphane Glondu * URL : http://ben.debian.net/ * License : AGPL-3+ Programming Lang: C, OCaml Description : toolbox for Debian maintainers * query: query packages using their metadata (similar to grep-dctrl, but uses a dedicated query language) Does it subsume the functionality of ara? ara is orphaned since some time, so this would mean that we could send it into retirement. (Disclaimer: I never used Ara. I just read its short description from http://ara.alioth.debian.org/). For now, ben query is just like grep-dctrl. Not much, not less. We don't have fancy web interfaces like Ara does. HTH, -- Mehdi Dogguy مهدي الدڤي -- 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/4fedff08.8040...@dogguy.org
Bug#686664: ITP: dochelp -- utility to browse doc-base registered documents
Package: wnpp Severity: wishlist Owner: Mehdi Dogguy me...@debian.org * Package name: dochelp Version : 0.1 Upstream Author : Mehdi Dogguy me...@debian.org * URL : http://git.debian.org/?p=users/mehdi/dochelp.git * License : GPL-3+ Programming Lang: OCaml, Javascript Description : utility to browse doc-base registered documents This package contains an utility to browse documentation installed on a Debian system. The utility has a command-line interface and can be used to search, open and display information of doc-base registered documents. It also generates an HTML catalog of the available documents each time a package registers a new one. Note that the project URL is temporary. The final one (that will appear in the package) should be http://dochelp.debian.net. Regards, -- Mehdi -- 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/20120904120651.11461.79599.reportbug@potassium
Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)
On 05/09/2012 22:11, Andreas Tille wrote: On Tue, Sep 04, 2012 at 08:19:29PM +0200, Stéphane Glondu wrote: Le 17/08/2012 13:08, Andreas Tille a écrit : So we finally have three independently developed solutions (we also have several instances of a debian/get-orig-source script in Debian Med team) and my suggestion was just to settle with a common and simple solution. This should be pretty simple to implement (I'd volunteer to do this but wanted to seek for comments before filing a bug report + patch). There is also the --filter-pristine-tar option to git-import-orig, which can be specified in debian/gbp.conf. We routinely use it in the OCaml team (see e.g. why). I'm not sure whether I understand what you want to tell here. Do you think git-import-orig should filter out / remove files mentioned in debian/copyright field Files-Excluded? I think he was mentioning another method that helps maintainers to automatically clean the imported tarball when importing it. IIRC, this method has been added to git-import-orig circa DebConf9. Its use is very simple, IMHO. Did you try to see how it works? (at least, its interface). See http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/why.git;a=blob;f=debian/gbp.conf;h=4435dcbe6d877cec7f562e8757939b7e98ecf5d8;hb=HEAD for how to configure it. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/5048a6cb.2080...@dogguy.org
