Hi Josselin,
Am -10.01.-28163 20:59, schrieb Josselin Mouette:
> Would it be possible to add support for ddebs?
are there any example packages that build ddebs? That we can use for
testing dak?
Cheers,
Torsten
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
On Tue, Feb 15, 2011 at 6:04 PM, Mark Hymers wrote:
> Could we choose to document that it can only be used in wheezy (enforced
> by dak if necessary) and above and then have the release notes state
> that users must upgrade dpkg and apt to the latest point release before
> doing the dist-upgrade?
On Tue, 15, Feb, 2011 at 08:55:50AM -0800, Steve Langasek spoke thus..
> > [*] It's also a bit of cheating if we allow such updates into stable.
> > Why didn't we add other compression formats and other source formats to
> > dpkg in stable then; we did claim that you need to wait a cycle fo
On Tue, Feb 15, 2011 at 07:30:29AM +, Philipp Kern wrote:
> > Of course I'm not taking it for granted that you would accept these packages
> > into squeeze and intended to ask you if this would be ok, once there were
> > actual patches to be considered. But since you're here: would targeted
>
On Mon, 14, Feb, 2011 at 01:08:51PM -0800, Steve Langasek spoke thus..
> I'm happy to file bug reports against the appropriate components if that's
> the right thing to do here; I'm raising it on the list first because I'm not
> sure whether dak is actually affected, and if so whether ftp.debian.or
On Mon, Feb 14, 2011 at 04:28:49PM -0800, Steve Langasek wrote:
> On Mon, Feb 14, 2011 at 09:52:32PM +, Roger Leigh wrote:
> > On Mon, Feb 14, 2011 at 01:08:51PM -0800, Steve Langasek wrote:
> > > And although for the most part the roll-out of multiarch is intended to be
> > > backwards-compati
On Tue, Feb 15, 2011 at 08:06:42AM +0100, Raphael Hertzog wrote:
> On Mon, 14 Feb 2011, Philipp Kern wrote:
> > You'd lose the notion of it being useful on other architectures (that's the
> > arch:all -> arch:i386 Raphael's talking about), though. But then packages
> > like qemu-system would just
Hi!
On Mon, 2011-02-14 at 08:39:21 +0100, Raphael Hertzog wrote:
> On Sat, 12 Feb 2011, Guillem Jover wrote:
> > Using Build-Architecture would be a workaround, it should not be
> > needed once multiarch is in place and those packages are built for
> > their respective architectures.
>
> While te
On 2011-02-15, Steve Langasek wrote:
> I wasn't suggesting the use of -backports here, I was referring to
> backported features in the general sense of the term.
I know. -backports would've been the "easy" way out, though. But obviously a
no-go for official infrastructure.
> Of course I'm not
On Mon, 14 Feb 2011, Philipp Kern wrote:
> You'd lose the notion of it being useful on other architectures (that's the
> arch:all -> arch:i386 Raphael's talking about), though. But then packages
> like qemu-system would just depend on openbios-sparc:sparc, no? If you
> don't need to deal with the
On Tue, Feb 15, 2011 at 06:15:35AM +, Philipp Kern wrote:
> On 2011-02-15, Steve Langasek wrote:
> >> sbuild switched to using Dpkg::Deps for parsing dependencies; we would
> >> ideally want an equivalent to Dpkg::Deps::reduce_arch() to do the
> >> stripping (if reduce_arch wasn't the appropri
On 2011-02-15, Steve Langasek wrote:
>> sbuild switched to using Dpkg::Deps for parsing dependencies; we would
>> ideally want an equivalent to Dpkg::Deps::reduce_arch() to do the
>> stripping (if reduce_arch wasn't the appropriate place to do it
>> already). This saves us from reimplementing yet
Charles Plessy wrote:
> Le Sun, Feb 13, 2011 at 10:46:53PM -0600, Raphael Geissert a écrit :
>> What signatures?
>
> The signatures that certify that the logs are really the ones for the the
> packages we distribute. I suppose that the closest to this is the .changes
> files signed by the buildd
On Mon, Feb 14, 2011 at 09:52:32PM +, Roger Leigh wrote:
> On Mon, Feb 14, 2011 at 01:08:51PM -0800, Steve Langasek wrote:
> > And although for the most part the roll-out of multiarch is intended to be
> > backwards-compatible and a smooth transition, there are two small extensions
> > required
Le Mon, Feb 14, 2011 at 04:37:36PM +0100, gregor herrmann a écrit :
> On Mon, 14 Feb 2011 13:27:38 +0900, Charles Plessy wrote:
>
> > I would be happy to get build logs as well, or at least a link to an URL
> > where they are dowloadable withouth HTML processing.
> >
> > For the moment, I only fo
On Mon, Feb 14, 2011 at 01:08:51PM -0800, Steve Langasek wrote:
> And although for the most part the roll-out of multiarch is intended to be
> backwards-compatible and a smooth transition, there are two small extensions
> required to the package relationship fields in order to deploy a full
> multi
On 2011-02-14, Luk Claes wrote:
> On 02/14/2011 08:39 AM, Raphael Hertzog wrote:
>> On Sat, 12 Feb 2011, Guillem Jover wrote:
>>> On Fri, 2011-02-11 at 11:33:10 +0800, Paul Wise wrote:
On Fri, Feb 11, 2011 at 5:58 AM, Ben Hutchings
wrote:
> Since there is no support for auto-buildi
Hi Joerg,
On Thu, Feb 03, 2011 at 10:05:27PM +0100, Joerg Jaspert wrote:
> Attached below is a tentative agenda. This is an unsorted list and we
> might not get to every point. We might also have missed any number of
> points, if so feel free to tell us about them.
One other item I'd like to sub
On 02/14/2011 08:39 AM, Raphael Hertzog wrote:
> On Sat, 12 Feb 2011, Guillem Jover wrote:
>> Hi!
>>
>> On Fri, 2011-02-11 at 11:33:10 +0800, Paul Wise wrote:
>>> On Fri, Feb 11, 2011 at 5:58 AM, Ben Hutchings wrote:
Since there is no support for auto-building arch-independent binaries
>>>
>>
On Mon, 14 Feb 2011 13:27:38 +0900, Charles Plessy wrote:
> I would be happy to get build logs as well, or at least a link to an URL
> where they are dowloadable withouth HTML processing.
>
> For the moment, I only found raw logs in /srv/buildd.debian.org/db on
> buildd.debian.org, but that direc
Le Sun, Feb 13, 2011 at 10:46:53PM -0600, Raphael Geissert a écrit :
> Charles Plessy wrote:
> >
> > I would be happy to get build logs as well, or at least a link to an URL
> > where they are dowloadable withouth HTML processing.
>
> You can always | html2text -utf8
Or scp
buildd.debian.org:/s
On 14/02/11 at 12:13 +, Philipp Kern wrote:
> On 2011-02-13, Tollef Fog Heen wrote:
> > ]] Philipp Kern
> >| Actually those build failures are nowadays sent to the PTS for further
> >| distribution (the "buildd" keyword). I don't know how many are subscribed
> >| to those notifications, thou
On 2011-02-14, Raphael Geissert wrote:
> Philipp Kern wrote:
>> Actually those build failures are nowadays sent to the PTS for further
>> distribution (the "buildd" keyword). I don't know how many are subscribed
>> to those notifications, though. (After all, they're not automatically
>> sent to
On 2011-02-13, Felipe Sateler wrote:
> AFAIK, that service also mails when the build was successful, leading to
> a lot of noise.
Eh no, it never did.
Kind regards
Philipp Kern
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
On 2011-02-13, Tollef Fog Heen wrote:
> ]] Philipp Kern
>| Actually those build failures are nowadays sent to the PTS for further
>| distribution (the "buildd" keyword). I don't know how many are subscribed
>| to those notifications, though. (After all, they're not automatically
>| sent to the
Le vendredi 11 février 2011 à 21:30 +, Mark Hymers a écrit :
> On Thu, 10, Feb, 2011 at 09:27:14PM +0100, Josselin Mouette spoke thus..
> > Would it be possible to add support for ddebs?
>
> I'll stick it on the agenda. I assume the details at
> http://wiki.debian.org/AutomaticDebugPackages
On Sat, 12 Feb 2011, Guillem Jover wrote:
> Hi!
>
> On Fri, 2011-02-11 at 11:33:10 +0800, Paul Wise wrote:
> > On Fri, Feb 11, 2011 at 5:58 AM, Ben Hutchings wrote:
> > > Since there is no support for auto-building arch-independent binaries
> >
> > I would hope that throwing away developer built
Charles Plessy wrote:
>
> I would be happy to get build logs as well, or at least a link to an URL
> where they are dowloadable withouth HTML processing.
You can always | html2text -utf8
> For the moment, I only found raw logs in /srv/buildd.debian.org/db on
> buildd.debian.org, but that directo
Le Sun, Feb 13, 2011 at 11:40:25PM +0100, Tollef Fog Heen a écrit :
> ]] Philipp Kern
>
> | Actually those build failures are nowadays sent to the PTS for further
> | distribution (the "buildd" keyword). I don't know how many are subscribed
> | to those notifications, though. (After all, they'r
Philipp Kern wrote:
> Actually those build failures are nowadays sent to the PTS for further
> distribution (the "buildd" keyword). I don't know how many are subscribed
> to those notifications, though. (After all, they're not automatically
> sent to the maintainer.)
Taking a look at the databas
]] Felipe Sateler
| On Sun, 13 Feb 2011 23:40:25 +0100, Tollef Fog Heen wrote:
|
| > FWIW, Ubuntu mails maintainers on build failures (at least in PPAs),
| > and I've found that to work well.
|
| AFAIK, that service also mails when the build was successful, leading
| to a lot of noise.
I don't
On 2011-02-13, Tollef Fog Heen wrote:
> Would people be opposed to changing that? I would be quite happy to get
> mails if my packages FTBFS on various architectures, and I believe I'm
> competent to at least usually see if something fails because of
> something obvious or if it looks like a chro
On Sun, 13 Feb 2011 23:40:25 +0100, Tollef Fog Heen wrote:
> Would people be opposed to changing that? I would be quite happy to get
> mails if my packages FTBFS on various architectures,
Agreed, getting mails with build logs (or pointers to them) for build
failures would be helpful IMO.
Chee
On Sun, 13 Feb 2011 23:40:25 +0100, Tollef Fog Heen wrote:
> ]] Philipp Kern
>
> | Actually those build failures are nowadays sent to the PTS for further
> | distribution (the "buildd" keyword). I don't know how many are
> subscribed | to those notifications, though. (After all, they're not
> a
Adam Borowski writes:
> For example, any package built on a system with nvidia's drivers will be
> built against them rather than mesa due to diversions, and will be
> unusable anywhere else.
This hasn't been the case for a while. We fixed this in the NVIDIA
packages.
--
Russ Allbery (r...@de
]] Philipp Kern
| Actually those build failures are nowadays sent to the PTS for further
| distribution (the "buildd" keyword). I don't know how many are subscribed
| to those notifications, though. (After all, they're not automatically
| sent to the maintainer.)
Would people be opposed to cha
On 2011-02-13, Lars Wirzenius wrote:
> On su, 2011-02-13 at 19:13 +0100, Luk Claes wrote:
>> On 02/13/2011 07:00 PM, Lars Wirzenius wrote:
>> > On su, 2011-02-13 at 18:49 +0100, Bernd Zeimetz wrote:
>> >> I don;t think that is a good idea, there are way too many people not
>> >> building
>> >> an
Samuel Thibault, le Sun 13 Feb 2011 19:51:07 +0100, a écrit :
> Michael Goetze, le Sun 13 Feb 2011 19:21:32 +0100, a écrit :
> > On 02/07/2011 12:10 AM, Svante Signell wrote:
> > >On 2011-02-03, Joerg Jaspert wrote:
> > >>* get rid of hurd (or discuss this)
> > >
> > >Why? GNU/Hurd has made vast i
Michael Goetze, le Sun 13 Feb 2011 19:21:32 +0100, a écrit :
> On 02/07/2011 12:10 AM, Svante Signell wrote:
> >On 2011-02-03, Joerg Jaspert wrote:
> >>* get rid of hurd (or discuss this)
> >
> >Why? GNU/Hurd has made vast improvements during last year. Even the
> >Debian installer is functional.
On 02/07/2011 12:10 AM, Svante Signell wrote:
On 2011-02-03, Joerg Jaspert wrote:
* get rid of hurd (or discuss this)
Why? GNU/Hurd has made vast improvements during last year. Even the
Debian installer is functional. Now, with support for VMs like qemu, xen
and virtualbox, more people are sh
On Sun, Feb 13, 2011 at 06:46:22PM +0100, Stefano Zacchiroli wrote:
> On Sat, Feb 12, 2011 at 08:22:39PM +0100, Bernhard R. Link wrote:
> > * Don Armstrong [110211 23:01]:
> > > 3) uniform, known build environments
> > I think is a major disadvantage of this suggestion.
> I'm unconvinced by your
On su, 2011-02-13 at 19:13 +0100, Luk Claes wrote:
> On 02/13/2011 07:00 PM, Lars Wirzenius wrote:
> > On su, 2011-02-13 at 18:49 +0100, Bernd Zeimetz wrote:
> >> I don;t think that is a good idea, there are way too many people not
> >> building
> >> and testing their packages properly already, we
brian m. carlson (13/02/2011):
> Also, FTBFS bugs are often filed by buildd admins; I'm sure they'd
> like to spend their time doing things other than filing those bugs.
Hell yes.
KiBi.
signature.asc
Description: Digital signature
On Sun, Feb 13, 2011 at 06:00:11PM +, Lars Wirzenius wrote:
> That's something I don't understand. If I upload a broken package, why
> should it be the buildd admin's job to deal with it? Should not I get
> notified of the error, and told to fix it?
I've seen packages that don't fail until the
On 02/13/2011 07:00 PM, Lars Wirzenius wrote:
> On su, 2011-02-13 at 18:49 +0100, Bernd Zeimetz wrote:
>> I don;t think that is a good idea, there are way too many people not building
>> and testing their packages properly already, we don't want to give that work
>> to
>> the buildd-admins...
>
>
On su, 2011-02-13 at 18:49 +0100, Bernd Zeimetz wrote:
> I don;t think that is a good idea, there are way too many people not building
> and testing their packages properly already, we don't want to give that work
> to
> the buildd-admins...
That's something I don't understand. If I upload a brok
On 02/10/2011 09:43 PM, Sandro Tosi wrote:
> On Thu, Feb 3, 2011 at 22:05, Joerg Jaspert wrote:
>> * Throwaway DD built .debs (well, let's have the fight^Wdiscussion)
>
> could you please keep in mind the bandwidth impaired and try something
> that avoids to upload those binary packages in the fi
On Sat, Feb 12, 2011 at 08:22:39PM +0100, Bernhard R. Link wrote:
> * Don Armstrong [110211 23:01]:
> > 3) uniform, known build environments
> I think is a major disadvantage of this suggestion.
I'm unconvinced by your (implicit) argument that switching to an uniform
build environment will make t
Bernhard R. Link wrote:
> I'd rather say "doing it right" means to properly test it's build to be
> robust. Only ever testing in an artifical environment has a certain
> outcome: certain failure.
That depends. How closely does the artificial environment mirror the
avarage system as measured by pop
On Sun, Feb 13, 2011 at 12:58 PM, Roger Leigh wrote:
> • adding build conflicts to ensure it will build on any arbitrary
> system with a random selection of installed packages will always be
> on a "best effort" basis:
Is this about automatically picking up optional dependencies (by
configure a
On Sun, Feb 13, 2011 at 03:23:30PM +0100, Bernhard R. Link wrote:
> * Holger Levsen [110213 13:13]:
> > On Sonntag, 13. Februar 2011, Bernhard R. Link wrote:
> > > But it is an essential part of doing it right, so we should try to do
> > > our best and not just give up early.
> >
> > doing it righ
Hi,
On Sonntag, 13. Februar 2011, Bernhard R. Link wrote:
> I'd rather say "doing it right" means to properly test it's build to be
> robust. Only ever testing in an artifical environment has a certain
> outcome: certain failure.
Nobody said people should stop rebuilding packages on those 100 der
Le Sun, Feb 13, 2011 at 12:42:57PM +0100, Bernhard R. Link a écrit :
> Porters trying to fix your crappy non-portable software
> Allowing things to build in a non-artificial environment is simply an
> important part of being a good free software citizen.
> we should try to do our best and not jus
* Holger Levsen [110213 13:13]:
> On Sonntag, 13. Februar 2011, Bernhard R. Link wrote:
> > But it is an essential part of doing it right, so we should try to do
> > our best and not just give up early.
>
> doing it right certainly doesnt mean to create a stable distro build in an
> unpredicatable
On Sun, Feb 13, 2011 at 12:42:57PM +0100, Bernhard R. Link wrote:
> * Roger Leigh [110212 21:58]:
> > The other side to this is that fixing such bugs gains us very litle.
> >
> > If we have a guaranteed clean build environment + package build deps,
> > we have as complete consistency as is practic
Hi,
On Sonntag, 13. Februar 2011, Bernhard R. Link wrote:
> But it is an essential part of doing it right, so we should try to do
> our best and not just give up early.
doing it right certainly doesnt mean to create a stable distro build in an
unpredicatable environment.
its rather done using a
* Lars Wirzenius [110212 20:40]:
> On la, 2011-02-12 at 20:22 +0100, Bernhard R. Link wrote:
> > If the packages used are only ever built in unnatural virgin
> > environments, there is basically no testing if building them on
> > a real user machine works. And things not tested usually just stop
>
On Sun, Feb 13, 2011 at 12:42:57PM +0100, Bernhard R. Link wrote:
> * Roger Leigh [110212 21:58]:
> Allowing things to build in a non-artificial environment is simply an
> important part of being a good free software citizen. We as packagers do
> not like it if upstream has an arcane build system
* Roger Leigh [110212 21:58]:
> The other side to this is that fixing such bugs gains us very litle.
>
> If we have a guaranteed clean build environment + package build deps,
> we have as complete consistency as is practicable.
You might have no problem producing nice binary packages so people mi
On su, 2011-02-13 at 08:41 +0100, Lucas Nussbaum wrote:
> On 12/02/11 at 15:29 -0600, Raphael Geissert wrote:
> > Lars Wirzenius wrote:
> > >
> > > If we wanted to be serious about this, it would be nice for someone to
> > > set up a maximal build chroot: something with as many packages installed
On 12/02/11 at 15:29 -0600, Raphael Geissert wrote:
> Lars Wirzenius wrote:
> >
> > If we wanted to be serious about this, it would be nice for someone to
> > set up a maximal build chroot: something with as many packages installed
> > as possible. Then do test builds of all packages, and report p
On Sat, 2011-02-12 at 15:12 +0100, Jarek Kamiński wrote:
> Na grupie linux.debian.devel napisałe(a)ś:
> > Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest
> > type that are going to run stock Debian are chroots on n900, which, with
> > 256MB, can handle all the phony stuff
On Sat, Feb 12, 2011 at 08:57:12PM +, Roger Leigh wrote:
> If we have a guaranteed clean build environment + package build deps,
> we have as complete consistency as is practicable.
>
> If we have a random build environment + package build deps, we might
> occasionally find something that need
Roger Leigh wrote:
> The other side to this is that fixing such bugs gains us very litle.
>
> If we have a guaranteed clean build environment + package build deps,
> we have as complete consistency as is practicable.
>
> If we have a random build environment + package build deps, we might
> occasi
Lars Wirzenius wrote:
>
> If we wanted to be serious about this, it would be nice for someone to
> set up a maximal build chroot: something with as many packages installed
> as possible. Then do test builds of all packages, and report problems.
> (Then upgrade the chroot, install as many new packa
On Sat, Feb 12, 2011 at 07:37:55PM +, Lars Wirzenius wrote:
> On la, 2011-02-12 at 20:22 +0100, Bernhard R. Link wrote:
> > If the packages used are only ever built in unnatural virgin
> > environments, there is basically no testing if building them on
> > a real user machine works. And things
]] Lars Wirzenius
| If we wanted to be serious about this, it would be nice for someone to
| set up a maximal build chroot: something with as many packages installed
| as possible. Then do test builds of all packages, and report problems.
| (Then upgrade the chroot, install as many new packages a
On la, 2011-02-12 at 20:22 +0100, Bernhard R. Link wrote:
> If the packages used are only ever built in unnatural virgin
> environments, there is basically no testing if building them on
> a real user machine works. And things not tested usually just stop
> working after some time...
Right now, su
* Don Armstrong [110211 23:01]:
> 3) uniform, known build environments
I think is a major disadvantage of this suggestion.
Free Software is about being able to modify what you run. The day a user
can no longer simply do a
apt-get build-dep name
apt-get source name
dpkg-so
Adam Borowski wrote:
> Trying to run unmodified Debian on 64MB is a suicide
The NSLU2 is still a supported platform, it runs in 32 mb. More or less
happily IME.
> Thus, I think there are no problems with enabling XZ on all architectures.
I see little benefit to enabling it on arm. Size of arm CD
On Sat, Feb 12, 2011 at 10:17:59PM +0800, Paul Wise wrote:
> On Sat, Feb 12, 2011 at 9:57 PM, Adam Borowski wrote:
>
> > On ARM, it's 90MB, I guess MIPS should be similar.
> > The man page says 65MB even in -9, but I guess they didn't count in the
> > code, libc, buffers and the likes.
> >
> My O
Hi!
On Sat, 2011-02-12 at 13:15:47 +, Philipp Kern wrote:
> On 2011-02-11, Hideki Yamane wrote:
> > On Fri, 4 Feb 2011 08:20:02 +0100
> > Raphael Hertzog wrote:
> >> I have not seen any word about XZ support.
> >> When you deployed support for new source package formats, you forbid
> >> lzma
Hi!
On Fri, 2011-02-11 at 11:33:10 +0800, Paul Wise wrote:
> On Fri, Feb 11, 2011 at 5:58 AM, Ben Hutchings wrote:
> > Since there is no support for auto-building arch-independent binaries
>
> I would hope that throwing away developer built debs would also apply
> to arch-independent packages, I
On Sat, 12 Feb 2011, Philipp Kern wrote:
> Do we have an idea how much more memory xz needs for decompression? I guess
> it wouldn't be feasible to switch dpkg's default on package builds on those
> architectures where we assume some more beefyness?
It depends on what compression level we use, th
Na grupie linux.debian.devel napisałe(a)ś:
> Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest
> type that are going to run stock Debian are chroots on n900, which, with
> 256MB, can handle all the phony stuff together with decompression just fine.
> If you allow for everyth
On Sat, Feb 12, 2011 at 3:06 PM, Andrey Rahmatullin wrote:
>> 128MB would work reasonably.
> I think that VPS'es with 128Mb RAM are still sold, not to mention existing
> installations.
May enable it on x64 first (those 128 mb VPSs are unlikely to run x64)
and then see about other archs later.
--
On Sat, Feb 12, 2011 at 9:57 PM, Adam Borowski wrote:
> On ARM, it's 90MB, I guess MIPS should be similar.
> The man page says 65MB even in -9, but I guess they didn't count in the
> code, libc, buffers and the likes.
>
> Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest
>
On Sat, Feb 12, 2011 at 02:57:59PM +0100, Adam Borowski wrote:
> Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest
> type that are going to run stock Debian are chroots on n900, which, with
> 256MB, can handle all the phony stuff together with decompression just fine.
> If y
On Sat, Feb 12, 2011 at 01:15:47PM +, Philipp Kern wrote:
> On 2011-02-11, Hideki Yamane wrote:
> > On Fri, 4 Feb 2011 08:20:02 +0100
> > Raphael Hertzog wrote:
> >> I have not seen any word about XZ support.
> > I want XZ support too, at least it reduce size for some font packages.
> > e.
On 2011-02-11, Hideki Yamane wrote:
> On Fri, 4 Feb 2011 08:20:02 +0100
> Raphael Hertzog wrote:
>> I have not seen any word about XZ support.
>> When you deployed support for new source package formats, you forbid
>> lzma because xz was coming along and you mentioned that wheezy could have
>> x
On Fri, 4 Feb 2011 08:20:02 +0100
Raphael Hertzog wrote:
> I have not seen any word about XZ support.
>
> When you deployed support for new source package formats, you forbid
> lzma because xz was coming along and you mentioned that wheezy could have
> xz enabled.
>
> I would like to see xz all
On Thu, 03 Feb 2011, Joerg Jaspert wrote:
> * Throwaway DD built .debs (well, let's have the fight^Wdiscussion)
This would allow
1) distribution-wide compilation options (for solving things like #552688)
2) distribution-wide debbuging debs
3) uniform, known build environments
the only major co
On Thu, 10, Feb, 2011 at 09:27:14PM +0100, Josselin Mouette spoke thus..
> Le jeudi 03 février 2011 à 22:05 +0100, Joerg Jaspert a écrit :
> > Attached below is a tentative agenda. This is an unsorted list and we
> > might not get to every point. We might also have missed any number of
> > points,
On Thu, 10, Feb, 2011 at 09:43:08PM +0100, Sandro Tosi spoke thus..
> On Thu, Feb 3, 2011 at 22:05, Joerg Jaspert wrote:
> > * Throwaway DD built .debs (well, let's have the fight^Wdiscussion)
>
> could you please keep in mind the bandwidth impaired and try something
> that avoids to upload those
On Fri, Feb 11, 2011 at 5:58 AM, Ben Hutchings wrote:
> Since there is no support for auto-building arch-independent binaries
I would hope that throwing away developer built debs would also apply
to arch-independent packages, IIRC that was part of the proposal.
There was talk of a Build-Architec
On Thu, Feb 10, 2011 at 09:58:57PM +, Ben Hutchings wrote:
> On Thu, 2011-02-10 at 21:43 +0100, Sandro Tosi wrote:
> > On Thu, Feb 3, 2011 at 22:05, Joerg Jaspert wrote:
> > > * Throwaway DD built .debs (well, let's have the fight^Wdiscussion)
> >
> > could you please keep in mind the bandwid
On Thu, 2011-02-10 at 21:43 +0100, Sandro Tosi wrote:
> On Thu, Feb 3, 2011 at 22:05, Joerg Jaspert wrote:
> > * Throwaway DD built .debs (well, let's have the fight^Wdiscussion)
>
> could you please keep in mind the bandwidth impaired and try something
> that avoids to upload those binary packag
On Thu, Feb 3, 2011 at 22:05, Joerg Jaspert wrote:
> * Throwaway DD built .debs (well, let's have the fight^Wdiscussion)
could you please keep in mind the bandwidth impaired and try something
that avoids to upload those binary packages in the first place? but
also something that avoids the risk o
Le jeudi 03 février 2011 à 22:05 +0100, Joerg Jaspert a écrit :
> Attached below is a tentative agenda. This is an unsorted list and we
> might not get to every point. We might also have missed any number of
> points, if so feel free to tell us about them.
Would it be possible to add support for d
On Feb 07, Svante Signell wrote:
> Now, with support for VMs like qemu, xen
> and virtualbox, more people are showing interest in GNU/Hurd.
[citation needed]
--
ciao,
Marco
signature.asc
Description: Digital signature
On 2011-02-03, Joerg Jaspert wrote:
> * get rid of hurd (or discuss this)
Why? GNU/Hurd has made vast improvements during last year. Even the
Debian installer is functional. Now, with support for VMs like qemu, xen
and virtualbox, more people are showing interest in GNU/Hurd.
--
To UNSUBSCRIB
On 2011-02-04 07:27, Philipp Kern wrote:
> On 2011-02-03, Joerg Jaspert wrote:
> > * Leaf packages. that is, the possibility of having small packages in
> > the archive, without bloating the packages files as a "full package"
> > would. Somehow, less information stored for them. Like only "Pac
Philipp Kern writes:
> On 2011-02-03, Joerg Jaspert wrote:
>> * Leaf packages. that is, the possibility of having small packages in
>> the archive, without bloating the packages files as a "full package"
>> would. Somehow, less information stored for them. Like only "Package",
>> "Installe
On 2011-02-03, Joerg Jaspert wrote:
> * Leaf packages. that is, the possibility of having small packages in
> the archive, without bloating the packages files as a "full package"
> would. Somehow, less information stored for them. Like only "Package",
> "Installed-Size", "Version", "FileName
Hi,
On Thu, 03 Feb 2011, Joerg Jaspert wrote:
> Attached below is a tentative agenda. This is an unsorted list and we
> might not get to every point. We might also have missed any number of
> points, if so feel free to tell us about them.
I have not seen any word about XZ support.
When you deplo
Hello world,
i just want to take the opportunity that everyone is watching the final
preparations for Squeeze to announce our next FTPMaster meeting. Your
beloved team of FTPMasters will meet from the 21st til 27th of March in
the LinuxHotel in Essen. During the weekend one of the wanna-build
admi
96 matches
Mail list logo
