* Peter Samuelson
| [Tollef Fog Heen]
| > I just stumbled across one issue: it doesn't handle the case where
| > you change your encoding without checking out the repository again:
| >
| > : [EMAIL PROTECTED] ~/svn/trunk > LANG=en_US.UTF-8 svn st
| > svn: Valid UTF-8 data
| > (hex: 46)
| > follo
* Petter Reinholdtsen
| Add a block like this in the init.d script (example based on
| xdebconfigurator):
|
| ### BEGIN INIT INFO
| # Provides: xdebconfigurator
| # Required-Start:$syslog
| # Required-Stop: $syslog
| # Should-Start: $local_fs
| # Should-Stop:
On Tue, Aug 23, 2005 at 07:58:40PM +0200, Adrian von Bidder wrote:
> On Monday 22 August 2005 23.51, Steve Langasek wrote:
> > On Mon, Aug 22, 2005 at 06:22:11PM +, W. Borgert wrote:
> > > On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote:
> > > > really matters: can we (the De
* Manoj Srivastava [Mon, 22 Aug 2005 07:58:06 -0500]:
> The end goal is not just to have packages built on the
> buildd -- and important goal for Debian, certainly, but not the only
> one we have. As promoters of free software, we also are committed to
> have packages build for our user
Shaun Jackman <[EMAIL PROTECTED]> writes:
> What's wrong with this Build-Depends line?
> Build-Depends: ia32-libs-dev [amd64], debhelper (>= 4.1.16)
> E: eagle source: invalid-arch-string-in-source-relation amd64
> [build-depends: ia32-libs-dev [amd64]]
lintian bug #322291. There's nothing wron
On Mon, Aug 22, 2005 at 11:13:35AM +0200, Andreas Jochens wrote:
> On 05-Aug-21 03:58, Wouter Verhelst wrote:
> > - must have successfully compiled 98% of the archive's source (excluding
> > arch-specific packages)
> It is not possible to build 98% of the unmodified source packages from
> the '
* Sven Luther [Mon, 22 Aug 2005 23:17:10 +0200]:
> > Sven Luther dijo [Mon, Aug 22, 2005 at 12:52:06PM +0200]:
> > > the security level would still be higher using only official
> > > buildds and centraly controled.
> > > The only reason this does not happen is that the ftp-masters dislike the
Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
> What does UCI-only mean?
UCI is a protocol for communication between the engine and a user
interface. The other popular protocol is WinBoard.
> What sets it apart from other chess engines in Debian, such as gnuchess or
> phalanx? (Or crafty, for
also sprach Shaun Jackman <[EMAIL PROTECTED]> [2005.08.24.0125 +0200]:
> Can I upload the package regardless, or will it break the buildd?
You can upload regardless.
You may want to add lintian and linda overrides. Check the
/usr/share/doc info for lintian and the linda manpage for
information of
Le Mer 24 Août 2005 01:25, Shaun Jackman a écrit :
> 2005/8/23, martin f krafft <[EMAIL PROTECTED]>:
> > also sprach Shaun Jackman <[EMAIL PROTECTED]> [2005.08.24.0044
+0200]:
> > > What's wrong with this Build-Depends line?
> > >
> > > Build-Depends: ia32-libs-dev [amd64], debhelper (>= 4.1.16)
>
2005/8/23, martin f krafft <[EMAIL PROTECTED]>:
> also sprach Shaun Jackman <[EMAIL PROTECTED]> [2005.08.24.0044 +0200]:
> > What's wrong with this Build-Depends line?
> >
> > Build-Depends: ia32-libs-dev [amd64], debhelper (>= 4.1.16)
> >
> > E: eagle source: invalid-arch-string-in-source-relation
Andreas Barth <[EMAIL PROTECTED]> writes:
> * Russ Allbery ([EMAIL PROTECTED]) [050823 22:58]:
>> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>> > It is out of date since it does not explain ~ yet. Maybe, if you have
>> > the time and since you just looked at the matter closely anyway, you
>>
also sprach Shaun Jackman <[EMAIL PROTECTED]> [2005.08.24.0044 +0200]:
> What's wrong with this Build-Depends line?
>
> Build-Depends: ia32-libs-dev [amd64], debhelper (>= 4.1.16)
>
> E: eagle source: invalid-arch-string-in-source-relation amd64
> [build-depends: ia32-libs-dev [amd64]]
Lintian d
On Tue, Aug 23, 2005 at 09:54:20PM +0200, Goswin von Brederlow wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> > Then you'd have to keep the master chroot image up-to-date. If you don't
> > do that, after a while the master image will digress too much from the
> > actual Debian archive, and
What's wrong with this Build-Depends line?
Build-Depends: ia32-libs-dev [amd64], debhelper (>= 4.1.16)
E: eagle source: invalid-arch-string-in-source-relation amd64
[build-depends: ia32-libs-dev [amd64]]
Thanks,
Shaun
debhelper 4.9.5
lintian 1.23.11
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Roger Leigh <[EMAIL PROTECTED]> writes:
> I often do "debuild -us -uc -nc" outside the chroot till i get the
> package to build and then build just source and dump it into the local
> buildd to confi
also sprach Russ Allbery <[EMAIL PROTECTED]> [2005.08.23.2257 +0200]:
> I'm certainly willing to do so, but I thought that policy wasn't ready to
> change yet. Wasn't it waiting on implementation of that feature in dak,
> which is currently using ~ internally for something else?
Yes, APT and dpkg
* Russ Allbery ([EMAIL PROTECTED]) [050823 22:58]:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> > It is out of date since it does not explain ~ yet. Maybe, if you have
> > the time and since you just looked at the matter closely anyway, you
> > could draw up a few lines and send a patch?
>
* Goswin von Brederlow ([EMAIL PROTECTED]) [050823 22:24]:
> Doing a count yourself you can get >10% divergence from the buildd.d.o
> stats depending what you count exactly.
>
> So before any line should be drawn someone should define a correct
> counting method and generate at least a month worth
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> It is out of date since it does not explain ~ yet. Maybe, if you have
> the time and since you just looked at the matter closely anyway, you
> could draw up a few lines and send a patch?
I'm certainly willing to do so, but I thought that policy w
On Tuesday 23 August 2005 22:39, Olaf van der Spek wrote:
> On 8/23/05, Frans Pop <[EMAIL PROTECTED]> wrote:
> > On Tuesday 23 August 2005 10:20, W. Borgert wrote:
> > > I have checked in some files into svn.debian.org. The files are
> > > in UTF-8 encoding[1], but the web front-end seems to belie
Russ Allbery <[EMAIL PROTECTED]> writes:
> Thanks for the confirmation!
>
> martin f krafft <[EMAIL PROTECTED]> writes:
>> also sprach Russ Allbery <[EMAIL PROTECTED]> [2005.08.23.1908 +0200]:
>
>>> Is there a document anywhere outside of the dpkg source that explains
>>> the algorithm for how ver
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
>
>> [Thomas Bushnell]
>>> Quite the contrary; it seems to me that this is to work *passively*
>>> against something.
>>
>> Not doing the work is working passively against it, while prohibiting
>> oth
Bastian Blank <[EMAIL PROTECTED]> writes:
> On Tue, Aug 23, 2005 at 05:04:57PM +0100, Roger Leigh wrote:
>> Not a kernel feature, but see
>> http://packages.debian.org/unstable/admin/schroot
>
> Does not help, each chroot needs to be setup by root and you need root
> priviledges to install packa
On 8/23/05, Frans Pop <[EMAIL PROTECTED]> wrote:
> On Tuesday 23 August 2005 10:20, W. Borgert wrote:
> > I have checked in some files into svn.debian.org. The files are
> > in UTF-8 encoding[1], but the web front-end seems to believe in
> > ISO-8859-1. Did I do something wrong when checking in f
Roger Leigh <[EMAIL PROTECTED]> writes:
> "Joe Smith" <[EMAIL PROTECTED]> writes:
>
>> Actually perhaps software should be built outside of clean
>> chroots. Why? Because if there is a possibility that a dirty chroot
>> will cause the package to fail, there is a bug in some peice of
>> software.
"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes:
> On Tue, Aug 23, 2005 at 12:40:18AM -0400, Joe Smith wrote:
>> Actually perhaps software should be built outside of clean chroots. Why?
>> Because if there is a possibility that a dirty chroot will cause the package
>> to
>> fail, there is a bug
Em Ter, 2005-08-23 às 11:11 -0700, Steve Langasek escreveu:
> If you do that, how do you ensure that these two cases are both handled
> sanely?:
>
> - after installing the coldplug package, the admin purges the hotplug
> package, and later reinstalls it (removing coldplug)
> - after installing t
On 8/23/05, Marc Haber <[EMAIL PROTECTED]> wrote:
> On Tue, 23 Aug 2005 01:42:18 +0200, Martin Pitt <[EMAIL PROTECTED]>
> wrote:
> >Something like this is in fact considered. Probably Ubuntu won't use
> >pbuilder itself since it is not the most efficient implementation
> >around, but rebuilding the
On 8/23/05, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 23, 2005 at 09:14:28AM -0400, Stephen Frost wrote:
> > * Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> > > On Tue, Aug 23, 2005 at 09:32:33AM +0200, Martin Pitt wrote:
> > > > It doesn't really hurt us right now, so we didn't start
Nathanael Nerode <[EMAIL PROTECTED]> writes:
> Sven Luther wrote:
>> All packages should be built by official debian buildds anyway, not on
>> developper machines with random cruft and unsecure packages installed, or
> even
>> possibly experimental or home-modified stuff.
>
> Actually, it's bette
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Mon, Aug 22, 2005 at 06:59:52AM -0500, John Hasler wrote:
>> Andreas Jochens writes:
>> Wouter Verhelst wrote:
>> > - must have successfully compiled 98% of the archive's source (excluding
>> > arch-specific packages)
>
>> Andreas Jochens writes:
>
Em Ter, 2005-08-23 às 09:54 -0700, Thomas Bushnell BSG escreveu:
> Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
>
> > [Thomas Bushnell]
> >> Quite the contrary; it seems to me that this is to work *passively*
> >> against something.
> >
> > Not doing the work is working passively against it, wh
"Joe Smith" <[EMAIL PROTECTED]> writes:
> "Pierre Habouzit" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>Human error, or poluted chroot/compilation env is more likely to happen
>>on the developper machine than in a buildd. Maybe this has already been
Also for each upload we h
On Tue, Aug 23, 2005 at 01:52:22PM -0300, Humberto Massa Guimarães wrote:
> ** Bastian Blank ::
>> You have a linux kernel ready, which allows chroot as normal user?
>> Please share it with us.
> It's called QEMU :-)
Or pbuilder-uml, once someone gets onto the user-mode-linunx package
(and kernel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bastian Blank <[EMAIL PROTECTED]> writes:
> On Tue, Aug 23, 2005 at 05:04:57PM +0100, Roger Leigh wrote:
>> Not a kernel feature, but see
>> http://packages.debian.org/unstable/admin/schroot
>
> Does not help, each chroot needs to be setup by root a
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Tue, Aug 23, 2005 at 09:14:28AM -0400, Stephen Frost wrote:
>> source upload
>> fastest/preferred buildd type (i386, amd64, whatever) attempts build
>> --> Success
>> Other buildds attempt to build
>
> That would introduce some delay which, tho
Marc Haber <[EMAIL PROTECTED]> writes:
> On Tue, 23 Aug 2005 01:42:18 +0200, Martin Pitt <[EMAIL PROTECTED]>
> wrote:
>>Something like this is in fact considered. Probably Ubuntu won't use
>>pbuilder itself since it is not the most efficient implementation
>>around, but rebuilding the buildd chroo
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Tue, Aug 23, 2005 at 11:25:41AM +0200, Marc Haber wrote:
>> On Tue, 23 Aug 2005 01:42:18 +0200, Martin Pitt <[EMAIL PROTECTED]>
>> wrote:
>> >Something like this is in fact considered. Probably Ubuntu won't use
>> >pbuilder itself since it is not th
Peter 'p2' De Schrijver <[EMAIL PROTECTED]> writes:
> On Tue, Aug 23, 2005 at 11:25:41AM +0200, Marc Haber wrote:
>> On Tue, 23 Aug 2005 01:42:18 +0200, Martin Pitt <[EMAIL PROTECTED]>
>> wrote:
>> >Something like this is in fact considered. Probably Ubuntu won't use
>> >pbuilder itself since it i
Martin Pitt <[EMAIL PROTECTED]> writes:
> Hi Tomas!
>
> Tomas Fasth [2005-08-23 9:31 +0200]:
>> >>So you suggest throwing buildd out of the window and switching to
>> >>pbuilder, then?
>> >
>> >
>> > Something like this is in fact considered. Probably Ubuntu won't use
>> > pbuilder itself since i
Martin Pitt skrev:
> Hi Tomas!
>
> Tomas Fasth [2005-08-23 9:31 +0200]:
>
>>As a side note, I have myself thought about extending pbuilder using
>>unionfs and overlays to avoid the tarball extraction for each build.
>
>
> Indeed I referred to the overhead of tarball extraction and the like.
> unio
Martin Pitt <[EMAIL PROTECTED]> writes:
> Hi Wouter!
>
> Wouter Verhelst [2005-08-23 1:26 +0200]:
>> On Mon, Aug 22, 2005 at 04:08:37PM +0200, Martin Pitt wrote:
>> > Hamish Moffatt [2005-08-22 23:47 +1000]:
>> > > There is the possibility that developer builds get extra features
>> > > enabled d
On Tue, Aug 23, 2005 at 05:04:57PM +0100, Roger Leigh wrote:
> Not a kernel feature, but see
> http://packages.debian.org/unstable/admin/schroot
Does not help, each chroot needs to be setup by root and you need root
priviledges to install packages in it.
Bastian
--
Madness has no purpose. Or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
"Joe Smith" <[EMAIL PROTECTED]> writes:
> Actually perhaps software should be built outside of clean
> chroots. Why? Because if there is a possibility that a dirty chroot
> will cause the package to fail, there is a bug in some peice of
> software. I
On Aug 23, Ben Armstrong <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-08-23 at 19:50 +0200, Marco d'Itri wrote:
> > The init file does, but /etc/hotplug.d/default/default.hotplug does not.
> Why is this file a conffile? I didn't see any obviously configurable
Historical reasons? It does not really m
Wouter Verhelst wrote:
> "Vancouver" has gotten a very specific meaning in the Debian
> community: one of a visionary proposal[1] that received quite its
> share of flames from many Debian contributors, including
> myself. Since it appeared to many of us that the intentional result
> of this propos
Hello David,
* David Nusinow <[EMAIL PROTECTED]>, [2005-08-21 19:44 -0400]:
> On Sun, Aug 21, 2005 at 11:29:51PM +0200, Petter Reinholdtsen wrote:
> > [Wouter Verhelst]
> > >b) the three beforementioned teams could already refuse to
> > >support a port anyhow, simply by not doing the w
On Tue, 2005-08-23 at 19:50 +0200, Marco d'Itri wrote:
> The init file does, but /etc/hotplug.d/default/default.hotplug does not.
Why is this file a conffile? I didn't see any obviously configurable
parts in it. If it were either wholly be moved elsewhere (/sbin) or the
guts of it moved elsewher
On Monday 22 August 2005 23.51, Steve Langasek wrote:
> On Mon, Aug 22, 2005 at 06:22:11PM +, W. Borgert wrote:
> > On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote:
> > > really matters: can we (the Debian project) maintain the port? Thus
> > > I propose we only limit on the
On Aug 23, Ben Armstrong <[EMAIL PROTECTED]> wrote:
> So, a hotplug event could load and run code (which happen to be in conf
> files, and therefore cannot be diverted) in the old hotplug package.
> The problem you're facing, it seems, is that while code should be
> divertable, conf files aren't,
On Tue, Aug 23, 2005 at 02:09:48PM -0300, Gustavo Noronha Silva wrote:
> Em Seg, 2005-08-22 às 01:32 +0200, Marco d'Itri escreveu:
> > The (still not uploaded) coldplug package conflicts+depends+provides
> > hotplug. The issue is that since all the important parts of hotplug are
> > conffiles they
Package: wnpp
Severity: wishlist
Owner: Florian Ragwitz <[EMAIL PROTECTED]>
* Package name: libshell-posix-select-perl
Version : 0.05
Upstream Author : Timothy F. Maher <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~yumpy/Shell-POSIX-Select-0.05/
* License
Package: wnpp
Severity: wishlist
Owner: Florian Ragwitz <[EMAIL PROTECTED]>
* Package name: libsysadm-install-perl
Version : 0.20
Upstream Author : Mike Schilli <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~mschilli/Sysadm-Install/
* License : Perl (GPL/Ar
On Tuesday 23 August 2005 06.44, Joe Smith wrote:
> > By the way, i386 does not make the cut according to the vancouver
> > prospect due to the number of buildds required. So are we left with 0
> > archs in etch? :) That will certainly speed up the release.
>
> LOL.
>
> Release NOW! Release now, da
Thanks for the confirmation!
martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Russ Allbery <[EMAIL PROTECTED]> [2005.08.23.1908 +0200]:
>> Is there a document anywhere outside of the dpkg source that explains
>> the algorithm for how version numbers are ordered by the archive
>> software
Package: wnpp
Severity: wishlist
Owner: Florian Ragwitz <[EMAIL PROTECTED]>
* Package name: libswish-api-common-perl
Version : 0.03
Upstream Author : Mike Schilli <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~mschilli/SWISH-API-Common/
* License : Perl (GP
Package: wnpp
Severity: wishlist
Owner: Florian Ragwitz <[EMAIL PROTECTED]>
* Package name: libperldoc-search-perl
Version : 0.01
Upstream Author : Mike Schilli <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~mschilli/Perldoc-Search/
* License : Perl (GPL/Ar
On Tuesday, 23 August 2005 09:57, Marco d'Itri wrote:
> On Aug 23, Isaac Clerencia <[EMAIL PROTECTED]> wrote:
> > I've just tried it and it has worked really great, except it has not
> > loaded mousedev module. Everything else has worked, and it's incredible
> > fast (at
>
> It's supposed to, do yo
dpkg --compare-versions provides exactly the ordering that I want, namely
that 1.4rc1 < 1.4.0 so by omitting the final patch number in the RC
revision I can use the correct upstream version without using epochs or
strange-looking version numbers. However, since this is a bit of an edge
case, I wan
On Tue, Aug 23, 2005 at 07:26:25PM +0200, Wouter Verhelst wrote:
> On Tue, Aug 23, 2005 at 06:01:24PM +0200, Piotr Roszatycki wrote:
> > Use fakechroot. Yes, it is ugly hack, but it allows me to recompile the
^^^
> > packages without root privileges.
>
> We all use fakeroot. The quest
On Tue, Aug 23, 2005 at 06:01:24PM +0200, Piotr Roszatycki wrote:
> On Tuesday 23 of August 2005 17:28, Bastian Blank wrote:
> > On Tue, Aug 23, 2005 at 12:06:41PM -0300, Humberto Massa Guimarães wrote:
> > > I vehemently disagree. I think exactly the opposite: debbuild and/or
> > > dpkg-buildpacka
On Tue, 2005-08-23 at 19:15 +0200, Marco d'Itri wrote:
> Think "hotplug events loop".
So, a hotplug event could load and run code (which happen to be in conf
files, and therefore cannot be diverted) in the old hotplug package.
The problem you're facing, it seems, is that while code should be
diver
Em Seg, 2005-08-22 às 19:45 +0200, Adrian von Bidder escreveu:
> On Monday 22 August 2005 11.25, Peter 'p2' De Schrijver wrote:
>
> [ the 'must have a working installer' requirement ]
>
> > > > Trivial. debootstrap does that.
> > >
> > > Debootstrap is not an installer, in very much the same way
On Aug 23, Gustavo Noronha Silva <[EMAIL PROTECTED]> wrote:
> > The (still not uploaded) coldplug package conflicts+depends+provides
> > hotplug. The issue is that since all the important parts of hotplug are
> > conffiles they are not deleted when the package is removed, and this
> > is bad (as i
also sprach Russ Allbery <[EMAIL PROTECTED]> [2005.08.23.1908 +0200]:
> case, I wanted to double-check and be sure that dpkg --compare-versions is
> the canonical ordering for version numbers. I'm pretty sure it is, but
> better safe than sorry to check.
Yes.
> Is there a document anywhere outsi
Em Seg, 2005-08-22 às 01:32 +0200, Marco d'Itri escreveu:
> The (still not uploaded) coldplug package conflicts+depends+provides
> hotplug. The issue is that since all the important parts of hotplug are
> conffiles they are not deleted when the package is removed, and this
> is bad (as in "the syst
Olaf van der Spek <[EMAIL PROTECTED]> writes:
> On 8/23/05, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>> Roger Leigh <[EMAIL PROTECTED]> writes:
>>
>> > Andreas Jochens in particular did a lot of hard work in fixing most of
>> > the GCC 4.0 failures and regressions over the last year while p
Em Seg, 2005-08-22 às 00:34 +0300, Riku Voipio escreveu:
> jffs2 image, which is then flashed to a pile of devices. Walking
> through d-i every time would be very clumsy, so there is no use
> for a working installer for those systems.
There's no use for a full-blown stable release for such thing
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> [Thomas Bushnell]
>> Quite the contrary; it seems to me that this is to work *passively*
>> against something.
>
> Not doing the work is working passively against it, while prohibiting
> others from doing the work is working actively against it. I
** Bastian Blank ::
> You have a linux kernel ready, which allows chroot as normal user?
> Please share it with us.
It's called QEMU :-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Thomas Bushnell]
> Quite the contrary; it seems to me that this is to work *passively*
> against something.
Not doing the work is working passively against it, while prohibiting
others from doing the work is working actively against it. If you do
both, you are working actively against it.
--
Gustavo Noronha Silva <[EMAIL PROTECTED]> writes:
> The constitution also states that no developer can work actively against
> the implementation of such a decision made by the project[0]. Not doing
> the work and not letting anyone else do it would constitute 'working
> actively againt'.
Quite t
On Tuesday 23 of August 2005 17:28, Bastian Blank wrote:
> On Tue, Aug 23, 2005 at 12:06:41PM -0300, Humberto Massa Guimarães wrote:
> > I vehemently disagree. I think exactly the opposite: debbuild and/or
> > dpkg-buildpackage should *always* build a package inside a clean and
> > minimal chroot j
On Tue, Aug 23, 2005 at 05:28:22PM +0200, Bastian Blank wrote:
> On Tue, Aug 23, 2005 at 12:06:41PM -0300, Humberto Massa Guimarães wrote:
> > I vehemently disagree. I think exactly the opposite: debbuild and/or
> > dpkg-buildpackage should *always* build a package inside a clean and
> > minimal ch
"Pierre Habouzit" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Human error, or poluted chroot/compilation env is more likely to happen
on the developper machine than in a buildd. Maybe this has already been
discussed once, but I think that binary uploaded packages (except the
b
On Tue, Aug 23, 2005 at 11:29:10AM +0200, Frans Pop wrote:
> WebSVN does not know about the contents of files in the repository period.
> As it is just a frontend to svn, you cannot expect it to know about every
> weird file format and encoding around.
Subversion is encoding-clean, the frontend
On Tue, Aug 23, 2005 at 12:06:41PM -0300, Humberto Massa Guimarães wrote:
> I vehemently disagree. I think exactly the opposite: debbuild and/or
> dpkg-buildpackage should *always* build a package inside a clean and
> minimal chroot jail. This way, (1) every package will predictably
> build from (u
Thanks for all the good advice, I will be more descriptive with the "short"
and "long" description, as I see that this is really necessary.
And I will be more careful while using reportbug, because I don't want to
bother people with ""Fruit is ..., Fruit is ..., Fruit is..." -- sorry
Where I d
** Joe Smith ::
> Actually perhaps software should be built outside of clean chroots. Why?
> Because if there is a possibility that a dirty chroot will cause the package
> to fail, there is a bug in some peice of software. It could prevent a user
> from recompiling on his own system, which thusly
On Tue, Aug 23, 2005 at 12:40:18AM -0400, Joe Smith wrote:
> Actually perhaps software should be built outside of clean chroots. Why?
Do I need to have root on the debian developer machines? I currently use
that machines to build packages for architectures I don't own.
Bastian
--
The best dipl
Thomas Bushnell BSG dijo [Mon, Aug 22, 2005 at 10:02:18PM -0700]:
> > The OBSD crowd have reimplemented many important subsystems because
> > they do not consider GPL-like licenses to be free enough. Yes, also
> > because of technical reasons, but in this case it seems to be about
> > (their versio
On Tue, Aug 23, 2005 at 12:14:33PM +, Gerrit Pape wrote:
> $ sed -ne '19,$p' The bincimap-run package provides the virtual package ``imap-server'' and
> conflicts with other packages providing ``imap-server''. This ensures that
> bincimap is the only service that listens on the address 0.0.0.
On Tue, Aug 23, 2005 at 02:49:34PM +0200, Oliver Korff wrote:
> * URL : http://wbec-ridderkerk.nl/
This URL does not mention anything about “fruit” at all; it seems to be a
chess tournament for computers or something along those lines.
> Description : Fruit is an UCI-only chess
* Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> On Tue, Aug 23, 2005 at 09:14:28AM -0400, Stephen Frost wrote:
> > Sure we do, for certain ports (ie: amd64). Really, this just means it'd
> > be better to implement a system along the lines of:
> >
> > source upload
> > fastest/preferred buildd type
On Tue, Aug 23, 2005 at 09:14:28AM -0400, Stephen Frost wrote:
> * Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> > On Tue, Aug 23, 2005 at 09:32:33AM +0200, Martin Pitt wrote:
> > > It doesn't really hurt us right now, so we didn't start to force
> > > building packages in pbuilder. buildd time is c
Hi,
* Oliver Korff [Tue, Aug 23, 2005 at 02:49:34PM +0200]:
> Package: wnpp
> Severity: wishlist
> Owner: Oliver Korff <[EMAIL PROTECTED]>
>
>
> * Package name: fruit
> Version : 2.1
> Upstream Author : Fabien Letouzey
> * URL : http://wbec-ridderkerk.nl/
> * Licens
On Tue, 2005-08-23 at 14:49 +0200, Oliver Korff wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Oliver Korff <[EMAIL PROTECTED]>
>
>
> * Package name: fruit
> Version : 2.1
> Upstream Author : Fabien Letouzey
> * URL : http://wbec-ridderkerk.nl/
> * License
Package: wnpp
Severity: wishlist
Owner: Oliver Korff <[EMAIL PROTECTED]>
* Package name: fruit
Version : 2.1
Upstream Author : Fabien Letouzey
* URL : http://wbec-ridderkerk.nl/
* License : (GPL)
Description : Fruit is an UCI-only chess engine.
Descrip
* Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> On Tue, Aug 23, 2005 at 09:32:33AM +0200, Martin Pitt wrote:
> > It doesn't really hurt us right now, so we didn't start to force
> > building packages in pbuilder. buildd time is cheap compared to
> > developer time, so introducing mandatory pbuilding
Sorry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
also sprach Tomas Davidek <[EMAIL PROTECTED]> [2005.08.23.1401 +0200]:
> I am trying to set up a tool for easy update of several computers in
> our institute. For example, I would like to create a package that
> updates several config files, e.g. /etc/apt/sources.list etc.
> What is the best way
Hello Tomas,
this question should better go to [EMAIL PROTECTED]
Quoting Tomas Davidek <[EMAIL PROTECTED]>:
> I am trying to set up a tool for easy update of several computers in
> our institute. For example, I would like to create a package that
> updates several config files, e.g. /etc/apt/so
On Tue, August 23, 2005 14:14, Gerrit Pape wrote:
> $ sed -ne '19,$p' The bincimap-run package provides the virtual package ``imap-server'' and
> conflicts with other packages providing ``imap-server''. This ensures
> that
> bincimap is the only service that listens on the address 0.0.0.0:993 on
Joe Smith writes:
> Actually perhaps software should be built outside of clean chroots. Why?
> Because if there is a possibility that a dirty chroot will cause the
> package to fail, there is a bug in some peice of software.
The probability that the developer has the particular package that will
c
Hi Joey,
Your response was very much what I needed to hear. I'll have to retract
most of my worries.
On Mon, Aug 22, 2005 at 07:20:07PM -0400, Joey Hess wrote:
> - A personal interest shared by me, tbm, and taggart is to get Debian
>working on the various types of cheap mips wireless access
On Tue, Aug 23, 2005 at 02:48:58AM -0700, Steve Langasek wrote:
> On Tue, Aug 23, 2005 at 11:21:00AM +0200, Wouter Verhelst wrote:
> > I'd much rather have seen that point go, but that didn't happen.
>
> Meaning you would have preferred that there not be a requirement of buildd
> redundancy, or yo
On Tue, Aug 23, 2005 at 12:32:15PM +0100, Edward wrote:
> Is it necessary for the following packages to "Conflict" with the
> virtual package "imap-server":
>
> bincimap-run
> courier-imap
> cyrus-imapd(*)
> cyrus21-imapd (*)
> dovecot-imapd
> mailutils-imap4d (*)
> uw
Em Seg, 2005-08-22 às 10:07 -0500, Manoj Srivastava escreveu:
> On Sun, 21 Aug 2005 23:29:51 +0200, Petter Reinholdtsen <[EMAIL PROTECTED]>
> said:
> The constitution states that no developer can have "democratic
> control" imposed on them at all. Indeed, I reject any such control
> ove
Hello,
I am trying to set up a tool for easy update of several computers in
our institute. For example, I would like to create a package that
updates several config files, e.g. /etc/apt/sources.list etc.
What is the best way of doing that ?
So far I think about an package that only contains a
1 - 100 of 133 matches
Mail list logo
