Hello fellow developers,
On Thu, Apr 10, 2025 at 07:37:32AM +0200, Helmut Grohne wrote:
> how about libc6-dev stops depending on libcrypt-dev?
with minor disagreement in details, I have received much positive
feedback and therefore moved forward.
> So far so good. That's 1 + 95 + 1
Hi,
On 2025-04-10 07:37, Helmut Grohne wrote:
> Hello fellow developers,
[ Snip ]
> Question 1: Do you see important aspects missed in this analysis?
No
> Question 2: Do you agree that this change is worth the effort?
I don't know. I do not see a huge benefit from the glibc point of view,
bu
Hi Marco,
On Thu, Apr 10, 2025 at 11:01:24AM +0200, Marco d'Itri wrote:
> On Apr 10, Helmut Grohne wrote:
> > how about libc6-dev stops depending on libcrypt-dev?
> Sure.
Thanks for the feedback.
> > material of course. Also libc6-dev would still "Recommends:
>
On Thu, 10 Apr 2025 07:37:32 +0200, Helmut Grohne wrote:
I sorted those logs and
you may now find them at
https://people.debian.org/~helmutg/glibc-no-crypt/logs/.
Thanks.
Beyond that, 11
packages build a perl extension module for testing purposes and
therefore need "Build-Depends: perl-xs-de
hand:
- A recommends will only have some effect for people not having
libcrypt-dev installed yet, so people upgrading from trixie to forky
who have both libc6-dev and libcrypt-dev installed will not see the
libcrypt-dev package mysteriously removed from their systems.
- In general, Debian users are al
On Apr 10, Helmut Grohne wrote:
how about libc6-dev stops depending on libcrypt-dev?
Sure.
material of course. Also libc6-dev would still "Recommends:
libcrypt-dev", but libcrypt-dev would no longer be build-essential.
What purpose would this Recommends solve?
Assuming "n
On Thu, 10 Apr 2025 at 07:37:32 +0200, Helmut Grohne wrote:
how about libc6-dev stops depending on libcrypt-dev?
I think this is a good idea for early in the forky cycle.
I also investigated
all apt-cache rdepends libcrypt1. That results in 151 source packages.
...
* steam-installer
This
Hello fellow developers,
how about libc6-dev stops depending on libcrypt-dev?
I mean for real. We cannot do it right away. The proposal is forky
material of course. Also libc6-dev would still "Recommends:
libcrypt-dev", but libcrypt-dev would no longer be build-essential.
The ob
On Mon, Oct 31, 2022 at 04:42:00PM +0100, Markus wrote:
> Hi,
>
> Thank you for your answer.
>
> > If you used debootstrap or mmdebstrap to create your own chroot or
> > container that only includes bullseye, and not bullseye-security or
> > bullseye-updates, then
Hi,
Thank you for your answer.
> If you used debootstrap or mmdebstrap to create your own chroot or
> container that only includes bullseye, and not bullseye-security or
> bullseye-updates, then you would get libc6 (= 2.31-13+deb11u4) in
> the chroot/container, and libc6-dev (= 2.3
On Mon, 31 Oct 2022 at 11:21:57 +0100, Markus Ritzmann wrote:
> > The following packages have unmet dependencies:
> > libc6-dev : Depends: libc6 (= 2.31-13+deb11u4) but 2.31-13+deb11u5 is to be
> > installed
> > E: Unable to correct problems, you have held broken packages
Hi
Currently libc6-dev cannot be installed on bullseye because of unmet
dependencies.
Error message:
> The following packages have unmet dependencies:
> libc6-dev : Depends: libc6 (= 2.31-13+deb11u4) but 2.31-13+deb11u5 is to be
> installed
> E: Unable to correct problems, y
ing setlocale("C.UTF-8") trick.
> > >
> > > However, several libc6 version ago, that behavior changed, to the point
> > > node-iconv fails its tests now.
> > >
> > > I've failed to work around that, and i'm lacking libc6 knowledge to
> fix it,
On 2016-10-09 10:21:03 +0300, Lars Wirzenius wrote:
> On Sun, Oct 09, 2016 at 01:49:14AM +0200, Jérémy Lal wrote:
> > node-iconv used to be able to translit utf-8 chars (ça va) to ascii (ca va)
> > using setlocale("C.UTF-8") trick.
> >
> > However, several lib
On Sun, Oct 09, 2016 at 01:49:14AM +0200, Jérémy Lal wrote:
> node-iconv used to be able to translit utf-8 chars (ça va) to ascii (ca va)
> using setlocale("C.UTF-8") trick.
>
> However, several libc6 version ago, that behavior changed, to the point
> node-iconv fails
Hi,
node-iconv used to be able to translit utf-8 chars (ça va) to ascii (ca va)
using setlocale("C.UTF-8") trick.
However, several libc6 version ago, that behavior changed, to the point
node-iconv fails its tests now.
I've failed to work around that, and i'm lacking libc6
I compiled unstable with libc6 2.23 (2.23-0experimental0) from
experimental.
I filed the following build failures:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=2.23;users=debian-gl...@lists.debian.org
--
Martin Michlmayr
http://www.cyrius.com/
On Sun, Dec 07, 2014 at 01:08:24AM +0100, Timo Weingärtner wrote:
> A short-term fix for the dpkg errors could be to express the conflicting
> loader paths with Conflicts: between the relevant libc6 packages.
Have multiarch conflicts/breaks been specified already? Sure, this would not
On Sun, Dec 7, 2014 at 8:08 AM, Timo Weingärtner wrote:
> So I enabled architectures in dpkg, updated the package lists and tried
> installing libc6 packages for each architecture, but dpkg refused to unpack
> libc6:mipsel after libc6:powerpc had been installed, because both
> archi
Hi,
last week I tried exploiting multiarch to set up a machine to build and run
binaries for multiple architectures.
So I enabled architectures in dpkg, updated the package lists and tried
installing libc6 packages for each architecture, but dpkg refused to unpack
libc6:mipsel after libc6
On Fri, Jan 18, 2013 at 10:11:50AM -0600, Paul Johnson wrote:
>
> $ dpkg -l | grep libc6
> ii libc6:amd64 2.13-37 amd64
> ii libc6:i3862.13-37 i386
> ii libc6-amd64 2.13-37 i386
> ii libc6-i3862.13-37 amd64
So you basicly have libc6 installed 4 times, twice
After
that, some Debian packages could be rebuilt, but the installer
refused, complaining about dependency on libc6-amd64.
While banging on that system to try to work it out, I did something
that completely broke the system. I mean, I completely broke it,
nothing would run, not "ls" no
/debian/control2012-10-28 00:23:38.0 +0200
> +++ eglibc-2.16/debian/control2012-11-02 10:40:56.0 +0100
> @@ -175,6 +175,17 @@
> Contains the symlinks, headers, and object files needed to compile
> and link programs which use the standard C library.
>
+0200
+++ eglibc-2.16/debian/control 2012-11-02 10:40:56.0 +0100
@@ -175,6 +175,17 @@
Contains the symlinks, headers, and object files needed to compile
and link programs which use the standard C library.
+Package: libc6-dev-compat
+Architecture: amd64 arm arm64 armel armhf hppa i386
* Julien Cristau [100703 12:07]:
> On Sat, Jul 3, 2010 at 11:55:40 +0200, Bernhard R. Link wrote:
> > Which still keeps open the problem of updating build-depends once a new
> > subarchitecture shows up. The only solution I currently see is having some
> > libc-allarchitectures-dev package pullin
Hi Bernhard,
Am Samstag, den 03.07.2010, 11:55 +0200 schrieb Bernhard R. Link:
> BTW: speaking about the different subarchitectures. Perhaps it would make
> sense to move the debian/rules code I've written for libnss-extrausers
> to some common file (perhaps in dpkg-dev or somewhere else),
> so it
On Sat, Jul 3, 2010 at 11:55:40 +0200, Bernhard R. Link wrote:
> Which still keeps open the problem of updating build-depends once a new
> subarchitecture shows up. The only solution I currently see is having some
> libc-allarchitectures-dev package pulling in all the needed stuff, which
> looks
to run 32bit variants
> and needs to install another package. The cost of this is the additional
> dependency on the “other” libc6-* package, as noted by Petter in this
> bug.
Take a look at http://packages.debian.org/sid/libnss-extrausers:
It only depends on libc6 (or libc0.1 or libc0.3 on k
Hi Petter,
Am Freitag, den 02.07.2010, 19:28 +0200 schrieb Petter Reinholdtsen:
> Package: libnss-myhostname
> Version: 0.2.4
>
> I ran into this problem using the DVD build of Debian Edu. The
> package was uninstallable on i386 because it failed to find
> libc6-amd64 on th
Processing commands for [EMAIL PROTECTED]:
> reassign 504516 general
Bug#504516: libc6 package allows for a potential root compromise to users in
'staff' group
Bug reassigned from package `libc6' to `general'.
> thanks
Stopping processing here.
Please contact me if yo
severity 482921 important
thanks
Hi,
* Matthias Klose ([EMAIL PROTECTED]) [080526 00:06]:
> Aurelien Jarno writes:
> > Matthias Klose a écrit :
> > > Package: glibc
> > > Version: 2.7-11
> > > Severity: important
> > >
> > > Please build l
Processing commands for [EMAIL PROTECTED]:
> severity 482921 important
Bug#482921: please provide libc6-hppa64 and libc6-hppa64-dev packages
Severity set to `important' from `serious'
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug
Processing commands for [EMAIL PROTECTED]:
> clone 482902 -1
Bug#482902: please provide libc6-hppa64 and libc6-hppa64-dev packages
Bug 482902 cloned as bug 482921.
> reassign -1 general
Bug#482921: please provide libc6-hppa64 and libc6-hppa64-dev packages
Bug reassigned from package `gli
has only 1.1.4.
> backports.org has subversion 1.4.1 for sarge, but no libsvn0-dev. ]
>
> Is there an compiled libc6 that has support for older kernels, too, or
> some easy way to recompile it?
Support for 2.4 kernels has been removed from upstream glibc.
--
.''`. A
On Tue, Aug 07, 2007 at 09:56:34AM +0200, Ph. Marek wrote:
> Hello everybody,
>
>
> I'd like to ask for some help.
>
> I have some machines running an old kernel (2.4.25, from Suse7.3).
> Now I'd like to get some newer software running on them, *without*
> re-installing the whole system.
We d
the -devel list was appropriate (hoping that
the libc6 maintainer "just" sends a new package :-)
Thank you.
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Hi,
On Tue, Aug 07, 2007 at 09:56:34AM +0200, Ph. Marek wrote:
> I'd like to ask for some help.
Please ask on debian-user, debian-devel is a development list.
regards,
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
).
[ I tried to use the sarge-packages; while the packages work on
2.4.25, they are really old versions, and unuseable. Eg. fsvs needs at
least subversion 1.2, while sarge has only 1.1.4.
backports.org has subversion 1.4.1 for sarge, but no libsvn0-dev. ]
Is there an compiled libc6 that has suppo
On Oct 26, Aurelien Jarno <[EMAIL PROTECTED]> wrote:
> Maybe hurd and m68k porters can maintain a glibc package using an old
> version (2.3.6 ??) together? Well that's for after Etch.
What for? Modern threaded software will require TLS more and more.
--
ciao,
Marco
signature.asc
Description: D
- Original Message -
From: "Michael Banck" <[EMAIL PROTECTED]>
To:
Cc:
Sent: Thursday, October 26, 2006 11:45 AM
Subject: Re: libc6 2.5 and Etch
On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote:
We plan to upload [glibc-2.5] right after the releas
Thomas Schwinge a écrit :
> Hello!
>
> On Thu, Oct 26, 2006 at 05:45:24PM +0200, Michael Banck wrote:
>> On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote:
>>> For m68k and hurd, I have sent a mail to the porters a few months ago, I
>>> haven't received any answer.
>
> That is untrue
Hello!
On Thu, Oct 26, 2006 at 05:45:24PM +0200, Michael Banck wrote:
> On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote:
> > For m68k and hurd, I have sent a mail to the porters a few months ago, I
> > haven't received any answer.
That is untrue. I replied for the Hurd people.
>
On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote:
> We plan to upload [glibc-2.5] right after the release of etch.
>
> This version works on all architectures, but m68k, hurd and hppa which
> don't have TLS support.
>
> For hppa the work is almost done, I am currently building the p
On Wed, Oct 25, 2006 at 10:42:08PM -0400, Kevin Mark wrote:
> When Sarge was released, amd64 was not officially released but had an
> unofficial release. why not do the same with the hopes tha etch+1 will
> see m68k in relase shape?
That's exactly what we're planning to do.
--
Home is where you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/25/06 21:42, Kevin Mark wrote:
> On Wed, Oct 25, 2006 at 08:21:39AM -0500, Ron Johnson wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/25/06 06:27, Aurelien Jarno wrote:
>>> Ron Johnson a écrit :
On 10/25/06 04:53, Mar
On Wednesday 25 October 2006 20:42, Kevin Mark wrote:
> When Sarge was released, amd64 was not officially released but had an
> unofficial release. why not do the same with the hopes tha etch+1 will
> see m68k in relase shape?
AMD64 is a modern architecture. M68k is an architecture that saw its pr
On Wed, Oct 25, 2006 at 08:21:39AM -0500, Ron Johnson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/25/06 06:27, Aurelien Jarno wrote:
> > Ron Johnson a écrit :
> >>
> >> On 10/25/06 04:53, Martin Michlmayr wrote:
> >>> * Ron Johnson <[EMAIL PROTECTED]> [2006-10-25 04:36]:
> [
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/25/2006 11:21 AM, Ron Johnson wrote:
> On 10/25/06 06:27, Aurelien Jarno wrote:
>
>>>Ron Johnson a écrit :
>>>
On 10/25/06 04:53, Martin Michlmayr wrote:
>* Ron Johnson <[EMAIL PROTECTED]> [2006-10-25 04:36]:
>
> [snip]
>
>>>For m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/25/06 06:27, Aurelien Jarno wrote:
> Ron Johnson a écrit :
>>
>> On 10/25/06 04:53, Martin Michlmayr wrote:
>>> * Ron Johnson <[EMAIL PROTECTED]> [2006-10-25 04:36]:
[snip]
> For m68k and hurd, I have sent a mail to the porters a few months ago,
Ron Johnson a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/25/06 04:53, Martin Michlmayr wrote:
>> * Ron Johnson <[EMAIL PROTECTED]> [2006-10-25 04:36]:
>>> Is there any reasonable possibility that it will make it into Etch?
>> No, of course not. We cannot put a copletely n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/25/06 04:53, Martin Michlmayr wrote:
> * Ron Johnson <[EMAIL PROTECTED]> [2006-10-25 04:36]:
>> Is there any reasonable possibility that it will make it into Etch?
>
> No, of course not. We cannot put a copletely new and untested libc in
> at t
* Ron Johnson ([EMAIL PROTECTED]) [061025 11:37]:
> Is there any reasonable possibility that it will make it into Etch?
No.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
* Steinar H. Gunderson <[EMAIL PROTECTED]> [2006-10-25 11:48]:
> > Is there any reasonable possibility that it will make it into Etch?
> libc6 is frozen (at 2.3.x -- I assume you mean 2.4, not 2.5?), so no.
2.5 came out a few days ago.
--
Martin Michlmayr
http://www.cyriu
* Ron Johnson <[EMAIL PROTECTED]> [2006-10-25 04:36]:
> Is there any reasonable possibility that it will make it into Etch?
No, of course not. We cannot put a copletely new and untested libc in
at this point of the release cycle. In fact, we don't even have 2.4
because there are a number of arch
On Wed, Oct 25, 2006 at 04:36:42AM -0500, Ron Johnson wrote:
> Is there any reasonable possibility that it will make it into Etch?
libc6 is frozen (at 2.3.x -- I assume you mean 2.4, not 2.5?), so no.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to [EM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Is there any reasonable possibility that it will make it into Etch?
Thanks
- --
Ron Johnson, Jr.
Jefferson LA USA
Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and
Hi Adam,
On Thu, Sep 01, 2005 at 03:37:08PM -0500, Adam Heath wrote:
> e2fsprogs 1.27-2
> libc6 2.3.2.ds1-21
> locales 2.3.2.ds1-21
> sysvinit 2.84-2woody1
This shows that you have a mixed woody/sarge system, and are trying to
upgrade to sid.
> Se
First, I don't know where I should file this bug. Looking for suggestions on
the list.
Second, any ideas on how to fix this problem?
So, I have a system that was created(by debootstrap) between Feb 14 and May
10(dates taken from the libc6 changelog, based on the version installed).
Howev
Oliver Elphick writes:
> On Wed, 2003-12-03 at 00:52, [EMAIL PROTECTED]
> wrote:
> > > /* map the file and load an extra page in case the new line expands the
> > > file across the page boundary; adding 2 allows for the truncating
> > > effect of integer division. Forcing an extra pa
On Wed, 2003-12-03 at 01:05, Steve Greenland wrote:
> > sprintf(buf, "Failed to open %s for writing", filename);
>
>
> Where did you make 'buf' point to any usuable memory? Everything after
> this is bogus...
You are right that that w
On 02-Dec-03, 18:37 (CST), Oliver Elphick wrote:
> /
> Write a line in user_clusters
> /
> void write_cluster_line(const char *user, const char *group,
>
On Wed, 2003-12-03 at 00:52, [EMAIL PROTECTED]
wrote:
> > /* map the file and load an extra page in case the new line expands the
> > file across the page boundary; adding 2 allows for the truncating
> > effect of integer division. Forcing an extra page ensures
> > that we can ide
> /* map the file and load an extra page in case the new line expands the
> file across the page boundary; adding 2 allows for the truncating
> effect of integer division. Forcing an extra page ensures
> that we can identify the end of the buffer by finding a NUL */
No, it does n
sed elsewhere in the
program and does not segfault.
=
Package: libc6
Version: 2.3.2.ds1-10
Severity: normal
I am building a program that at one point uses strchr(). It segfaults in
sysdeps/i386/strchr.S.
I attach a gdb trace. I am not familiar
On Tue, Nov 11, 2003 at 03:11:50PM -0600, Jesse Yurkovich wrote:
> Seems that we have:
> ii libc6 2.3.2-9GNU C Library: Shared libraries and Timezone
> ii libc6-dev 2.3.2-9GNU C Library: Development Libraries and Hea
>
> I'm guessing this was
Seems that we have:
ii libc6 2.3.2-9GNU C Library: Shared libraries and Timezone
ii libc6-dev 2.3.2-9GNU C Library: Development Libraries and Hea
I'm guessing this was released in err then? A new apt-get update doesn't
indicate
any other upgrades. Thi
On Tue, Nov 11, 2003 at 12:54:18PM -0800, Mike Fedyk wrote:
> On Tue, Nov 11, 2003 at 03:29:06PM -0500, Daniel Jacobowitz wrote:
> > It could. I decided that building four was excessive and having
> > the act of installing libc6-i686 act to disable NPTL would be a little
>
On Tue, Nov 11, 2003 at 03:29:06PM -0500, Daniel Jacobowitz wrote:
> It could. I decided that building four was excessive and having
> the act of installing libc6-i686 act to disable NPTL would be a little
> bit too strange.
Can you clue me in as to why the non-optimized libc6 package
t; And Nikita just pointed out there's libc6-i686. It might make sense to
> > > > add
> > > > linux-i686 too. I'm open for discussing that, but this discussion
> > > > doesn't
> > > > belong on the ITP bug.
> > >
> > >
On Mon, Nov 10, 2003 at 10:19:39PM -0500, Daniel Jacobowitz wrote:
> On Mon, Nov 10, 2003 at 07:17:13PM -0800, Mike Fedyk wrote:
> > On Sat, Nov 08, 2003 at 06:43:09PM +0100, Robert Millan wrote:
> > > And Nikita just pointed out there's libc6-i686. It might make sense to a
On Tue, Nov 11, 2003 at 12:09:42PM -0500, Daniel Jacobowitz wrote:
> On Mon, Nov 10, 2003 at 11:49:42PM -0500, Matt Zimmerman wrote:
> > On Mon, Nov 10, 2003 at 10:18:46PM -0600, Jesse Yurkovich wrote:
> >
> > > With the recent libc6 bugs closed, I tried upgrading b
> > > On Mon, Nov 10, 2003 at 07:17:13PM -0800, Mike Fedyk wrote:
> > > >> On Sat, Nov 08, 2003 at 06:43:09PM +0100, Robert Millan wrote:
> > > >> > And Nikita just pointed out there's libc6-i686. It might make sense
> > > >> > to
On Mon, Nov 10, 2003 at 11:49:42PM -0500, Matt Zimmerman wrote:
> On Mon, Nov 10, 2003 at 10:18:46PM -0600, Jesse Yurkovich wrote:
>
> > With the recent libc6 bugs closed, I tried upgrading both a testing and
> > an unstable machine to the latest deb.
>
> You failed
On Tue, 11 Nov 2003 14:28, Isaac To wrote:
> Unless one patch the kernel to support all the things like . files in
> /proc, futex, O(1) scheduler, ... (i.e., as in the "2.4" kernel of
> Redhat).
I have been seriously considering a kernel-patch-2.4-redhat package which
contains a patch with every
; On Sat, Nov 08, 2003 at 06:43:09PM +0100, Robert Millan wrote:
> > >> > And Nikita just pointed out there's libc6-i686. It might make sense to
> > >> > add
> > >> > linux-i686 too. I'm open for discussing that, but this discussion
> &g
On Mon, Nov 10, 2003 at 10:18:46PM -0600, Jesse Yurkovich wrote:
> With the recent libc6 bugs closed, I tried upgrading both a testing and
> an unstable machine to the latest deb.
You failed to specify which version exhibited the problem, and which version
you upgraded to. If you are
Hi,
With the recent libc6 bugs closed, I tried upgrading both a testing and an
unstable machine to the latest deb.
However, the problems with utilities like chown still remain on both machines.
Can someone please add a line in their /etc/group file under the group 'users'
and make
PM +0100, Robert Millan wrote: > And
> >> Nikita just pointed out there's libc6-i686. It might make sense to
> >> add > linux-i686 too. I'm open for discussing that, but this
> >> discussion doesn't > belong on the ITP bug.
> >>
t;> > And Nikita just pointed out there's libc6-i686. It might make sense to
> >> > add
> >> > linux-i686 too. I'm open for discussing that, but this discussion doesn't
> >> > belong on the ITP bug.
> >>
> >> And why is i
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Mon, Nov 10, 2003 at 07:17:13PM -0800, Mike Fedyk wrote:
>> On Sat, Nov 08, 2003 at 06:43:09PM +0100, Robert Millan wrote:
>> > And Nikita just pointed out there's libc6-i686. It might make sense to add
>
>>>>> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
Daniel> On Mon, Nov 10, 2003 at 07:17:13PM -0800, Mike Fedyk wrote:
>> On Sat, Nov 08, 2003 at 06:43:09PM +0100, Robert Millan wrote: > And
>> Nikita just pointed out ther
On Mon, Nov 10, 2003 at 07:17:13PM -0800, Mike Fedyk wrote:
> On Sat, Nov 08, 2003 at 06:43:09PM +0100, Robert Millan wrote:
> > And Nikita just pointed out there's libc6-i686. It might make sense to add
> > linux-i686 too. I'm open for discussing that, but this discuss
On Sat, Nov 08, 2003 at 06:43:09PM +0100, Robert Millan wrote:
> And Nikita just pointed out there's libc6-i686. It might make sense to add
> linux-i686 too. I'm open for discussing that, but this discussion doesn't
> belong on the ITP bug.
And why is it only for 2.6
On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote:
> On 05-Nov-03, 19:14 (CST), Jonathan Dowland <[EMAIL PROTECTED]> wrote:
> > I'm in two minds whether or not to ask this, but I've been wondering
> > about the naming scheme for linux packages - kernel-*. Why not
> > linux-kernel-* o
On Wed, Nov 05, 2003 at 08:43:52PM -0500, Greg Folkert wrote:
> On Wed, 2003-11-05 at 20:14, Jonathan Dowland wrote:
> > I'm in two minds whether or not to ask this, but I've been wondering
> > about the naming scheme for linux packages - kernel-*. Why not
> > linux-kernel-* or linux-* ? If alterna
On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote:
> On 05-Nov-03, 19:14 (CST), Jonathan Dowland <[EMAIL PROTECTED]> wrote:
> > I'm in two minds whether or not to ask this, but I've been wondering
> > about the naming scheme for linux packages - kernel-*. Why not
> > linux-kernel-* o
Hi,
On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote:
> On 05-Nov-03, 19:14 (CST), Jonathan Dowland <[EMAIL PROTECTED]> wrote:
> > I'm in two minds whether or not to ask this, but I've been wondering
> > about the naming scheme for linux packages - kernel-*. Why not
> > linux-kern
On 06-Nov-03, 13:47 (CST), Keegan Quinn <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote:
> > Surely these won't all show up in the same Packages file...if you're
> > running GNU/KFreeBSD, it will be a FreeBSD kernel, right? Why would the
> > Linux and H
On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote:
> On 05-Nov-03, 19:14 (CST), Jonathan Dowland <[EMAIL PROTECTED]> wrote:
> > I'm in two minds whether or not to ask this, but I've been wondering
> > about the naming scheme for linux packages - kernel-*. Why not
> > linux-kernel-* o
On 05-Nov-03, 19:14 (CST), Jonathan Dowland <[EMAIL PROTECTED]> wrote:
> I'm in two minds whether or not to ask this, but I've been wondering
> about the naming scheme for linux packages - kernel-*. Why not
> linux-kernel-* or linux-* ? If alternative kernels in debian become
> more popular, is th
Scripsit Zenaan Harkness <[EMAIL PROTECTED]>
> When I search for packages, I think I'd prefer (assuming I want
> to see all kernel- type packages), I'd prefer kernel-linux-*,
> kernel-hurd-*, kernel-freebsd-*, etc.
Instead of trying to cram that into package names, would it not be
more appropriat
also sprach Greg Folkert <[EMAIL PROTECTED]> [2003.11.06.0243 +0100]:
> > about the naming scheme for linux packages - kernel-*. Why not
> > linux-kernel-* or linux-* ? If alternative kernels in debian become
> > more popular, is there a potential for confusion in the future?
> [...]
> Martin Kraaf
On Thu, 2003-11-06 at 12:14, Jonathan Dowland wrote:
> I'm in two minds whether or not to ask this, but I've been wondering
> about the naming scheme for linux packages - kernel-*. Why not
> linux-kernel-* or linux-* ? If alternative kernels in debian become
> more popular, is there a potential for
; alleviate that initial perception, IMO. Why not libc6-linux-headers?
>
> I'm in two minds whether or not to ask this, but I've been wondering
> about the naming scheme for linux packages - kernel-*. Why not
> linux-kernel-* or linux-* ? If alternative kernels in debian b
On Wed, Nov 05, 2003 at 11:21:11AM -0500, Daniel Jacobowitz wrote:
> On Wed, Nov 05, 2003 at 10:37:24PM +1100, Herbert Xu wrote:
> > Jonathan Dowland <[EMAIL PROTECTED]> wrote:
> > >
> > > In what situation would the linux-kernel-headers package be needed
> > > seperate from libc?
> >
> > Ths iss
On Wed, Nov 05, 2003 at 11:13:28AM -0600, Ryan Underwood wrote:
> Before that realization, it seemed like the type of random cruft that
> sometimes gets pulled in on dist-upgrade; a name change would help
> alleviate that initial perception, IMO. Why not libc6-linux-headers?
I'
On Wed, Nov 05, 2003 at 05:23:30PM -0500, Andrew Pimlott wrote:
> On Mon, Nov 03, 2003 at 01:20:49PM -0500, Daniel Jacobowitz wrote:
> > It does not need to. Feel free to propose a patch to document this
> > more clearly (I don't really want to rename it again...)
>
> Add something like this to t
On Mon, Nov 03, 2003 at 01:20:49PM -0500, Daniel Jacobowitz wrote:
> It does not need to. Feel free to propose a patch to document this
> more clearly (I don't really want to rename it again...)
Add something like this to the description:
These headers are not used to compile kernel modules,
lization, it seemed like the type of random cruft that
sometimes gets pulled in on dist-upgrade; a name change would help
alleviate that initial perception, IMO. Why not libc6-linux-headers?
--
Ryan Underwood, <[EMAIL PROTECTED]>
On Wed, Nov 05, 2003 at 10:37:24PM +1100, Herbert Xu wrote:
> Jonathan Dowland <[EMAIL PROTECTED]> wrote:
> >
> > In what situation would the linux-kernel-headers package be needed
> > seperate from libc?
>
> Ths issue is not whether it is needed separately from libc-dev, the
> issue is that it c
1 - 100 of 615 matches
Mail list logo
