Re: Debian ppa
On Thu, 2010-09-23 at 07:17 +0200, Marc 'HE' Brockschmidt wrote: > Julien Cristau writes: > > On Wed, Sep 22, 2010 at 16:24:44 +0200, Holger Levsen wrote: > >> On Mittwoch, 22. September 2010, Mike Hommey wrote: > >>> PS: for my personal needs, some way to get random packages autobuilt > >>> would already be helpful (call that ppa if you want).>> > >> I seem to recall, ftpmaster was planning something like that. Or wanted to? > >> If so, what the status? If not, shall we start it? I think so. > > HE proposed something like this (on the buildd side) for gsoc, there > > were no takers, iirc. > > Actually, the proposed project [1] also included work on the dak side > and a minimalistic web interface. Joerg Jaspert agreed to help with the > dak side of things, back then. > > I still believe that this can and should be implemented. If someone is > interested, I'm happy to help; I assume the same holds for Joerg. While Launchpad.net does not provide Debian PPAs, what prevents you from taking the Launchpad code, rebranding it, and running your own instance? It does require some changes to work with Debian's suites, but that would be far easier than reimplementing all the functionality yourself. William. signature.asc Description: This is a digitally signed message part
Re: Bug#597571: nodejs: non common executable name (exclusive alternatives ?)
On Thu, 23 Sep 2010 01:32:21 +0200
Jérémy Lal wrote:
> On 23/09/2010 01:24, Ian Jackson wrote:
> > Jérémy Lal writes ("Re: Bug#597571: nodejs: non common executable
> > name (exclusive alternatives ?)"):
> >> On might object "node" would have a different meaning, depending
> >> on the packages installed ; still, nodejs or x25node (if its
> >> maintainer cares to follow) would be there, and unambiguous.
> >
> > I think this kind of horrendous stuff should not be done in packages
> > and certainly not by just installing them.
> >
> > If the sysadmin really hates it so much, they can
> > ln -s /usr/bin/nodejs /usr/local/bin/node
> > surely ?
>
> Of course, then i guess it's ok to put this in the description ?
Ummm, no. Any sysadmin who doesn't know about 'ln -s' shouldn't be a
sysadmin any longer. It's not the job of the package description to
educate the user, it just describes the package.
These naming conflicts are not new, packages just have to rename their
executables. There have always been complaints about "user scripts and
other tools" etc. but the answer is the same: rename the executables
and document this in README.Debian or the manpage.
Blame upstream - and direct users to complain to upstream too.
> I fear most people won't read README.Debian.
Nevertheless, that is an appropriate place for this "information" if you
really think that your users will not think of it themselves.
Alternatively, put it in the manpage.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgptZXA9TNiRU.pgp
Description: PGP signature
Re: Debian ppa
Julien Cristau writes: > On Wed, Sep 22, 2010 at 16:24:44 +0200, Holger Levsen wrote: >> On Mittwoch, 22. September 2010, Mike Hommey wrote: >>> PS: for my personal needs, some way to get random packages autobuilt >>> would already be helpful (call that ppa if you want).>> >> I seem to recall, ftpmaster was planning something like that. Or wanted to? >> If so, what the status? If not, shall we start it? I think so. > HE proposed something like this (on the buildd side) for gsoc, there > were no takers, iirc. Actually, the proposed project [1] also included work on the dak side and a minimalistic web interface. Joerg Jaspert agreed to help with the dak side of things, back then. I still believe that this can and should be implemented. If someone is interested, I'm happy to help; I assume the same holds for Joerg. Marc Footnotes: [1] http://wiki.debian.org/SummerOfCode2010/DeveloperPackageRepositories -- Fachbegriffe der Informatik - Einfach erklärt 190: Cisco Protokolhure. (unbekannt) pgpPMWEVgMUMU.pgp Description: PGP signature
Re: unstable/testing/[pending/frozen/]stable
On Wed, 22 Sep 2010, Raphael Hertzog wrote: > 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. hm... did you mean http://lwn.net/Articles/406301/ "A constantly usable testing distribution for Debian" [LWN subscriber-only content] ? if indeed, taken on the reasoning that "testing" is a bad name and "rolling" is better, then it goes similar to what I saw behind 'constatly present' testing up to replacing rolling -> testing ->[removal of packages] -> frozen now about 'pending': following description confused me quite a bit: ... during a freeze, testing is no longer automatically updated, which makes it inappropriate to feed the rolling distribution. That's why rolling would be reconfigured to grab updates from unstable (but using the same rules as testing). But unstable remains to serve as the entry point to feed frozen testing as well, so with absent other entry-point (pending in my scenario) there is a conflict -- I can't upload 1 version which I intend to get to frozen testing and another one to get into rolling (experimental obviously can't serve as such). or it all would go through an addendum (*-proposed-updates)? -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- 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/20100923022237.gw12...@onerussian.com
Re: Bug#597571: nodejs: non common executable name (exclusive alternatives ?)
On 23/09/2010 01:24, Ian Jackson wrote:
> Jérémy Lal writes ("Re: Bug#597571: nodejs: non common executable name
> (exclusive alternatives ?)"):
>> On might object "node" would have a different meaning, depending
>> on the packages installed ; still, nodejs or x25node (if its maintainer
>> cares to follow) would be there, and unambiguous.
>
> I think this kind of horrendous stuff should not be done in packages
> and certainly not by just installing them.
>
> If the sysadmin really hates it so much, they can
> ln -s /usr/bin/nodejs /usr/local/bin/node
> surely ?
Of course, then i guess it's ok to put this in the description ?
I fear most people won't read README.Debian.
Jérémy.
--
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/4c9a9205.3070...@edagames.com
Re: Bug#597571: nodejs: non common executable name (exclusive alternatives ?)
Jérémy Lal writes ("Re: Bug#597571: nodejs: non common executable name
(exclusive alternatives ?)"):
> On might object "node" would have a different meaning, depending
> on the packages installed ; still, nodejs or x25node (if its maintainer
> cares to follow) would be there, and unambiguous.
I think this kind of horrendous stuff should not be done in packages
and certainly not by just installing them.
If the sysadmin really hates it so much, they can
ln -s /usr/bin/nodejs /usr/local/bin/node
surely ?
Ian.
--
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/19610.36900.786289.318...@chiark.greenend.org.uk
Re: [RFC] Binary packages containing the source
Matt Zagrabelny writes ("Re: [RFC] Binary packages containing the source"):
> On Wed, Sep 22, 2010 at 12:35 PM, Ian Jackson
> wrote:
> > No :-). Perhaps "ls" rather than "Ls" would have been more correct.
> > I'm not sure of the correct rule for this situation...
> >
> > (If you're thinking of "Lets", surely the sentence you are
> > contemplating is missing its subject?)
>
> I'll bite:
...
> Which one is it?!
>
> Unless it is 'Also' and your capital L is nothing more than a red herring.
I'm afraid you've got it. As I say, I wasn't sure what the correct
rule is but starting the sentence with "ls" looked wrong.
Ian.
--
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/19610.36682.624131.677...@chiark.greenend.org.uk
Re: Bug#597571: nodejs: non common executable name (exclusive alternatives ?)
On 21/09/2010 18:01, Patrick Ouellette wrote: > On Tue, Sep 21, 2010 at 05:26:30PM +0200, Mehdi Dogguy wrote: >> >> 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. > > Part of the historical discussion on debian-hams and Jéré mentioned > it in this thread today. > > > Pat To sump up view points from upstream and from debian : *it's your problem* Maybe a solution would be to define a kind of "exclusive alternative" : if one wants some "node" link, that points to /usr/sbin/node (x)or to /usr/bin/nodejs, he could choose which one's the best in a postinst routine, common to both packages. On might object "node" would have a different meaning, depending on the packages installed ; still, nodejs or x25node (if its maintainer cares to follow) would be there, and unambiguous. Do that notion of "exclusive alternatives" is insane, or been discussed before ? Jérémy. -- 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/4c9a7fc0.3040...@edagames.com
Re: Backports service becoming official
On Wed, 22 Sep 2010, Stefano Zacchiroli wrote: > From what concerns the BTS, Don's proposal in [2] (the main one, not > the alternative solution) seems reasonable to me and others in the > thread. The proposal also seems to assume a different Maintainer > field for the bpo package, as hinted above, am I wrong Don? Right. The idea here is that there will be an additional recipient for bugs which affect the version present in bpo; in the case where the bug is bpo only, headers in the message will allow maintainers to filter out these bugs in mail and the bug listings. [Possibly even by default, but the opt-in mechanism is harder than the default-in to implement.] Don Armstrong -- Americans can always be counted on to do the right thing, after they have exhausted all other possibilities. -- W. Churchill http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20100922201919.gc6...@teltox.donarmstrong.com
Re: [RFC] Binary packages containing the source
On Wed, 22 Sep 2010, Goswin von Brederlow wrote: > Call it "source" if you like. The point was that the arch follows the > package name. It's interesting that this is exactly backwards from the way the BTS does it. [Source packages are src:foopkg.] Don Armstrong -- [The] JK-88 [coffee] percolator is capable of achieving the ultimate balance of aroma and density, aftertaste and emollience, pentosans and tannins. The next step is to reduce the cost of the HPLC-E technology to the point where it can be manufactured for less than the cost of a Boeing 757. -- Charles Stross "Extracts from the Club Diary" in _Toast_ p83-4 http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20100922202731.gd6...@teltox.donarmstrong.com
debdelta back online
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dear all, due to my PC running out of disk space, no deltas were generated in the last week (while I was absent); I found more space, so it will be back online as soon as it generates all needed deltas. If you do not know what debdelta is , see http://debdelta.debian.net BTW, I hope that someday the generation of deltas will be done in some big Debian server , and not on my PC... it is not easy to keep a mirror of the repository (and indeed I only mirror debs, and hence only generate deltas, for 'i386' and 'amd64') a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyaaz8ACgkQ9B/tjjP8QKTE8wCeNW/PPHzyKC7qolqWVcfdPVfY 2iMAn1X5lGAMoQe2WYUtxfmmvwA8Ss/c =ORZQ -END PGP SIGNATURE- -- 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/4c9a6b3f.30...@debian.org
Re: unstable/testing/[pending/frozen/]stable
On 2010-09-22, Bruce Sass wrote: > I've heard that Testing cycles between good/installable and > bad/un-installable--do those good times correspond to times when it > would be possible to freeze a set of packages? You're wrong. That's FUD you've read. Cheers Philipp Kern -- 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/slrni9ko8v.nl.tr...@kelgar.0x539.de
Re: [RFC] Binary packages containing the source
On Wed, Sep 22, 2010 at 12:35 PM, Ian Jackson
wrote:
> Brett Parker writes ("Re: [RFC] Binary packages containing the source"):
>> On 22 Sep 12:47, Ian Jackson wrote:
>> > Julien Cristau writes ("Re: [RFC] Binary packages containing the source"):
>> > > Why do people hate vowels so much?
>> >
>> > Bcs f y lv thm t y cn wrt ncmprhnsbl gbbrsh mch mr ffctvly. Ls y sv
>> > smll mnt f typng.
>> ^Lts
>> surely?
>
> No :-). Perhaps "ls" rather than "Ls" would have been more correct.
> I'm not sure of the correct rule for this situation...
>
> (If you're thinking of "Lets", surely the sentence you are
> contemplating is missing its subject?)
I'll bite:
grep -i '^l[aeiou]*s[aeiou]*$' /usr/share/dict/american-english-insane
Lais
Laise
Laius
Laos
Las
Lasi
Leasia
Leesa
Leese
Leis
Leos
Les
Lesa
Lias
Liesa
Lis
Lisa
Lise
Loasa
Lois
Loise
Loos
Los
Lose
Louis
Louisa
Louise
Ls
Luis
Luisa
Luise
Lusa
Lusia
laas
laesie
laiose
laius
laos
las
lasa
lase
laus
leas
lease
lees
leese
leis
leos
les
lese
liaise
lias
lies
lieus
lis
lisu
loasa
looies
loos
loose
los
lose
louies
louis
louise
louse
ls
luaus
lues
Which one is it?!
Unless it is 'Also' and your capital L is nothing more than a red herring.
-matt zagrabelny
--
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/aanlktinp-ozwt2ttu8-wjpww6bØxnuz3_svnsby...@mail.gmail.com
Bug#597753: ITP: mspdebug -- debugging tool for MSP430 microcontrollers
Package: wnpp Severity: wishlist Owner: Luca Bruno * Package name: mspdebug Version : 0.11 Upstream Author : Daniel Beer * URL : http://mspdebug.sourceforge.net/ * License : GPLv2+ Programming Lang: C Description : debugging tool for MSP430 microcontrollers MSPDebug is a free debugger for use with MSP430 MCUs. It supports FET430UIF, eZ430, RF2500 and Olimex MSP-JTAG-TINY programmers. It can be used as a proxy for gdb or as an independent debugger with support for programming, disassembly and reverse engineering. . -- 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/20100922185318.27405.50189.report...@localhost
Re: Backports service becoming official
On 22/09/10 13:53, Stefano Zacchiroli wrote:
> Thinking about it, what we _conceptually_ need is pretty simple: a
> mechanism to declare who is the Maintainer of the bpo package and
> enforce its declaration. The responsibility of bpo maintenance will be
> on the declared bpo maintainer. If the default maintainer wants to be
> the bpo maintainer too, fine; if someone else wants to, fine too. One
> way to do that would be to require setting new values for
> Maintainer/Uploaders, possibly backing up the default values to
> Orig-{Maintainer,Uploaders} [1]. Is there any reason *not* to do that?
Since people are basically arguing about the bug traffic, maybe require
a Bugs: field when doing a NMU to backports?
Unfortunately, this doesn't help when the faulty backport is a library
which causes another binary to fail.
--
Saludos,
Felipe Sateler
signature.asc
Description: OpenPGP digital signature
Re: Backports service becoming official
On Tue, Sep 07, 2010 at 07:46:56AM +0200, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport maintainer = maintainer of the
> package in unstable).
>
> Of course, that doesn't remove the possibility for people to upload NMU
> backports when the maintainer is not responsive/interested in providing
> a backport. But then the normal rules of NMUs should apply (in
> particular, the NMUer must not change the Maintainer field, and should
> monitor the bugs of the package).
So, this one is a fairly important topic. Let me try to summarize the
discussion thus far and to add some roadmap comments.
The crux is deciding what does it mean that the "bpo service has become
official". At the very least, it means that the resources (hardware and
peoplepower) needed to run it are now provided by Debian, rather than by
a 3rd party vendor. That is important for users as they don't need to
trust anything else than Debian. I believe this point to be fairly
uncontroversial.
The next question is whether the new bpo status entails new
responsibilities (e.g. doing the backport, caring for its bugs, etc.)
for "default" package Maintainers or not. It's clear from the discussion
that there are objections to the idea that it does. Quite
understandably, a good deal of those objections come from maintainers of
packages who get lots of bugs.
My first comment is that while we might decide that official bpo comes
with new responsibility, that's not a decision to be taken lightly:
current maintainers agreed to do maintenance without bpo on the table,
and forcing new work on top of people (who possibly disagree with it!)
is definitely not healthy.
Thinking about it, what we _conceptually_ need is pretty simple: a
mechanism to declare who is the Maintainer of the bpo package and
enforce its declaration. The responsibility of bpo maintenance will be
on the declared bpo maintainer. If the default maintainer wants to be
the bpo maintainer too, fine; if someone else wants to, fine too. One
way to do that would be to require setting new values for
Maintainer/Uploaders, possibly backing up the default values to
Orig-{Maintainer,Uploaders} [1]. Is there any reason *not* to do that?
We need to define such a mechanism before squeeze-backports gets open.
From what concerns the BTS, Don's proposal in [2] (the main one, not the
alternative solution) seems reasonable to me and others in the thread.
The proposal also seems to assume a different Maintainer field for the
bpo package, as hinted above, am I wrong Don?
The goal for BTS support is not bothering default maintainer when
default maintainer != bpo maintainer. To understand how to get there, I
fear we need an estimate on whether support for [2] can be ready in time
for squeeze-backports or not. If not, we can go for the alternative
solution proposed by Don and patching reportbug.
Once more, we need to choose among the two alternative paths ahead
before squeeze-backports gets open (and well before that, if we want to
patch reportbug on time).
Cheers.
[1] in fact, as there are similarities with what derivatives do, we
might want to do that in a generic way and push it to derivatives as
a standard way to give credit to the maintenance work done in Debian
[2] http://lists.debian.org/debian-devel/2010/09/msg00161.html
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: [RFC] Binary packages containing the source
Brett Parker writes ("Re: [RFC] Binary packages containing the source"):
> On 22 Sep 12:47, Ian Jackson wrote:
> > Julien Cristau writes ("Re: [RFC] Binary packages containing the source"):
> > > Why do people hate vowels so much?
> >
> > Bcs f y lv thm t y cn wrt ncmprhnsbl gbbrsh mch mr ffctvly. Ls y sv
> > smll mnt f typng.
>^Lts
>surely?
No :-). Perhaps "ls" rather than "Ls" would have been more correct.
I'm not sure of the correct rule for this situation...
(If you're thinking of "Lets", surely the sentence you are
contemplating is missing its subject?)
Ian.
--
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/19610.15957.393564.977...@chiark.greenend.org.uk
Re: unstable/testing/[pending/frozen/]stable
On September 22, 2010 01:35:14 am Mehdi Dogguy wrote: > 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. Unstable and Testing appear to quickly diverge from a new release's versions, becoming "something quite different from released", in a matter of days or few weeks. The only difference in this regard if a "frozen" existed would be that they could diverge sooner... wouldn't that be a headstart on the next Stable? What if packages only became "frozen" when the set of dependency relationships they are involved in is consistent (enough?) In this scenario there would be no (only minor?) transitions happening in Frozen, and consequently no (little?) need to merge dependency related bugfixes (the only "some" of consequence, afaict) into Unstable or Testing packages. Simply having that as a goal may encourage more or more prompt work on packages in Testing. I've heard that Testing cycles between good/installable and bad/un-installable--do those good times correspond to times when it would be possible to freeze a set of packages? i.e., is there already an indicator that can be used to trigger a mostly automatic action which over time would result in Frozen becoming a release candidate? anyways, here's a somewhat philosophical thought on the matter... Currently Debian can only "see" the past (Stable) and present (Unstable/Testing). Creating an always-consistent-"frozen" category of packages would let Debian "see" the past (Stable), present (Frozen), and future (Unstable/Testing). - Bruce -- 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/201009221117.16849.bms...@shaw.ca
Re: debootstrap and fsck on lvm2 and udev
On Wed, Sep 22, 2010 at 02:41, Pier Paolo wrote: > i) I debootstrap (squeeze package) from lenny on a empty ext3 lvm partition > (rectius: logical volume); > ii) all goes well: > mount proc... > mount sysfs > chroot > aptitude ... udev, lvm2, linux-image, linux-source, ... > update-initramfs > iii) I was trying to obtain a bootable squeeze system, obviously > update-grub (from regular lenny) and things (i.e. change root partition > root=...lvSid) > iv) the booting process stop with a kernel(?) console, saying it can't fsck > the root, mounted by lvm fallback system (not udev, it seems to me the bug > #593375): > > Beg your pardon, madames et messieurs... I investigate the problem, and it came out that... i was not very smart yesterday night: the issue was a slash instead of a backslash in chrooted etc/fstab. so embarassing > Thanks, > Pier Paolo. > > Anyway, thank you.
A new Priority level, ‘bac kports’ ? (Re: unstable/testing/[pending/frozen/]stable)
Dear Yaroslav and everybody, the addition of new suites has the disadvantage of dispersing our userbase. Here is a proposition that conserves the current flow of package migration for packages released in Stable, and that makes Testing the meeting point for all the packages. We could introduce a new priority level, ‘backports’, with the following features: This priority level would be lower than ‘extra’. Higher levels would not be allowed to depend nor build-depend on packages of priority ‘backports’. Source packages would not be allowed to contain a mixture binary packages containing ‘backports’ level and higher priorities. These packages would not be released in Stable, but would be uploaded to Unstable and migrate in Testing as usual, with the exception that they would not be affected by a freeze. They could be removed by default from Testing in case they block a transition. As the name indicates, the packages which prove their stability in Testing (and only them, as in the current backports rules) would be backported in backports.debian.org. The backports would be prepared by the maintainers themselves (this would open a way to the use of the BTS) and would be the final distribution medium for Stable users. The system I propose is intended to keep fruitful interactions between higher turnover packages and stable releases: - It would keep Unstable and Testing as a central point for our users who would like an early access to new software, therefore preserving a high number of testers for the packages of higher quality, which are aimed at Stable. (In contrary for instance to distribution outside of Debian or in the experimental suite.) - Since immediatly after the release the backports are trivial, it would motivate the interest of the maintainers of ‘Priority: backports’ packages for Stable and its release process, to ensure frequent windows of easy backporting. - By removing from testing – on a voluntary basis – a lot of packages for which there is no stable upstream release, or which are still in active development, it would reduce the load on regular operations. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100922153816.ga28...@merveille.plessy.net
Re: Debian ppa (was Re: unstable/testing/[pending/frozen/]stable)
On Wed, Sep 22, 2010 at 16:24:44 +0200, Holger Levsen wrote: > Hi, > > On Mittwoch, 22. September 2010, Mike Hommey wrote: > > PS: for my personal needs, some way to get random packages autobuilt > > would already be helpful (call that ppa if you want). > > I seem to recall, ftpmaster was planning something like that. Or wanted to? > If so, what the status? If not, shall we start it? I think so. > HE proposed something like this (on the buildd side) for gsoc, there were no takers, iirc. Cheers, Julien signature.asc Description: Digital signature
Debian ppa (was Re: unstable/testing/[pending/frozen/]stable)
Hi, On Mittwoch, 22. September 2010, Mike Hommey wrote: > PS: for my personal needs, some way to get random packages autobuilt > would already be helpful (call that ppa if you want). I seem to recall, ftpmaster was planning something like that. Or wanted to? If so, what the status? If not, shall we start it? I think so. cheers, Holger signature.asc Description: This is a digitally signed message part.
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: [RFC] Binary packages containing the source
Julien Cristau writes: > On Wed, Sep 22, 2010 at 11:39:01 +0200, Goswin von Brederlow wrote: > >> Going by what multiarch proposed and apt already supports that should be >> >> apt-get install linux-2.6:src >> >> where "src" is just another architecture (at least for the user >> interface). >> > Why do people hate vowels so much? > > Cheers, > Julien Call it "source" if you like. The point was that the arch follows the package name. MfG Goswin -- 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/87tylh7w2u@frosties.localdomain
Re: [RFC] Binary packages containing the source
On 22 Sep 12:47, Ian Jackson wrote:
> Julien Cristau writes ("Re: [RFC] Binary packages containing the source"):
> > Why do people hate vowels so much?
>
> Bcs f y lv thm t y cn wrt ncmprhnsbl gbbrsh mch mr ffctvly. Ls y sv
> smll mnt f typng.
^Lts
surely?
--
Brett Parker http://www.sommitrealweird.co.uk/
PGP Fingerprint 1A9E C066 EDEE 6746 36CB BD7F 479E C24F 95C7 1D61
--
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/20100922123237.ga32...@sommitrealweird.co.uk
Re: unstable/testing/[pending/frozen/]stable
Hi all, On Tue, 21 Sep 2010, Yaroslav Halchenko wrote: > CUT discussions at debconf10 and recent news of the birth of Linux Mint discussions on CUT have continued after debconf on the CUT mailing. I wrote a summary of the discussion that will be published in Linux Weekly News before tomorrow. Hopefully this summary will then lead to a constructive discussion on the way forward. http://cut.debian.net/ http://lists.alioth.debian.org/pipermail/cut-team/ > [experimental/]unstable(sid)/testing(e.g squeeze)/stable > > *constantly* present and functioning all the time the same way. You're not alone wishing that. I also would like Debian to provide a rolling distribution that never stops to roll. :-) > NB I am having some deja vu that 'frozen' used to be used explicitly >in the archive... is that so? Yes. frozen was a snapshot of unstable at time of freeze, and people could upload to frozen directly afterwards to fix remaining RC bugs. > But I cannot be first thinking about that, and I bet there were good > reasons why such approach was not taken -- could anyone enlighten/point > me to the shortcomings? I'm not sure it was an explicit choice at that time. We just had to adjust the way we dealt with freeze once testing was introduced. Getting fixes from unstable is easier/safer for everybody compared to testing-proposed-updates so release managers asked people to not upload packages which could not migrate to testing and many do. It also means unstable is less interesting during freeze. Also having the package in unstable for some time ensures that it doesn't break horribly, something that you don't have with testing-proposed-updates. There is room for improvements here I think. On Wed, 22 Sep 2010, Mehdi Dogguy wrote: > 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. 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's always the same story, you can't force people to care about stable simply by not having a "play-forever-suite". 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. 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. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20100922130147.gh4...@rivendell.home.ouaza.com
Re: Bug#596511: ITP: simon -- Open source speech recognition
Am 2010-09-21 22:39, schrieb Simon Josefsson: Also, any external GPL code that Simon links to needs to have the same exception. Is there any external GPL code? Well of course - KDE. I believe kdelibs is LGPL, so maybe you are OK. It depends on what parts of KDE is used. You are right: http://developer.kde.org/documentation/licensing/licensing.html Only the server links to Julius which is kdecore but in the current implementation it might link to kdeui through simonscenarios (which should be split in the future in a separate non gui part). Other than that, we don't link to anything on the server afaik (Qt is LGPL). This is getting ridiculously frustrating. It's not that I don't think it's an important issue but I guess if you'd gather all involved parties and ask them if the current setup would be ok I am pretty sure everyone would agree. Oh well I guess that just comes with the territory. I know the pain, I've ended up rewriting several projects because of license problems with earlier implementations. What I have learned is that you should react to license issues as soon as possible, or you'll end up investing a lot of work into something that needs to be redesigned. True... I obviously can't hack this into simon 0.3.0 but for the next version, would it help if I split the Julius-interfacing part into a plugin that doesn't link to KDE? This would be the easiest option in my opinion but as I understand it it would mean to distribute the plugin seperately? If Julius is not "free" in Debian eyes this would mean that simon becomes pretty much useless to be honest. I don't really have an opinion whether it is free or not yet, but it looks complicated. Interestingly, the japanese sourceforge page lists Julius license as "OSI Approved, Other/Proprietary License". Best regards, Peter -- 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/4c99f352.8090...@simon-listens.org
Re: [RFC] Binary packages containing the source
Julien Cristau writes ("Re: [RFC] Binary packages containing the source"):
> Why do people hate vowels so much?
Bcs f y lv thm t y cn wrt ncmprhnsbl gbbrsh mch mr ffctvly. Ls y sv
smll mnt f typng.
Ian.
(sorry)
--
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/19609.60607.635924.856...@chiark.greenend.org.uk
Re: [RFC] Binary packages containing the source
On Wed, Sep 22, 2010 at 11:39:01 +0200, Goswin von Brederlow wrote: > Going by what multiarch proposed and apt already supports that should be > > apt-get install linux-2.6:src > > where "src" is just another architecture (at least for the user > interface). > Why do people hate vowels so much? Cheers, Julien signature.asc Description: Digital signature
Re: [RFC] Binary packages containing the source
Hector Oron writes: > Dear developers, > > ABSTRACT > How to enable in some special cases a way to allow one source > package have multiple maintainers within Debian archive. It might be better to say they have different flavours which should (out of practicallity) or must be build on their own. You say huh? should? must? Well, "should" is the case you described. You have different (teams of) maintainers with different extra patches or use cases that work best on their own. Or building all the flavours at once would create a monster package that would take forever to build and thus hinder developing the source. But there are also "must" cases, at least for now. For cross compiling you need certain libraries like libgcc1, packaged as libgcc1-armel-cross for example. The libgcc1-armel-cross is an arch:all package to be used by any cross compiler of any arch compiling for armel. Lacking all the cross compilers the package must also be compiled on armel, at least for now. On the other hand libgcc1-mipsel-cross is build on mipsel and also arch:all. But any package upload must contain all the arch:all packages of a source. Which means the gcc maintainer would have to build gcc on all architectures manually and merge the results to get all the arch:all packages for an upload. Something that is just not feasable. So libgcc1-armel-cross must be build seperate from the normal gcc package and libgcc1-mipsel-cross too. There needs to be one gcc-x.y-$arch source package per architecture for full cross compile coverage. With the above proposal they would all Build-Depend on the gcc source and only contain a minimal debian dir though. They could probably also be just binNMUed whenever gcc-x.y is uploaded, something that could even be automated. MfG Goswin -- 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/87bp7q85la@frosties.localdomain
Re: [RFC] Binary packages containing the source
Josselin Mouette writes: > Le jeudi 16 septembre 2010 à 03:08 +0200, Jakub Wilk a écrit : >> * Hector Oron , 2010-09-15, 21:26: >> > c) allow build depends on source packages, which it is probably a worst >> > idea. >> >> On the contrary, I think that allowing source packages to be installable >> in the same way as binary packages is an excellent idea. Imagine you can >> do: >> >> apt-get install src:linux-2.6 >> >> which will install Linux sources into a standard location, or upgrade it >> if it's already installed. > > I agree this is a cleaner solution, but how do you ensure there are > sources (deb-src) referenced in the sources.list ? > > Plus, these packages would (in the current state of affairs) lack a > description. Going by what multiarch proposed and apt already supports that should be apt-get install linux-2.6:src where "src" is just another architecture (at least for the user interface). apt-get install foo:src should then install the source and also all Build-Depends(-Indep) of the source. Besides packages Build-Depending on source packages this is also verry usefull for working on sources. The foo:src package will be marked manual while all Build-Depends remain automatic. When one is done working with a source one can purge foo:src and all the Build-Depends can be autoremoved if nothing else needs them. MfG Goswin -- 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/87iq1y86dm@frosties.localdomain
Re: Oracle’s Unbreakable Enterprise Kernel - is th ere more to it?
On Wed, Sep 22, 2010 at 4:44 PM, Fabian Greffrath wrote: > Oracle recently announced [1] their own 2.6.32-based Unbreakable Enterprise > Kernel for their RHEL derivative called Oracle Linux. The announcement > promises severe performance improvements compared to the stock RHEL kernel. > > Do you know what patches they applied to the kernel and if they (or parts of > them) are acceptable for Debian's linux-2.6 kernel as well? Some details about that are in the comments on the LWN article: http://lwn.net/Articles/406199/#Comments http://lwn.net/Articles/406242/ -- bye, pabs http://wiki.debian.org/PaulWise -- 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/aanlktimyha-n-cpxf3rbtl-z32jpl5a6jk8khge7x...@mail.gmail.com
Oracle’s Unbreakable Enterprise Kernel - is there more to it?
Dear kernel team and -devel, Oracle recently announced [1] their own 2.6.32-based Unbreakable Enterprise Kernel for their RHEL derivative called Oracle Linux. The announcement promises severe performance improvements compared to the stock RHEL kernel. Do you know what patches they applied to the kernel and if they (or parts of them) are acceptable for Debian's linux-2.6 kernel as well? Best regards, - Fabian [1] http://www.oracle.com/us/corporate/press/173453 -- 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/4c99c1f7.3090...@greffrath.com
Re: unstable/testing/[pending/frozen/]stable
On 09/22/2010 02:52 AM, Yaroslav Halchenko wrote: [...] > [experimental/]unstable(sid)/testing(e.g squeeze)/stable > > *constantly* present and functioning all the time the same way. > > Then upon freeze we just copy the state of > unstable -> pending > testing(squeeze) -> frozen(squeeze, e.g together with a codename) > and link new codename (e.g. wheezy) against testing. while I like the idea to support distributions like MINT which pull from testing, I doubt it would be useful for Dbeian. Even if we would have the manpower in the release team to handle it, I'd expect that a lot of developers would concentrate on throwing new stuff into unstable instead of fixing bugs to be able to release soon. The proper way to fix the issue is to release faster by fixing all remaining issues faster :) -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4c99bc6b.6020...@bzed.de
Re: unstable/testing/[pending/frozen/]stable
Hi, On Tue, Sep 21, 2010 at 08:52:09PM -0400, Yaroslav Halchenko wrote: > NB I am having some deja vu that 'frozen' used to be used explicitly >in the archive... is that so? Indeed. That was before testing was introduced. > Then unstable/testing would roll further as usual, and pending->frozen > according to the freeze schedule. This would enable CUTs, fulfill > the ideas behind LMDE to have something rolling without hickups, and > users of 'testing' (and unstable) would enjoy testing/unstable the way > they usually do. The introduction of testing has had positive and negative effects. While it is generally a good thing that packages are tested for some time and required to be consistent with respect to other packages to even be considered for a release, it has also led to a situation where releases are mostly ignored by some maintainers, who just continue to upload new packages and live with the consequence that some snapshot goes into stable. I'm not sure whether explicitly telling people that it is okay to upload new versions to unstable while a release is being prepared is a good thing in that context. Simon -- 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/20100922080333.ga2...@richter
Re: unstable/testing/[pending/frozen/]stable
On Wed, Sep 22, 2010 at 08:26:22AM +0100, Neil Williams wrote: > On Wed, 22 Sep 2010 08:47:31 +0200 > 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. > > Splitting the user base / testing base isn't necessarily a good idea. > In other words, it might work for heavily utilised packages but it > would cause a lot of complexity in bug triage. How is the maintainer > meant to test the version in unstable if he's running the frozen > version or vice-versa? How is the maintainer meant to test the version in stable if he's running the unstable version of vice-versa? and s/stable/testing/. Anyways, yes, it might work for heavily utilised packages, but on the other hand, they are exactly the kind of packages where it would make sense. > > 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. > > With something like iceweasel, is there frankly any point in building > experimental versions on architectures which can barely handle the > stable releases? There frankly is one: that of catching bugs early. For example, I already know iceweasel 4.0 betas are broken on several of our architectures. If I hadn't tried to build it once, I wouldn't have realized until I uploaded 4.0 final, at which point it's even harder to get fixes upstream, which means yet more patches applied to our package. For instance, being able to work on 4.0 since its early days helped getting the number of patches from 100+ on 3.5 and 3.6 down to around 50. > How many users are there using iceweasel not on x86/x86-64? Do you realize the iceweasel package is not about iceweasel alone? Check the number of build-rdeps and rdeps on libmozjs, and xulrunner. And who knows what future netbooks may bring more users for mips or arm, for instance? Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100922074654.ga19...@glandium.org
Re: unstable/testing/[pending/frozen/]stable
On Wed, 22 Sep 2010 07:31:45 +0100 Neil Williams wrote: > So when and where are library transitions meant to occur? Transitions > are always disruptive, always cause some packages to be non-functional > or non-installable. There has to be somewhere (unstable) where libfoo2 > can be uploaded with libfoo2-dev so that all packages which depend on > libfoo1 can start the migration to the new API. As the migration > starts, there is a period (which in the case of GTK1->2 took several > years) where many packages in unstable are uninstallable or FTBFS or > just horribly buggy. (note: this only gets worse with libfoo-dev_2 replacing libfoo-dev_1 but that does not mean that libfoo-dev should be disallowed or deprecated.) > > But I cannot be first thinking about that, and I bet there were good > > reasons why such approach was not taken -- could anyone > > enlighten/point me to the shortcomings? > > In a word, transitions. Personally, I've always considered it *more* important for Debian to stabilise code than to always have the newest code. Stable beats new every time. I run a mix of Debian machines, some for Debian development which run unstable, some for Emdebian development which run testing and some for upstream development which run stable. That is quite enough work, thanks, I really, really don't want to have to add another variant of unstable and/or testing to suit the needs of people who prioritise buggy bleeding edge code over stable tools. The core system (i.e. everything I'm not currently debugging) must be stable and reliable if I'm going to get my work done. Do people really want a version of unstable that always has the latest broken version of iceweasel or some horrible partial transition to python3 or the bleeding edge version of Xorg built directly from VCS and which constantly crashes?? Having *everything* new and bleeding edge means that no bugs ever get identified because you cannot tell which bit is bust or the bug you want to fix is blocked by a bug in the X server or the python interpreter or a buggy version of libgcc1 or something. The platform (whatever packages are deemed part of the platform for any one developer) *must* be stable if the code is to improve. Therefore, individual developers need a stable platform onto which can be added their own buggy code - not as packages from Debian but as checkouts from whichever VCS is in use. Predictability and reliability are key components of a usable development platform. Without those, there is no chance of fixing intermittent or corner case bugs. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpUYK2tSFX6o.pgp Description: PGP signature
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
Bug#597683: ITP: ukopp -- Full and incremental backup to disk or disk-like device
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: ukopp Version : 3.8 Upstream Author : Michael Cornelison * URL : http://kornelix.squarespace.com/ukopp/ * License : GPL Programming Lang: C Description : Full and incremental backup to disk or disk-like device Ukopp is used to copy or back-up disk files to a disk or disk-like device, such as a USB stick. It copies only new or modified files since the last backup, and is therefore quite fast. A GUI is used to navigate the file system to include or exclude files or directories at any level. These choices can be saved in a job file for repeated use. New files appearing within the included directories are handled automatically. Optionally, previous versions of the backup files can be retained instead of being overwritten. Files can be selectively restored using a GUI. Ownership and permissions are also restored, even if the target device uses a Microsoft file system. -- 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/20100922071854.3039.26859.report...@alessio-laptop
Re: unstable/testing/[pending/frozen/]stable
On Wed, 22 Sep 2010 08:47:31 +0200 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. Splitting the user base / testing base isn't necessarily a good idea. In other words, it might work for heavily utilised packages but it would cause a lot of complexity in bug triage. How is the maintainer meant to test the version in unstable if he's running the frozen version or vice-versa? > 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. With something like iceweasel, is there frankly any point in building experimental versions on architectures which can barely handle the stable releases? How many users are there using iceweasel not on x86/x86-64? > This could be more work, but I understand that for people who want to > do it, the testing freeze time is frustrating. New versions break stuff - there has to be a way of stabilising bleeding-edge code and that should not be in a quiet backwater with no users. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgprWd0xrIva2.pgp Description: PGP signature
