* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110428 20:21]:
> Interestingly, you seem to be confused about RC bugs. ;)
Can you please stop the ad-hominem attacks? Thanks.
Andi
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
* Raphael Hertzog (hert...@debian.org) [110428 22:16]:
> On Thu, 28 Apr 2011, sean finney wrote:
> > On Thu, Apr 28, 2011 at 02:55:31PM +0200, Raphael Hertzog wrote:
> > > Good. I just want to point out that "frozen" built on top on rolling
> > > (which is what we're proposing here) is different fr
* Stefano Zacchiroli (z...@debian.org) [110429 14:22]:
> In general we need to promote the reduction of (potential) bottlenecks
> in Debian rather than the contrary. ... and don't get me wrong: I'm very
> well aware that this specific "bottleneck" is a very good feature to
> have for the preparatio
* Raphael Hertzog (hert...@debian.org) [110430 09:46]:
> > Who is going to install a "rolling" release instead of "testing"?
>
> If we change our documentation to say that rolling can be used by anyone
> who likes a constantly evolving distribution (and can live with the
> occasionnal hiccup) and
* Philipp Kern (tr...@philkern.de) [110430 09:49]:
> It's not that it isn't meant. Of course we could also look at overlay
> solutions. (That said, while I'm very happy about mozilla.debian.net, I
> somehow still feel that those packages should be added in a co-installable way
> into some officia
* Russ Allbery (r...@debian.org) [110430 09:54]:
> I think this is a fairly small portion of our developer base, and most
> developers do care about testing and pursue issues, particularly when
> informed of them by the excellent mail messages letting people know that
> packages haven't migrated as
* Stefano Zacchiroli (lea...@debian.org) [110430 12:56]:
> What we lack for that to become a reality is "just" the code. Marc and
> Tollef had set up a nice proposal [1] for GSoC this year and were
> willing to mentor it, but unfortunately no student has shown up. If
> there are people willing to c
* Mike Hommey (m...@glandium.org) [110430 12:16]:
> That being said, it would be really helpful to be able to get buildds
> to build the mozilla.d.n packages...
Would it work to build the packages in unstable? If so, why not
uploading them to experimental and re-branding them in mozilla.d.n?
And
* Mike Hommey (m...@glandium.org) [110430 13:28]:
> On Sat, Apr 30, 2011 at 01:06:57PM +0200, Andreas Barth wrote:
> > * Mike Hommey (m...@glandium.org) [110430 12:16]:
> > > That being said, it would be really helpful to be able to get buildds
> > > to bui
* Raphael Hertzog (hert...@debian.org) [110430 14:28]:
> On Sat, 30 Apr 2011, Andreas Barth wrote:
> > * Raphael Hertzog (hert...@debian.org) [110430 09:46]:
> > > > Who is going to install a "rolling" release instead of "testing"?
> > >
> &
* Arno Töll (deb...@toell.net) [110430 15:17]:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 30.04.2011 14:36, Andreas Barth wrote:
> > Feel free to use rolling.debian.net, set it up and have success. Like
> > aj did with setting up testing (after froz
* Arno Töll (deb...@toell.net) [110430 17:46]:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 30.04.2011 16:48, Andreas Barth wrote:
> > Actually, it worked quite well for both volatile and backports to
> > start as a non-official service. As well as building
* Mike Hommey (m...@glandium.org) [110430 17:57]:
> On Sat, Apr 30, 2011 at 02:18:06PM +0200, Andreas Barth wrote:
> > * Mike Hommey (m...@glandium.org) [110430 13:28]:
> > > On Sat, Apr 30, 2011 at 01:06:57PM +0200, Andreas Barth wrote:
> > > > * Mike Hommey (m.
* Raphael Hertzog (hert...@debian.org) [110430 20:51]:
> Hi Andreas,
>
> On Sat, 30 Apr 2011, Andreas Barth wrote:
> > Actually, it worked quite well for both volatile and backports to
> > start as a non-official service. As well as building packages in
> > non-free. An
Hi,
I have a problem I need to solve in perl within wanna-build:
Sometimes we have a few packages we don't want to build on a certain
buildds. Sometimes this is because this package needs lots of ram. Or
it takes quite long and would waste the parallel building a machine
supports. Or whatever els
* Pierre Habouzit (madco...@madism.org) [110501 01:32]:
> back a few versions. I couldn't care about testing any less. And at
> work, every person I know either uses just stable or does the same as
> me. I know no testing user around me. Of course I'm not pretending I
> know the absolute Truth, but
* Ingo Jürgensmann (i...@2011.bluespice.org) [110501 11:55]:
> On Sun, 1 May 2011 01:36:38 +0200, Andreas Barth wrote:
>> Now, what I would like to do is to write that down in a central file
>> with categories.
>
> I would recommend to use a database, really.
Sorry, but
* Raphael Hertzog (hert...@debian.org) [110501 08:41]:
> Fixing RC bugs in testing and getting new upstream versions that are
> ready in testing is not a burden for developers, it's what we're
> supposed to do to ensure we can release as quickly as possible.
Who is the "we" you are speaking about
* Roger Leigh (rle...@codelibre.net) [110501 12:02]:
> I just wanted to add that if you would like more statistics reporting
> for this purpose, I'll be happy to add that to sbuild.
I only worry about the ~20-40 packages that are currently sitting in
some no_auto_build on the buildds. Not more but
* Marc Haber (mh+debian-de...@zugschlus.de) [110501 14:16]:
> On Sat, 30 Apr 2011 16:48:24 +0200, Andreas Barth
> wrote:
> >Actually, it worked quite well for both volatile and backports to
> >start as a non-official service.
>
> Agreed for backports, violently disagree
* Roger Leigh (rle...@codelibre.net) [110501 15:08]:
> Even if the NSS situation changes, surely it's immediately obvious
> that a random library function should not tamper with the uid of a
> process as a side-effect? Unless the caller explicitly requested
> dropping of root privs, no library has
* Pierre Habouzit (madco...@madism.org) [110501 01:32]:
> - link that PPA stuff to the main repository in a way that "merging"
> PPA into unstable is just a matter of one single command, or a few.
>
> - make it easy for users to subscribe to PPAs, meaning you have to
> have some kind o
* Stefano Zacchiroli (z...@debian.org) [110501 16:12]:
> On Fri, Apr 29, 2011 at 06:05:35PM -0400, Joey Hess wrote:
> > > In the Squeeze release we have done better than before by calling for
> > > explicit upgrade testing (kudos to the Release Team!), but a specific
> > > plan of alpha/beta/... mi
* Ian Jackson (ijack...@chiark.greenend.org.uk) [110501 16:39]:
> Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> > On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > > I second your original proposal though, that packages must not delete
> > > system users th
* Stéphane Glondu (glo...@debian.org) [110501 17:00]:
> Le 01/05/2011 15:34, Andreas Barth a écrit :
> > 1. How to push from a vcs (git, svn, ...) to ppa? (This should be
> > coordinated with ftp-masters, so that the same method could be used
> > later on for uploading into
* Raphael Hertzog (hert...@debian.org) [110501 18:23]:
> On Sun, 01 May 2011, Andreas Barth wrote:
> > However, to get that done right for multiple software is not so easy.
> > But please prove me wrong - as soon as 2. is done, I'm happy to help
> > setting up autobuil
* Stéphane Glondu (glo...@debian.org) [110501 18:24]:
> Le 01/05/2011 17:16, Andreas Barth a écrit :
> > Well yes, but how many autobuilding suites should we add? 50? 100?
> > 200? How do we do key management so that we know that the autobuilder
> > build the packages that
* Roger Leigh (rle...@codelibre.net) [110501 18:46]:
> On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> > * Raphael Hertzog (hert...@debian.org) [110501 18:23]:
> > > On Sun, 01 May 2011, Andreas Barth wrote:
> > > How can we submit jobs to a buildd?
&g
* Roger Leigh (rle...@codelibre.net) [110501 19:04]:
> WRT the signing key, there would need to be some form of trust path
> or else the signature would be worthless. If packages are being
> uploaded to Debian infrastructure, and are under our control, can't
> we use a single signing key? We pres
* Jan Hauke Rahm (j...@debian.org) [110502 18:34]:
> On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> > * Raphael Hertzog (hert...@debian.org) [110501 18:23]:
> > > - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
> > > build-depe
* Joey Hess (jo...@debian.org) [110501 22:36]:
> The problem with the moving target is that it means that d-i betas begin
> to be broken as time goes on after their release, starting with the
> smallest boot images and moving up to the netinst images.
We could e.g. create an copy of testing at the
* Marc 'HE' Brockschmidt (h...@ftwca.de) [110502 09:12]:
> Pierre Habouzit writes:
> > - PPA should focus on:
> > * co-installability when endurable;
> > * documented and working rollback to unstable (IOW downgrading a
> > package to unstable when co-installability is not pos
* Jan Hauke Rahm (j...@debian.org) [110502 19:22]:
> On Mon, May 02, 2011 at 07:16:47PM +0200, Andreas Barth wrote:
> > > I guess I'm misunderstanding you here, so please help me out. If a
> > > package is being worked on in different PPAs regarding different
&
* Scott Kitterman (deb...@kitterman.com) [110502 19:32]:
> If one could do something like:
>
> wb gb libieee1284 mod-wsgi nflog-bindings zinnia . ia64 . !caballero
good idea. I'll consider how to do that.
Andi
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject o
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110503 11:47]:
> On 02/05/11 at 16:19 -0700, Russ Allbery wrote:
> > Lucas Nussbaum writes:
> >
> > > [ Note that my position is based on the assumption that we have a share
> > > of DDs interested in rolling similar to the share of DDs interested in
>
* René Mayorga (rmayo...@debian.org) [110503 22:52]:
> On Sat, Apr 30, 2011 at 12:56:15PM +0200, Stefano Zacchiroli wrote:
> > On Sat, Apr 30, 2011 at 12:07:24PM +0200, Andreas Barth wrote:
> > >
> > > I think it would make quite sense to get something like e.g. ppa
* Don Armstrong (d...@debian.org) [110607 04:25]:
> On Mon, 06 Jun 2011, Philipp Kern wrote:
> > I.e. I think we should still allow non-buildd binaries, e.g. for
> > those cases you mentioned.
>
> Non-buildd binaries should still be allowed, but they should be
> followed immediately by a binNMU. [
* Don Armstrong (d...@debian.org) [110607 18:11]:
> On Tue, 07 Jun 2011, Andreas Barth wrote:
> > * Don Armstrong (d...@debian.org) [110607 04:25]:
> > > On Mon, 06 Jun 2011, Philipp Kern wrote:
> > > > I.e. I think we should still allow non-buildd binaries, e.
* Russ Allbery (r...@debian.org) [110719 01:36]:
> Uoti Urpala writes:
> > I know I would personally be a lot happier with a Debian that supports
> > systemd functionality than with a Debian that can run on a BSD kernel.
>
> Well, while we're putting stakes in the ground, I suppose I'll hammer mi
* Joey Hess (jo...@debian.org) [110719 22:52]:
> Andreas Barth wrote:
> > The decision is already taken that Debian can run on BSD kernels. So
> > if someone wants to revert that decision, it'd need an GR. Not the
> > other way.
>
> That decision was made wit
* Simon McVittie (s...@debian.org) [110724 23:52]:
> On Sun, 24 Jul 2011 at 21:59:40 +0200, Wouter Verhelst wrote:
> > even init.d has a documented (and what's
> > more, actually *working*) implementation of not starting daemons at
> > boot. It's called 'remove the *** symlink'.
>
> If you rem
Hi,
During bootstraping a new architecture, there are sometimes ugly
build-dependency-loops (usually involving generating documentation
for the core build utilities means you need to have the architecture
already available; same with graphical tools). During DebConf, Wookey
had a talk which lead
* Eugene V. Lyubimkin (jac...@debian.org) [110813 14:58]:
> On 2011-08-13 13:28, Andreas Barth wrote:
> > Building with core Dependencies only
> >
> > If doing an build of the core functionality only, norecommends is
> > added to the environment DEB_BUILD_OPTIONS. This
* Colin Watson (cjwat...@debian.org) [110813 15:27]:
> On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote:
> > During bootstraping a new architecture, there are sometimes ugly
> > build-dependency-loops (usually involving generating documentation
> > for the core
* Joachim Breitner (nome...@debian.org) [110813 16:05]:
> Hi,
>
> just a minor note:
>
> Am Samstag, den 13.08.2011, 13:28 +0200 schrieb Andreas Barth:
> > To mark such packages and to be able to decide when to re-schedule the
> > build, all binary-packages get the ad
* Steve McIntyre (st...@einval.com) [110815 12:27]:
> Eugene V. Lyubimkin wrote:
> >Source: fbreader
> >Build-Depends-Core: debhelper (>= 7), libbz2-dev
> >Build-Depends-Qt3: libqt3-mt-dev
> >Build-Depends-Qt4: libqt4-dev
> >Build-Depends-Gtk2: libgtk2.0-dev
> I can see this turning into a large m
* Steve McIntyre (st...@einval.com) [110815 12:30]:
> Andreas Barth wrote:
> >Generic options are usually better IMHO, but well - YMMV.
>
> Often, yes. But also often at extra cost.
No doubt about that.
> Where is the added benefit
> here - i.e. what are the use cases?
* Carsten Hey (cars...@debian.org) [110815 13:36]:
> An optional "Build-Depends:" field per binary package as you described
> is essentially the same as the following, with the notable difference,
> that the below could appear as it is in the output of, i.e., apt-cache
> showsrc without requiring m
* Carsten Hey (cars...@debian.org) [110815 14:36]:
> * Andreas Barth [2011-08-15 13:46 +0200]:
> > * Carsten Hey (cars...@debian.org) [110815 13:36]:
> > > An optional "Build-Depends:" field per binary package as you described
> > > is essentially the sa
* Roger Leigh (rle...@codelibre.net) [110815 17:12]:
> Are these any other downsides we need to consider? One issue is the
> existence of badly broken programs³, which make stupid assumptions
> about lockfiles.
This will break all existing programms on an partial upgrades. There
are three ways to
* Joey Hess (jo...@debian.org) [110815 18:32]:
> Andreas Barth wrote:
> > Also, the binary packages in the debian/control template could have
> > Build-Depends specified which means that they should only be built if
> > those packages are actually installed (so we could do a
* Lars Wirzenius (l...@liw.fi) [110815 19:36]:
> 584163 134 file sizes (MiB)
Thanks for comparing these numbers. That tells me that at least in the
average case we just can continue with gz, and not care much about the
relativly small difference to xz.
Andi
--
To UNSUBSCRIBE,
* Lars Wirzenius (l...@liw.fi) [110815 23:27]:
> On Mon, Aug 15, 2011 at 11:04:51PM +0200, Carsten Hey wrote:
> > * Lars Wirzenius [2011-08-15 18:33 +0100]:
> > > raw gz xz
> > > 584163 134 file sizes (MiB)
> > >0421 450 savings compared to raw (Mi
* Henrique de Moraes Holschuh (h...@debian.org) [110820 14:39]:
> Yes. And we can easily maintain a current one for Debian-packaged software,
> although the initial build of such a blacklist will take some work.
Actually, the existing interface net.ipv4.ip_local_port_range seems to
work quite wel
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 08:59]:
> I'd like to reinforce the fact that it's the porters' responsibility
> to investigate porters issues, and propose the following
> responsibilities:
> (1) It is the responsibility of porters to:
> - track architecture-specific bugs (
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 13:10]:
> If you take a list of packages that failed on $PORTER_ARCH, but built
> fine on at least two or three other architectures, do you really expect
> to get many false positives (i.e, non-arch-specific problems)?
If we have methods which pr
* Russ Allbery (r...@debian.org) [110829 20:42]:
> Samuel Thibault writes:
> > Lucas Nussbaum, le Mon 29 Aug 2011 16:49:17 +0200, a écrit :
>
> >> Those packages should be set Not-For-Us anyway, no? So they still need
> >> an action from porters or buildd maintainers.
>
> > We want to avoid Not-
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 10:56]:
> Also, in the case of architectures targetted at embedded systems (I'm
> thinking about mips and mipsel), what is important is that Debian
> infrastructure supports the development of those architectures, but I
> don't think that there's
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 07:34]:
> Regarding architectures, we made releases with a semi-official status on
> two occasions at least (etch-m68k and kfreebsd in squeeze).
I hope you see the difference between etch-m68k and kbsd.
Kbsd is "too new", whereas etch-m68k was (
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 12:07]:
> On 31/08/11 at 11:40 +0200, Andreas Barth wrote:
> > * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 07:34]:
> > > Being in the second set would be fine, and would not be a step towards
> > > being thrown
* Joerg Jaspert (jo...@debian.org) [110903 12:44]:
>
> > Yeah, yeah. We've beaten that horse to death, and our side lost. I also
> > advocate that all debs should be signed, but that was not the will of the
> > ftp-masters the last time the issue was up for discussion.
>
> Thats wrong.
> Since
* Stefano Zacchiroli (z...@debian.org) [110908 19:22]:
> I think maintainers should be empowered more to fiddle with the
> Architecture list of their packages, but also that they should give
> some sort of explanation (as simple as bug report pointers) for the
> architectures they do not su
* Stefano Zacchiroli (z...@debian.org) [110908 19:53]:
> On Thu, Sep 08, 2011 at 07:34:41PM +0200, Andreas Barth wrote:
> > Yes. Because one of the most frequent users is the security team
> > asking where this and that security build is. We don't want that
> >
* Kurt Roeckx (k...@roeckx.be) [110910 15:38]:
> We changed this some time ago and made $arch readable by anybody,
> the mbox's are at:
> buildd.debian.org:/org/buildd.debian.org/mbox/
>
> We've ask the security team to use wb-t...@buildd.debian.org
> instead, which is not public available.
Ok wi
Hi together,
minutes from the "32bit architectures in Debian" bof right now.
Andi
32bit architectures in Debian
- 32bit architectures are not going away for the forseeable
- Compiling/Linking is the memory-using issue
- We need a way to compile/link with more memory
Proposal A:
- Use "cross-c
* Florian Weimer (f...@deneb.enyo.de) [150823 17:02]:
> * Andreas Barth:
>
> > Specific issues:
> > - for i386, there is still sold new hardware with 32bit-only. Are
> > there open issues for i386 (apart from the 32bit-generic ones)?
>
> FWIW, for x32, the securit
* Russ Allbery (r...@debian.org) [150825 03:09]:
> Andreas Barth writes:
>
> > - for i386, there is still sold new hardware with 32bit-only. Are
> > there open issues for i386 (apart from the 32bit-generic ones)?
> > Discussion that we need to get rid of it o
* Helmut Grohne (hel...@subdivi.de) [150831 16:49]:
> On Thu, Aug 20, 2015 at 03:04:17PM +0200, Andreas Barth wrote:
> > minutes from the "32bit architectures in Debian" bof right now.
>
> It is my understanding that it was also agreed that mips and mipsel
>
er this as rude.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
601 - 669 of 669 matches
Mail list logo
