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 w
[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 c
> 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
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
>
>
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
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
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 ha
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.
>
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
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. Bu
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 u
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. I
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 underst
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
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
> > i
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
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
> res
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 versi
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
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 "p
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
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: Digit
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
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 f
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 t
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
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.
Tha
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 prop
28 matches
Mail list logo
