-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Suffield wrote:
On Sun, Aug 21, 2005 at 12:18:29AM -0400, Benjamin Seidenberg
wrote:
Many internet cafe's or kiosk computers (or school computers,
*sigh* though they're a lot better than they used to be) prevent
running executables from
On Sun, Aug 21, 2005 at 07:28:55PM +0200, Jonas Smedegaard wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 21-08-2005 03:58, Wouter Verhelst wrote:
We also came to the conclusion that some of the requirements proposed in
Vancouver would make sense as initial requirements --
On 8/21/05, Matthew Palmer [EMAIL PROTECTED] wrote:
I'm quite confident that there will be an upgrade path from Arch archives to
bzr archives. Canonical, amongst other people, have too much invested in
Arch to just let that history fester. As for hct, I understand it is a
wrapper frontend to
Processing commands for [EMAIL PROTECTED]:
unblock 322762 by 256226
Bug#322762: /usr/doc still exists (transition tracking bug)
Was blocked by: 189856 190020 203278 254800 254913 254924 254930 255590 256226
256250 302504 320084 320103 321926 322749 322769 322772 322775 322776 322778
322779
[Marcelo E. Magallon]
Isn't just:
wait
enough?
In this case, yes. In the general case, it is unknown if a background
process was forked off earlier in the script, so you want to control
which processes to wait for.
I suspect 'wait $pid || true' or similar is needed though, as the
[Martin F Krafft]
The place to discuss issues like this would be the initscripts-ng
project on alioth. There's a mailing list...
Good idea. I'll head over there. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Marco d'Itri]
I'm sure that a fair number of critical scripts (e.g. some dealing
with networking) are not.
Yeah, me too. I've seen incorrect init.d ordering several times. And
to be able to detect and fix incorrect boot order, we need to know
dependencies. I hope as many as possible will
Wouter,
Thank you for your work in preparing this; I think this summary is a
good beginning for revisiting the questions the Vancouver meeting poses
for etch.
On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote:
Vancouver has gotten a very specific meaning in the Debian community:
-- from debian manifesto:Debian Linux is a brand-new kind of Linux distribution. Rather than being developed by one isolated individual or group, as other distributions of Linux have been developed in the
past, Debian is being developed openly in the spirit of Linux and GNU.
* Riku Voipio ([EMAIL PROTECTED]) [050822 00:07]:
On Sun, Aug 21, 2005 at 10:54:43PM +0200, Andreas Barth wrote:
* Peter 'p2' De Schrijver ([EMAIL PROTECTED]) [050821 22:39]:
- must have a working, tested installer
Trivial. debootstrap does that.
How do you boot the system to
On Sun, Aug 21, 2005 at 11:28:00PM -0500, Peter Samuelson wrote:
[Andreas Barth]
machine translates with partition btw - though the two different
partitions should be in different physical locations, for obvious
reasons. Yes, we want a redundancy for good reasons.
[p2]
Which is
Scripsit Wouter Verhelst [EMAIL PROTECTED]
On Sun, Aug 21, 2005 at 05:31:34PM -0600, Bob Proulx wrote:
An example where an epoc would be needed would be if 0.7.3.3 was
uploaded as 7.3.3 instead. The epoc is designed to handle this
problem and allows 1:0.7.3.3 to be later than 7.3.3 to fix
Package: wnpp
Severity: wishlist
Owner: Vincent Danjean [EMAIL PROTECTED]
* Package name: commit-tool
Version : 0.2
Upstream Author : Fredrik Kuivinen [EMAIL PROTECTED]
* URL : http://www.cyd.liu.se/users/~freku045/gct/
* License : GPL
Description : GUI
On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote:
1. The requirement that 'an architecture must be publically available to
buy new'.
It was explained that this requirement was not made to be applied
retroactively to already existing ports; rather, it was designed to
Quoting Sven Luther [EMAIL PROTECTED]:
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.
That would be very good, indeed. I am very much in favour
Hi,
The reasonable foundation for having a redundant buildd in a separate
physical location is, I think, well-established. Any random facility
can lose power, perform big router upgrades, burn down, etc. Debian
machines also seem to be prone to bad RAM, bad power supplies, bad disk
arrays,
On Sun, Aug 21, 2005 at 11:24:48PM +0200, Peter 'p2' De Schrijver wrote:
Overall:
- must have successfully compiled 98% of the archive's source
(excluding arch-specific packages)
Useless requirement. Less then 98% of the archive may be useful for the
architecture
How do you boot to a system to run debian-installer when there is no
bios or bootloader on the system yet?
Just take a look at the existing Debian ports, and you see that it's ok
to use a bios that's part of the hardware.
Should debian-installer support
installing via JTAG? What
* Peter 'p2' De Schrijver ([EMAIL PROTECTED]) [050822 10:44]:
How do you boot to a system to run debian-installer when there is no
bios or bootloader on the system yet?
Just take a look at the existing Debian ports, and you see that it's ok
to use a bios that's part of the hardware.
On Aug 21, 2005 at 14:30, Pierre Habouzit praised the llamas by saying:
Package: wnpp
Severity: wishlist
Owner: Pierre Habouzit [EMAIL PROTECTED]
* Package name: ldapscripts
Version : 1.2
Upstream Author : Ganaël LAPLANCHE [EMAIL PROTECTED]
* URL :
Le Lun 22 Août 2005 10:29, Peter 'p2' De Schrijver a écrit :
Hi,
The reasonable foundation for having a redundant buildd in a
separate physical location is, I think, well-established. Any
random facility can lose power, perform big router upgrades, burn
down, etc. Debian machines also
Quoting Steve Langasek [EMAIL PROTECTED]:
code that's not portable, then I don't see any point at all in treating
these as release architectures to begin with, because at that point
they're *not* shipping the same OS that the other architectures are.
Agreed, however, I would see optional
On Sat, Aug 20, 2005 at 04:06:39PM -0400, Joe Smith wrote:
This package contains no data files. You will need to either install the
commercial data from the Quake II CD-ROM with the ``quake2-data'' package,
or install some free data files.
I'd suggest deriving a `quake3-data' from the
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 'unstable' distribution. This is true for any port including i386.
For the
On Mon, Aug 22, 2005 at 10:19:38AM +0200, Ingo Juergensmann wrote:
On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote:
1. The requirement that 'an architecture must be publically available to
buy new'.
It was explained that this requirement was not made to be applied
On Mon, Aug 22, 2005 at 11:05:59AM +0200, Pierre Habouzit wrote:
Le Lun 22 Août 2005 10:29, Peter 'p2' De Schrijver a écrit :
Hi,
The reasonable foundation for having a redundant buildd in a
separate physical location is, I think, well-established. Any
random facility can lose
On Mon, Aug 22, 2005 at 10:45:58AM +0200, W. Borgert wrote:
Quoting Sven Luther [EMAIL PROTECTED]:
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
On Sun, Aug 21, 2005 at 10:30:08PM +0200, Laszlo Boszormenyi wrote:
I do rebuild them and more on this that I download the .orig.tar.gz
for myself from the official upstream location and check the diff
ofcourse. This may sound paranoid, but this is me.
As a user, I certainly appreciate
* Andreas Jochens ([EMAIL PROTECTED]) [050822 11:36]:
I understand that the amd64 port has to be recompiled for the
final inclusion into the official archive because the current amd64
packages have not been built by DDs. But currently more than 10% of
the unmodified source packages from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22-08-2005 08:24, Sven Luther wrote:
On Sun, Aug 21, 2005 at 07:28:55PM +0200, Jonas Smedegaard wrote:
On 21-08-2005 03:58, Wouter Verhelst wrote:
We also came to the conclusion that some of the requirements proposed in
Vancouver would make
Trivial. debootstrap does that.
Debootstrap is not an installer, in very much the same way that tar
isn't, either.
They both are. They can install debian, so it's an installer.
- security team, DSA, and release team must not veto inclusion
Arbitrary veto power. This requirement
Quoting Wouter Verhelst [EMAIL PROTECTED]:
According to stories I've heard from people from Ubuntu (that does it
this way), it quite clearly isn't, because of the pretty high number of
people who upload packages without even testing the build themselves.
Of course, DDs will do better :-)
On Sun, Aug 21, 2005 at 10:16:53PM +0200, Peter 'p2' De Schrijver wrote:
- must be freely usable (without NDA)
- must be able to run a buildd 24/7 without crashing
- must have an actual, working buildd
- must include basic UNIX functionality
Whatever that may mean
That we don't want to
On 8/22/05, Steve Langasek [EMAIL PROTECTED] wrote:
In particular, we invariably run into arch-specific problems every time
a new version of a toolchain package is uploaded to unstable. Some may
remember that the new glibc/gcc blocked non-toolchain progress for
months during the beginning of
On Mon, Aug 22, 2005 at 10:19:38AM +0200, Ingo Juergensmann wrote:
3. The veto powers given to the DSA team, the Security team, and the
Release team, on a release of any given port.
Some of us feared for abuse of this veto power. All understood the
problems that exist if any
Sven Luther a écrit :
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.
What about packages built on developer machines, but using the same
On Mon, Aug 22, 2005 at 11:05:59AM +0200, Pierre Habouzit wrote:
Le Lun 22 Août 2005 10:29, Peter 'p2' De Schrijver a écrit :
This is still somewhat arch specific code as it assumes iopl and the
availability of an isa bus. I'm more thinking of packages which
require a lot of RAM to build
but well, I suppose the line is hard to draw.
Exactly, and that is why we don't try.
I agree with you that mozilla is probably fairly useless on m68k. But if
you start excluding packages, you'll fairly soon end up on a slipperly
slope where you start excluding packages, and in the end
On 05-Aug-22 11:48, Andreas Barth wrote:
* Andreas Jochens ([EMAIL PROTECTED]) [050822 11:36]:
I understand that the amd64 port has to be recompiled for the
final inclusion into the official archive because the current amd64
packages have not been built by DDs. But currently more than 10%
On Mon, Aug 22, 2005 at 12:09:00PM +0200, Peter 'p2' De Schrijver wrote:
but well, I suppose the line is hard to draw.
Exactly, and that is why we don't try.
I agree with you that mozilla is probably fairly useless on m68k. But if
you start excluding packages, you'll fairly soon end
On Mon, 22 Aug 2005, W. Borgert wrote:
Quoting Wouter Verhelst [EMAIL PROTECTED]:
According to stories I've heard from people from Ubuntu (that does it
this way), it quite clearly isn't, because of the pretty high number of
people who upload packages without even testing the build
On Mon, 22 Aug 2005, Petter Reinholdtsen wrote:
my packages. After all, it can not hurt to document expectations, and
the headers can be used by any implementation so it is not tied to a
given approach.
No, they cannot. But they are a good starting point, so go ahead.
If you want me to
On Mon, Aug 22, Wouter Verhelst wrote:
- binary packages must be built from unmodified Debian source
Uhm? When there is a new arch upcoming, they need to modifiy the Debian
source, at least sometimes, right?
Yes, and this happens. I've already had requests to modify my
Architecture:
On Mon, 22 Aug 2005 09:32:48 +0200, Petter Reinholdtsen
[EMAIL PROTECTED] wrote:
Yeah, me too. I've seen incorrect init.d ordering several times. And
to be able to detect and fix incorrect boot order, we need to know
dependencies. I hope as many as possible will add dependency
information using
* Andreas Jochens ([EMAIL PROTECTED]) [050822 12:56]:
On 05-Aug-22 11:48, Andreas Barth wrote:
* Andreas Jochens ([EMAIL PROTECTED]) [050822 11:36]:
I understand that the amd64 port has to be recompiled for the
final inclusion into the official archive because the current amd64
On Mon, Aug 22, 2005 at 11:51:55AM +0200, Aurelien Jarno wrote:
Sven Luther a écrit :
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.
What
On Mon, 22 Aug 2005 10:19:38 +0200, Ingo Juergensmann
[EMAIL PROTECTED] wrote:
On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote:
4. The requirement that any port has to have 5 developers support it,
and be able to demonstrate that there are (at least) 50 users.
How should this
On Mon, Aug 22, 2005 at 12:59:49PM +0200, Marc Haber wrote:
On Mon, 22 Aug 2005 09:32:48 +0200, Petter Reinholdtsen
[EMAIL PROTECTED] wrote:
Yeah, me too. I've seen incorrect init.d ordering several times. And
to be able to detect and fix incorrect boot order, we need to know
dependencies.
I don't agree with that interpretation of arch-specific, and neither
do the maintainers of the Packages-arch-specific list AFAICT, so please
stop trying to use creative interpretations of people's words to torpedo
the proposal that porters should be accountable for their ports.
I have no
* Olaf van der Spek ([EMAIL PROTECTED]) [050822 12:35]:
On 8/22/05, Steve Langasek [EMAIL PROTECTED] wrote:
In particular, we invariably run into arch-specific problems every time
a new version of a toolchain package is uploaded to unstable. Some may
remember that the new glibc/gcc blocked
Quoting Henrique de Moraes Holschuh [EMAIL PROTECTED]:
At doing stupid things, you mean :-( Our demographics do not allow
source-only uploads unfortunately.
I don't really get this sentence, could you please re-word?
(Sorry, I'm not a native speaker of English)
Which doesn't mean we can't
On Mon, August 22, 2005 10:45, W. Borgert wrote:
Fortunately, Martin Krafft came up with the idea of
allowing source-only uploads only together with a signed test protocol.
The test protocol would have to include the output of lintian, linda,
and piuparts - warnings allowed, errors not.
I
* Ingo Juergensmann ([EMAIL PROTECTED]) [050822 10:42]:
On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote:
4. The requirement that any port has to have 5 developers support it,
and be able to demonstrate that there are (at least) 50 users.
How should this demonstration
On Sat, Aug 13, 2005 at 01:12:18AM +0200, Marc 'HE' Brockschmidt wrote:
aj and Joey Hess blogged about it today (well, yesterday for some of
us), so it's a fairly new feature. It would be nice if this (and the
syntax) could be announced on dda in the next few days.
Since the announcemente is
On Mon, 22 Aug 2005, W. Borgert wrote:
Quoting Henrique de Moraes Holschuh [EMAIL PROTECTED]:
At doing stupid things, you mean :-( Our demographics do not allow
source-only uploads unfortunately.
I don't really get this sentence, could you please re-word?
The current set of DDs will do
Quoting Thijs Kinkhorst [EMAIL PROTECTED]:
I dislike this idea: it is way overengineered. For starters I don't
understand why you would want to run both lintian and linda, since those
I really don't care whether one has to run either lintian or linda
or both. That's an implementation detail.
On Mon, 22 Aug 2005, Thijs Kinkhorst wrote:
they would complement eachother, then why are the vast majority of their
tests present in both programs? I'll just talk about lintian below, but
Vast majority isn't the complete set, and new tests are usually written for
lintian and not linda. I have
Quoting Henrique de Moraes Holschuh [EMAIL PROTECTED]:
On Mon, 22 Aug 2005, W. Borgert wrote:
I don't really get this sentence, could you please re-word?
The current set of DDs will do unverified source uploads immediately if
given half a chance. Unverified binary uploads are rather common,
Uh, no. Just to name one example: tell me, are you absolutely and 100%
sure no user will ever try to use a gecko-based browser on an older
architecture? And yes, if you want to support that, that means you have
to build mozilla
There _are_ lightweight gecko-based browsers, you know.
Andreas Jochens writes:
Wouter Verhelst wrote:
- must have successfully compiled 98% of the archive's source (excluding
arch-specific packages)
Andreas Jochens writes:
It is not possible to build 98% of the unmodified source packages from
the 'unstable' distribution. This is true for any
On Mon, Aug 22, 2005 at 10:45:58AM +0200, W. Borgert wrote:
Quoting Sven Luther [EMAIL PROTECTED]:
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
Quoting Matthew Palmer [EMAIL PROTECTED]:
I used to think that too. I took a wander through queue/reject on merkel.
I don't think that any more. I'm curious as to how Ubuntu is going to
sustain source-only uploads, honestly.
Mandatory, signed build and test logs? I've no idea...
Cheers, WB
Re: Stefano Zacchiroli in [EMAIL PROTECTED]
Since the announcemente is still missing, could you please give some
references to the blog postings you were referring to?
http://kitenet.net/~joey/blog/entry/bts_blockers_support-2005-08-12-15-43.html
Christoph
--
[EMAIL PROTECTED] |
On Mon, 22 Aug 2005 11:51:55 +0200, Aurelien Jarno [EMAIL PROTECTED] said:
Sven Luther a écrit :
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.
Hi Matthew!
Matthew Palmer [2005-08-22 22:22 +1000]:
On Mon, Aug 22, 2005 at 10:45:58AM +0200, W. Borgert wrote:
Quoting Sven Luther [EMAIL PROTECTED]:
All packages should be built by official debian buildds anyway, not on
developper machines with random cruft and unsecure packages
On Mon, Aug 22, 2005 at 03:31:40PM +0200, Martin Pitt wrote:
Please let's not try to solve the problem of sloppy maintainers with a
(wrong) technical solution. If a maintainer doesn't care for his
packages, he can screw up a binary upload as well (or even worse than)
a source upload. If a DD
Hi,
I am using debian linux and i want to make a system snapshot using LVM
or EVMS.
Now i am having running system with one partition (/dev/hda1 of 30GB,
~7GB used) and i can't modify or delete existing data.
I want to take the snapshot (one or more) in some point, save it
locally and rollback if
Hi!
W. Borgert [2005-08-22 14:37 +0200]:
Quoting Matthew Palmer [EMAIL PROTECTED]:
I used to think that too. I took a wander through queue/reject on merkel.
I don't think that any more. I'm curious as to how Ubuntu is going to
sustain source-only uploads, honestly.
Mandatory, signed
Quoting Roberto C. Sanchez [EMAIL PROTECTED]:
Because the user is (99% chance) an admin.
We should use debtags for this kind of information, IMHO.
Because the user may not want extraneous or extra Perl modules
installed on his system. If you are building a production box, you may
want to
On Mon, Aug 22, 2005 at 10:29:44AM +0100, David Pashley wrote:
On Aug 21, 2005 at 14:30, Pierre Habouzit praised the llamas by saying:
Package: wnpp
Severity: wishlist
Owner: Pierre Habouzit [EMAIL PROTECTED]
* Package name: ldapscripts
Version : 1.2
Upstream
On Mon, 22 Aug 2005 14:37:10 +0200, W Borgert [EMAIL PROTECTED] said:
Quoting Matthew Palmer [EMAIL PROTECTED]:
I used to think that too. I took a wander through queue/reject on
merkel. I don't think that any more. I'm curious as to how Ubuntu
is going to sustain source-only uploads,
Hi!
Hamish Moffatt [2005-08-22 23:47 +1000]:
On Mon, Aug 22, 2005 at 03:31:40PM +0200, Martin Pitt wrote:
Please let's not try to solve the problem of sloppy maintainers with a
(wrong) technical solution. If a maintainer doesn't care for his
packages, he can screw up a binary upload as
Quoting Hamish Moffatt [EMAIL PROTECTED]:
There is the possibility that developer builds get extra features
enabled due to other installed libraries etc. This could be checked for
by analysing the packages files for different architectures or similar.
This is a really nice idea: A DD with a
On Mon, Aug 22, 2005 at 12:52:06PM +0200, Sven Luther wrote:
On Mon, Aug 22, 2005 at 11:51:55AM +0200, Aurelien Jarno wrote:
Sven Luther a écrit :
All packages should be built by official debian buildds anyway, not on
developper machines with random cruft and unsecure packages installed, or
On 8/22/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote:
On Mon, 22 Aug 2005 14:37:10 +0200, W Borgert [EMAIL PROTECTED] said:
Quoting Matthew Palmer [EMAIL PROTECTED]:
I used to think that too. I took a wander through queue/reject on
merkel. I don't think that any more. I'm
On 8/22/05, W. Borgert [EMAIL PROTECTED] wrote:
Source-only uploads (with mandatory, signed build- and test-logs)
would have the advantage of not having to upload large binaries.
I have DSL - upload is ca. eight times slower than download here.
You'd prefer 33k6, where upload and download are
Am Sonntag, 21. August 2005 03.58 schrieb Wouter Verhelst:
Hi all,
Good morning
Most of the time I only read on this list and so I've done with this
discussion. But sometimes I dare to write something and suggest somthing ;-)
(see below).
snip
Initial:
- must be publically available to
On Mon, 22 Aug 2005 11:27:33 +0200, Jonas Smedegaard [EMAIL PROTECTED] said:
Also, as Manoj[1] and others have pointed out, sponsors are
_expected_ to recompile packages they sign, but I believe it is not
part of policy.
Which policy?
So I ask again: Is this an intended (and IMO
Quoting Olaf van der Spek [EMAIL PROTECTED]:
Indeed. Why would those checks be done client-side instead of
server-side anyway?
To prevent overload from the buildds. But maybe Martin Pitt is
right, and we should just do it like Ubuntu (source-only uploads)
and invent measures, if the need
It would be cool, for sure, but it still has to be done. And as Christian
noted, the bottleneck is mostly on the developper side here. I mean that
there is more translator waiting for their translations to get integrated
than developpers waiting for a given translator to update his work.
Daniel Stone wrote:
vim! emacs!
And my cats looked out to see who was calling them... :)
--
.''`. Follow the white Rabbit - Ranty (and Lewis Carroll)
: :' :
`. `'Proudly running Debian GNU/Linux (Sid 2.6.11 Ext3)
`- www.amayita.com www.malapecora.com
Hi!
Manoj Srivastava [2005-08-22 7:58 -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 users, in a
On 8/22/05, Andreas Barth [EMAIL PROTECTED] wrote:
* Olaf van der Spek ([EMAIL PROTECTED]) [050822 12:35]:
On 8/22/05, Steve Langasek [EMAIL PROTECTED] wrote:
In particular, we invariably run into arch-specific problems every time
a new version of a toolchain package is uploaded to
On 8/22/05, Hamish Moffatt [EMAIL PROTECTED] wrote:
Really? The maintainer can still embed rm -rf / in the postinst either
way. We need to be able to trust developers.
Similarly, sponsored packages should be rebuilt because the project
hasn't decided to official trust those contributors.
On 8/22/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote:
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
On Mon, 22 Aug 2005 10:13:23 +0200, Henning Makholm [EMAIL PROTECTED] said:
Scripsit Wouter Verhelst [EMAIL PROTECTED]
On Sun, Aug 21, 2005 at 05:31:34PM -0600, Bob Proulx wrote:
An example where an epoc would be needed would be if 0.7.3.3 was
uploaded as 7.3.3 instead. The epoc is
On Sun, 21 Aug 2005 23:29:51 +0200, Petter Reinholdtsen [EMAIL PROTECTED]
said:
[Wouter Verhelst]
b) the three beforementioned teams could already refuse to
support a port anyhow, simply by not doing the work.
This is not really a valid argument. If a team in debian refuses to
accept
* Olaf van der Spek ([EMAIL PROTECTED]) [050822 17:01]:
On 8/22/05, Andreas Barth [EMAIL PROTECTED] wrote:
* Olaf van der Spek ([EMAIL PROTECTED]) [050822 12:35]:
On 8/22/05, Steve Langasek [EMAIL PROTECTED] wrote:
In particular, we invariably run into arch-specific problems every time
Sven Luther dijo [Mon, Aug 22, 2005 at 12:52:06PM +0200]:
What about packages built on developer machines, but using the same
software as on the official debian buildds? I mean using sbuild in a
dedicated chroot. I sometimes do that for my packages when buildd are
lagging or when a
Hi,
I have installed lvm2 on debian and trying to run:
pvcreate /dev/snap
(when /dev/snap is a loopback file)
and get an error Device /dev/snap not found.
My exact steps:
1) dd if=/dev/urandom of=/dev/snap bs=4096 count=1310702 (lopback file
5GB)
2) mkfs.ext3 /dev/snap
3) pvcreate /dev/snap
Why
Jonas Smedegaard dijo [Sun, Aug 21, 2005 at 07:28:55PM +0200]:
We also came to the conclusion that some of the requirements proposed in
Vancouver would make sense as initial requirements -- requirements that
a port would need to fulfill in order to be allowed on the mirror
network -- but
On Mon, Aug 22, 2005 at 10:15:12AM -0500, Manoj Srivastava wrote:
debian-changelog-mode automatically increments the version numbers for
me, including the epoch, so it is no burden -- even the poor vi using
sods can just do cut and paste
dch -i
- David Nusinow
--
To UNSUBSCRIBE, email to
On Mon, Aug 22, 2005 at 12:22:47AM -0700, Steve Langasek wrote:
There was discussion in Vancouver about requiring ports to have an
upstream kernel maintainer, FSO upstream; perhaps we should be
considering requiring there to be a glibc/gcc/binutils upstream for each
port, so that we don't get
Hello,
[EMAIL PROTECTED] wrote:
I have installed lvm2 on debian and trying to run:
pvcreate /dev/snap
(when /dev/snap is a loopback file)
and get an error Device /dev/snap not found.
While technically this is a problem for the debian-users mailing list, I
will try to help:
My exact steps:
* Gunnar Wolf ([EMAIL PROTECTED]) [050822 18:01]:
Huh? Would an off-the-shelf old 1.5GHz P4 lag behind a top-of-the-line
m68k or ARM?
If you manage to put enough ram in the current arm: Definitly yes. Last
time when I was about to buy me a new machine, the only reason why I
didn't buy an
Hi,
How do you boot to a system to run debian-installer when there is no
bios or bootloader on the system yet?
Just take a look at the existing Debian ports, and you see that it's ok
to use a bios that's part of the hardware.
Eh, that was not what I asked. My point was, that there is no
also sprach David Nusinow [EMAIL PROTECTED] [2005.08.22.1728 +0200]:
debian-changelog-mode automatically increments the version numbers for
me, including the epoch, so it is no burden -- even the poor vi using
sods can just do cut and paste
dch -i
Ssssh. Don't expect Manoj to use modern
On Monday 22 August 2005 16.08, W. Borgert wrote:
[...]
This is a really nice idea: A DD with a strange sense of humour
could
[...]
If we're starting to worry about what kind of damage a DD can do to the
world by providing some bogus uploads, let's just not. Any DD can cause
code to be
On 8/22/05, Adrian von Bidder [EMAIL PROTECTED] wrote:
On Monday 22 August 2005 16.08, W. Borgert wrote:
[...]
This is a really nice idea: A DD with a strange sense of humour
could
[...]
If we're starting to worry about what kind of damage a DD can do to the
world by providing some
On Monday 22 August 2005 12.58, Marc Haber wrote:
I can imagine that for archs with less than 50 machines reporting to
popcon it could be possible to have some kind of registration
mechanism.
Uh, please don't add huge technical overhead for corner cases that will
rarely happen, if ever. I'm
1 - 100 of 227 matches
Mail list logo
