* 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
* Niels Thykier (ni...@thykier.net) [131215 12:36]:
> In practise, it has not worked out so well. In my experience, many
> of the Wheezy release goals became "second-rate" goals - we simply
> failed to follow up on those goals as we promised, we would. To me,
> release goals became "that outsta
Hi,
* John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de) [140118 18:26]:
> Unfortunately, this package currently fails to build on the buildds
> while it builds fine when building in a pbuilder environment [1].
Did you try to build it with dpkg-buildpackage -B (i.e. not building
binary-all-
* Adam D. Barratt (a...@adam-barratt.org.uk) [140126 22:03]:
> On Sun, 2014-01-26 at 21:13 +0100, Karsten Merker wrote:
> > Most older documentation states something like "if
> > things are unclear, just log in and take a look at the official
> > Debian wanna-build installation", but that is of cou
* Stephen Powell (zlinux...@wowway.com) [140329 15:05]:
> On Sat, 29 Mar 2014 01:34:27 -0400 (EDT), Andrei POPESCU wrote:
> >
> > Or connman.
>
> Frankly, I think that the claim that ifupdown is dysfunctional is an
> exaggeration at
> best and untrue at worst. I am not claiming that it is bug f
* Dimitri John Ledkov (x...@debian.org) [140429 23:34]:
> On 29 April 2014 21:02, Thomas Koch wrote:
> > On Tuesday, April 29, 2014 02:26:49 AM Scott Kitterman wrote:
> >> Recently there have been a number of questions about source requirements
> >> for the Debian archive. The FTP master view of
* Stephen Powell (zlinux...@wowway.com) [100523 21:21]:
> On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote:
> > After some discussion about lilo on #debian-devel in IRC, it has pretty
> > much been determined that kernel sizes have crossed the line past where
> > lilo can reliably de
* Adam Borowski (kilob...@angband.pl) [100905 11:04]:
> It's a massive script, so the file count of 1 doesn't really matter. Also,
> it needs to update more often than wine proper, as it refers to outside
> locations.
>
> I'd vote for having it as a separate package.
It'd rather make sense to cr
* Chris Carr (ranting...@gmail.com) [100907 10:20]:
> Are we in danger of making the best the enemy of the good? Packaging
> winetricks as-is would be helpful: making it a part of the packaging system,
> keeping it up-to-date, maybe adding a man page.
>
> Massive integration of distributable libr
* Stephen Kitt (st...@sk2.org) [100907 23:27]:
> I agree, I don't think it would be appropriate to try to package the
> DFSG-free Windows software installable via winetricks (such as 7-zip); in any
> case, packaging winetricks needn't involve shipping random free software for
> Windows inside Debia
* 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
* Florian Weimer (f...@deneb.enyo.de) [111002 21:59]:
> Couldn't we get rid of static libraries altogether, replacing static
> linking with ahead-of-time dynamic linking?
Could you explain what this means for people not so deep into that?
(E.g. how is the linking done? When? What does that mean fo
* Neil Williams (codeh...@debian.org) [111015 22:23]:
> The problem with "Standard" is that it is currently (and heavily) biased
> towards multi-user servers and most of the replies in this thread which
> decry the absence of an MTA would appear to come from those principally
> concerned with serve
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
>
601 - 669 of 669 matches
Mail list logo
