Bug#619800: general: The touchpad's mouse clicks
2011/3/27, Julien Viard de Galbert : > On Sun, Mar 27, 2011 at 07:09:42AM +0200, ArGeMaNiA wrote: >> Package: general >> Severity: normal >> >> The touchpad's mouse click is enabled.Before login it doesn't effect.After >> login it effects. >> > Hello, > > Which login manager (xdm, gdm, kdm ?) and which desktop environment are > you using ? (GNOME, KDE, XFCE ... ). > > Best Regards, > > -- > Julien Viard de Galbert > http://silicone.homelinux.org/ > GPG Key ID: D00E52B6 Published on: hkp://keys.gnupg.net > Key Fingerprint: E312 A31D BEC3 74CC C49E 6D69 8B30 6538 D00E 52B6 > Sory,for late.. Login manager:gdm Desktop Environment:GNOME -- 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/aanlktikzgxkxu9r3bxcuxfhodxb-boj+ssa4sacf0...@mail.gmail.com
Re: [buildd-tools-devel] new buildd dependency resolution breaks self depends?
[Lennart Sorensen] > Oh OK, so there is no build dependancy issue at all then (since no one > would be dumb enough to make a package that build depends on one of its > own binaries, would they?). You didn't read the beginning of the thread, I guess? This is a situation much like gcc, where the compiler is self-hosting. gcc avoids the (explicit) self-dependency by being in Build-Essential. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.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/20110329222820.gg10...@p12n.org
Re: Meeting Minutes, FTPMaster meeting March 2011
> Note that it isn't entirely clear to me how splitting up keyrings per
> architecture would help there, so some explanation might help (if I want
> to make sure that whatever patch I come up with actually solves the
> issue at hand...).
You need to check on which site you luck. Lets take it that dak simply
requires one keyring per arch for accepting packages into the archive,
the part we talk about here is how to add/remove keys.
Now, currently this is implemented using ONE keyring to check the sigs
against before processing files. So what you probably want to do is to
give me a patch against buildd-{add,remove}-keys that will allow to have
one admin keyring per architecture. This shouldn't be too hard to
change, at the place we use it you already know the architecture.
When its agreed this is the way to go and you do it, please move the
admin keyrings into a subdir. The one and only currently is in the
keyrings maindir, it would be confusing to have the arch specific admin
rings there.
Also, I am on VAC until end of April, so any merge wont happen before
then.
--
bye, Joerg
I read the DUMP and agree to it.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcz1shux@gkar.ganneff.de
Bug#615153: exec: 58: /usr: Permission denied
I forgot one thing... the /root/.bash_history file had nothing important to see... only few commands without importance... 2011/3/29 Debian_bug_report > Sorry for the delay, but I did all you request and compress in the .zip > file attached to you. > > Regards. > > 2011/3/1 Bernhard R. Link > > * Debian_bug_report >> [110301 14:57]: >> > My problem happen after I did the distro upgrade... I pass 2 months out >> of >> > my debian distro, and I used the testing version (Squeeze), but I return >> > yesterday to my debian distro and the Squeeze becomes stable... so I did >> > the change to Debian testing again (now called Wheezy)... >> >> A full upgrade is a very complicated thing to reproduce. And you seem to >> have 3rd party repositories, so there are packages from other people >> that might have bugs, so finding this will be complicated. >> >> > so I rename all my source packages like this source.list: >> >[...] >> > #mirror multimídia >> > deb http://ftp.br.debian.org/debian-multimedia/ testing main >> > #deb http://ftp.debian-unofficial.org/debian testing main contrib >> non-free >> > >> > #mirror wine: >> > #deb http://www.lamaresh.net/apt/ squeeze/main >> >> As those are 3rd party repositories, there is some probability the bug >> is there. >> >> > So, I went to my Lxterminal and type: "sudo aptitude update". After I >> type: >> > "sudo aptitude safe-upgrade". >> > >> > The system make a download of 839mb of data. Everything was made without >> any >> > errors reported... I not use any login manager... I do my login in getty >> and >> > after I start my X and window manager (fluxbox). So, when I restart my >> > machine >> > and try to start my X with the command "startx", the system returns the >> > error: >> > "xinit: connection to X server lost" and after said "Wait for X server >> to >> > shut >> > down" and stayed with prompt flashing again. So, I tried invoke X with >> root >> > and >> > I had sucess! When I went to the .xsession-errors I saw this error: >> > >> > Xsession: X session started for invisiblemanguard at Ter Fev 22 16:36:02 >> BRT >> > 2011 >> > exec: 58: /usr: Permission denied >> >> Could you check the actual permissions of those directories? >> Perhaps the output of "ls -la /" would be best. >> >> Where things are mounted might also be interesting, i.e. the /etc/fstab >> and the /proc/mounts files. >> >> Other information interesting might be the /var/log/dpkg.* files >> covering the interesting timespan. >> >> (Saving /root/.bash_history and looking into it for anything interesting >> might also be sensible). >> >>Bernhard R. Link >> > > >
Re: [buildd-tools-devel] new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 07:59:12PM +0200, Wesley W. Terpstra wrote: > It's all one source package. I split it up the binaries because: > 1) about 60% of the package could be in an 'all' package. > 2) the runtime components for different architectures can be installed > side-by-side... thus enabling cross-compilation. Oh OK, so there is no build dependancy issue at all then (since no one would be dumb enough to make a package that build depends on one of its own binaries, would they?). > According to Kurt, there is no problem. It's all in my head. :) Oh good. -- Len Sorensen -- 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/20110329190808.gb...@caffeine.csclub.uwaterloo.ca
Re: [buildd-tools-devel] new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 7:10 PM, Lennart Sorensen < lsore...@csclub.uwaterloo.ca> wrote: > Does mlton-basis depend on mlton-runtime or mlton-compiler to build? > If the answer is yes, then most likely these should not be three seperate > source packages. > It's all one source package. I split it up the binaries because: 1) about 60% of the package could be in an 'all' package. 2) the runtime components for different architectures can be installed side-by-side... thus enabling cross-compilation. If no, then why doesn't it just work or is the problem a previous version > causing a mess? > According to Kurt, there is no problem. It's all in my head. :)
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 7:27 PM, Kurt Roeckx wrote: > Note that in unstable you don't see the arch arch all version > until the arch any version is also available. Or you would see > the old arch all version until the new arch any version is > available. > That's great! My thanks to whomever had the foresight to prevent this temporary dependency breakage for all->any dependencies. I guess this would otherwise have annoyed unstable users for packages that had yet to be built for their architecture..? This means that the version from unstable should always be > installable, unless there is some other reason it's not like > a transition of some other library. > Yes, the libgmp3-dev -> libgmp-dev transition already bit me this way. I assumed I was in for more of the same with the self dependency. The problem is that the buildds currently also see the newer > arch all version. But this version will go away after some > time and it will only see the version from unstable. > If I may ask, for what purpose do the buildds have a special list of packages above and beyond those in unstable? The new version of mlton-basis will only be visible to the buildds > for about a day, after which they should have no problem building > it. > Thank god. :)
Re: Meeting Minutes, FTPMaster meeting March 2011
On Mon, Mar 28, 2011 at 10:19:32PM +, Philipp Kern wrote: > On 2011-03-28, Wouter Verhelst wrote: > > But I'd think that "making sure this buildd host can still do uploads in > > a timely manner when the key expires" is pretty well inside the realm of > > the buildd admin's responsibility. > > And manual signing wouldn't be timely? Less so. > I talked with Joerg at the meeting and we agreed that arch-based admin > keyrings aren't needed. If you feel so strongly about it, I think you > should take it up yourself and make [0] support one keyring per arch. > (Or get Joerg to do it. As I told him that he doesn't need to consider > it in the initial design it feels unfair to me to ask him now. Either > way, if it isn't done, you don't feel strongly enough about it. There's > no policy decision in the way this time.) Sure; I'd be happy to put my code where my mouth is, if that helps solve this particular issue. It'll have to wait until my current move is over, however (see my [vac] on -private). Note that it isn't entirely clear to me how splitting up keyrings per architecture would help there, so some explanation might help (if I want to make sure that whatever patch I come up with actually solves the issue at hand...). > I still don't think it's necessary, as it will be mostly identical on > all archs and we'll be doing the work anyway but frankly I don't care, > as long as the keys are following the rules the ftp-masters set for > them. We'll still monitor the expiry and if you don't react quickly > enough do it ourselves. Of course. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 07:54:59PM +0200, Wesley W. Terpstra wrote: > The problem is that the buildds currently also see the newer > > arch all version. But this version will go away after some > > time and it will only see the version from unstable. > > > > If I may ask, for what purpose do the buildds have a special list of > packages above and beyond those in unstable? So that in case various packages have to be build in an order, where the seconds depends on the first being available and so on, that it doesn't take weeks to get them all build. We would have to wait at least a dinstall before the next one could be build, assuming sometimes has the time to sign the package between dinstalls. It basicly just avoids a whole lot of delays. Kurt -- 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/20110329180343.ga14...@roeckx.be
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 06:58:36PM +0200, Wesley W. Terpstra wrote: > On Tue, Mar 29, 2011 at 6:42 PM, Kurt Roeckx wrote: > > > As long as the Packages file for the buildds mentions this arch > > all package, no buildd can build it, because it only considers > > installing the latest version. But it should get removed > > from that file after 24 or 32 hours or something. In which case > > we'll only see the old version, can install those, and things should > > work from there. > > > > > What I don't understand about your explanation: once the new all+i386 .debs > hit unstable, won't the buildds see the new 'all' package in unstable and > thus want to install it in preference to the old 'any' package even after it > is removed from the Packages file? The 'all' package will still be > uninstallable since it depends on the missing 'any' packages. Let's take a look at all current Packages files: - The buildd Packages file, as seen by *all* the buildds, not only the i386 one: kroeckx@grieg:~$ zcat /org/wanna-build/tmp/archive/debian/buildd-sid/Packages.gz | grep-dctrl -F Package mlton -s Package,version,Architecture Package: mlton-basis version: 20100608-3 Architecture: all Package: mlton-compiler version: 20100608-3 Architecture: i386 Package: mlton version: 20100608-3 Architecture: all Package: mlton-tools version: 20100608-3 Architecture: i386 Package: mlton-runtime-native version: 20100608-3 Architecture: i386 Package: mlton-runtime-i486-linux-gnu version: 20100608-3 Architecture: i386 Package: mlton-doc version: 20100608-3 Architecture: all The i386 unstable one: kroeckx@grieg:~$ zcat /org/wanna-build/tmp/archive/debian/archive/sid/main/binary-i386/Packages.gz | grep-dctrl -F Package mlton -s Package,version,Architecture Package: mlton-basis version: 20100608-3 Architecture: all Package: mlton-compiler version: 20100608-3 Architecture: i386 Package: mlton-doc version: 20100608-3 Architecture: all Package: mlton-runtime-i486-linux-gnu version: 20100608-3 Architecture: i386 [...] The amd64 one: kroeckx@grieg:~$ zcat /org/wanna-build/tmp/archive/debian/archive/sid/main/binary-amd64/Packages.gz | grep-dctrl -F Package mlton -s Package,version,Architecture Package: mlton version: 20100608-2 Architecture: amd64 Note that in unstable you don't see the arch arch all version until the arch any version is also available. Or you would see the old arch all version until the new arch any version is available. This means that the version from unstable should always be installable, unless there is some other reason it's not like a transition of some other library. The problem is that the buildds currently also see the newer arch all version. But this version will go away after some time and it will only see the version from unstable. > The basis, runtime, and compiler packages should all be at the same version > to compile correctly. The basis package is an 'all' package which includes > the cross-platform bits of the runtime library. The runtime and compiler are > 'any' packages with compiled object code. > > If the Build-Depends lists 'mlton-compiler' (ie: after I resolve the current > problem), any future uploads will see that it has these versions available: > mlton-compiler (= old-version) depends on runtime > mlton-runtime (= old-version) depends on basis > mlton-basis (= new version) > ... which I believe means that the old-version mlton-compiler package will > be uninstallable since the old-version of the basis in unstable is hidden by > the new-version. The new version of mlton-basis will only be visible to the buildds for about a day, after which they should have no problem building it. Kurt -- 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/20110329172733.ga14...@roeckx.be
Re: [buildd-tools-devel] new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 06:58:36PM +0200, Wesley W. Terpstra wrote: > I hope what you're telling me is true, because it will save me a lot of > work! :) > > What I don't understand about your explanation: once the new all+i386 .debs > hit unstable, won't the buildds see the new 'all' package in unstable and > thus want to install it in preference to the old 'any' package even after it > is removed from the Packages file? The 'all' package will still be > uninstallable since it depends on the missing 'any' packages. > > While I can fix the problem at hand by removing the mlton 'all' package for > an upload, I see a more troublesome problem on the horizon: > > The basis, runtime, and compiler packages should all be at the same version > to compile correctly. The basis package is an 'all' package which includes > the cross-platform bits of the runtime library. The runtime and compiler are > 'any' packages with compiled object code. > > If the Build-Depends lists 'mlton-compiler' (ie: after I resolve the current > problem), any future uploads will see that it has these versions available: > mlton-compiler (= old-version) depends on runtime > mlton-runtime (= old-version) depends on basis > mlton-basis (= new version) > ... which I believe means that the old-version mlton-compiler package will > be uninstallable since the old-version of the basis in unstable is hidden by > the new-version. > > Have I understood this problem correctly? Does mlton-basis depend on mlton-runtime or mlton-compiler to build? If the answer is yes, then most likely these should not be three seperate source packages. If no, then why doesn't it just work or is the problem a previous version causing a mess? I hate circular build dependancies. :) -- Len Sorensen -- 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/20110329171048.ga...@caffeine.csclub.uwaterloo.ca
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 6:42 PM, Kurt Roeckx wrote: > As long as the Packages file for the buildds mentions this arch > all package, no buildd can build it, because it only considers > installing the latest version. But it should get removed > from that file after 24 or 32 hours or something. In which case > we'll only see the old version, can install those, and things should > work from there. > I hope what you're telling me is true, because it will save me a lot of work! :) What I don't understand about your explanation: once the new all+i386 .debs hit unstable, won't the buildds see the new 'all' package in unstable and thus want to install it in preference to the old 'any' package even after it is removed from the Packages file? The 'all' package will still be uninstallable since it depends on the missing 'any' packages. While I can fix the problem at hand by removing the mlton 'all' package for an upload, I see a more troublesome problem on the horizon: The basis, runtime, and compiler packages should all be at the same version to compile correctly. The basis package is an 'all' package which includes the cross-platform bits of the runtime library. The runtime and compiler are 'any' packages with compiled object code. If the Build-Depends lists 'mlton-compiler' (ie: after I resolve the current problem), any future uploads will see that it has these versions available: mlton-compiler (= old-version) depends on runtime mlton-runtime (= old-version) depends on basis mlton-basis (= new version) ... which I believe means that the old-version mlton-compiler package will be uninstallable since the old-version of the basis in unstable is hidden by the new-version. Have I understood this problem correctly?
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 05:52:23PM +0200, Julien Cristau wrote: > As far as I can tell the problem is that you switched the mlton binary > package to 'Architecture: all'. Which means it's available on all > architectures already in the new version, even though it's not > installable. If I understand the situation, this means the buildd's already see the new mlton arch all in the Packages file for the buildds. But you won't see in on the mirrors until the arch any package for that arch is available. And the arch all binary package has a strict version requirement binary any package. As long as the Packages file for the buildds mentions this arch all package, no buildd can build it, because it only considers installing the latest version. But it should get removed from that file after 24 or 32 hours or something. In which case we'll only see the old version, can install those, and things should work from there. So I think you either need to be patient, or have a less strict version requirement. Kurt -- 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/20110329164239.ga13...@roeckx.be
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 5:52 PM, Julien Cristau wrote: > As far as I can tell the problem is that you switched the mlton binary > package to 'Architecture: all'. Which means it's available on all > architectures already in the new version, even though it's not > installable. > Ahh! That makes a lot of sense, thanks. I'll need to figure out a way to work-around this.
Re: new buildd dependency resolution breaks self depends?
Hi, Am Dienstag, den 29.03.2011, 17:52 +0200 schrieb Julien Cristau: > > *mlton/alpha dependency installability problem:* > > > > mlton (= 20100608-3) build-depends on one of: > > - mlton (= 20100608-3) > > > > ... this is, of course, impossible. The buildd must install the old version > > in order to build the new. I have a suspicion that an overzealous 'use the > > same version' rule in the dependency resolver might be the cause of this > > bug. > > > As far as I can tell the problem is that you switched the mlton binary > package to 'Architecture: all'. Which means it's available on all > architectures already in the new version, even though it's not > installable. sounds similar to what just happend to me with ghc: http://lists.debian.org/debian-haskell/2011/03/msg00108.html In this case, with some help of the ftp team this could be resolved. But in your case, as it is not transitional, it looks harder. I guess you need to ensure that version n+1 can be built using the arch:any packages of version n and the arch:all packages of either version n or version n +1... or undo the package split. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Bug#620018: ITP: nova -- open source software for building reliable cloud infrastructure
On 03/29/2011 07:50 PM, Cyril Brulebois wrote: Thomas Goirand (29/03/2011): Description : open source software for building reliable cloud infrastructure Please drop “open source software”, that's what Debian is about, no need to mention it in package descriptions (both short and long btw). KiBi. I agree. I lamely did a cut/past from the description of the Ubuntu package, but doing so, I thought about it. I am very happy that you share my opinion about it, and that you took time to say it without even having to discuss the topic. So thank you! 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/4d91fd84.7040...@goirand.fr
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 17:25:14 +0200, Wesley W. Terpstra wrote: > I've read that there was a recent change made to the buildd resolution with > regards to ensuring that consistent package versions are used on the builds > [0]. Is it possible that this changed also messed up self-dependency > resolution? > > My package, mlton, has a versioned dependency on itself for version >= > 20070826. As it is a compiler for SML written in SML, it needs a previous > version of itself installed in order to compile the new version. Previously, > this has presented no problems; the buildd installed the old version and > compiled the new version. Now, the buildd demands that the same version be > installed as is to be built [1]: > > *mlton/alpha dependency installability problem:* > > mlton (= 20100608-3) build-depends on one of: > - mlton (= 20100608-3) > > ... this is, of course, impossible. The buildd must install the old version > in order to build the new. I have a suspicion that an overzealous 'use the > same version' rule in the dependency resolver might be the cause of this > bug. > As far as I can tell the problem is that you switched the mlton binary package to 'Architecture: all'. Which means it's available on all architectures already in the new version, even though it's not installable. Cheers, Julien -- 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/20110329155223.gg3...@radis.liafa.jussieu.fr
new buildd dependency resolution breaks self depends?
I've read that there was a recent change made to the buildd resolution with regards to ensuring that consistent package versions are used on the builds [0]. Is it possible that this changed also messed up self-dependency resolution? My package, mlton, has a versioned dependency on itself for version >= 20070826. As it is a compiler for SML written in SML, it needs a previous version of itself installed in order to compile the new version. Previously, this has presented no problems; the buildd installed the old version and compiled the new version. Now, the buildd demands that the same version be installed as is to be built [1]: *mlton/alpha dependency installability problem:* mlton (= 20100608-3) build-depends on one of: - mlton (= 20100608-3) ... this is, of course, impossible. The buildd must install the old version in order to build the new. I have a suspicion that an overzealous 'use the same version' rule in the dependency resolver might be the cause of this bug. Thanks for any help understanding why the buildd system will no longer attempt to build my package! [0] http://lists.debian.org/debian-policy/2011/03/msg00103.html [1] https://buildd.debian.org/status/package.php?p=mlton
Bug#620060: ITP: libdmapsharing -- DMAP client and server library
Package: wnpp Severity: wishlist Owner: Josselin Mouette * Package name: libdmapsharing Version : 2.9.6 Upstream Authors: Andre Moreira Magalhaes Jonathan Matthew William Jon McCann W. Michael Petullo Charles Schmidt Alexandre Rosenfeld Noah Alcantara * URL : http://www.flyn.org/projects/libdmapsharing/ * License : LGPL 2.1+ Programming Lang: C Description : DMAP client and server library libdmapsharing is a library you may use to access and share DMAP (DAAP & DPAP) content. The library is written in C using GObject and libsoup. The DMAP family of protocols are used by products such as iTunes(TM), iPhoto(TM) and the Roku SoundBridge(TM) family to share content such as music and photos. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling -- 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/20110329145525.ga18...@malsain.org
Re: Meeting Minutes, FTPMaster meeting March 2011
On Tue, 29 Mar 2011, Dominique Dumont wrote: > On Monday 28 March 2011 19:43:52 Henrique de Moraes Holschuh wrote: > > So, we have to either accept source-only uploads with the knowledge that > > some people will upload even more crap, or don't accept source-only > > uploads at all. There is no "punishment for the bad uploader" option, > > anyone proposing that is just setting the project up for a lot of > > aggravation IMO. > > How about putting "bad uploaders" on a low priority queue, so that source > package from "good uploaders" are built first ? > > This could minimize the impact of source package only upload... Why insist on a solution that is likely to cause social damage? Why insist on something that IS going to cause aggravation the very first time someone decides to complain about it? There are many other ways to avoid the need of a binary package upload from a DD's box/PDA/smartphone/laptop/netbook/whatever. You *WILL* have to build (and _test_) the binary packages anyway, otherwise you're either a perfect DD that never makes mistakes, or exactly the kind of DD we don't want near a source-only upload in the first place. At that point, exactly why should you not upload the entire thing? You have already built them. You already have to be able to sign the upload anyway, be it source-only, or source+binary. Very few DDs have to deal with uploading extremely large binary packages from upload-constrained boxes, and those are likely to be already using one of the numerous methods available to them to minimize the problem. This is off-topic for this thread, and I am repeating all that has been said before in numerous threads. I will post about this no further. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20110329135031.gd21...@khazad-dum.debian.net
Re: Meeting Minutes, FTPMaster meeting March 2011
Bernd Zeimetz (29/03/2011): > And as you have to test-build your packages anyway the only reason I > see why you wouldn't be able to upload them is a very slow > connection to the rest of the world. One can test-build in her own, non-chroot environment, and still be cautious about what changed in configure.ac (or similar); so building in a chroot can be usually extra, fruitless work. (mesa or xorg-server come to mind.) And as far as I'm concerned, I just hate having to wait for xorg-server to be built on say mips or sparc before asking for xserver-xorg-dev to be installed on a porter machine to build my drivers there, when I *know* they build (since I tested them on say amd64, by tweaking the Architecture line). Not to mention the fact DSA doesn't want to handle anything like “experimental” chroots, so you can't get build dependencies from experimental, at all. Finally, requiring binary packages to be uploaded along source packages doesn't stop people from uploading broken packages, which basically lack a build dependency on say autoconf, automake, libtool, pkg-config, cmake, python, whatever. It doesn't look like that “let's require binary packages” filter is helping much. The BTS is full of such FTBFS bug reports. KiBi. signature.asc Description: Digital signature
Re: Bug#620018: ITP: nova -- open source software for building reliable cloud infrastructure
Thomas Goirand (29/03/2011): > Description : open source software for building reliable cloud > infrastructure Please drop “open source software”, that's what Debian is about, no need to mention it in package descriptions (both short and long btw). KiBi. signature.asc Description: Digital signature
Bug#620019: ITP: swift -- a distributed virtual object store
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: swift Version : 1.2.0 Upstream Author : Openstack * URL : http://www.openstack.org/ * License : Apache 2.0 Programming Lang: Python Description : a distributed virtual object store Swift is a distributed virtual object store that can be used by the Openstack cloud computing software. -- 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/20110329104913.2183.53721.report...@buzig.gplhost.com
Bug#620018: ITP: nova -- open source software for building reliable cloud infrastructure
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: nova Version : 2011.1.1 Upstream Author : Openstack developers * URL : http://www.openstack.org/ * License : Apache 2.0 Programming Lang: Python Description : open source software for building reliable cloud infrastructure OpenStack is free, open source software for building reliable cloud infrastructure. The OpenStack mission is to produce the ubiquitous Open Source cloud computing platform that will meet the needs of public and private cloud providers regardless of size, by being simple to implement and massively scalable. OpenStack Compute, codenamed Nova, is a cloud computing fabric controller. In addition to its "native", open API (the OpenStack API), it also supports the Amazon EC2 API. Nova is intended to be modular and easy to extend and adapt. It supports many different hypervisors (KVM and Xen to name a few), different database backends (SQLite, MySQL, and PostgreSQL, for instance), different types of user databases (LDAP or SQL), etc. -- 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/20110329103817.2063.40292.report...@buzig.gplhost.com
Re: Packaging Openstack for Debian: anyone else interested?
2011/3/28 Steve Langasek : > There is a patch for debhelper that will remove this constraint (i.e., both > upstart jobs and sysvinit scripts will be installed /together/), but there's > further groundwork to be applied in other packages before it should be > included in the Debian archive. Until this happens (assuming it's not going to be Real Soon Now[tm]), wouldn't it make more sense to just make dh_installinit favour init scripts over upstart jobs? That's really all I'm suggesting. I understand handling this from maintainer scripts as opposed to making the call at dh_installinit time is more elegant, but the current logic seems like it should be the other way around. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ OpenStack Developer http://www.openstack.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/AANLkTi=Sp=ug+r5rmqx213tzuu_f83fz03x08pa8q...@mail.gmail.com
Re: Meeting Minutes, FTPMaster meeting March 2011
On ti, 2011-03-29 at 09:52 +0200, Bernd Zeimetz wrote: > And as you have to test-build your packages anyway the only reason I see > why you wouldn't be able to upload them is a very slow connection to the > rest of the world. Bandwidth quotas would be another reason. (I have no opinion on whether uploads should be required or not, though.) -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- 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/1301385335.11500.10.ca...@havelock.liw.fi
Re: Meeting Minutes, FTPMaster meeting March 2011
On 03/28/2011 07:05 PM, Philipp Kern wrote: > I think people who screw up repeatedly even after being told to be careful > should have their upload privileges suspended at the discretion of the > ftp-masters. We had that in the past as well. Then source-only uploads > shouldn't be a problem. That won't work, at least not within a proper time frame. And as you have to test-build your packages anyway the only reason I see why you wouldn't be able to upload them is a very slow connection to the rest of the world. > .oO( Don't throw too many technical(ly inferior) solutions onto social > problems... ) Sometimes simple technical solutions are easier to implement than fixing social problems. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 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/4d918fd5.7010...@bzed.de
Re: Meeting Minutes, FTPMaster meeting March 2011
On Monday 28 March 2011 19:43:52 Henrique de Moraes Holschuh wrote: > So, we have to either accept source-only uploads with the knowledge that > some people will upload even more crap, or don't accept source-only > uploads at all. There is no "punishment for the bad uploader" option, > anyone proposing that is just setting the project up for a lot of > aggravation IMO. How about putting "bad uploaders" on a low priority queue, so that source package from "good uploaders" are built first ? This could minimize the impact of source package only upload... HTH Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- 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/201103290925.08655.dominique.dum...@hp.com
