Re: Time to merge back ubuntu improvements!
On Sat, 05 Jan 2013 14:03:25 +0800 Thomas Goirand wrote: > On 01/05/2013 09:50 AM, Paul Wise wrote: > > > > Please check out these links if you want to make this happen. Probably > > an initial target of supporting oldstable for the same length of time > > as stable (instead of just a year) is a good first goal to achieve > > before adding more supported suites. > I agree. It would be nice if it was at least possible to upload security > updates > right now to old-stable, even if that wasn't officially supported. At > least, this > would be a nice way to go forward (eg: based on "best effort", and without > forcing added work on anyone (yet)). Debian cannot force added work on anyone, ever. All that happens is that those who are overworked either "do their best" and get things wrong or leave the project due to the stress of not getting things wrong. Neither is "a nice way to go forward" and Debian has seen plenty of both just in the time I've been involved. Allowing unsupervised or unchecked random uploads outside the normal procedures of a particular team puts additional strain on that team because it will be the team who will be first contact for everyone else when those uploads break stuff. There is every reason to regard not following the procedures of a long-standing team as "breaking stuff". Those who are not proposing to do the work do not have the right to impose work on those who do. Additional work can created only by additional manpower or at the request of those doing the work currently. (Even then, the rest of Debian does have the responsibility to question if the request is really within the ability of the team.) Debian has also been, historically, quite bad at handling reductions in workload when teams become too small to function. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpvKwhjJA8v0.pgp Description: PGP signature
Bug#697429: ITP: gitignore-boilerplates -- shell script for easily accessing gitignore boilerplate
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: gitignore-boilerplates Version : 1.0.1 Upstream Author : Simon Whitaker * URL or Web page : https://github.com/simonwhitaker/gitignore-boilerplates * License : public domain Description : shell script for easily accessing gitignore boilerplate This tool makes gitignore file. It gathers boilerplates from github.com/github/gitignore . These boilerplates include some typical purpose, for example, Python, Ruby, and other langauges, and Emacs, vim and other environments. -- 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/87ehi05a0j.wl%tak...@asis.media-as.org
Re: Time to merge back ubuntu improvements!
Hi Neil, On Sa 05 Jan 2013 09:58:48 CET Neil Williams wrote: On Sat, 05 Jan 2013 14:03:25 +0800 Thomas Goirand wrote: On 01/05/2013 09:50 AM, Paul Wise wrote: > > Please check out these links if you want to make this happen. Probably > an initial target of supporting oldstable for the same length of time > as stable (instead of just a year) is a good first goal to achieve > before adding more supported suites. I agree. It would be nice if it was at least possible to upload security updates right now to old-stable, even if that wasn't officially supported. At least, this would be a nice way to go forward (eg: based on "best effort", and without forcing added work on anyone (yet)). Debian cannot force added work on anyone, ever. All that happens is that those who are overworked either "do their best" and get things wrong or leave the project due to the stress of not getting things wrong. Neither is "a nice way to go forward" and Debian has seen plenty of both just in the time I've been involved. Allowing unsupervised or unchecked random uploads outside the normal procedures of a particular team puts additional strain on that team because it will be the team who will be first contact for everyone else when those uploads break stuff. There is every reason to regard not following the procedures of a long-standing team as "breaking stuff". Those who are not proposing to do the work do not have the right to impose work on those who do. Additional work can created only by additional manpower or at the request of those doing the work currently. (Even then, the rest of Debian does have the responsibility to question if the request is really within the ability of the team.) Debian has also been, historically, quite bad at handling reductions in workload when teams become too small to function. I fully get your point here. I would not suggest some extra feature implementing extra workload for some of the teams if I wasn't willing to help out. Either in the teams directly or compensating in some other corner of Debian. However, I am currently in NM process, so this comes first. Then I will see to my packaging projects (and Debian Edu wheezy), then pop up at next DebConf and then offer help. For me, gaining experience comes first. But then I will be happy to help out! light+love, Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpPaWMKdWucD.pgp Description: Digitale PGP-Unterschrift
Re: Time to merge back ubuntu improvements!
Hi Thomas, On Sa 05 Jan 2013 07:03:25 CET Thomas Goirand wrote: On 01/05/2013 09:50 AM, Paul Wise wrote: Please check out these links if you want to make this happen. Probably an initial target of supporting oldstable for the same length of time as stable (instead of just a year) is a good first goal to achieve before adding more supported suites. I agree. It would be nice if it was at least possible to upload security updates right now to old-stable, even if that wasn't officially supported. At least, this would be a nice way to go forward (eg: based on "best effort", and without forcing added work on anyone (yet)). Puuhhh... openly allowed uploads without review process to a not-any-more support version of Debian? This does not sound like Debian at all, does it? light+love Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpjYUyAsXVlZ.pgp Description: Digitale PGP-Unterschrift
Re: Time to merge back ubuntu improvements!
Hi pabs, On Sa 05 Jan 2013 02:50:47 CET Paul Wise wrote: On Sat, Jan 5, 2013 at 5:09 AM, Mike Gabriel wrote: Slightly different approach: However, for serious server deployments we in Debian might want to think about supporting older releases a little longer than atm. A scheme like veryoldstable -> oldstable -> stable -> testing -> unstable From the perspective of someone administrating several deployments a support range of 5 years would be very welcome. Like Ubuntu LTS (so that nobody can say, my mail is getting off-topic ;-) ). (The lifetime of lenny e.g. was apprx. 3 years.) Please check out these links if you want to make this happen. Probably an initial target of supporting oldstable for the same length of time as stable (instead of just a year) is a good first goal to achieve before adding more supported suites. This would already be awesome. (!!!) http://lists.debian.org/debian-security-announce/2011/msg00238.html http://www.debian.org/News/2012/20120209 http://wiki.debian.org/DebianSecurity/Meetings/2011-01-14 http://lists.debian.org/debian-devel-announce/2011/01/msg6.html http://lists.debian.org/debian-security/2011/10/msg00029.html http://lists.debian.org/debian-security/2011/10/msg00030.html http://lists.debian.org/debian-security/2011/10/msg00033.html http://lists.debian.org/debian-security/2011/10/threads.html#1 I will take this pile of lecture with me and get to you once I am fully in the loop of already discussed contents. THANKS! Mike (aka sunweaver) -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpbYQFanZfeW.pgp Description: Digitale PGP-Unterschrift
Re: Updates in the very-old-stable (was: Time to merge back ubuntu improvements!(
On 01/06/2013 02:02 AM, Mike Gabriel wrote: > Hi Thomas, > >> I agree. It would be nice if it was at least possible to upload security >> updates >> right now to old-stable, even if that wasn't officially supported. At >> least, this >> would be a nice way to go forward (eg: based on "best effort", and >> without >> forcing added work on anyone (yet)). > > Puuhhh... openly allowed uploads without review process to a > not-any-more support version of Debian? This does not sound like > Debian at all, does it? That's not what I wrote. Also, I don't know why Neils wrote so much about forcing people when I wrote that we shouldn't. My intention was to write that I thought this could be an experiment for a start, without strong rules, to see what can be done. Damned, am I expressing myself so badly? :( First of all, this could be a separated repo, it doesn't have to, and IMO shouldn't for such an experiment, overwrite what's in archive.debian.org. Second, we can still do a review process, but it doesn't have to be done the way it is done currently for still supported releases. The way to implement it is a totally different topic. (let's not discuss this first... this could be setup gradually as well...) Last but not least, I don't understand why leaving unpatched packages on deprecated releases with absolutely no way at all to get them updated is a better thing than allowing maintainers to update their package if they feel like it. If there's not enough manpower, we can just recognize that fact. If someone volunteers for it, we may have a list of known unfixed problems (including security issues, and even a list of possible problems if we don't have the resources to check for the vulnerabilities). The only problem I see with the above is if ftp-masters have no time to setup a specific repository for the updates. I have no idea how much work that represent, within the Debian infrastructure. If nobody wants to go this way (eg: within the Debian infrastructure), then we can make a completely unofficial repository. That may work as well. In fact, that could be the best way to start as an experiment. Any positive thoughts anyone? Thomas -- 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/50e8749a.4040...@debian.org
Bug#697477: ITP: ostree -- Linux-based operating system develop/build/deploy tool
Package: wnpp Severity: wishlist Owner: Thomas Bechtold * Package name: ostree Version : 2012.13 Upstream Author : Colin Walters * URL : https://live.gnome.org/OSTree/ * License : GPL-2+ Programming Lang: C Description : Linux-based operating system develop/build/deploy tool OSTree is a tool for developing, building, and deploying Linux-based operating systems. It is most similar to tools like dpkg and rpm in "Linux distributions". However, it is not a package system (though one could be built on top). -- 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/20130105192732.31244.95430.reportbug@banane
Re: Bug#697477: ITP: ostree -- Linux-based operating system develop/build/deploy tool
Thomas Bechtold, le Sat 05 Jan 2013 20:27:32 +0100, a écrit : > Package: wnpp > Severity: wishlist > Owner: Thomas Bechtold > > * Package name: ostree > Version : 2012.13 > Upstream Author : Colin Walters > * URL : https://live.gnome.org/OSTree/ > * License : GPL-2+ > Programming Lang: C > Description : Linux-based operating system develop/build/deploy tool > > OSTree is a tool for developing, building, and deploying Linux-based > operating systems. It is most similar to tools like dpkg and rpm in "Linux > distributions". However, it is not a package system (though one could be > built on top). I have to say I thus don't understand what it does if it's similar to dpkg/rpm but is not a package system. What does it do that dpkg/rpm do which is not package management? I guess you should add something like: it installs binaries, but replacing the "package" abstraction with [...] (what?), and add usage examples. Samuel -- 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/20130105194310.gn5...@type.youpi.perso.aquilenet.fr
Re: Updates in the very-old-stable (was: Time to merge back ubuntu improvements!(
On Sun, 06 Jan 2013 02:44:42 +0800 Thomas Goirand wrote: > On 01/06/2013 02:02 AM, Mike Gabriel wrote: > > Hi Thomas, > > > >> I agree. It would be nice if it was at least possible to upload security > >> updates > >> right now to old-stable, even if that wasn't officially supported. At > >> least, this > >> would be a nice way to go forward (eg: based on "best effort", and > >> without > >> forcing added work on anyone (yet)). > > > > Puuhhh... openly allowed uploads without review process to a > > not-any-more support version of Debian? This does not sound like > > Debian at all, does it? > > That's not what I wrote. > > Also, I don't know why Neils wrote so much about > forcing people when I wrote that we shouldn't. No, you expressly indicated the prospect of this being forced: > >> without > >> forcing added work on anyone (yet)). There can be no "yet". No implied force, ever. > My > intention was to write that I thought this could be > an experiment for a start, without strong rules, to > see what can be done. Then do it but start on a separate server, just like Emdebian did. > Damned, am I expressing > myself so badly? :( Yes. > First of all, this could be a separated repo, it > doesn't have to, and IMO shouldn't for such an > experiment, overwrite what's in archive.debian.org. archive.debian.org shouldn't be updated - what is old stays old, new stuff arrives at the top of the stack. ftp.debian.org and backports.debian.org are where updates are done. > Last but not least, I don't understand why leaving > unpatched packages on deprecated releases > with absolutely no way at all to get them updated > is a better thing than allowing maintainers to > update their package if they feel like it. That means that maintainers have to support deprecated upstream releases - with all the bugs inherent in those releases. Most updates cannot be backported to old releases because there are interdependencies on other updated code. It's not about prohibiting updates, it's that most maintainers don't have time to support deprecated versions. Sooner or later, a maintainer who does want to update an old version finds that the update is blocked by another package which has be re-factored in the meantime, making it impractical to backport the minor changes in package A as it relies on massive changes in package B. This is the most common problem with the current backports and that is within the current limits of support. The longer the window of support, the more packages will have changed, the more complex the backport becomes, the fewer packages actually get backported. This means that any backports which can be done are at risk of being patchy, incomplete, untested, liable to generate new bugs and thereby increase the workload of those maintainers long after the work of the actual backport is complete. The longer the interval covered by the backport, the worse the problem becomes. This then means that security support for such versions is all but impossible to achieve. Upstream don't want to know, the newest version has diverged too far from the buggy version to identify the relevant fix. For this situation, the only sane security support is to upgrade to the next relevant Debian release - the entire OS. At least that way, the system migrates to a combination of software which has had an appreciable amount of testing. > If there's not enough manpower, we can just > recognize that fact. There's never enough manpower. This is about priorities. Most maintainers prioritise the current stable release of whatever software they use / package / maintain. The further back in time this goes, the more likely it is that the updates to one package will be utterly blocked by necessary changes in another package somewhere down the dependency chain. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpXM6RxSHsHr.pgp Description: PGP signature
Re: Bug#697477: ITP: ostree -- Linux-based operating system develop/build/deploy tool
On Sat 05 Jan 2013 16:43:10 Samuel Thibault escribió: > Thomas Bechtold, le Sat 05 Jan 2013 20:27:32 +0100, a écrit : > > Package: wnpp > > Severity: wishlist > > Owner: Thomas Bechtold > > > > * Package name: ostree > > > > Version : 2012.13 > > Upstream Author : Colin Walters > > > > * URL : https://live.gnome.org/OSTree/ > > * License : GPL-2+ > > > > Programming Lang: C > > Description : Linux-based operating system develop/build/deploy > > tool > > > > OSTree is a tool for developing, building, and deploying Linux-based > > operating systems. It is most similar to tools like dpkg and rpm in > > "Linux distributions". However, it is not a package system (though one > > could be built on top). > > I have to say I thus don't understand what it does if it's similar to > dpkg/rpm but is not a package system. What does it do that dpkg/rpm do > which is not package management? > > I guess you should add something like: it installs binaries, but > replacing the "package" abstraction with [...] (what?), and add usage > examples. Maybe something like bitbake? -- 18: Como se pueden evitar los problemas de alimentacion electrica * No coma cerca de un enchufe Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Is the Package-List field necessary for uploads ?
Dear FTP team and everybody, we are documenting in the Policy the Package-List field of the Debian source control files. Multiline field listing all the packages that can be built from the source package. The first line of the field value is empty. Each one of the next lines describe one binary package, by listing its name, type, section and priority separated by spaces. There are two possible package types: binary package (deb) or micro binary package (udeb). I do not know if this field should be marked mandatory, recommended or optional. Is this field is strictly necessary for uploads ? Have a nice Sunday, -- 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/20130106001211.gc26...@falafel.plessy.net
Re: Is the Package-List field necessary for uploads ?
Charles Plessy (06/01/2013):
> I do not know if this field should be marked mandatory, recommended
> or optional. Is this field strictly necessary for uploads ?
I'm not sure how we could be making this field mandatory all of a
sudden. (Think uploads to {o,s}-p-u, for a start.)
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: [debian-devel:18459] Bug#697421: ITP: unidic-mecab -- free Japanese Dictionaries for mecab
Hi, I thought about this package at one point but I did not since its real upstream Japanese government agency had very restrictive license. http://www.tokuteicorpus.jp/ (Japanese pages) http://www.tokuteicorpus.jp/dist/ Version 1.3.12 http://www.tokuteicorpus.jp/dist/modules/system/modules/menu/main.php?page_id=18&op=change_page (Japanese) UniDic Copyright © 2007-2010 DEN Yasuharu, YAMADA Atsushi, OGURA Hideki, KOISO Hanae, OGISO Toshinobu It states: personal use only, no distribution, ... So this was not even good for non-free. On Sat, Jan 05, 2013 at 09:27:08AM +0900, Hideki Yamane wrote: > Package: wnpp > Severity: wishlist > Owner: Hideki Yamane > X-Debbugs-CC: debian-devel@lists.debian.org, debian-de...@lists.debian.or.jp > >Package name: unidic-mecab > Version: 2.1.1 > Upstream Author: The UniDic Consortium > URL: http://sourceforge.jp/projects/unidic/ This is kind of new site. Seems to be provided by one of the upstream author of original government supported one. > License: BSD-3-cluase > LPGL-2.1 > GPL-2 With much better licenses :-) But considering "Upstream Author" is still Govenment one, we better make sure the current license situation to keep clean hands. Sourceforge license review may not be good enough for Debian. > Description: free Japanese Dictionaries for mecab > unidic-mecab is a Dictionary for MeCab, Japanese morphological analysis > implementation. > . > * All entries are based on the definition of "SUW (short-unit word)" that is > specified by NINJAL (The National Institute for Japanese Language and > Linguistics), which provides word segmentation in uniform size suited for > linguistic research. > * It has three-layered structure with > - lemma > - form > - spelling > And it can provide a clear distinction of two types of word variant: > spelling variant and form variant. > * It is useful for research of Speech processing since it can be added > accent and shift in sound information. It does not mention anything about efferts taken to put these as above license. Or is it written in the package. Please check with Mr. Toshinobu Ogiso how he got clearance from Government agency first. Initial discussion may be better done first in debian-de...@lists.debian.or.jp in Japanese if we discuss situation in Japanese ... Osamu signature.asc Description: Digital signature
Re: Updates in the very-old-stable
Neil, I agree on all what you said (eg: difficulties in doing such a maintenance, the fact we don't have unlimited manpower, etc.), but I'm still convince it would be worth a try. On 01/06/2013 04:39 AM, Neil Williams wrote: > It's not about prohibiting updates, it's that most maintainers don't > have time to support deprecated versions. How about allowing anyone to work on any package in very-old-stable? This might work at least for a few key packages, which some users badly need. For example, I'd like to provide backports for bind if it has a major hole (probably, I will care less about things I don't use (yet) like DNSSEC, but I don't see this as an issue). It's probable that others will want to updates for apache, postfix, and stuff like that as well. Anyone maintaining a large amount of servers will see value in this (eg: better than nothing). (My own target would be servers, not desktops) The idea isn't to keep quality as high as we have for stable or old-stable. The idea isn't to keep the same maintenance rules either. It's about allowing what can be done to happen. Please don't do again a very discouraging negative post. Thomas -- 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/50e9119a.8040...@debian.org
Re: Updates in the very-old-stable
On Sun, Jan 06, 2013 at 01:54:34PM +0800, Thomas Goirand wrote: > > Neil, > > I agree on all what you said (eg: difficulties in doing such a maintenance, > the fact we don't have unlimited manpower, etc.), but I'm still convince it > would be worth a try. > > On 01/06/2013 04:39 AM, Neil Williams wrote: > > It's not about prohibiting updates, it's that most maintainers don't > > have time to support deprecated versions. > > How about allowing anyone to work on any package in very-old-stable? Nothing stops you :) ... > Please don't do again a very discouraging negative post. Sure. We as DD have shell access to people.debian.org. Also many people have shell access to alioth.debian.org. Both seems to have packages needed to set up PPA like archive[1]. I think using any one of the following tools should be good enough: * reprepro (support pool)[2] (I am thinking now to use this soonish) * mini-dinstall[3] * dpkg-scanpackages (I used to use it. Package: dpkg-dev)[4] So theoretically, you can have PPA like archive supporting such or any other purposes useful to our users. See: [1] http://wiki.debian.org/HowToSetupADebianRepository [2] http://upsilon.cc/~zack/blog/posts/2009/04/howto:_uploading_to_people.d.o_using_dput/ [3] http://wiki.debian.org/SettingUpSignedAptRepositoryWithReprepro [4] http://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_small_public_package_archive Osamu -- 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/20130106063249.GA16357@goofy.localdomain
