Re: removing /etc/hotplug.d/ support

[Horms]

On Wed, Aug 24, 2005 at 04:59:01PM -0700, Steve Langasek wrote:
> On Thu, Aug 25, 2005 at 01:01:10AM +0200, Marco d'Itri wrote:
> > On Aug 24, martin f krafft <[EMAIL PROTECTED]> wrote:
> 
> > > > udev has also been the hotplug multiplexer for some time now.
> > > Yeah. Horrible. Will udev become an editor and MTA too, maybe after
> > > etch?
> > No. But since it had to deal with most events, applying the same process
> > to the others was a natural extension of its design.
> 
> > > > 2.4 kernels will not be supported in etch,
> > > I don't think this is an authoritative statement. At the moment,
> > > some architectures do not work with 2.6.
> > It's an educated guess. I consulted some of the interested maintainers
> > and followed the debian-kernel list, and so far there is no sign that
> > 2.4 will be supported (and if 2.6 will not be fixed on architectures
> > like sparc32, too bad for them).
> 
> Although being able to ship just one kernel for all our ports in etch is
> everyone's first choice, the release team has not made any decision yet to
> exclude 2.4 kernels from etch if they're needed for a particular arch or
> subarch.  Given that the kernel team is still rolling new 2.4 updates in
> unstable, and d-i still defaults to 2.4 on a majority of archs, I think it
> is premature to drop hotplug support for 2.4 at this point.
> 
> It would certainly be a big help to the release team in making this decision
> if the kernel team would begin to drop 2.4 kernels as early as possible in
> the release cycle for those architectures where they believe they are no
> longer needed.  Together with working out which ports are actually viable
> for etch under the new requirements (which of course first requires fully
> specifying those requirements), we should be able to get a clear picture in
> a couple of months of just what the kernel requirements are for etch.

There are some architectures where 2.4 is required, its
because of these that it seems that we are stuck with 2.4 for Etch.
  alpha (installer), m68k (2.6 only works on amiga), s390 (installer), 
  mips, mipsel

There are some architectures where 2.4 has been abandonded uptream,
and these are being removed from the arcive
  powerpc  (ok, thats one, not some)

There are some architectures, like i386, which are pretty well
maintained upstream for 2.4, so it seems reasonable to keep them,
as we need 2.4 because of the first group, and its not a whole lot of
extra effort - if it is lets get rid of them. I'm aware of the udev
issue, I'm happy for that to be a catalyst for canning 2.4 where
possible. But what about the arches that need 2.4. Does that mean
we have to backport udev anyway?


I might add, that right now I'm doing the bulk of 2.4 maintenance,
and my current plan is to just keep patching 2.4.27, the sarge kernel,
and eventually, once all the current teething problems are ironed
out with the single-source 2.6 package, use that framework to
produce a new 2.4.X, probably .35 or so by then.

Also, I only have powerpc (not supported by 2.4) and i386 hardware
at my disposal, so it would be very convenient for me to keep
2.4.27 around for i386. Though I'm not really concerend about
being able to install 2.4.27, just have something to test, so
I guess that doesn't have to be a package that appears in Debian.
But if I'm building the things, it seems like it might as well.

Finally, the lists above are probably incomplete, please jump
in with additional information if you have it.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem

[Paul TBBle Hampson]

