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 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 depend
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-compatible and
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.org
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 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 for
On Tue, Feb 15, 2011 at 6:04 PM, Mark Hymers m...@debian.org 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
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 are
On 2011-02-13, Tollef Fog Heen tfh...@err.no 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
On 2011-02-13, Felipe Sateler fsate...@debian.org 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.
On 2011-02-14, Raphael Geissert geiss...@debian.org 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
On 14/02/11 at 12:13 +, Philipp Kern wrote:
On 2011-02-13, Tollef Fog Heen tfh...@err.no 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,
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
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 directory
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 b...@decadent.org.uk wrote:
Since there is no support for auto-building arch-independent binaries
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
On 2011-02-14, Luk Claes l...@debian.org 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 b...@decadent.org.uk
wrote:
Since there is no
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
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 found raw
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 to
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 2011-02-15, Steve Langasek vor...@debian.org 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
On Tue, Feb 15, 2011 at 06:15:35AM +, Philipp Kern wrote:
On 2011-02-15, Steve Langasek vor...@debian.org 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
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 them
On 2011-02-15, Steve Langasek vor...@debian.org 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
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
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
as
* Roger Leigh rle...@codelibre.net [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
On Sun, Feb 13, 2011 at 12:42:57PM +0100, Bernhard R. Link wrote:
* Roger Leigh rle...@codelibre.net [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
* Lars Wirzenius l...@liw.fi [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
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
On Sun, Feb 13, 2011 at 12:42:57PM +0100, Bernhard R. Link wrote:
* Roger Leigh rle...@codelibre.net [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
* Holger Levsen hol...@layer-acht.org [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
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 just
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
On Sun, Feb 13, 2011 at 03:23:30PM +0100, Bernhard R. Link wrote:
* Holger Levsen hol...@layer-acht.org [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.
On Sun, Feb 13, 2011 at 12:58 PM, Roger Leigh rle...@codelibre.net 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
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 popcon?
On Sat, Feb 12, 2011 at 08:22:39PM +0100, Bernhard R. Link wrote:
* Don Armstrong d...@debian.org [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
On 02/10/2011 09:43 PM, Sandro Tosi wrote:
On Thu, Feb 3, 2011 at 22:05, Joerg Jaspert jo...@ganneff.de 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
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 broken
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...
That's
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
brian m. carlson sand...@crustytoothpaste.net (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 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 don't want
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 d...@debian.org [110211 23:01]:
3) uniform, known build environments
I think is a major disadvantage of this suggestion.
I'm unconvinced
On 02/07/2011 12:10 AM, Svante Signell wrote:
On 2011-02-03, Joerg Jaspertjo...@ganneff.de 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,
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 Jaspertjo...@ganneff.de wrote:
* get rid of hurd (or discuss this)
Why? GNU/Hurd has made vast improvements during last year. Even the
Debian installer is
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 Jaspertjo...@ganneff.de wrote:
* get rid of hurd (or discuss this)
Why? GNU/Hurd has made vast
On 2011-02-13, Lars Wirzenius l...@liw.fi 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
and
]] 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
Adam Borowski kilob...@angband.pl 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
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
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.
On 2011-02-13, Tollef Fog Heen tfh...@err.no 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
]] 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
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 database it
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're not
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 directory
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 b...@decadent.org.uk wrote:
Since there is no support for auto-building arch-independent binaries
I would hope that throwing away
On 2011-02-11, Hideki Yamane henr...@debian.or.jp wrote:
On Fri, 4 Feb 2011 08:20:02 +0100
Raphael Hertzog hert...@debian.org 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
On Sat, Feb 12, 2011 at 01:15:47PM +, Philipp Kern wrote:
On 2011-02-11, Hideki Yamane henr...@debian.or.jp wrote:
On Fri, 4 Feb 2011 08:20:02 +0100
Raphael Hertzog hert...@debian.org wrote:
I have not seen any word about XZ support.
I want XZ support too, at least it reduce size
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 you
On Sat, Feb 12, 2011 at 9:57 PM, Adam Borowski kilob...@angband.pl 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
On Sat, Feb 12, 2011 at 3:06 PM, Andrey Rahmatullin w...@wrar.name 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
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 everything
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, this
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 b...@decadent.org.uk 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
Hi!
On Sat, 2011-02-12 at 13:15:47 +, Philipp Kern wrote:
On 2011-02-11, Hideki Yamane henr...@debian.or.jp wrote:
On Fri, 4 Feb 2011 08:20:02 +0100
Raphael Hertzog hert...@debian.org wrote:
I have not seen any word about XZ support.
When you deployed support for new source package
On Sat, Feb 12, 2011 at 10:17:59PM +0800, Paul Wise wrote:
On Sat, Feb 12, 2011 at 9:57 PM, Adam Borowski kilob...@angband.pl 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
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 CDs
* Don Armstrong d...@debian.org [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
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, such
]] 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
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 not
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 packages
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
occasionally
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 needs a
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 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 problems.
On Thu, 10, Feb, 2011 at 09:43:08PM +0100, Sandro Tosi spoke thus..
On Thu, Feb 3, 2011 at 22:05, Joerg Jaspert jo...@ganneff.de 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
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, if so
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
On Fri, 4 Feb 2011 08:20:02 +0100
Raphael Hertzog hert...@debian.org 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
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
On Thu, Feb 3, 2011 at 22:05, Joerg Jaspert jo...@ganneff.de 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
On Thu, 2011-02-10 at 21:43 +0100, Sandro Tosi wrote:
On Thu, Feb 3, 2011 at 22:05, Joerg Jaspert jo...@ganneff.de 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 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 jo...@ganneff.de wrote:
* Throwaway DD built .debs (well, let's have the fight^Wdiscussion)
could you please keep in mind the
On Fri, Feb 11, 2011 at 5:58 AM, Ben Hutchings b...@decadent.org.uk 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
On Feb 07, Svante Signell svante.sign...@telia.com 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 jo...@ganneff.de 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.
Philipp Kern tr...@philkern.de writes:
On 2011-02-03, Joerg Jaspert jo...@ganneff.de 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
On 2011-02-04 07:27, Philipp Kern wrote:
On 2011-02-03, Joerg Jaspert jo...@ganneff.de 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
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
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
On 2011-02-03, Joerg Jaspert jo...@ganneff.de 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,
96 matches
Mail list logo
