Dave Carrigan wrote:
On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote:
this makes it IMHO a plausible release goal to get rid of 2.95
maintenance for etch.
No it is not. Just because debian packages don't use 2.95 doesn't mean
that end users have the same luxury.
The
The need for gcc-2.95 usually means the source code is broken (in C99
terms) and should be fixed. Do you have an example of an use case where
this is unfeasible, and which is important enough to justify continued
maintenance of gcc 2.95?
Device driver development for embedded systems?
Debian is not rushing to drop gcc 2.95, but in the long run, it's
inevitable. Or, to put it in your words, there is a business case for
dropping gcc 2.95 support in etch.
If current debian maintainer(s) don't want to maintain gcc-2.95 any longer,
they should probably orphan it, just like any
I have devoted some time cross-compiling a number of essential packages,
with glibc-based,
uclibc-based and dietlibc-based ARM and MIPS toolchains and found all of
that not a huge
problem at all, given that debian/rules is provisioned with proper
calls to --host (as described
by the earlier
You may look at dpkg-cross ...
I did, and I'm using it, thanks:-)
What is the deal BTW with that new rewrite_dependencies (as of 1.26)
producing bogus names with
-dcv1 suffix? I had to comment 2 lines out of dpkg-cross script to make
it work for libgpm for instance...
It's versioning
Libary locations and library search paths. dpkg-cross and every other
crosscompiling solution moves libraries to unexpected locations. You no
longer can just apt-get the target arch libs you need. This is
managable as long as you stick with autoconf -based software, but you'll
go nuts with
As you see, I get depends with -dcv1 suffix as well as -cross suffix.
Yes, it's exactly what it should do.
Each package xxx-arm-cross package created with dpkg-cross = 1.26 will
Provide: xxx-arm-dcv1. In your case, this will not allow libc6-arm-cross
created by older dpkg-cross to satisfy
I think I know now what the problem is, see below...
On Thu, Mar 16, 2006 at 07:35:41PM +0300, Nikita V. Youshchenko wrote:
As you see, I get depends with -dcv1 suffix as well as -cross
suffix.
Yes, it's exactly what it should do.
Each package xxx-arm-cross package created
You have too old version of libgcc1-arm-cross, that does not provide
libgcc1-arm-dcv1 (and, btw, installs to /usr/arm-linux/)
No, that's not true. It does install into /usr/arm-linux-gnu.
I got this one from the latest gcc sources
(4.0.2-9). And it still does not provide libgcc1-arm-dcv1.
I hope that my patches (#357629, mailto:[EMAIL PROTECTED] #357658
mailto:[EMAIL PROTECTED], #357661
mailto:[EMAIL PROTECTED]) are proper enough:-)
This is incomplete: not only libgcc does not provide -dcv1, but libstdc++
and -dev and -dbg.
Would you be so kind to post undeted patches to these
Would you be so kind to post undeted patches to these bugs?
s/undeted /updated :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hello
Should /etc/hostname contain only short hostname, or FQDN name?
Is this documented anywhere?
I've always thougth that /etc/hostname should contain short hostname.
But e.g. etherconf package puts FQDN name there ...
Hello.
I am running several systems that are a mix of stable, testing and sid, with
apt preferences set up such that stable is the highest priority, testing
lower than stable, sid lower that testing.
When something from e.g. sid is needed for some reason, I run
apt-get -t unstable install xxx
Here is a script that finds different versions of installed binary packages
with the same source package name.
Running this script on some of my systems gave me lots of interesting
information ...
find_inconsistent
Description: application/shellscript
On Sat, Jun 21, 2003 at 09:52:35AM +0400, Nikita V. Youshchenko wrote:
Here is a script that finds different versions of installed binary
packages with the same source package name.
it does not take into account removed (deinstalled) packages, where only
the outdated config files
Hmm...
Seems that apt-get ignores -o DPkg::Options.
[EMAIL PROTECTED]:~ cat /tmp/xxx
#!/bin/sh
echo dpkg $*
exit 1
[EMAIL PROTECTED]:~ LANG=C apt-get -o 'Dir::Bin::dpkg=/tmp/xxx' -o
'DPkg::Options={--xxx;}' install nvi
Reading Package Lists... Done
Building Dependency Tree... Done
The following
On Thu, 26 Jun 2003, Nikita V. Youshchenko wrote:
Hmm...
Seems that apt-get ignores -o DPkg::Options.
-o dpkg::options::=foo -o dpkg::optons::=bar
Thank you. Is this documented anywhere?
It's really good news that someone is writing on this. Since Debian is
somewhat hard to install and configure for unexperienced user, but
otherwise Debian is The Best :), I guess many people are doing custom
Debain installation tools.
- Preconfigure the packages we install
Using two
Nikita V. Youshchenko [EMAIL PROTECTED] wrote:
[...]
Another thing is replacing #!/bin/sh by #!/bin/bash --login in
/etc/kde3/kdm/Xsession (and other dm's Xsession files). This is the only
way I know to make login shell startup files evaluated during X logins.
This issue is known for ages
Currently, BTS sends weekly two mails to debian-devel-announce - one about
WNPP and one about RC bugs.
I think it will help to improve Debian quality if several more lists will be
broadcasted by BTS:
- Bugs that have patch tag for (e.g.) 2 weeks (and don't have wontfix
tag). Broadcasting such
As gcc changelog.Debian states, bugs filed against earlier versions of gcc
(e.g. gcc-3.2 or gcc-2.95) are closed when they are fixed in later version
(e.g. gcc 3.3).
Is that really correct?
gcc-3.2 package is still in Debian and still contains those bugs. So IMHO
bugs should be still opened
On Tue, 29 Jul 2003, Nikita V. Youshchenko wrote:
As gcc changelog.Debian states, bugs filed against earlier versions
of gcc (e.g. gcc-3.2 or gcc-2.95) are closed when they are fixed in
later version (e.g. gcc 3.3).
Is that really correct?
gcc-3.2 package is still in Debian and still
On Tue, Jul 29, 2003 at 12:31:53AM +0400, Nikita V. Youshchenko wrote:
Currently, BTS sends weekly two mails to debian-devel-announce - one
about WNPP and one about RC bugs.
I think it will help to improve Debian quality if several more lists will
be broadcasted by BTS:
I'm rather
Guess how many hours it takes for the m68k
buildd to rebuild kdegraphics. OVER 38 HOURS!
By the way, isn't it a good time to rise up a discussion about package
cross-compiling infrastructure?
Today I was reminded of something that causes apps not to migrate into
sarge. When maintainers remove old libraries from the archive! Today
for example libexif8 was removed by Christophe Barbe and replaced by
libexif9. Guess what that does... any package which depends on libexif8
now
On Mon, Aug 04, 2003 at 04:28:49PM +0400, Nikita V. Youshchenko wrote:
Guess how many hours it takes for the m68k
buildd to rebuild kdegraphics. OVER 38 HOURS!
By the way, isn't it a good time to rise up a discussion about package
cross-compiling infrastructure?
Isn't it good
On Mon, Aug 04, 2003 at 03:54:56PM +0200, Matthias Urlichs wrote:
Surprise, I was thinking about the same thing, yesterday. Basic idea:
mount the slow system's build chroot from the fast server, replace
gcc/g++/ld with scripts that call the server's version remotely. The
biggest problem
On Tue, Aug 05, 2003 at 01:07:42AM +0400, Nikita V. Youshchenko wrote:
So buidd + distcc on a slow m68k/arm/whatever, and distccd on a fast
P4 or Athlon, or even on several of those. This is expected to reduce
the compile time to almost the same as it is on x86 :).
I'm not sure that's
* Finally drop the bogus libapache-mod-ssl dependency from the
apache1.3 php4 module, as glibc (= 2.3.2.ds1-17) has fixed the
dlopen refcount bug that we were hacking around (closes: #205553,
#230956, #271000)
However, libapache-mod-php4 cdoes not depend on libc6 (=
Hello.
I can't find a way to track more-or-less easilly all bugs in BTS that I am
somewhat involved into.
Currently I can subscribe to bugs on per-package-basis (using PTS), or to
all bugs using [EMAIL PROTECTED]
Something thar could be really usable is subscribing to bugs that I've
either
Current situation is version of libapache-mod-php4 currently in
testing does not work correctly with version of libc6 currently in
testing.
If a certain range of versions of a package was buggy, that is annoying,
but not a reason for all packages affected by it to depend on non-buggy
Anand Kumria [EMAIL PROTECTED]:
On Tue, 12 Oct 2004 13:37:37 +0400, Nikita V. Youshchenko wrote:
I can't find a way to track more-or-less easilly all bugs in BTS that
I
am somewhat involved into.
If by 'involved' you mean submitted, then this might be useful:
URL:http
Hello.
I've already tried to write this to debian-qt-kde, but there was no reply.
There are many packages that:
- do provide icons for programs they provide
- do provide files for /usr/lib/menu/
- but don't have Icon= lines in menu files.
This results in unwanted visual effects, such as when a
And before many people jump up and say: ooh, I have a nice PNG icon
there... Do not use them as-is. If I remember Bill's comment correctly,
the menu system is not supposed to work for anything but XPM now
Oops. Forgot about that.
However:
[EMAIL PROTECTED]:/usr/lib/menu grep icon * | grep png
Package: wnpp
Severity: wishlist
* Package name: libcompress-lzo-perl
Version : 1.08
Upstream Author : Markus Franz Xaver Johannes Oberhumer [EMAIL PROTECTED]
* URL : http://www.oberhumer.com/opensource/lzo/
* License : GPL
Description : Perl bindings for
#include hallo.h
IMHO it's somewhat silly to stop the experiment now and drop testing.
Although there are problems with testing, there *are* well-known positives
of having it.
Yes, there are problems with current scheme. So one should write down the
facts and do a careful, in-detail,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
#include hallo.h
* Nikita V. Youshchenko [Sun, Oct 24 2004, 03:53:23PM]:
#include hallo.h
IMHO it's somewhat silly to stop the experiment now and drop
testing. Although there are problems with testing, there *are*
well-known positives
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello.
Could the script that generates the RC bug list be modified to show two
additional numbers for each bug: first, how old it is (in days), and
second, how old (in days) is the last message posted to the bug?
This will allow to see easilly
and before anybody asks, I already but all the things into logrotate. I
just curious why its not there from beginning.
With current default configuration, if I add some more log files
info /etc/syslog.conf (e.g. to catch localN facilities), they get rotation
automatically. Can the same be
Speaking of which: there used to be some proposed addition to FHS about
re-locating all dot-files into ~/etc or some directory like that. Does
anybody know what happened to that? I'm aware of the problems (sharing
$HOME over several different machines etc.), but but I'll be glad if the
mess
The removable.sh shell script (pasted below) returns whether a device
is actually removable by looking at the removable sysfs attribute.
However, this attribute was introduced in the kernel not before 2.6.8.
This is okay for Ubuntu since it ships with 2.6.8.1, and since even
Sarge ships with
Hello.
On the topic of all those talks about reducing network traffic caused by
apt-get update, without putting too high load into server (as rsync does).
Can't CVS (or Subversion or other similar tool) solve this problem?
Seems that if apt-get update will turn into 'cvs update', it will save
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This problem is caused by invalid font configuration.
Qt's QFont object are always unicode at API level. If underlying platform
font doesn't have all unicode glyphs, single QFont object uses several
platform fonts. Sometimes Qt can't find those
Hello.
Upstream of a library package that I maintain changed function prototypes
in the followinf way:
-int mailpop3_retr(mailpop3 * f, uint32_t index, char ** result,
+int mailpop3_retr(mailpop3 * f, unsigned int index, char ** result,
size_t * result_len);
That is,
When you install an alsa-modules package for the 2.4 kernel, you get
alsa-base per the dependencies. However, when you install sarge with a
2.6 kernel, alsa-base doesn't end up being installed. The result is that
for most sound cards, both OSS and ALSA modules end up installed,
resulting in
How to reproduse:
create test1_1.deb with package 'test1', version '1'
creaet test1_2.deb with package 'test1', version '2'
create test2.deb with package 'test2' that depends on test1 (= 2)
dpkg -i test1_2.deb
dpkg -i test2.deb
dpkg -i test1_1.deb
The last commands completes without errors, and
Hello.
I've read (a part of) resent kernel ITP flamewar.
The more I read, the more it frightens me.
Seems that someone without any sort of complete knowledge of the problem,
decided to maintain one of the most important parts of the system. And the
way he chooses is removing everything that I
#include hallo.h
* Nikita V. Youshchenko [Sat, Nov 08 2003, 12:39:58PM]:
Optimization is a serious issue too. Unlike most user space software,
using 386 kernel on modern PC will cause serious performance loose.
Especially if you consider mmx/sse/... and SMP issues. Note also
Please please please don't go the Windows way - let's make it usable
for dummies at the price of making it hardly usable by experts! The
saying is: Create a system that is usable even by idiots, and only
idiots will use it.
I made the package in the way I found most consistent and easy
I'm not removing anything. All I do is providing an alternative. If you
don't like my alternative, you may keep using the current scheme.
The impression after reaIding the initial discussion was that this ITP
intends to replace the old scheme.
If this is not true, I will stop my complains.
On Sat, Nov 08, 2003 at 10:58:03AM +0100, Eduard Bloch wrote:
#include hallo.h
* Nikita V. Youshchenko [Sat, Nov 08 2003, 12:39:58PM]:
Optimization is a serious issue too. Unlike most user space
software, using 386 kernel on modern PC will cause serious
performance loose
On Tue, Dec 02, 2003 at 05:32:59PM +1100, Zenaan Harkness wrote:
Can requesting removal from archive be automated, to occur say after 3
weeks of inactivity of rc/grave/serious bug?
As a DD, I assume there is some pride and/ or utility in having your
package in the archive. This would give
Changes:
scrollkeeper (0.3.14-10.1) unstable; urgency=low
.
* Non-maintainer upload.
* Foo.
Files:
Wonderful changelog :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
* Nikita V. Youshchenko:
However, if I will build library against libdb4.4 instead of
libdb4.2, this will probably break any binaries built against the
library - both packaged and local.
What kind of interface does libetpan expose? Based on the package
description, I wouldn't expect
[CCing to -devel and to people who maintain packages that depend on
libetpan]
Package: libetpan
Severity: wishlist
Hi,
currently several versions of the berkeley db libraries are used in the
archive: libdb[4.2,4.3,4.4].
Please consider upgrading to libdb4.4 in order to ship etch with
Hello.
I just found that my package, libetpan, was not updated for m68k.
[1] states that it is out of date on m68k.
But [2] states that latest version was successfully built on m68k long ago
- on Apr17.
What's going on? Whom to contact on this issue?
Nikita
[1]
* Andreas Barth:
Why that? It would only affect packages that (correctly or wrongly)
also depend on libdb4.2. (And libdb4.2 unfortunatly doesn't have
versioning, otherwise, it wouldn't be any issue; lidb4.3 and libdb4.4
are better in that regard.)
Berkeley DB 4.2 was compiled such that
Have fun with updating the library, it won't affect depending packages.
:) Some times are that easy to solve, you know?
Ok, will upload today :)
pgpHAIvddyz9K.pgp
Description: PGP signature
The command 'debdelta-upgrade' is meant to be run between 'apt-get
update' and 'apt-get upgrade'; it downloads .debdelta files and
recreate the new .deb files from them; always using the *installed* old
version of the .deb, and not the old .deb file itself.
Is it safe - e.g. in case of
Binary dependent
extensions are put for all supported python versions into the
same python-foo package.
So these packages are going to depend on all supported python versions,
making impossible to remove old python versions from user's systems?
pgp8TX0wkQDNo.pgp
Description: PGP
El domingo, 18 de junio de 2006 a las 22:03:32 -0500, Ron Johnson
escrib?a:
When I tried to install it as root (using su - from an xterm
window), it complained about not being able to find DISPLAY. Unlike
Sun Java Macromedia Flash, it uses a GUI installer.
I've found sux works
Seems that 4.1.0-16 fixed at last the old problem with garbage-on-screen in
kicker and in nedit scrollbars on r128 card.
Great work !
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Seems that 4.1.0-16 fixed at last the old problem with garbage-on-screen
in kicker and in nedit scrollbars on r128 card.
Oh no, the bug is still there :-(. But not as often as before :-).
Anyway, it is not really harmful.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Hello debian-devel.
I was reading the threads about libpng[23] and glibc/db1 than cause
incompatabilities that are hard to describe with debian dependency control
fields. And I've got an idea.
What about adding one more field with the following semantics.
If package P has
FirstCompatable: N
Hello.
I wanted to install g++ 3.2 (instead of 3.1 that is buggy) on our server
running woody with several packages from unstable.
I noticed that g++ 3.2 depends on recent libc6. Is it safe to install libc6
from unstable now? Are libdb problems resolved?
As for quality of X Type1 rasterizer, I believe that it is a temporary
problem. At least one Type1 renderer, gv, has no problems with visual
quality, so this is not a fundamental flaw, just another challenge.
To get the quality, gv uses antialiasing, doesn't it?
But X core protocol doesn't
Hello.
Are multiarch ideas alive?
Do they have any future in Debian?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Thu, Jul 07, 2005 at 10:03:09PM +0200, Pierre Habouzit wrote:
Le Jeu 7 Juillet 2005 21:17, Josselin Mouette a ?crit :
If we don't start the multiarch effort now, it won't be good for
etch. Are we postponing this to the next release?
I hope not ... I'm a quite happy owner of amd64
Hello.
I'm going to update dpkg-cross package, to follow post-sarge changes in
dpkg and company.
Dpkg-cross is a tool to create cross-compile environment, useful to
cross-compile debian packages and other software.
One of dpkg-cross's functions is to process a native library or libdev
package
Dpkg-cross is a tool to create cross-compile environment, useful to
cross-compile debian packages and other software.
One of dpkg-cross's functions is to process a native library or libdev
package for some arch, and turn it into arch-all packages that install
libraries info
Nikita V. Youshchenko [EMAIL PROTECTED] writes:
Dpkg-cross is a tool to create cross-compile environment, useful to
cross-compile debian packages and other software.
One of dpkg-cross's functions is to process a native library or
libdev package for some arch, and turn it into arch
The multiarch and FHS proposals say that ${prefix}/${target}/* would
pollute the / and /usr directories while the lib and include subdirs
already have tons of files/dirs and the extra dirs won't matter.
I think that following years-old de-facto standard of
cross-compilation environment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adrian von Bidder [EMAIL PROTECTED] writes:
On Monday 04 July 2005 11.51, Horms wrote:
I am not sure about 3.4's ability to compile 2.4.27, but
it seems unlikely to me that all of the gcc versions you mention above
will be omitted from
The question is - how to process existing cross-compile environment,
created by earlier versions of dpkg-cross.
I am thinking to make the following trick. In postinst of new
dpkg-cross, it will check for /usr/arm-linux, /usr/powerpc-linux/, and
other places where packages created by earlier
- tree at old location may become inconsistent (if x depends on y,
x-arch-cross is generated by new dpkg-cross, and y-arch-cross is
generated by old dpkg-cross),
I meant 'y depends on x'.
pgpIcwjCKqUZO.pgp
Description: PGP signature
Hello.
Several people probably faced the problem that after initial system bootup,
and startup of *dm, keyboard does not work.
Suggested workaround was to add implicit 'vtX' parameter to X server
command line in Xservers file.
I've never seen an explanation of what is actually hapenning, and
As in once you confirmed one subscription the next one doesn't ask
anymore? Sort of greylisting?
Sounds good.
It should always ask for confirmation unless someone has specifically
made the decision that they don't want to have to opt-in.
Maybe it should honour subscription requests
Hello.
For one of our internal projects, libxml++2.6 was too old.
So I've created a package for libxml++2.10, using debian/ dir for the
latest libxml++2.6 package.
Upstream source looked somewhat inconsistent. I had to change '2.6' to
'2.10' in many files and rerun autotools to make package
For one of our internal projects, libxml++2.6 was too old.
So I've created a package for libxml++2.10, using debian/ dir for the
latest libxml++2.6 package.
I packaged it for Ubuntu - libxml++2.6 and libxml++2.10 were never
designed to be installable parallely.
I believe my package could
Hi Nikita,
Am Donnerstag, den 28.07.2005, 12:04 +0400 schrieb Nikita V.
Youshchenko:
I talked to upstream and they
said, the ABI broke during the development unintentionally, but we
should better stick to libxml++2.6-2.10.0 and recompile the
dependent packages.
Is 2.10
Package: wnpp
Severity: wishlist
Owner: Nikita V. Youshchenko [EMAIL PROTECTED]
* Package name: pyicq-t
Version : 0.6-1
Upstream Author : Daniel Henninger [EMAIL PROTECTED]
* URL : http://pyicq-t.blathersource.org/
* License : GPL
Description : ICQ
Hello.
As it is being currently discussed on debian-security [1], security team
has hard times supporting mozilla family of packages, because of
unfriendly upstream policy - they don't want to isolate security fixes
from a large changesets of new upstream releases. And given the huge size
of
On Sun, 2005-07-31 at 23:10 +0400, Nikita V. Youshchenko wrote:
(3) allow new upstream into stable.
But, how would be the proposed process for this software?
I mean, should they also have some kind of grace period after uploading
to unstable? Would it enter stable after unstable? Or after
On Sun, Jul 31, 2005 at 11:10:04PM +0400, Nikita V. Youshchenko wrote:
As it is being currently discussed on debian-security [1], security
team has hard times supporting mozilla family of packages, because of
unfriendly upstream policy - they don't want to isolate security fixes
from
Awaiting AM assignment 140 days
Awaiting DAM Approval184 days
I'm already waiting for DAM approval for almost 6 months, and I'm ready to
wait more (after all, there is a psyhological difference between a day and
a month, but not between 6 and 12 months).
The only thing that makes me feel
Hello
How is the effort going
(http://lists.debian.org/debian-devel/2005/09/msg01362.html)?
Pity I've read about this only now :(
Making support for such additional 'archs', targeting mainly uclibc archs,
is *the* direction where I was going to move with dpkg-cross and debian
I'm now working on discovering the best order to build the 87 needed
source packages to get a base+buildessential set for debootstrap.
I believe this should be done on normal debian host, using dpkg-cross's
'dpkg-buildpackage -a'. As of it's current state, it won't work. But it
could be made to
ad b) where is that .ldif file to be saved? For small directories not an
issue (take /var/backups or something). For big directories it should be
on a different disk than /var/lib/ldap with enough space to get sensible
performance.
I think that people who are running large directories should
Bartosz Fenski aka fEnIo [EMAIL PROTECTED] writes:
I'm packaging adesklets stuff, and it cames with Vera.ttf font included.
We've got this font in ttf-bitstream-vera package, so I was wondering if
is it ok to duplicate it, since some packages are doing it already.
A symlink and a
From: http://linuxdevices.com/news/NS3716070830.html
...
The open source software component of the Nokia 770 can be downloaded from
Maemo.org as a complete filesystem, or managed as a collection of Debian
source and binary packages.
...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
hi,
On Sat, May 28, 2005 at 01:19:05AM +0100, Adrian Mastronardi wrote:
I need to setup an shell variable:
ENFDATA=/usr/share/rnamotif/enfdata/
according to debian policy, programs must not have to rely on the
existence of environment variables. what you should probably do is
Le dimanche 05 juin 2005 ? 13:25 +0200, Matthias Klose a ?crit :
For etch we will update the toolchain (glibc, binutils,
linux-kernel-headers, gcc) again. Some updates look easy, other will
have a bigger impact on packages. One aspect of the toolchain update
is the change of the C++ ABI
Now that sarge is out (BTW, congrats to everybody!), can I close bug
reports tagged woody ?
I think that you should close those reports if and only if corresponding
bugs are fixed in sarge.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Hello.
Is the TODO list for etch available anywhere?
I think that it would be great to have current status available on a known
place, and probably posted regulary (weekly?) to -devel-announce, where
issues currently pending for etch are described, so interested people could
know what exactly
Hi
Is there an statement in Debian Policy that explicitly requires higher
version of a shared library package to be backwards-binary-compatible with
previous versions of the same package?
I mean, is a situation when after library package upgrade local binaries
stops working because of missing
Nikita V. Youshchenko wrote:
Hi
Is there an statement in Debian Policy that explicitly requires higher
version of a shared library package to be backwards-binary-compatible
with previous versions of the same package?
I mean, is a situation when after library package upgrade local
On Sun, Sep 6, 2009 at 12:50:59 +0200, Emilio Pozuelo Monfort wrote:
Nikita V. Youshchenko wrote:
Hi
Is there an statement in Debian Policy that explicitly requires
higher version of a shared library package to be
backwards-binary-compatible with previous versions of the same
Hello.
What do people look on the following idea: not allow packages to migrate
from sid to testing if they have unanswered bug reports with severity =
normal?
I guess it may be difficult to analyse automatically what is 'unanswered'
(because there could be follow-ups by submitter and other
reopen 412989
thanks
I think that correct solution for the issue is to make udev package to
create (in local /etc/groups) all missing groups referenced in it's
default configuration files.
I don't.
If you believe that some users or groups need to be unconditionally
created please
And in the current situation, udev is *the* package that, by
installing it's default configuration files, injects references to
non-resolvable-locally users and groups into early stage of boot.
Wrong. Your expectations to what is allowed to be
non-resolvable-locally are not in sync with
1 - 100 of 242 matches
Mail list logo