On Wed, Aug 24, 2005 at 03:54:38PM +0200, Domenico Andreoli wrote:
> On Fri, Aug 19, 2005 at 12:07:09PM +1000, Paul TBBle Hampson wrote:
>> On Thu, Aug 18, 2005 at 11:00:41AM +0200, Domenico Andreoli wrote:
> >>   with curl 7.14.0-5 currently in incoming, i added two new packages
> >> libcurl3-gnutls and libcurl3-gnutls-dev. libcurl3 and libcurl3-gnutls
> >> conflict each other since both install libcurl.so.3.0.0 in /usr/lib/.
>> 
>> If the problem is that using gnutls or openssl changes the ABI for libcurl,
>> then they should have different sonames. (I'd expect the newer one, gnuTLS,
>> would get its own soname, so that existing packages work, and packages can
>> optionally build against the gnuTLS version if they so wish. Once everything
>> builds happily against the gnuTLS version, the next upstream soname bump can
>> use the gnuTLS library, and we're compatible with other distributions again.)

> problem is right the change of ABI.

> Daniel Stenberg (the upstream developer) is available to implement a
> solution based on the proposal of Richard Atterer [0].

The issue in the above is that the suggestion of two different versions of
libcurl being a problem for prog A is only a problem if the sonames/sovers are
not differentiated, and I suggest they _be_ differentiated. I mean, they
provide different ABIs. Will the openSSL version provide dummy gnuTLS entries
as well?  And what about a different ssl implementation? pssl, or whatever it's
called?  If you want to have one ABI no matter which libraries are being used,
then you need to provide an ABI that abstracts away anything SSL, and doesn't
require the curl-using program to care what it's linked against. _Then_ you
provide a pair of curl packages, one with openSSL and one with gnuTLS, same
soname and sover, both providing libcurl3, and programs that need the
functionality of the openSSL version can conflict with the libgnutls version of
the library, and programs that don't care can use either. However, that's not a
huge improvement over now, while my below suggestion allows GPL'd curl-using
programs to be uploaded without having to remove openssl-needing curl-using
programs.

> in the meanwhile new packages can be built using the gnutls variant of
> libcurl3. be aware that libcurl3 and libcurl3-gnutls currently cannot
> be installed at the same time.

I'd again suggest changing the soname of the gnuTLS libcurl to something else,
since the changed ABI means that programs must choose to build against one or
the other, and so it's not a problem if programs need to be told to link
against libcurl-gnutls3.so instead of libcurl3.so, since presumably no other
distro is trying to simultaneously support both openSSL and gnuTLS versions of
libcurl, which is the strongest motivation for keeping upstream's soname. ^_^

And then the two packages can be parallel-installed, avoiding this particularly
nasty issue in this proposed solution. I cannot see what motivation there is to
only have one of the library pacakges installed. The _dev_ packages need to
conflict as they provide the same API, of course.

This also means you need to produce a -dev pacakge for both libcurl and
libcurl-gnutls. Those programs that know they need the gnuTLS version of
libcurl can build-depend on libcurl-gnutls-dev and so they'll have
libcurl-gnutls.so.3 in their library load list instead of libcurl.so.3.

Programs which are unhampered by licenses can try out the gnuTLS version, and
if it works, the can use that, or stick with the openSSL version until the
gnuTLS version matures and can fully replace the openSSL version as
libcurl.so.4. (And a bit of trickery with the libcurl-gnutls4-dev would mean
anything built against that gets the unified libcurl4 dependancy.)

The _important_ point is that no pair of programs becomes uninstallable due to
conflicts between their dependant curl library versions.

I'm not sold on the idea of run-time dynamic choosing of openSSL vs a stub, and
for that matter it means the issue of curl-config --features (my bug report
from way back when) becomes a lot more complicated.

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

License: http://creativecommons.org/licenses/by/2.1/au/
---


pgp1MX4VYuG8E.pgp
Description: PGP signature

Re: Unnecessary "Conflicts" with imap-server packages

[Brian May]

> "Gerrit" == Gerrit Pape <[EMAIL PROTECTED]> writes:

Gerrit>  bincimap-run package provides the virtual package
Gerrit> ``imap-server'' and conflicts with other packages
Gerrit> providing ``imap-server''.  This ensures that bincimap is
Gerrit> the only service that listens on the address 0.0.0.0:993
Gerrit> on a system, and also satisfies packages that depend on a
Gerrit> running imap service.  The bincimap package without the
Gerrit> bincimap-run package can be installed alongside other
Gerrit> imap-server packages on a system, e.g. to provide
Gerrit> different imap or imaps services on different addresses
Gerrit> simultaneously.

So are you suggesting that every imap-server (for example) should be
split into two packages?

Taken a step further this would include every server where multiple
implementations exist.

Is this really a good idea?
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: removing /etc/hotplug.d/ support

[Nathanael Nerode]

Gabor Gombas <[EMAIL PROTECTED]> wrote:
> Well, I have a different view: udev is a program to receive kernel
> events and evaluate/execute different rules based on the event, and it
> comes with a default ruleset to manage /dev nodes.

So can we configure udev to stop managing /dev?  This would remove my qualms 
about making udev mandatory.  (I have been quite happy with static /dev and 
have not found udev ready for prime time yet.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: invalid-arch-string-in-source-relation amd64

[Goswin von Brederlow]

Shaun Jackman <[EMAIL PROTECTED]> writes:

> 2005/8/24, Tollef Fog Heen <[EMAIL PROTECTED]>:
>> * Shaun Jackman
>> 
>> | What's wrong with this Build-Depends line?
>> |
>> | Build-Depends: ia32-libs-dev [amd64], debhelper (>= 4.1.16)
>...
> dh_shlibdeps
> /usr/bin/ldd: line 171: /lib/ld-linux.so.2: No such file or directory
> ldd: /lib/ld-linux.so.2 exited with unknown exit code (127)
> dpkg-shlibdeps: failure: ldd on `debian/tmp/usr/share/eagle/bin/eagle'
> gave error exit status 1
> dh_shlibdeps: command returned error code 256
> make: *** [binary-arch] Error 1
>
> With the attached patch 'eagle' can be compiled on amd64.
>
> Regards
> Andreas Jochens

The LD is in ia32-libs. Try using that instead. The -dev is only
needed if you compile and link 32bit code.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using buildds only

[Goswin von Brederlow]

Olaf van der Spek <[EMAIL PROTECTED]> writes:

> 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 buildd chroots from scratch would help to
>> >eliminate many FTBFS bugs due to polluted chroots.
>> 
>> Surely you are aware how much time it takes to rebuild a chroot on
>> slower architectures. Some technology able to restore a large
>> directory tree to a static default in short time should be used here.
>
> What causes this long times? Slow IO?

Slow disks, slow/little ram, slow cpu. Restoring a chroot at 1MB/s
will take minutes.

But what is 5m to copy a clean chroot compared to the 60m to install
all the kde Build-Depends for a huge build and another 60m to remove
them again because one libs version isn't high enough to build
anything?

Also one doesn't need to do this every time, spreading the restore
time over multiple compiles makes that rather small per package.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Will the amd64 port be rejected because of the 98% rule?

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * 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 of stats to see
>> what would be a reasonable first try for a line.
>
> Well, I currently tend to continue with the 98%, knowing that the
> specification how we count needs to be done, and that this can change
> the number again. But the general impression that 98% gives is definitly
> the right one - "must basically be able to compile almost everything
> that's sensible to have compiled".
>
>
> Cheers,
> Andi

The only stats currently generated by Debian are the w-b output and
then only i386 qualifies. Ppc (97%) and amd64 (96.5%) are well below
the 98% mark, excluding the second and third most used archs.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: More pbuilder use!

[Goswin von Brederlow]

Roger Leigh <[EMAIL PROTECTED]> writes:

> The chroot is not really suitable for anything but exclusive use by
> sbuild (otherwise you risk messing it up by installing random stuff
> so that it's no better than the host environment...).
>
> You could always use a separate chroot for user access, but I don't
> personally have the need (nor the free disk space).
>
>
> Regards,
> Roger

I have debfoster installed automaticaly in all my chroots (as part of
the create a chroot script) and I just run this every now and then:

sudo debfoster -f -o RemoveCmd="apt-get --purge remove -y"

Remember that sbuild does not always clean up properly. Debfoster is
my maid that does serious cleanup while sbuild just tries not to mess
things up too bad.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using buildds only

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> 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 you end up with spending loads of cpu time
>> > upgrading the same packages over and over again after each build.
>> 
>> You have to keep the chroot up-to-date manualy anyway as sbuild does
>> not upgrade unless a Build-Depends requires a newer version
>> specificaly.
>
> In my experience, it's not that bad. Last time I manually upgraded
> anything inside the chroot must have been about two or three months ago.
> Yet it failed a number of packages due to a bug in glibc 2.3.5-3 which
> made libraries break on kernels without NPTL support (such as the 2.2
> kernel which is running on that system). This particular bug also hit
> q950 and tanda, two of our other buildd systems.
>
> Considering glibc was uploaded to the archive on August 5th (or at
> least, the katie mail was sent out at that time), that I started
> noticing this bug about a week ago, and that it probably took about a
> day for the new glibc to be built on m68k and uploaded by the buildd
> (but I can't check that, debian-devel-m68k-changes doesn't appear to
> have worked since 2003), that leaves about ten days for the package to
> be installed after it was available.
>
> Manual maintenance wouldn't have made that go much faster, if at all;
> and the way glibc got upgraded in this particular occasion is far from
> exceptional.
>
> Anyway, this is of course all moot for me particularly since LVM doesn't
> work on 2.2, and 2.6 doesn't work reliably on all m68k macs yet either.
> But at least we're getting places in that area already :-)

The reason glibc was installed is probably quite simple: Some
Build-Depends was build against it (on another buildd) and when it got
installed the Depends line pulled in glibc.

Anyway, point is that you have to check, clean and update the chroot
every so often now too. Having the chroot get remade automaticaly
sometimes saves some cleanup runs for the cost of more upgrades. I bet
that part doesn't give or lose anything.

But misbuilds caused by a failure to remove packages, especialy ones
that leave the chroot in a state where apt/dpkg keep failing, would be
avoided that way.

And don't forget that you don't need lvm, it is just one option. The
fastest one I believe but a simple rm + tar will do just as well.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: WebSVN of svn.debian.org uses wrong encoding

[Bryan Donlan]

On 8/23/05, W. Borgert <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> 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 files, or
> is WebSVN too plain in its assumptions?  How/where can I file a
> bug, if the problem is in svn.debian.org?  TIA!
> 
> [1] http://svn.debian.org/wsvn/ddp/refcard/trunk/entries-ru.dbk?op=file
> 
> (If WebSVN does not know about encodings, UTF-8 might be a more
> sensible default than ISO-8859-1 nowadays.)
> 

Try setting the mime type with a command like:
svn ps svn:mime-type 'text/plain; charset=UTF-8' foobar.txt

Re: Closing bugs in BTS

[Adeodato Simó]

* Steinar H. Gunderson [Thu, 25 Aug 2005 01:03:03 +0200]:

> BTW, does the BTS understand that the package might "fork"? Specifically, if
> I have a bug in a sarge package (say, 1.0) that is fixed in an upstream
> version 1.2, but is backported to sarge (because it's an RC bug), can I say
> that it's also closed in 1.0+sarge1, or will that confuse the BTS, when etch
> has 1.1 and I want to keep the bug open?

  It'll work, as per Colin's explanations that the versioning tracking
  in the BTS does not use a naive approach "if v2 > v1, every fix in v1
  is present in v2". The changelogs are feeded to and parsed by the BTS,
  and a tree of versions is composed; if certain version X is not
  descendant of a version where the bug was marked as fixed, the bug
  will be open for that version X.

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
It is impossible to make anything foolproof because fools are so ingenious.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: removing /etc/hotplug.d/ support

[Steve Langasek]

On Thu, Aug 25, 2005 at 01:01:10AM +0200, Marco d'Itri wrote:
> On Aug 24, martin f krafft <[EMAIL PROTECTED]> wrote:

> > > udev has also been the hotplug multiplexer for some time now.
> > Yeah. Horrible. Will udev become an editor and MTA too, maybe after
> > etch?
> No. But since it had to deal with most events, applying the same process
> to the others was a natural extension of its design.

> > > 2.4 kernels will not be supported in etch,
> > I don't think this is an authoritative statement. At the moment,
> > some architectures do not work with 2.6.
> It's an educated guess. I consulted some of the interested maintainers
> and followed the debian-kernel list, and so far there is no sign that
> 2.4 will be supported (and if 2.6 will not be fixed on architectures
> like sparc32, too bad for them).

Although being able to ship just one kernel for all our ports in etch is
everyone's first choice, the release team has not made any decision yet to
exclude 2.4 kernels from etch if they're needed for a particular arch or
subarch.  Given that the kernel team is still rolling new 2.4 updates in
unstable, and d-i still defaults to 2.4 on a majority of archs, I think it
is premature to drop hotplug support for 2.4 at this point.

It would certainly be a big help to the release team in making this decision
if the kernel team would begin to drop 2.4 kernels as early as possible in
the release cycle for those architectures where they believe they are no
longer needed.  Together with working out which ports are actually viable
for etch under the new requirements (which of course first requires fully
specifying those requirements), we should be able to get a clear picture in
a couple of months of just what the kernel requirements are for etch.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: removing /etc/hotplug.d/ support

[Al Viro]

On Thu, Aug 25, 2005 at 01:09:14AM +0200, Marco d'Itri wrote:
> When I asked the udev maintainer about this, he replied that he does not
> believe that it will be an issue in the future.
> We are not even at the step of requiring udev for everything, only for
> less than ten packages which require some special hotplug support.

Aha, so I'll be able to carry sane forks of those.  Good to know - Debian
userland is nice for kernel work, would be a PITA to be forced to go looking
for replacement...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#324861: ITP: pptpproxy -- a small app that forwards PPTP VPN connections through a Linux firewall

[Michel van der Klei]

Hi,

On Thu, Aug 25, 2005 at 12:45:52AM +0200, Thomas Viehmann wrote:

> Michel van der Klei wrote:
> > I will change it in:
> > 
> > pptpproxy is a good old forwarder daemon. It's most probably not as
> > elegant as a kernel+iptables based solutions, but it has the very
> > sizeable advantage of Working For Me. It's a "timesaver" for those who
> > are getting tired of trying to get iptables to properly forward PPTP 
> > through a Linux firewall.
> 
> While you at it, could you please switch the text type from an anecdote
> to tell someone over beer to a matter-of-fact package description?
> The process of installing a Debian system is not the quite time to be
> inspired by humorous descriptions appearing on the screen.

Yes is will Thomas, i've changed the control file already.

pptpproxy is a small forwarder deamon which forwards pptp traffic
to a Windows VPN server through an iptables firewall.  

I supose this will do. 

Kind regards,

Michel van der Klei


signature.asc
Description: Digital signature

Re: removing /etc/hotplug.d/ support

[Marco d'Itri]

On Aug 24, martin f krafft <[EMAIL PROTECTED]> wrote:

> > udev has also been the hotplug multiplexer for some time now.
> Yeah. Horrible. Will udev become an editor and MTA too, maybe after
> etch?
No. But since it had to deal with most events, applying the same process
to the others was a natural extension of its design.

> > 2.4 kernels will not be supported in etch,
> I don't think this is an authoritative statement. At the moment,
> some architectures do not work with 2.6.
It's an educated guess. I consulted some of the interested maintainers
and followed the debian-kernel list, and so far there is no sign that
2.4 will be supported (and if 2.6 will not be fixed on architectures
like sparc32, too bad for them).

> > and we never tried to support proprietary drivers if doing so
> > harms the rest of the system.
> Apart from the tg3-and-related stuff, we never took active action
> to make lives of those in need of proprietary drivers any more
> difficult than it already is.
We are not discussing changes because I am bored, but because there are
sound technical reasons which justify them.

> > Some people have reservations, but they appear to be driver more
> > by emotion than by technical reasons.
> Really? I have technical issues with udev-does-it-all, and I have
> issues with the upstream decisions. On a technical level, udev is
> too Gentoo for me, it's far from stable, and thus far from
> non-optional integration into Debian. This is my two cents.
Both SuSE and Red Hat have made udev mandatory, so you will need much
better arguments if you want to persuade people that udev has
fundamental design problems which make it unsuitable for Debian.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: removing /etc/hotplug.d/ support

[Marco d'Itri]

On Aug 24, Julien BLACHE <[EMAIL PROTECTED]> wrote:

> Two points:
> 
>  - I am tired of having to revamp the hotplugging framework every
> other month;
Not a great point. There has been exactly one other change in the
hotplug API in the past, and it started long ago with a very long
transition period: switching from map files to hotplug.d/.

>  - I don't want to see udev being forced upon our users if a clear,
> working and transparent upgrade path is not provided for each new
> version of udev from now on.
When I asked the udev maintainer about this, he replied that he does not
believe that it will be an issue in the future.
We are not even at the step of requiring udev for everything, only for
less than ten packages which require some special hotplug support.
It's something which has to happen anyway before etch is frozen, so
unless there are really good reasons to postpone it it may be a good
idea to start now.

> If only upstream could be a bit more stable. What are we going to get
> next month ? Ah yes, usbfs being deprecated in favor of udev and sysfs.
udev is just following kernel changes...
I understand that /dev/bus/usb/ does not even requires udev.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Closing bugs in BTS

[Steinar H. Gunderson]

On Thu, Aug 25, 2005 at 12:49:19AM +0200, martin f krafft wrote:
>> AFAICT there is no support for a "done" command to [EMAIL PROTECTED]
> 
> I meant "close":
> 
>   close 99 1.2

BTW, does the BTS understand that the package might "fork"? Specifically, if
I have a bug in a sarge package (say, 1.0) that is fixed in an upstream
version 1.2, but is backported to sarge (because it's an RC bug), can I say
that it's also closed in 1.0+sarge1, or will that confuse the BTS, when etch
has 1.1 and I want to keep the bug open?

(The real-world version doesn't have the version in etch, but I guess you get
the point.)

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Closing bugs in BTS

[Blars Blarson]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>In recent announce about changes in BTS (Subject: BTS version tracking
>Date: Mon, 18 Jul 2005 12:06:29 +0100) is described how to use new
>versioning system. I'm not sure if sending mail to [EMAIL PROTECTED] is
>now prefered way to closing bug rather than closing it in Changelog ?

If the bug is fixed by an upload, close it in the changelog.
If the bug is fixed some other way, or the change has already been
uploaded, use the nnn-done address with a version pseudo-header.

>(I conclude that it is not possible to close bug for specific version,
>in testing, unstable and allow to remain opened in stable closing via
>Changelog, am I right ?).

Closing it in the changelog will mark it fixed in that version.

>Moreover I wonder if when closing via mail should I write in Changelog
>sth like: this upload fixes bug number 1234567 in testing and
>unstable which has been closed via mail, and add tag sarge to bug that
>remain opened in &dist=3Dstable ?

No, use the found and notfound BTS commands to mark what package
version the bug applies to if needed.

You can even keep track of bugs fixed in multiple versions.  (Mainly
for release-critical bugs fixed by security/proposed updates.)

>Next issue I wanted to discuss is information on the page generated by
>BTS.

The bug by default applies from the version reported until the version
it is fixed in.

>Thanks in advance for answering my mail and sorry for taking Your time
>if I really omitted some part of documentation or so !

The version tracking stuff is new and may still have a few rough edges.
It is documented on http://www.debian.org/Bugs/
-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Closing bugs in BTS

[martin f krafft]

also sprach Frans Pop <[EMAIL PROTECTED]> [2005.08.25.0038 +0200]:
> >   done 99 1.2
> 
> AFAICT there is no support for a "done" command to [EMAIL PROTECTED]

I meant "close":

  close 99 1.2

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"in matters of grave importance, style, not sincerity is the vital
 thing."
-- oscar wilde


signature.asc
Description: Digital signature (GPG/PGP)

Re: Bug#324861: ITP: pptpproxy -- a small app that forwards PPTP VPN connections through a Linux firewall

[Thomas Viehmann]

Hi.

Michel van der Klei wrote:
> I will change it in:
> 
> pptpproxy is a good old forwarder daemon. It's most probably not as
> elegant as a kernel+iptables based solutions, but it has the very
> sizeable advantage of Working For Me. It's a "timesaver" for those who
> are getting tired of trying to get iptables to properly forward PPTP 
> through a Linux firewall.

While you at it, could you please switch the text type from an anecdote
to tell someone over beer to a matter-of-fact package description?
The process of installing a Debian system is not the quite time to be
inspired by humorous descriptions appearing on the screen.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Closing bugs in BTS

[Grzegorz Bizon]

Thu, 25 Aug 2005 00:25:08 +0200
martin f krafft <[EMAIL PROTECTED]> wrote:

> > In recent announce about changes in BTS (Subject: BTS version
> > tracking Date: Mon, 18 Jul 2005 12:06:29 +0100) is described how to
> > use new versioning system. I'm not sure if sending mail to
> > [EMAIL PROTECTED] is now prefered way to closing bug rather than
> > closing it in Changelog ?
> 
> The ChangeLog approach automatically records the version. To do the
> same with a message to -done, you should start the -done mail like
> a submit@ mail:
> 
>   Package: hello
>   Version: 2.1.1-2
> 
> which will then mark the bug closed in 2.1.1-2 but not in 2.1.1-1.
> 
> > (I conclude that it is not possible to close bug for specific
> > version, in testing, unstable and allow to remain opened in stable
> > closing via Changelog, am I right ?).
> 
> Yes it is. If you write into the changelog entry for 2.1.1-2 that it
> closes bug #99, that bug will be marked closed in 2.1.1-2, but
> remain open in 2.1.1-1.

It's now all clear. THANKS !
 
Best regards,
 Verdan

-- 
[  ,''`.  [EMAIL PROTECTED] // [EMAIL PROTECTED] ]
[ : :' :  GG: 830398 //   JID: verdan(at)chrome.pl ]
[ `. `'   [EMAIL PROTECTED]  //GPG: 0xDF32F531 ]
[   `-  1A6F A0A1 01D1 3033 332A  60FE 4C7B 8037 DF32 F531 ]


pgp9H6eD5Giqe.pgp
Description: PGP signature

Re: Closing bugs in BTS

[Frans Pop]

On Thursday 25 August 2005 00:25, martin f krafft wrote:
>   done 99 1.2

AFAICT there is no support for a "done" command to [EMAIL PROTECTED]


pgps430gVp78z.pgp
Description: PGP signature

Re: Closing bugs in BTS

[Gustavo Noronha Silva]

Em Qua, 2005-08-24 às 23:59 +0200, Grzegorz Bizon escreveu:
> In recent announce about changes in BTS (Subject: BTS version tracking
> Date: Mon, 18 Jul 2005 12:06:29 +0100) is described how to use new
> versioning system. I'm not sure if sending mail to [EMAIL PROTECTED] is
> now prefered way to closing bug rather than closing it in Changelog ?
> (I conclude that it is not possible to close bug for specific version,
> in testing, unstable and allow to remain opened in stable closing via
> Changelog, am I right ?).
> Moreover I wonder if when closing via mail should I write in Changelog
> sth like: this upload fixes bug number 1234567 in testing and
> unstable which has been closed via mail, and add tag sarge to bug that
> remain opened in &dist=stable ?

I'm not sure what you problem is, but simply close the bug in the
ChangeLog. The bug is supposed to remain open for sarge and there's no
need to further tag it.

> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=specter&dist=stable
> and
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=specter&dist=unstable
> 
> show same version, 1.4-1 is missing in the list. It's a bit confusing.
> In my opinion it may lead to misunderstandings :/. Do You know what I
> mean ?

I don't see a problem in that. I believe the new BTS assumes the bug
applies to all later versions, and that's it.

See ya,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



signature.asc
Description: This is a digitally signed message part

Re: Closing bugs in BTS

[martin f krafft]

also sprach Grzegorz Bizon <[EMAIL PROTECTED]> [2005.08.24.2359 +0200]:
> Maintainer uploads fixed package into unstable and closes bug in
> Changelog, after few days corrected package enters testing, depending on
> urgency.  Granted that reported bug wasn't so important to justify
> upload do stable-proposed-updates, it still exists in stable.

As of late[0], the bug is not just marked closed, the bug is marked
as fixed in the version that has been uploaded to unstable. The
version in sarge is less than this new version, but since the bug
has been fixed only in the new version, the BTS still knows that it
continues to apply to all older versions.

0. http://lists.debian.org/debian-devel-announce/2005/07/msg00010.html

> 
> In recent announce about changes in BTS (Subject: BTS version tracking
> Date: Mon, 18 Jul 2005 12:06:29 +0100) is described how to use new
> versioning system. I'm not sure if sending mail to [EMAIL PROTECTED] is
> now prefered way to closing bug rather than closing it in Changelog ?

The ChangeLog approach automatically records the version. To do the
same with a message to -done, you should start the -done mail like
a submit@ mail:

  Package: hello
  Version: 2.1.1-2

which will then mark the bug closed in 2.1.1-2 but not in 2.1.1-1.

> (I conclude that it is not possible to close bug for specific
> version, in testing, unstable and allow to remain opened in stable
> closing via Changelog, am I right ?).

Yes it is. If you write into the changelog entry for 2.1.1-2 that it
closes bug #99, that bug will be marked closed in 2.1.1-2, but
remain open in 2.1.1-1.

> Moreover I wonder if when closing via mail should I write in
> Changelog sth like: this upload fixes bug number 1234567 in
> testing and unstable which has been closed via mail, and add tag
> sarge to bug that remain opened in &dist=stable ?

No, the sarge tag is deprecated.

> But strange thing is that:
> 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=specter&dist=stable
> and
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=specter&dist=unstable
> 
> show same version, 1.4-1 is missing in the list. It's a bit
> confusing. In my opinion it may lead to misunderstandings :/. Do
> You know what I mean ?

This just shows that the bug has been found in the sarge packet. The
BTS assumes that it exists in subsequent versions too. If you want
to make that explicit, you can send a control command

  found 324909 1.4-1

but that is not necessary. The important part is that a bug found in
1.0 will likely exist in 1.1 as well. If it is fixed in 1.2, it
continues to exist in 1.0 and 1.1.

  found 99 1.0
  done 99 1.2

this has exactly the above effect: the bug exists in 1.0 and 1.1,
but has been fixed in 1.2.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"oh what a tangled web we weave,
 when first we practice to deceive."
-- shakespeare


signature.asc
Description: Digital signature (GPG/PGP)

Re: better init.d/* : who carres ?

[Mauro Calderara]

On Aug 24, 2005, at 6:43 PM, sean finney wrote:


On Wed, Aug 24, 2005 at 05:22:32PM +0100, Andrew Porter wrote:

/usr/sbin/mysqld --print-defaults \
| tr " " "\n" \
| grep -- "--$1" \
| tail -n 1 \
| cut -d= -f2


is harder to read than


 /usr/sbin/mysqld --print-defaults |
 sed -ne "s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p"


Both require knowledge of a particular tools - one only one tool 
though.


that's not completely true, unless knowledge of sed also implies a good
understanding of posix regular expressions, in which case i wouldn't be
so hasty to claim it was easier to understand.

however, all of this notwithstanding, if someone takes the time to
submit a patch similar to this it will probably be included.

Of course this would all be so much simpler if we could actually use 
the

power of modern shells (post 1993) in init scripts - subprocesses
wouldn't be required at all


it is a /bin/bash script, so i suppose bashisms are allowed, provided
that there aren't other reasons christian or i would object to them.


Aren't the init-scripts supposed to be posix-compilant? Often when
installing dash as /bin/sh this becomes a problem because even though
dash is posix-compatible it tends to break init-scripts for me. Whether
this is dash's fault or the init-scripts is beyond my knowledge since I 
don't

know POSIX very well. But still I think bashisms should be avoided.



sean



mauro


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: better init.d/* : who carres ?

[Mauro Calderara]

On Aug 24, 2005, at 11:19 PM, sean finney wrote:


On Wed, Aug 24, 2005 at 11:08:41PM +0200, Mauro Calderara wrote:

Aren't the init-scripts supposed to be posix-compilant? Often when
installing dash as /bin/sh this becomes a problem because even though
dash is posix-compatible it tends to break init-scripts for me. 
Whether
this is dash's fault or the init-scripts is beyond my knowledge since 
I

don't
know POSIX very well. But still I think bashisms should be avoided.


/bin/sh init scripts are supposed to be posix sh compliant (with
an additional specification about echo in policy).  but as i said,
it is a *bash* script...



#!/bin/bash
#
# MySQL daemon start/stop script.

Right you are ... I'm sorry, should have checked before posting. You 
have

my apologies


sean


mauro


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Closing bugs in BTS

[Grzegorz Bizon]

Hi there !

I was just wondering about few issues in BTS after recent changes - 
how to close bugs in apropriate way.

Maintainer uploads fixed package into unstable and closes bug in
Changelog, after few days corrected package enters testing, depending on
urgency.  Granted that reported bug wasn't so important to justify
upload do stable-proposed-updates, it still exists in stable.

In recent announce about changes in BTS (Subject: BTS version tracking
Date: Mon, 18 Jul 2005 12:06:29 +0100) is described how to use new
versioning system. I'm not sure if sending mail to [EMAIL PROTECTED] is
now prefered way to closing bug rather than closing it in Changelog ?
(I conclude that it is not possible to close bug for specific version,
in testing, unstable and allow to remain opened in stable closing via
Changelog, am I right ?).
Moreover I wonder if when closing via mail should I write in Changelog
sth like: this upload fixes bug number 1234567 in testing and
unstable which has been closed via mail, and add tag sarge to bug that
remain opened in &dist=stable ?

Next issue I wanted to discuss is information on the page generated by
BTS. For example: Dimitri Puzin has reported bug in specter (thanks !)
I'm currently maintaning. Both specter versions are affected
(1.3+1.4pre2-2  -> stable, 1.4-1 -> testing, unstable). On the page
generated by BTS -
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=specter
we can find specter version that bug was filled against.
But strange thing is that:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=specter&dist=stable
and
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=specter&dist=unstable

show same version, 1.4-1 is missing in the list. It's a bit confusing.
In my opinion it may lead to misunderstandings :/. Do You know what I
mean ?

What do You think about that? Maybe there is something I've passed over?

Thanks in advance for answering my mail and sorry for taking Your time
if I really omitted some part of documentation or so !

Best regards,
 Grzegorz ,,Verdan'' Bizon

-- 
[  ,''`.  [EMAIL PROTECTED] // [EMAIL PROTECTED] ]
[ : :' :  GG: 830398 //   JID: verdan(at)chrome.pl ]
[ `. `'   [EMAIL PROTECTED]  //GPG: 0xDF32F531 ]
[   `-  1A6F A0A1 01D1 3033 332A  60FE 4C7B 8037 DF32 F531 ]


pgpQYWz6HI2cC.pgp
Description: PGP signature

Bug#324930: ITP: gollem -- file manager component for horde framework

[Roberto C. Sanchez]

Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: gollem
  Version : x.y.z
  Upstream Author : Michael Slusarz <[EMAIL PROTECTED]>
* URL : http://www.horde.org/gollem/
* License : GPL
  Description : file manager component for horde framework

 Gollem is the Horde web-based File Manager, providing the ability to
 fully manage a hierarchical file system stored in a variety of backends
 such as a SQL database, as part of a real filesystem, or on an FTP server.
 It uses the Horde's MIME_Viewer framework to identify file types, associate
 icons, etc.
 .
 Homepage: http://www.horde.org/gollem/

- -- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-miami-16
Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDDOqTTfhoonTOp2oRAgU5AKDdFE9POchvdcf8CoLDQOG139jaQgCgt8U7
RacQ+EDsOM8yTDpp0kdh5u0=
=e7jo
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: better init.d/* : who carres ?

[sean finney]

On Wed, Aug 24, 2005 at 11:08:41PM +0200, Mauro Calderara wrote:
> Aren't the init-scripts supposed to be posix-compilant? Often when
> installing dash as /bin/sh this becomes a problem because even though
> dash is posix-compatible it tends to break init-scripts for me. Whether
> this is dash's fault or the init-scripts is beyond my knowledge since I 
> don't
> know POSIX very well. But still I think bashisms should be avoided.

/bin/sh init scripts are supposed to be posix sh compliant (with
an additional specification about echo in policy).  but as i said,
it is a *bash* script...

sean


-- 


signature.asc
Description: Digital signature

Re: better init.d/* : who carres ?

[Russ Allbery]

Marc Chantreux <[EMAIL PROTECTED]> writes:

> there are a lot of things in /etc/init.d/*, and {pre,post}inst scripts
> that can be rewritten more efficiently ( i think ).

> for example, in /etc/init.d/mysqld

> mysqld_get_param() {
> /usr/sbin/mysqld --print-defaults \
> | tr " " "\n" \
> | grep -- "--$1" \
> | tail -n 1 \
> | cut -d= -f2
> }

> can be written like :

> mysqld_get_param () {
> local string=$( /usr/sbin/mysqld --print-defaults | grep -o -- "--$1=[^ 
> ]*" )
> echo ${string#*=}
> }

> that are not bugs so i wonder if package maintainers where pleased if i
> reportbug those lines as wishlist.

It would certainly be fine for me to get wishlist bugs of this sort
against my packages, although in this particular case I would probably
close the bug with the explanation that I find the first form easier to
read and don't think the efficiency difference is particularly important.

I find constructs like ${string#*=} particularly difficult to read, since
they require that I remember what all the different punctuation characters
inside this sort of parameter expansion do.  According to the bash manual,
there are sixteen of them, and I had to read the description of
${parameter#word} three times before I completely understood what it said.

The advantage of the original form is that each one of those lines is
doing something very simple and straightforward.  Yes, you have to
understand the function of four different programs, but each of those four
programs are considerably simpler than sed or awk and the ways in which
they're being used are very common ones.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: removing /etc/hotplug.d/ support

[martin f krafft]

also sprach Gabor Gombas <[EMAIL PROTECTED]> [2005.08.24.2204 +0200]:
> So IMHO udev is more generic than hotplug.

This is Unix, not monolithic-land.

Also, udev was set out to do nothing other than device node
management.

> > The other comment is that udev is not generally accepted. A lot
> > of people still have reservations about it.
> 
> I think the reason is that udev is still under rapid development
> and people are only starting to explore the flexibility it
> provides.

Uh, that's one way of looking at it. The other might be sheer
insanity on the side of the developers.

> The question is will etch support 2.4 kernels out-of-the-box or not?

... which we can't answer yet.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"half a bee, philosophically,
 must ipso facto half not be."
 -- monty python


signature.asc
Description: Digital signature (GPG/PGP)

Re: removing /etc/hotplug.d/ support

[Gabor Gombas]

On Wed, Aug 24, 2005 at 06:23:37PM +0200, Julien BLACHE wrote:

> To be honest, I installed a laptop the other day, and udev works well
> on it (sarge with a 2.6.12 kernel); but I probably won't be able to
> upgrade the kernel without running into problems with udev, which is a
> total pain.

I only know of one major upgrade problem related to pre- and post-2.6.12
kernels and pre- and post-0.60 udev that was due to an unfortunate
libsysfs bug that did not get detected early enough.

The problem as I see it is that the in-kernel hotplug support is still
incomplete so people working on hotplug support are likely to use both
the latest kernel and latest user-space tools. This means cross-version
problems won't be detected until non-developers start to use the code.

> If only upstream could be a bit more stable. What are we going to get
> next month ? Ah yes, usbfs being deprecated in favor of udev and sysfs.

AFAIK the idea is to deprecate everything under /proc which is not
strictly process-related information, but that transition will take many
years (if ever completed, which I somewhat doubt).

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: removing /etc/hotplug.d/ support

[Gabor Gombas]

On Wed, Aug 24, 2005 at 05:36:43PM +0200, martin f krafft wrote:

> I have two comments: udev is a device node manager, not a hook
> system for generic actions to be taking when a device is plugged or
> unplugged. RUN rules kinda make this possible, but udev is on the
> right track of doing the wrong thing (i.e. too much).

Well, I have a different view: udev is a program to receive kernel
events and evaluate/execute different rules based on the event, and it
comes with a default ruleset to manage /dev nodes. hotplug is a
program to receive kernel events and has a hardcoded way to execute some
scripts based on these events.

So IMHO udev is more generic than hotplug.

> The other comment is that udev is not generally accepted. A lot of
> people still have reservations about it.

I think the reason is that udev is still under rapid development and
people are only starting to explore the flexibility it provides.

> Moreover, several setups
> cannot be migrated to udev just like that, including 2.4 kernels,

The question is will etch support 2.4 kernels out-of-the-box or not?
If it will, then it is indeed a problem; otherwise it is just to be
mentioned in the release notes.

> but also machines with devices not supporting the new kernel driver
> model (e.g. commercial drivers).

As I see many Linux distributions are starting to use udev so commercial
drivers will have to catch up in the not-so-distant future. Also, there
are some quite easy workarounds (like creating device nodes in an init
script) for most of the drivers.

> Using udev is a decision that
> affects large other parts of the system and may break it.

Yes, that's true. It has a lot of potential however that may worth some
breakage, especially since we are quite early in the release cycle.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: invalid-arch-string-in-source-relation amd64

[Shaun Jackman]

2005/8/24, Tollef Fog Heen <[EMAIL PROTECTED]>:
> * Shaun Jackman
> 
> | What's wrong with this Build-Depends line?
> |
> | Build-Depends: ia32-libs-dev [amd64], debhelper (>= 4.1.16)
> 
> Unless eagle is a toolchain package, you shouldn't build-dep on
> ia32-libs-dev.  ia32-libs-dev is a helper package to bootstrap biarch
> compilers, and not suitable for general development.

eagle (the package on topic) is a binary non-free i386 package. I was
told that it needs a build dependency on ia32-libs-dev for
dh_shlibdeps. The relevant bug is #306312.

Cheers,
Shaun

Bug #306312: eagle: FTBFS (amd64): Please add amd64 support
Package: eagle
Version: 4.11-8
Severity: wishlist
Tags: patch

When building 'eagle' on amd64/unstable,
I get the following error:

dh_shlibdeps
/usr/bin/ldd: line 171: /lib/ld-linux.so.2: No such file or directory
ldd: /lib/ld-linux.so.2 exited with unknown exit code (127)
dpkg-shlibdeps: failure: ldd on `debian/tmp/usr/share/eagle/bin/eagle'
gave error exit status 1
dh_shlibdeps: command returned error code 256
make: *** [binary-arch] Error 1

With the attached patch 'eagle' can be compiled on amd64.

Regards
Andreas Jochens

Re: better init.d/* : who carres ?

[Humberto Massa Guimarães]

** Peter Palfrader ::
> > mysqld_get_param () {
> > /usr/sbin/mysqld --print-defaults |
> > sed -ne "s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p"
> > }
> 
> And harder to read.  Making scripts more complex and harder to
> read for some dubious efficiency is not a good idea in my opinion.

I respectfully disagree, especially in the example case, in the
following counts:

1. In the example case, we have four pipes (five concurrent
processes), and here we have only one, which I think settles the
performance gain in the "non-dubious" zone.

2. In the example case, one regexp in the sed command-line explains
quite clearly what you want to extract from the output of
print-defaults, which I think settles the case for the "making
scripts more complex and harder to read". I was still in doubt of
what the script extracted from the output of print-defaults until I
saw the regexp.

If I was the DD in charge, I would apply the patch.

--
HTH,
Massa


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: better init.d/* : who carres ?

[sean finney]

On Wed, Aug 24, 2005 at 05:22:32PM +0100, Andrew Porter wrote:
> > /usr/sbin/mysqld --print-defaults \
> > | tr " " "\n" \
> > | grep -- "--$1" \
> > | tail -n 1 \
> > | cut -d= -f2
> 
> is harder to read than
> 
> >  /usr/sbin/mysqld --print-defaults |
> >  sed -ne "s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p"
> 
> Both require knowledge of a particular tools - one only one tool though.

that's not completely true, unless knowledge of sed also implies a good
understanding of posix regular expressions, in which case i wouldn't be
so hasty to claim it was easier to understand.

however, all of this notwithstanding, if someone takes the time to
submit a patch similar to this it will probably be included.

> Of course this would all be so much simpler if we could actually use the
> power of modern shells (post 1993) in init scripts - subprocesses
> wouldn't be required at all

it is a /bin/bash script, so i suppose bashisms are allowed, provided
that there aren't other reasons christian or i would object to them.


sean

-- 


signature.asc
Description: Digital signature

Re: Results of the meeting in Helsinki about the Vancouver proposal

[W. Borgert]

Quoting Peter 'p2' De Schrijver <[EMAIL PROTECTED]>:
> Most packages are not tested automatically at all.

Unfortunately not.

> Most cross compiled software also runs 24/7. I have yet to see problems
> produced by cross compiling the code.
...
> I don't think the risk is real considering the amount of cross compiled
> software already running in the world.

Yes.  In "my" company we rely heavily on cross-compilation, because
our target environment is not (meant to be) self-hosting.  There is
absolutely no problem in terms of stability, that is related to the
cross-compilation.  Sometimes we ran into gcc bugs, but those were
not only in the cross cc.

Cheers, WB


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: removing /etc/hotplug.d/ support

[Julien BLACHE]

[EMAIL PROTECTED] (Marco d'Itri) wrote:

[/etc/hotplug.d being deprecated in favour of udev RUN rules]

> I'd like to know your opinion about speeding up the transition and
> removing right now support for hotplug.d/ in your packages, making them
> depend on udev.

Two points:

 - I am tired of having to revamp the hotplugging framework every
other month;

 - I don't want to see udev being forced upon our users if a clear,
working and transparent upgrade path is not provided for each new
version of udev from now on.


To be honest, I installed a laptop the other day, and udev works well
on it (sarge with a 2.6.12 kernel); but I probably won't be able to
upgrade the kernel without running into problems with udev, which is a
total pain.

udev RUN rules at least guarantee that the device node exists when the
script is run, which is definitely an improvement.


If only upstream could be a bit more stable. What are we going to get
next month ? Ah yes, usbfs being deprecated in favor of udev and sysfs.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: better init.d/* : who carres ?

[sean finney]

hi,

On Wed, Aug 24, 2005 at 04:50:40PM +0200, Marc Chantreux wrote:
> for example, in /etc/init.d/mysqld
> 
> mysqld_get_param() {
> /usr/sbin/mysqld --print-defaults \
> | tr " " "\n" \
> | grep -- "--$1" \
> | tail -n 1 \
> | cut -d= -f2
> }
> 
> can be written like :
> 
> mysqld_get_param () {
> local string=$( /usr/sbin/mysqld --print-defaults | grep -o -- "--$1=[^ 
> ]*" )
> echo ${string#*=}
> }

as a general rule, stuff like this can be reported as wishlist bugs
to the package in question (with patch attached).  i think in many cases
if what you are doing is replacing a set of hackish/semi-broken commands
with something simpler and more elegant, you'll have a good chance of
having the patch accepted.

in this case, however, you are reducing a set of simple and non-intensive
system commands from 5 to 3 (and possibly introducing some non-posixish
stuff according to Miquel).  i can't guarantee you christian or i would
bother to include it.  reduce it to one fairly understandable command and
maybe :)


sean



signature.asc
Description: Digital signature

Re: better init.d/* : who carres ?

[Andrew Porter]

On Wed, 2005-08-24 at 17:44 +0200, Peter Palfrader wrote:

I could debate with you whether

> /usr/sbin/mysqld --print-defaults \
> | tr " " "\n" \
> | grep -- "--$1" \
> | tail -n 1 \
> | cut -d= -f2

is harder to read than

>  /usr/sbin/mysqld --print-defaults |
>  sed -ne "s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p"

Both require knowledge of a particular tools - one only one tool though.
Once you have that knowledge I would suggest that the single command
version is easier to read (though I personally would use awk).
Also, in pursuit of faster boot times, the single process solution is
more keen.

Of course this would all be so much simpler if we could actually use the
power of modern shells (post 1993) in init scripts - subprocesses
wouldn't be required at all




signature.asc
Description: This is a digitally signed message part

Re: removing /etc/hotplug.d/ support

[martin f krafft]

also sprach Marco d'Itri <[EMAIL PROTECTED]> [2005.08.24.1752 +0200]:
> > I have two comments: udev is a device node manager, not a hook
> > system for generic actions to be taking when a device is plugged
> > or
> udev has also been the hotplug multiplexer for some time now.

Yeah. Horrible. Will udev become an editor and MTA too, maybe after
etch?

> 2.4 kernels will not be supported in etch,

I don't think this is an authoritative statement. At the moment,
some architectures do not work with 2.6.

> and we never tried to support proprietary drivers if doing so
> harms the rest of the system.

Apart from the tg3-and-related stuff, we never took active action
to make lives of those in need of proprietary drivers any more
difficult than it already is.

> Some people have reservations, but they appear to be driver more
> by emotion than by technical reasons.

Really? I have technical issues with udev-does-it-all, and I have
issues with the upstream decisions. On a technical level, udev is
too Gentoo for me, it's far from stable, and thus far from
non-optional integration into Debian. This is my two cents.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"the duration of passion is proportionate
 with the original resistance of the woman."
   -- honoré de balzac


signature.asc
Description: Digital signature (GPG/PGP)

Re: better init.d/* : who carres ?

[Peter Palfrader]

On Wed, 24 Aug 2005, Miquel van Smoorenburg wrote:

> >for example, in /etc/init.d/mysqld
> >
> >mysqld_get_param() {
> >/usr/sbin/mysqld --print-defaults \
> >| tr " " "\n" \
> >| grep -- "--$1" \
> >| tail -n 1 \
> >| cut -d= -f2
> >}
> >
> >can be written like :
> >
> >mysqld_get_param () {
> >local string=$( /usr/sbin/mysqld --print-defaults | grep -o --
> >"--$1=[^ ]*" )
> >echo ${string#*=}
> >}
> 
> So in this case, the solution below is better (and shorter):
> 
> mysqld_get_param () {
> /usr/sbin/mysqld --print-defaults |
> sed -ne "s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p"
> }

And harder to read.  Making scripts more complex and harder to read for
some dubious efficiency is not a good idea in my opinion.

-- 
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
messages preferred.| : :' :  The  universal
   | `. `'  Operating System
 http://www.palfrader.org/ |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#324861: ITP: pptpproxy -- a small app that forwards PPTP VPN connections through a Linux firewall

[Michel van der Klei]

On Wed, 2005-08-24 at 09:47 -0500, Graham Wilson wrote:
> X-Mitch IT-MailScanner: Found to be clean
> X-MailScanner-From: [EMAIL PROTECTED]
> 
> On Wed, Aug 24, 2005 at 03:41:10PM +0200, Michel van der Klei wrote:
> > * Package name: pptpproxy
> >   Version : 2.0
> >   Upstream Author : Emmanuel Mogenet <[EMAIL PROTECTED]>
> > * URL : http://www.mgix.com/pptpproxy
> > * License : Public Domain
> >   Description : a small app that forwards PPTP VPN connections through 
> > a Linux firewall
> > 
>  > pptpproxy is a good old forwarder daemon. It's most probably not as
> > elegant as a kernel+iptables based solutions, but it has the very
> > sizeable advantage of Working For Me. It's a "timesaver" for those who
> > are getting tired of trying to get iptables, ipchains  or whatever
> > it's called this week to properly forward PPTP through a Linux
> > firewall.
> 
> The Debian iptables package has existed since Mar 2000, which, if my
> math is correct, is a bit longer than a week. You'll proably want to
> change your long description.

That won't be that much of a problem 

I will change it in:

pptpproxy is a good old forwarder daemon. It's most probably not as
elegant as a kernel+iptables based solutions, but it has the very
sizeable advantage of Working For Me. It's a "timesaver" for those who
are getting tired of trying to get iptables to properly forward PPTP 
through a Linux firewall.

Michel van der Klei




signature.asc
Description: This is a digitally signed message part

Re: removing /etc/hotplug.d/ support

[Marco d'Itri]

On Aug 24, martin f krafft <[EMAIL PROTECTED]> wrote:

> I have two comments: udev is a device node manager, not a hook
> system for generic actions to be taking when a device is plugged or
udev has also been the hotplug multiplexer for some time now.

> The other comment is that udev is not generally accepted. A lot of
> people still have reservations about it. Moreover, several setups
> cannot be migrated to udev just like that, including 2.4 kernels,
> but also machines with devices not supporting the new kernel driver
> model (e.g. commercial drivers).
2.4 kernels will not be supported in etch, and we never tried to
support proprietary drivers if doing so harms the rest of the system.

Some people have reservations, but they appear to be driver more by
emotion than by technical reasons.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: WebSVN of svn.debian.org uses wrong encoding

[Martin v. Löwis]

Frans Pop wrote:
> Who cares what default it sets or not sets? The point is that it has no 
> way to determine the correct encoding for files in the svn repo.

That is not true. For file that have the svn:mime-type property, it
might be possible. For example, if the mime-type indicates it is XML,
then you can find the encoding from the contents of the file. In this
case, this would have helped.

There are repeated discussions whether a svn:charset property should be
introduced. I think this discussion always ended with the observation
that the mime-type property has values that are really media-types,
and that media-types can have parameters, such as the charset parameter.

If people really want to get proper web-rendering of Subversion
repositories, they should start using these properties; then websvn
should start dealing with them in a more convenient way.

Regards,
Martin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#318590: curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem

[Domenico Andreoli]

On Wed, Aug 24, 2005 at 04:23:19PM +0200, Marco d'Itri wrote:
> On Aug 24, Domenico Andreoli <[EMAIL PROTECTED]> wrote:
> 
> > in the meanwhile new packages can be built using the gnutls variant of
> > libcurl3. be aware that libcurl3 and libcurl3-gnutls currently cannot
> > be installed at the same time.
> What is the point then? They *will* be needed at the same time.
> If they cannot be installed on the same system then looks like you are
> wasting your time.

the conflict is temporary. as soon as curl is fixed with this regard the
conflict will be removed and the packages depending on libcurl3-gnutls
will be bugged to be rebuilt.

> That "solution", BTW is a disgusting hack.

Daniel will be surely happy to see better patches. regarding me,
i prefer disgusting over inexistent.

if only Daniel liked the idea of using plugins in curl... eh, Daniel?

> Again, there should be no reasons to need to use a openssl instead of
> gnutls. If some program really needs it, then it should be linked to a
> *special* libcurl-with-openssl library until it can be fixed.
> But the default should be to use gnutls.

gnutls is not mature, it has been just added. people willing to test
it and signal bugs are welcome.

-[ Domenico Andreoli, aka cavok
 --[ http://people.debian.org/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: removing /etc/hotplug.d/ support

[martin f krafft]

also sprach Marco d'Itri <[EMAIL PROTECTED]> [2005.08.24.1727 +0200]:
> I'd like to know your opinion about speeding up the transition and
> removing right now support for hotplug.d/ in your packages, making
> them depend on udev.

I have two comments: udev is a device node manager, not a hook
system for generic actions to be taking when a device is plugged or
unplugged. RUN rules kinda make this possible, but udev is on the
right track of doing the wrong thing (i.e. too much).

The other comment is that udev is not generally accepted. A lot of
people still have reservations about it. Moreover, several setups
cannot be migrated to udev just like that, including 2.4 kernels,
but also machines with devices not supporting the new kernel driver
model (e.g. commercial drivers). Using udev is a decision that
affects large other parts of the system and may break it. Requiring
users to make that decision in favour of udev just to use my
package (libphidgets) is a little over the top.

PS: no need to CC me, I read -devel.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"they that can give up essential liberty
 to obtain a little temporary safety
 deserve neither liberty nor safety."
  -- benjamin franklin


signature.asc
Description: Digital signature (GPG/PGP)

Re: better init.d/* : who carres ?

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Marc Chantreux  <[EMAIL PROTECTED]> wrote:
>there are a lot of things in /etc/init.d/*, and {pre,post}inst
>scripts that can be rewritten more efficiently ( i think ).
>
>for example, in /etc/init.d/mysqld
>
>mysqld_get_param() {
>/usr/sbin/mysqld --print-defaults \
>| tr " " "\n" \
>| grep -- "--$1" \
>| tail -n 1 \
>| cut -d= -f2
>}
>
>can be written like :
>
>mysqld_get_param () {
>local string=$( /usr/sbin/mysqld --print-defaults | grep -o --
>"--$1=[^ ]*" )
>echo ${string#*=}
>}
>
>that are not bugs so i wonder if package maintainers where pleased if i
>reportbug those lines as wishlist.

Make sure you use only POSIX features when doing this. I think
"grep -o" is a GNU extension, FreeBSD doesn't have it for example.

So in this case, the solution below is better (and shorter):

mysqld_get_param () {
/usr/sbin/mysqld --print-defaults |
sed -ne "s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p"
}

Mike.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

removing /etc/hotplug.d/ support

[Marco d'Itri]

Currently only a very small number of packages using the deprecated
/etc/hotplug.d/ interface is left.
Keeping hotplug.d/ support is both a waste of resources on every system
(multiple programs needs to be run for every event, even if they are not
needed) and makes the transition from hotplug to something+udev much
harder (see the current coldplug thread on debian-devel).
The alternative is for packages to install in /etc/udev/ a file
containing RUN rules. Packages cannot support both interfaces at the
same time, or they would receive the hotplug events two times when using
udev.

I'd like to know your opinion about speeding up the transition and
removing right now support for hotplug.d/ in your packages, making them
depend on udev.

-- 
ciao,
Marco


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: better init.d/* : who carres ?

[Ondrej Sury]

> that are not bugs so i wonder if package maintainers where pleased if i
> reportbug those lines as wishlist.

If you submit patch as wishlist, then it's ok (at least for me).

O.
-- 
Ondrej Sury <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: better init.d/* : who carres ?

[Francesco P. Lovergine]

On Wed, Aug 24, 2005 at 04:50:40PM +0200, Marc Chantreux wrote:
> that are not bugs so i wonder if package maintainers where pleased if i
> reportbug those lines as wishlist.
> 

Why not? a patch is a patch.

-- 
Francesco P. Lovergine


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

better init.d/* : who carres ?

[Marc Chantreux]

Hi all,

there are a lot of things in /etc/init.d/*, and {pre,post}inst
scripts that can be rewritten more efficiently ( i think ).

for example, in /etc/init.d/mysqld

mysqld_get_param() {
/usr/sbin/mysqld --print-defaults \
| tr " " "\n" \
| grep -- "--$1" \
| tail -n 1 \
| cut -d= -f2
}

can be written like :

mysqld_get_param () {
local string=$( /usr/sbin/mysqld --print-defaults | grep -o -- "--$1=[^ ]*" 
)
echo ${string#*=}
}

that are not bugs so i wonder if package maintainers where pleased if i
reportbug those lines as wishlist.

can you advice me? 

regards
mc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: how to fully replace another package

[Marco d'Itri]

On Aug 24, Ben Armstrong <[EMAIL PROTECTED]> wrote:

> > This is not strictly needed, but I cannot avoid it until udev will
> > become mandatory to have hotplug support (is there a consensus on this?).
> Could udev be modified to not run the hotplug.d handlers
> if /sbin/hotplug is missing?  (Or is that even the right thing to do?)
It's not, the problem is that some other packages install their handler
there instead of just using an udev RUN rule, this is why I'm still
supporting hotplug.d/.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#324861: ITP: pptpproxy -- a small app that forwards PPTP VPN connections through a Linux firewall

[Graham Wilson]

On Wed, Aug 24, 2005 at 03:41:10PM +0200, Michel van der Klei wrote:
> * Package name: pptpproxy
>   Version : 2.0
>   Upstream Author : Emmanuel Mogenet <[EMAIL PROTECTED]>
> * URL : http://www.mgix.com/pptpproxy
> * License : Public Domain
>   Description : a small app that forwards PPTP VPN connections through a 
> Linux firewall
> 
> pptpproxy is a good old forwarder daemon. It's most probably not as
> elegant as a kernel+iptables based solutions, but it has the very
> sizeable advantage of Working For Me. It's a "timesaver" for those who
> are getting tired of trying to get iptables, ipchains  or whatever
> it's called this week to properly forward PPTP through a Linux
> firewall. 

The Debian iptables package has existed since Mar 2000, which, if my
math is correct, is a bit longer than a week. You'll proably want to
change your long description.

-- 
gram


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: how to fully replace another package

[Ben Armstrong]

On Wed, 2005-08-24 at 16:30 +0200, Marco d'Itri wrote:
> On udev systems events are received by udevd, either using udevsend or
> (when the kernel input subsystem will be fixed) a netlink socket.
> /sbin/hotplug does not enter in the picture at all.
> 
> Then the default udev configuration will run the hotplug.d/ handlers.

Aha!  OK.  That makes it perfectly clear.  So the mere existence of the
default handler causes it to be run, and there's no way to stop that
without purging it.  This seems like a very bad design.

> This is not strictly needed, but I cannot avoid it until udev will
> become mandatory to have hotplug support (is there a consensus on this?).

Could udev be modified to not run the hotplug.d handlers
if /sbin/hotplug is missing?  (Or is that even the right thing to do?)

> > 3a. if a specific handler isn't found, any handler(s) in the default
> > directory are called
> No, default handlers are always run.

Doh!  Stupid me.  That's evident now in a reread of the code *and* GKH
even says so in his comments.

Thanks for clarifying the nature of the problem.

Ben


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Peter 'p2' De Schrijver]

> > > * By using a cross-compiler, by definition you use a compiler that is
> > >   not the same as the default compiler for your architecture. As such,
> > >   your architecture is no longer self-hosting. This may introduce bugs
> > >   when people do try to build software for your architecture natively
> > >   and find that there are slight and subtle incompatibilities.
> > > 
> > 
> > I have never seen nor heared about such a case. IME this is extremely
> > rare (if it happens at all).
> 
> Do you want to take the chance of finding out the hard way after having
> built 10G (or more) worth of software?
> 

I don't see why the risk would be higher compared to native compilation.

> This is not a case of embedded software where you cross-compile
> something that ends up on a flash medium the size of which is counted in
> megabytes; this is not a case of software which is being checked and

Some embedded software is fairly extensive and runs from HD.

> tested immediately after compilation and before deployment. This is a

Most packages are not tested automatically at all.

> whole distribution. Subtle bugs in the compiler may go unnoticed for a
> fair while if you don't have machines that run that software 24/7. If

Only a very tiny fraction of the software in debian runs 24/7 on debian
machines.

> you replace build daemons by cross-compiling machines, you lose machines
> that _do_ run the software at its bleeding edge 24/7, and thus lose
> quite some testing. It can already take weeks as it is to detect and

Most cross compiled software also runs 24/7. I have yet to see problems
produced by cross compiling the code.

> track down subtle bugs if they creep up in the toolchain; are you
> willing to make it worse by delaying the time of detection like that?
> 

They wouldn't necessarily show up any faster in native builds. 

> I'm not saying this problem is going to hit us very often. I do say this
> is going to hit us at _some_ point in the future; maybe next year, maybe
> in five years, maybe later; in maintaining autobuilder machines over the
> past four years, I've seen enough weird and unlikely problems become
> reality to assume murphy's law holds _quite_ some merit here. The
> important thing to remember is that this is a risk that is real, and
> that should be considered _before_ we blindly switch our build daemons
> to cross-compiling machines.
> 

I don't think the risk is real considering the amount of cross compiled
software already running in the world.

Cheers,

Peter (p2).


signature.asc
Description: Digital signature

Re: curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem

[Marco d'Itri]

On Aug 24, Domenico Andreoli <[EMAIL PROTECTED]> wrote:

> in the meanwhile new packages can be built using the gnutls variant of
> libcurl3. be aware that libcurl3 and libcurl3-gnutls currently cannot
> be installed at the same time.
What is the point then? They *will* be needed at the same time.
If they cannot be installed on the same system then looks like you are
wasting your time.

That "solution", BTW is a disgusting hack.

Again, there should be no reasons to need to use a openssl instead of
gnutls. If some program really needs it, then it should be linked to a
*special* libcurl-with-openssl library until it can be fixed.
But the default should be to use gnutls.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: how to fully replace another package

[Marco d'Itri]

On Aug 24, Ben Armstrong <[EMAIL PROTECTED]> wrote:

> 1. kernel hotplug subsystem detects an event
> 2. kernel dispatches the event handling using the program named
> in /proc/sys/kernel/hotplug (default is /sbin/hotplug) passing it any
> necessary argument(s) to hotplug
> 3. /sbin/hotplug dispatches the request to the appropriate handler named
> in the first argument
On udev systems events are received by udevd, either using udevsend or
(when the kernel input subsystem will be fixed) a netlink socket.
/sbin/hotplug does not enter in the picture at all.

Then the default udev configuration will run the hotplug.d/ handlers.
This is not strictly needed, but I cannot avoid it until udev will
become mandatory to have hotplug support (is there a consensus on this?).

> 3a. if a specific handler isn't found, any handler(s) in the default
> directory are called
No, default handlers are always run.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Andreas Barth]

* Olaf van der Spek ([EMAIL PROTECTED]) [050824 15:52]:
> On 8/24/05, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
> > | Wouldn't that at least catch the non-platform-specific bugs?
> > 
> > They are usually caught fairly quickly.  The problem here is what to
> > do in the cases where nobody cares enough about the port to fix
> > toolchain breakages which only affect that arch.  If we have a broken

> 'Officially' ignore the port until it's solved?

Ah, and that's just what this proposal is about.


Cheers,
Andi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: arch, svn, cvs

[Florian Weimer]

* Francesco P. Lovergine:

> Comparing svn and arch is like comparing apples and tomatos. They have
> completely different purposes (i.e. centralized vs distributed).

The purpose is the same (collaboration ona code base), only the means
are quite different.  The available implemnetations also involve
different trade-offs.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem

[Domenico Andreoli]

On Fri, Aug 19, 2005 at 12:07:09PM +1000, Paul TBBle Hampson wrote:
> On Thu, Aug 18, 2005 at 11:00:41AM +0200, Domenico Andreoli wrote:
> >   with curl 7.14.0-5 currently in incoming, i added two new packages
> > libcurl3-gnutls and libcurl3-gnutls-dev. libcurl3 and libcurl3-gnutls
> > conflict each other since both install libcurl.so.3.0.0 in /usr/lib/.
> 
> If the problem is that using gnutls or openssl changes the ABI for libcurl,
> then they should have different sonames. (I'd expect the newer one, gnuTLS,
> would get its own soname, so that existing packages work, and packages can
> optionally build against the gnuTLS version if they so wish. Once everything
> builds happily against the gnuTLS version, the next upstream soname bump can
> use the gnuTLS library, and we're compatible with other distributions again.)

problem is right the change of ABI.

Daniel Stenberg (the upstream developer) is available to implement a
solution based on the proposal of Richard Atterer [0].

in the meanwhile new packages can be built using the gnutls variant of
libcurl3. be aware that libcurl3 and libcurl3-gnutls currently cannot
be installed at the same time.

cheers
domenico

[0] http://curl.haxx.se/mail/lib-2005-08/0118.html

-[ Domenico Andreoli, aka cavok
 --[ http://people.debian.org/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Olaf van der Spek]

On 8/24/05, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 24, 2005 at 02:13:50PM +0200, Peter 'p2' De Schrijver wrote:
> Do you want to take the chance of finding out the hard way after having
> built 10G (or more) worth of software?
>
> This is not a case of embedded software where you cross-compile
> something that ends up on a flash medium the size of which is counted in
> megabytes; this is not a case of software which is being checked and
> tested immediately after compilation and before deployment. This is a
> whole distribution. Subtle bugs in the compiler may go unnoticed for a
> fair while if you don't have machines that run that software 24/7. If
> you replace build daemons by cross-compiling machines, you lose machines

Instead of replacing machines you could add cross-compiling machines
to detect bugs earlier if the native machines can't keep up with
(speculative) compiling to find (toolchain) bugs.

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Olaf van der Spek]

On 8/24/05, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
> | Wouldn't that at least catch the non-platform-specific bugs?
> 
> They are usually caught fairly quickly.  The problem here is what to
> do in the cases where nobody cares enough about the port to fix
> toolchain breakages which only affect that arch.  If we have a broken

'Officially' ignore the port until it's solved?

Bug#324861: ITP: pptpproxy -- a small app that forwards PPTP VPN connections through a Linux firewall

[Michel van der Klei]

Package: wnpp
Severity: wishlist
Owner: Michel van der Klei <[EMAIL PROTECTED]>

* Package name: pptpproxy
  Version : 2.0
  Upstream Author : Emmanuel Mogenet <[EMAIL PROTECTED]>
* URL : http://www.mgix.com/pptpproxy
* License : Public Domain
  Description : a small app that forwards PPTP VPN connections through a 
Linux firewall

pptpproxy is a good old forwarder daemon. It's most probably not as elegant as 
a kernel+iptables 
based solutions, but it has the very sizeable advantage of Working For Me. It's 
a "timesaver" for 
those who are getting tired of trying to get iptables, ipchains  or whatever 
it's called this week 
to properly forward PPTP through a Linux firewall. 


-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Tollef Fog Heen]

* Olaf van der Spek 

| On 8/24/05, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
| > * Olaf van der Spek
| > 
| > | I understand most maintainers don't try the new toolchain themselves,
| > | but wouldn't it be possible for someone else to build the entire
| > | archive (or parts of it by multiple people) and (automatically) report
| > | bugs?
| > 
| > With the toolchain, it won't help to just rebuild the archive on a
| > fast architecture: A single AMD64 system can rebuild the archive in a
| > couple of days, but few other architectures can.
| 
| Wouldn't that at least catch the non-platform-specific bugs?

They are usually caught fairly quickly.  The problem here is what to
do in the cases where nobody cares enough about the port to fix
toolchain breakages which only affect that arch.  If we have a broken
toolchain across all architectures, it's something different.

| And what about cross-compiling?

Cross-compilation is prone to failures and not really a good
solution.  This has been discussed here a lot before.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Michael Banck]

On Wed, Aug 24, 2005 at 02:13:50PM +0200, Peter 'p2' De Schrijver wrote:
> > * Many packages don't support cross-compiling, and those that do may
> >   have bugs in their makefiles that make cross-compiling either harder
> >   or impossible.
> > * You can't run the test suites of the software you're compiling, at
> >   least not directly.
> > * There's a serious problem with automatically installing
> >   build-dependencies. Dpkg-cross may help here, but there's no
> >   apt-cross (at least not TTBOMK); and implementing that may or may not
> >   be hard (due to the fact that build-dependencies do not contain
> >   information about whether a package is an arch:all package or not).
> 
> scratchbox solves these problems.

[...]

> Which is why scratchbox is a more interesting solution, as it only runs
> those parts on target which can't be done on the host.

Sounds interesting.  Will you work on implementing this?


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Wouter Verhelst]

On Wed, Aug 24, 2005 at 02:13:50PM +0200, Peter 'p2' De Schrijver wrote:
> > * Many packages don't support cross-compiling, and those that do may
> >   have bugs in their makefiles that make cross-compiling either harder
> >   or impossible.
> > * You can't run the test suites of the software you're compiling, at
> >   least not directly.
> > * There's a serious problem with automatically installing
> >   build-dependencies. Dpkg-cross may help here, but there's no
> >   apt-cross (at least not TTBOMK); and implementing that may or may not
> >   be hard (due to the fact that build-dependencies do not contain
> >   information about whether a package is an arch:all package or not).
> 
> scratchbox solves these problems.

As does distcc; that wasn't the point, these are just issues that occur
with cross-compilers.

> > * By using a cross-compiler, by definition you use a compiler that is
> >   not the same as the default compiler for your architecture. As such,
> >   your architecture is no longer self-hosting. This may introduce bugs
> >   when people do try to build software for your architecture natively
> >   and find that there are slight and subtle incompatibilities.
> > 
> 
> I have never seen nor heared about such a case. IME this is extremely
> rare (if it happens at all).

Do you want to take the chance of finding out the hard way after having
built 10G (or more) worth of software?

This is not a case of embedded software where you cross-compile
something that ends up on a flash medium the size of which is counted in
megabytes; this is not a case of software which is being checked and
tested immediately after compilation and before deployment. This is a
whole distribution. Subtle bugs in the compiler may go unnoticed for a
fair while if you don't have machines that run that software 24/7. If
you replace build daemons by cross-compiling machines, you lose machines
that _do_ run the software at its bleeding edge 24/7, and thus lose
quite some testing. It can already take weeks as it is to detect and
track down subtle bugs if they creep up in the toolchain; are you
willing to make it worse by delaying the time of detection like that?

I'm not saying this problem is going to hit us very often. I do say this
is going to hit us at _some_ point in the future; maybe next year, maybe
in five years, maybe later; in maintaining autobuilder machines over the
past four years, I've seen enough weird and unlikely problems become
reality to assume murphy's law holds _quite_ some merit here. The
important thing to remember is that this is a risk that is real, and
that should be considered _before_ we blindly switch our build daemons
to cross-compiling machines.

I'm not even saying I oppose to using cross-compilers; it's just that
the idea of "slow architectures' build daemons are slow, but luckily
there's an easy solution; we can replace them by fast machines that do
cross-compiling" is blatantly incorrect.

> The only way to know if this is a real problem is to try using cross
> compiling and verify against existing native compiled binaries.

That's not much help. We need to test this continuously, not just once a
tiny little bit and then never again. If you need to compare against
natively built packages, you'll need build daemons anyway; so what's the
point then?

> Unfortunately the verify bit is quite annoying as a simple cmp will
> likely fail because of things like build date, build number, etc
> included in the binary.

Well, that makes it even less of a help.

> For packages which have a testsuite, this testsuite could be used as
> the verification step. 

Sure -- but the number of packages that have a reliable testsuite is
miserably low.

> > Hence the point of trying out distcc in the post to d-d-a; that will fix
> > the first three points here, but not the last one. But it may not be
> > worth the effort; distcc runs cc1 and as on a remote host, but cpp and
> > ld are still being run on a native machine. Depending on the program
> > being compiled, this may take more time than expected.
> 
> Which is why scratchbox is a more interesting solution, as it only runs
> those parts on target which can't be done on the host.

I'm not so sure I agree with you on that one. Speed is just one part of
the story; quality is another. The more you run natively, the more bugs
you'll find.

But I guess I can have a look at scratchbox before I say no to it.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: vancouver revisited

[Michael Banck]

On Wed, Aug 24, 2005 at 10:46:18AM +0200, Sven Luther wrote:
> You know, the wording of the original vancouver document, as well as the
> mood of the discussion that followed it seems to be pretty near such a madman
> scenario, so ...

You misunderstood.  'Madman scenario' as in the respective teams would
get mad, not the people discussing the proposal.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: how to fully replace another package

[Ben Armstrong]

On Tue, 2005-08-23 at 10:00 +0200, Marco d'Itri wrote:
> Right, it's not used but it's checked.
> But then there is still /etc/hotplug.d/default/default.hotplug, which if
> present will create all kinds of troubles.

Let me get one more thing straight before we move on ...

What's the sequence of calls that leads to this code being invoked?
Somehow I thought it was like this:

1. kernel hotplug subsystem detects an event
2. kernel dispatches the event handling using the program named
in /proc/sys/kernel/hotplug (default is /sbin/hotplug) passing it any
necessary argument(s) to hotplug
3. /sbin/hotplug dispatches the request to the appropriate handler named
in the first argument
3a. if a specific handler isn't found, any handler(s) in the default
directory are called

So doesn't this all fail if /sbin/hotplug is missing?  And if that is
so, why is this a problem if the hotplug package is removed but not
purged?

Or does your coldplug package provide a /sbin/hotplug that still
reads /etc/hotplug.d, and if so, why?

I do see that on a udev system, /proc/sys/kernel/hotplug is something
else (/sbin/udevsend).  Is that part of the problem?  If so, how?

Ben


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [PATCH] Simple parallellized boot sequence (and a plea for LSB complience)

[Jon Dowland]

On Wed, Aug 24, 2005 at 08:52:36AM +0200, Tollef Fog Heen wrote:
> If you have an USB mouse, you need to have the driver for it loaded
> before starting gdm (or the boot will fail), if it uses Xdmcp for
> connecting to a terminal server, it will need networking to be up (and
> so on).

This is the net result of a few broken behaviours in X, though. X should
not mandate the use of a mouse.

With a 2.6 kernel, you should set your mouse device to /dev/input/mice.
This device should exist even if there are no mice in the system (just
not give out any events, obviously). I think right now it doesn't.

-- 
Jon Dowland   http://jon.dowland.name/
FD35 0B0A C6DD 5D91 DB7A  83D1 168B 4E71 7032 F238


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Peter 'p2' De Schrijver]

> * Many packages don't support cross-compiling, and those that do may
>   have bugs in their makefiles that make cross-compiling either harder
>   or impossible.
> * You can't run the test suites of the software you're compiling, at
>   least not directly.
> * There's a serious problem with automatically installing
>   build-dependencies. Dpkg-cross may help here, but there's no
>   apt-cross (at least not TTBOMK); and implementing that may or may not
>   be hard (due to the fact that build-dependencies do not contain
>   information about whether a package is an arch:all package or not).

scratchbox solves these problems.

> * By using a cross-compiler, by definition you use a compiler that is
>   not the same as the default compiler for your architecture. As such,
>   your architecture is no longer self-hosting. This may introduce bugs
>   when people do try to build software for your architecture natively
>   and find that there are slight and subtle incompatibilities.
> 

I have never seen nor heared about such a case. IME this is extremely 
rare (if it happens at all). The only way to know if this is a real
problem is to try using cross compiling and verify against existing
native compiled binaries. Unfortunately the verify bit is quite annoying
as a simple cmp will likely fail because of things like build date,
build number, etc included in the binary. For packages which have a testsuite, 
this testsuite could be used as the verification step. 

> Hence the point of trying out distcc in the post to d-d-a; that will fix
> the first three points here, but not the last one. But it may not be
> worth the effort; distcc runs cc1 and as on a remote host, but cpp and
> ld are still being run on a native machine. Depending on the program
> being compiled, this may take more time than expected.
> 

Which is why scratchbox is a more interesting solution, as it only runs
those parts on target which can't be done on the host.

Cheers,

Peter (p2).


signature.asc
Description: Digital signature

CURSO INTERATIVO HP12C

[carlos santos]

Senhores,

Solicito informações de como proceder o download do
CURSO INTERATIVO HP12C

Att
Carlos

__
Converse com seus amigos em tempo real com o Yahoo! Messenger 
http://br.download.yahoo.com/messenger/ 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Wouter Verhelst]

On Wed, Aug 24, 2005 at 11:42:28AM +0200, Olaf van der Spek wrote:
> And what about cross-compiling?

Cross-compiling is no magic wand that can save us from the slow
architectures. There are quite a number of problems with
cross-compiling:

* Many packages don't support cross-compiling, and those that do may
  have bugs in their makefiles that make cross-compiling either harder
  or impossible.
* You can't run the test suites of the software you're compiling, at
  least not directly.
* There's a serious problem with automatically installing
  build-dependencies. Dpkg-cross may help here, but there's no
  apt-cross (at least not TTBOMK); and implementing that may or may not
  be hard (due to the fact that build-dependencies do not contain
  information about whether a package is an arch:all package or not).
* By using a cross-compiler, by definition you use a compiler that is
  not the same as the default compiler for your architecture. As such,
  your architecture is no longer self-hosting. This may introduce bugs
  when people do try to build software for your architecture natively
  and find that there are slight and subtle incompatibilities.

Hence the point of trying out distcc in the post to d-d-a; that will fix
the first three points here, but not the last one. But it may not be
worth the effort; distcc runs cc1 and as on a remote host, but cpp and
ld are still being run on a native machine. Depending on the program
being compiled, this may take more time than expected.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: vancouver revisited

[Gustavo Noronha Silva]

[Please do not CC me, I'm on the list]

Em Qua, 2005-08-24 às 11:36 +0100, Alastair McKinstry escreveu:
> Yes, there is: one of the more frequent uses of minority architectures 
> is diversity in internet-facing machines: I've run sparc, powerpc and 
> MIPs machines in this role, and am currently running linksys (mips) box 
> as my firewall / gateway / DMZ (doing more than that, of course). The 
> security and stability of stable is whats important to me: it'll never 
> run X or mozilla ;-)

So you're saying you would miss the security support and 'versions won't
change' properties of the release?

I believe the porters themselves could work with the security and
release teams and do their own release, and keep tracking the security
fixes and stuff themselves, if they don't get to meet the requirements.

Meeting the requirements, though, would be a more important goal; so
just doing a good job of maintaining the port can take you there.

> For this reason I think its important to work on the underlying _real_ 
> techincal problem: some way of fixing the toolchain issues that make 
> having the archs a problem. Solutions such as autobuilding the arch with 
> upcoming toolchains in experimental, pulling more test suites into the 
> build so that the packages are not just built but run on the archs, etc.

Such automatic stuff is not fully helpful; if porters want an arch
surviving as a release arch they sure can step up and do the work.

What I see in this whole proposal is not a "we don't want these arches
supported" mindset, but a "we need to improve the day-to-day maintaince
of our work on all arches, or our release will keep suffering"
translating to "porters, do a better work, you're overloading us".

See ya,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



signature.asc
Description: This is a digitally signed message part

Re: Using buildds only

[Wouter Verhelst]

On Wed, Aug 24, 2005 at 09:23:59AM +0200, Martin Pitt wrote:
> Hi! 
> 
> Goswin von Brederlow [2005-08-23 21:54 +0200]:
> > You have to keep the chroot up-to-date manualy anyway as sbuild does
> > not upgrade unless a Build-Depends requires a newer version
> > specificaly.
> 
> That's not true for Ubuntu's buildds, they are upgraded daily. I guess
> with the amount of new compilers that were uploaded in the last weeks,
> there is no other choice anyway.
> 
> I'm surprised how Debian can get away without doing that. So buildd
> admins need to manually watch for toolchain updates and install them?

Well, yes and no. As said, the toolchain does get updated by direct and
indirect dependencies without manual intervention. It's just in cases
where things break that updates *have* to be done manually (such as with
glibc 2.5.3-3, or the recent switch to gcc 4.0). Other than that, a
buildd chroot will not usually contain libraries that are more than a
few weeks (if that much) out of date IME.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: vancouver revisited

[Alastair McKinstry]

Gustavo Noronha Silva wrote:


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 things, most of
the times, either.

See ya,

 

Yes, there is: one of the more frequent uses of minority architectures 
is diversity in internet-facing machines: I've run sparc, powerpc and 
MIPs machines in this role, and am currently running linksys (mips) box 
as my firewall / gateway / DMZ (doing more than that, of course). The 
security and stability of stable is whats important to me: it'll never 
run X or mozilla ;-)


This is why (some) people find the 'second class' nature of the 
Vancouver proposal so disturbing: not just whats happening now, but its 
cutting off such futures that we are working towards.


In my day job I am using Debian and openwrt (cut down Linux on linksys, 
etc) and with the resources on such boxes growing, and the ability to 
cut down linux (eg. replace glibc in base by ulibc, put base on a diet, 
etc.) we can forsee a time where Debian stable will run on such machines 
directly.
However dropping Mips, etc. would cause a stagnation: just when you get 
the Debian base to fit on the machines, Debian stable is no longer 
supported on them. This is what we want to avoid.


Hence its important to avoid this: while I appreciate the reluctance to 
have architectures with "no users" in the archive, its having Debian 
available on the arch that makes it feasible to use the arch in your 
next project, and bring the users.


For this reason I think its important to work on the underlying _real_ 
techincal problem: some way of fixing the toolchain issues that make 
having the archs a problem. Solutions such as autobuilding the arch with 
upcoming toolchains in experimental, pulling more test suites into the 
build so that the packages are not just built but run on the archs, etc.


Regards
Alastair


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [PATCH] Simple parallellized boot sequence (and a plea for LSB complience)

[Marc Haber]

On Mon, 22 Aug 2005 13:21:19 +0200, Petter Reinholdtsen
<[EMAIL PROTECTED]> wrote:
>On Mon, Aug 22, 2005 at 12:59:49PM +0200, Marc Haber wrote:
>> How about a recipe for doing so?
>
>Good idea.  Here is a quick and dirty draft based on my current
>understanding.

http://wiki.debian.net/?LSBInitScripts

Thanks for the document.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: arch, svn, cvs (was: Bug#323855: ITP: opencvs -- OpenBSD CVS implementation with special emphasis in security)

[Francesco P. Lovergine]

On Fri, Aug 19, 2005 at 02:22:26PM +0200, Marc Haber wrote:
> On Fri, 19 Aug 2005 13:06:49 +0200, "Steinar H. Gunderson"
> <[EMAIL PROTECTED]> wrote:
> >I'd love to see people migrating to Arch
> 
> Compared to SVN from the view of somebody who is acquainted with CVS,
> arch sucks badly. I tend to agree with most of the things that Florian
> Weimer lists on http://www.enyo.de/fw/software/arch/design-issues.html
> 

Comparing svn and arch is like comparing apples and tomatos. They have
completely different purposes (i.e. centralized vs distributed).

-- 
Francesco P. Lovergine


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Olaf van der Spek]

On 8/24/05, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
> * Olaf van der Spek
> 
> | I understand most maintainers don't try the new toolchain themselves,
> | but wouldn't it be possible for someone else to build the entire
> | archive (or parts of it by multiple people) and (automatically) report
> | bugs?
> 
> With the toolchain, it won't help to just rebuild the archive on a
> fast architecture: A single AMD64 system can rebuild the archive in a
> couple of days, but few other architectures can.

Wouldn't that at least catch the non-platform-specific bugs?
And what about cross-compiling?

Re: vancouver revisited

[Sven Luther]

On Mon, Aug 22, 2005 at 10:55:11AM +0200, Wouter Verhelst wrote:
> On Sun, Aug 21, 2005 at 10:16:53PM +0200, Peter 'p2' De Schrijver wrote:
> > > - security team, DSA, and release team must not veto inclusion
> > 
> > Arbitrary veto power. This requirement is unacceptable for me. Noone
> > should be allowed to just ignore other peoples work within the project.
> 
> This is one argument I do have sympathy for. In fact, I went to that
> meeting with the exact same thought.
> 
> The thing is, however, that you're dealing with a madman scenario:
> you're afraid that one day, a member of one of the above teams will go
> crazy and declare that they don't like this person that works on a port,
> or just that port entirely. Or, less extreme, you're afraid that a
> member of the above teams will make a judgement error and veto a port
> for bogus reasons.

You know, the wording of the original vancouver document, as well as the
mood of the discussion that followed it seems to be pretty near such a madman
scenario, so ...

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Andreas Barth]

Hi,

* GOTO Masanori ([EMAIL PROTECTED]) [050824 10:38]:
> At Sun, 21 Aug 2005 03:58:24 +0200,
> Wouter Verhelst wrote:
> > - must be a developer-accessible debian.org machine for the
> >   architecture
> 
> Does this part mean "developer-accessible machine is always usable for
> all debian developers"?  Does such machine have dchroot for
> old-stable/stable/unstable ?

It was definitly meant that way, yes.


Cheers,
Andi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Wouter Verhelst]

On Wed, Aug 24, 2005 at 05:04:40PM +0900, GOTO Masanori wrote:
> At Sun, 21 Aug 2005 03:58:24 +0200,
> Wouter Verhelst wrote:
> > - must be a developer-accessible debian.org machine for the
> >   architecture
> 
> Does this part mean "developer-accessible machine is always usable for
> all debian developers"?  Does such machine have dchroot for
> old-stable/stable/unstable ?
> 
> I want you to describe this part explicitly:
> 
>  - must be at least one development debian.org machine that is
>available for all debian developers (not restricted) for the
>architecutre.  dchroot for stable/unstable must be available on
>that machine.

For clarity: the list of items specified in that post was just the items
from the original proposal, rearranged in two lists.

We have not discussed this particular bit in detail; so I can't just go
ahead and start changing them -- but I'd say your modification would
make sense and sounds reasonable.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Tollef Fog Heen]

* Olaf van der Spek 

| I understand most maintainers don't try the new toolchain themselves,
| but wouldn't it be possible for someone else to build the entire
| archive (or parts of it by multiple people) and (automatically) report
| bugs?

With the toolchain, it won't help to just rebuild the archive on a
fast architecture: A single AMD64 system can rebuild the archive in a
couple of days, but few other architectures can.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Results of the meeting in Helsinki about the Vancouver proposal

[GOTO Masanori]

At Sun, 21 Aug 2005 03:58:24 +0200,
Wouter Verhelst wrote:
> - must be a developer-accessible debian.org machine for the
>   architecture

Does this part mean "developer-accessible machine is always usable for
all debian developers"?  Does such machine have dchroot for
old-stable/stable/unstable ?

I want you to describe this part explicitly:

 - must be at least one development debian.org machine that is
   available for all debian developers (not restricted) for the
   architecutre.  dchroot for stable/unstable must be available on
   that machine.

We, architecture specific package maintainers, including toolchain
package (gcc and glibc), frequently need to compile and test their
packages to support them (ex: new ABI and upstream release).  I
sometimes met such developer un-accessible architectures - developer
accessible machine is more important to keep each architecture usable.
IMO, such unmaintained architecture machines must be SCC, caused by
lazyness of porting teams.

Regards,
-- gotom


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: WebSVN of svn.debian.org uses wrong encoding

[W. Borgert]

Quoting Christian Perrier <[EMAIL PROTECTED]>:
> Several translation teams (including mine) still use Latin-1 as their
> default...but this is not a reason to still use Latin-1 as an overall
> default...:-)

Btw. I looked into the d-i manuals in SVN and some Western
European languages, e.g. German, are already in UTF-8.

Cheers, WB


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Can't we at least agree on Anti-Virus for our mail

[Richard A Nelson]

Just today 250+ viruses, mostly - clamd found the Worm.Mydoom.AT virus

These are coming from master/gluck, and being a good citizen, I'm just
dropping them on the floor (instead of creating backscatter).

I know there's been heated debate about which, if any RBLs and other
anti-spam tools to employ, but come on... an AV should be a no-brainer !

I'm personally running both clamav and f-prot with very nice results...
--
Rick Nelson
 I really don't want much at all...  Just a kind word, an
   attractive woman, and UNLIMITED BANDWIDTH!!


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: WebSVN of svn.debian.org uses wrong encoding

[Christian Perrier]

Quoting W. Borgert ([EMAIL PROTECTED]):

> I will do that, thanks for the hint!
> (However, my original plea for using UTF-8 in WebSVN remains.)


Which I support, BTW, even if I understand Frans arguments. Actually,
I support UTF-8 over ISO-8859-1 encoding when only one encoding is
possible, for barely one reason: there is no serious reason to be
"western european centric" and assume that Latin-1 is good enough.

Several translation teams (including mine) still use Latin-1 as their
default...but this is not a reason to still use Latin-1 as an overall
default...:-)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [PATCH] Simple parallellized boot sequence (and a plea for LSB complience)

[Petter Reinholdtsen]

[Tollef Fog Heen]
> This doesn't handle the case of dynamic dependencies:

That is correct.  So to handle those, one need to support override
files loaded from somewhere else.  This also make it possible to add
dependency info for scripts currently missing it.

I got a sketch package working as a replacement for sysv-rc,
reorganizing the order in rc#.d/, and running scripts in parallel.
Seem to work, but need more effort to get the dependencies right in
the override files.

Using this approach I am able to cut the boot time of the ltsp client
in qemu by 62%.

Please add dependency information to the init.d scripts to make it
easier to get this right.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using buildds only

[Martin Pitt]

Hi! 

Goswin von Brederlow [2005-08-23 21:54 +0200]:
> You have to keep the chroot up-to-date manualy anyway as sbuild does
> not upgrade unless a Build-Depends requires a newer version
> specificaly.

That's not true for Ubuntu's buildds, they are upgraded daily. I guess
with the amount of new compilers that were uploaded in the last weeks,
there is no other choice anyway.

I'm surprised how Debian can get away without doing that. So buildd
admins need to manually watch for toolchain updates and install them?

Thanks,

Martin
-- 
Martin Pitthttp://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org


signature.asc
Description: Digital signature

Re: Results of the meeting in Helsinki about the Vancouver proposal

[Anthony Towns]

On Tue, Aug 23, 2005 at 11:06:37PM -0700, Steve Langasek wrote:
> > (I mean, how does my proposal to drop the 'has users' requirement in favor 
> > of 'do we have developers' ignore the resource usage.  I certainly do not 
> > dispute that a port uses resources.)
> Ok, then perhaps it doesn't ignore it, but I don't believe that it
> addresses it adequately.  A 5GB repository on a central project machine,
> that adds to the maintenance load of DSA and the ftp-masters,

5GB? The archive's 140GB, so that's over 10GB per architecture on each
mirror, and there's additional space for old binaries that're kept around
in the morgue -- which is a little under 3GB per month per architecture;
we're keeping old debs around for between six months and a year atm,
so that's probably more like 34GB centrally and 10GB on mirrors.

The real problem, IMO, with not having users is that it becomes easy
to say "oh, well, no one's using it, doesn't matter if it stays broken
a while longer, I've got other things to do", or, worse, "this fix is
crucially needed for this architecture which no one users, sorry that
it breaks i386".

> > And even if:  would a userless port have the developers?  

Heh.

I thought there was going to be separate questions, something like: show
you've got 5-10 DDs who'll support and maintain the port, appropriate
upstream support for the toolchain, and ~50 actual users who'll use the
port for real life things.

(And that's the /general/ case, if s390 doesn't need 50 separate users
because it has 10 machines with 50 billion users each to justify its
existance, that's fine -- exceptions can be made to any of these sorts
of rules when appropriate)

Cheers,
aj


signature.asc
Description: Digital signature

Re: invalid-arch-string-in-source-relation amd64

[Tollef Fog Heen]

* Shaun Jackman 

| What's wrong with this Build-Depends line?
| 
| Build-Depends: ia32-libs-dev [amd64], debhelper (>= 4.1.16)

Unless eagle is a toolchain package, you shouldn't build-dep on
ia32-libs-dev.  ia32-libs-dev is a helper package to bootstrap biarch
compilers, and not suitable for general development.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]