On Wed, 23 Mar 2011, Laurent COOPER wrote:
Il est vrai que si l'admin fait juste un rm /etc/apache2/conf.d/munin, à
la prochaine mise à jour du paquet, munin réinstalle le lien symbolique.
Est ce que je dois considérer ça comme un bug et ouvrir un rapport de
bogue (ce lien ne devrait être
Hi,
On Wed, 23 Mar 2011, Goswin von Brederlow wrote:
What is the policy on conffiles under multiarch? Can a Multi-Arch: same
package have conffiles? Or would that confuse dpkg too much?
They can have conffiles but obviously the confffile must be the same
across all architectures (for a given
On Wed, 23 Mar 2011, Goswin von Brederlow wrote:
They can have conffiles but obviously the confffile must be the same
across all architectures (for a given version).
And if I change the conffile and upgrade does dpkg then ask twice if I
want to keep my version?
No.
What about stopping to
On Thu, 17 Mar 2011, Sean Finney wrote:
If you do it with the patch system (quilt or even plain dpkg),
before building the package source, you cannot ensure that files are
patched in the right order.
What do you mean in the right order ?
autofoo stuff examines timestamps on
On Thu, 10 Mar 2011, Piotr Ożarowski wrote:
seriously, THERE WILL BE NO NEW PYTHON 2.X VERSION RELEASED UPSTREAM¹,
we don't have to worry about 2.X transitions when 2.7 will become the
only supported one. If you don't like Breaks, I will remove it, it
really doesn't matter - that's why at the
On Thu, 10 Mar 2011, Lucas Nussbaum wrote:
What is the correct way to override what dpkg-shlibdeps detects?
Either you replace the dependency associated to the interpreters' libraries
by providing debian/shlibs.local (or any other file that you indicate with
-L) or you tell dpkg-shlibdeps to put
On Wed, 09 Mar 2011, Piotr Ożarowski wrote:
[Josselin Mouette, 2011-03-06]
You might “like” Breaks, but this:
Depends: python
Breaks: python (= 2.8), python ( 2.5)
has the same semantics as:
Depends: python (= 2.5), python ( 2.8)
Yes it does; if you will not add
On Mon, 07 Mar 2011, Sandro Tosi wrote:
While a review on -devel (and in general sharing news about his plans) is
always welcome, I really don't see the point of bringing this up as if it
was a big violation of a rule.
Never said it's a 'big violation'. The fact is: we have a rule, we
Hi,
On Mon, 07 Mar 2011, Anders Kaseorg wrote:
So in this case the pre-dependency should *not* be set, as it only
serves to complicate the upgrade path.
If this becomes the consensus of debian-devel, there are two things that
should probably be changed:
• The section of the
Hi,
On Mon, 07 Mar 2011, Sandro Tosi wrote:
Hello Matthias,
was this MBF announced coordinated somewhere (and I simply missed
that message) as specified in [1]?
He's the maintainer of python-central, he can certainly decide of its
fate.
While a review on -devel (and in general sharing news
Hi Marius,
no need to CC Guillem privately, the dpkg maintainers are reachable at
debian-d...@lists.debian.org. :)
On Wed, 02 Mar 2011, Marius Vollmer wrote:
- Instead, we move all packages that are to be unpacked into
half-installed / reinstreq before touching the first one, and put a
On Thu, 03 Mar 2011, Marius Vollmer wrote:
ext Raphael Hertzog hert...@debian.org writes:
On Wed, 02 Mar 2011, Marius Vollmer wrote:
- Instead, we move all packages that are to be unpacked into
half-installed / reinstreq before touching the first one, and put a
big sync() right
Hi,
On Thu, 03 Mar 2011, Carsten Hey wrote:
* Raphael Hertzog [2011-03-02 15:06 +0100]:
In general parsing the status file should not be done, instead you
should use dpkg-query.
Is there any reason for this, except that the format of the status files
will evolve?
dpkg-query
Hi,
On Thu, 03 Mar 2011, Stefano Zacchiroli wrote:
Is there a way to ask dpkg-query to dump all the information contained
in /var/lib/dpkg/status without either having to: (1) list all fields
explicitly (using --show + --showformat) or (2) list all package names
(using --status)?
I
Hi,
On Thu, 03 Mar 2011, Phillip Susi wrote:
I have another proposal. It looks like right now dpkg extracts all of
the files in the archive, then for each one, calls fsync() then
rename(). Because this is done serially for each file in the archive,
it forces small, out of order writes that
[ Bcc to -dpkg for info ]
Hello,
since multiarch support in dpkg is on good track, it's about time to
identify what will break when people start using multiarch packages...
I have started filing a few bugs for some packages where I knew of
the problems but I need your help to identify other
On Mon, 28 Feb 2011, Matthias Klose wrote:
On 28.02.2011 08:02, Raphael Hertzog wrote:
Well, if the mangling changed it means binaries linked against old
libraries will no longer work so it's rather good that the symbols files
doesn't match any more because you have to bump the mimimum
Package: dpkg-dev
Version: 1.15.8.10
Severity: wishlist
On Mon, 28 Feb 2011, Jakub Wilk wrote:
* Raphael Hertzog hert...@debian.org, 2011-02-28, 16:01:
symbols which should not be used can either be not listed in the
symbols file (and be auto-added at build time with a strict
dependency
On Sun, 27 Feb 2011, Matthias Klose wrote:
Unreflected usage of symbols files for C++ libraries
-
These seem to be limited to Qt and KDE related libraries.
Apparently g++-4.4 did emit references to symbols defined in header files of
Salut,
On Tue, 22 Feb 2011, Laurent COOPER wrote:
Oui, c'est bien un dpkg-new qui est là.
Par contre, comme je n'ai pas de dépot avec mes paquets de test,
l'installation est faite par
dpkg --unpack paquet.deb
aptitude install paquet
C'est peut être çà qui met en évidence le problème
Salut Laurent,
On Tue, 22 Feb 2011, Laurent COOPER wrote:
Dans le cadre du projet SLIS nous maintenons un ensemble de paquets
debian. J'aimerais avoir votre avis sur une question de dépendances.
Un paquet B dépend du paquet A
Un paquet C dépend du paquet B. Mais on note aussi une
Salut,
On Tue, 22 Feb 2011, Laurent COOPER wrote:
J'essaye de faire une diversion avec dpkg-divert sur une confile mais je
pense que bien que fermé le bug 476899 est toujorus d'actualité :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476899
En effet, le BTS indique que dans la version
(Moving to debian-b...@lists.debian.org where it's more appropriate)
On Fri, 18 Feb 2011, Adnan Hodzic wrote:
Hello,
During Squeeze installation process, since volatile archive was
replaced with squeeze-updates and error of unreachable archive occurs.
Of course installation process can be
Hi,
On Mon, 14 Feb 2011, Josselin Mouette wrote:
Le samedi 12 février 2011 à 01:15 +0900, Norbert Preining a écrit :
I'd say it should probably be reported as a minor bug in gvfs-open, to
respect gnome settings before falling back to mimeinfo.cache.
I consider that not minor. If
On Mon, 14 Feb 2011, Josselin Mouette wrote:
How is one supposed to prioritize between the various browsers?
There will be a default selected in gnome-session, that can be changed
by user action. Without a session-wide default (any session manager can
set one, of course) a random choice
On Mon, 14 Feb 2011, Philipp Kern wrote:
You'd lose the notion of it being useful on other architectures (that's the
arch:all - arch:i386 Raphael's talking about), though. But then packages
like qemu-system would just depend on openbios-sparc:sparc, no? If you
don't need to deal with them
On Sat, 12 Feb 2011, Guillem Jover wrote:
Hi!
On Fri, 2011-02-11 at 11:33:10 +0800, Paul Wise wrote:
On Fri, Feb 11, 2011 at 5:58 AM, Ben Hutchings b...@decadent.org.uk wrote:
Since there is no support for auto-building arch-independent binaries
I would hope that throwing away
On Sat, 12 Feb 2011, Philipp Kern wrote:
Do we have an idea how much more memory xz needs for decompression? I guess
it wouldn't be feasible to switch dpkg's default on package builds on those
architectures where we assume some more beefyness?
It depends on what compression level we use, this
Hi,
On Thu, 03 Feb 2011, Joerg Jaspert wrote:
Attached below is a tentative agenda. This is an unsorted list and we
might not get to every point. We might also have missed any number of
points, if so feel free to tell us about them.
I have not seen any word about XZ support.
When you
Hi,
your questions are probably better answered on
debian-ment...@lists.debian.org.
On Tue, 18 Jan 2011, harish badrinath wrote:
Given that i was told that you can deterministically determine which
file would run first DEBIAN/control _or_ DEBIAN/preinst, I have this
following query.
You
On Sun, 16 Jan 2011, Olaf van der Spek wrote:
On Sun, Jan 16, 2011 at 3:54 AM, Russ Allbery r...@debian.org wrote:
It's the responsibility of packages to clean up obsolete conffiles as
they're upgraded. If you run into the case of a package that's been
upgraded and not cleaned up its
On Fri, 31 Dec 2010, Carsten Hey wrote:
* Philipp Kern [2010-12-29 05:38 +]:
On 2010-12-28, Carsten Hey cars...@debian.org wrote:
... One reason for this is that dpkg's perl scripts were rewritten
in C.
I know you phrased it differently but wasn't the motivation for this
Bonjour,
On Sat, 25 Dec 2010, Mike Massonnet wrote:
http://raphaelhertzog.fr/tag/contribuer/
C'est à priori le seul à écrire à ce sujet (kudos), en tout cas de
manière visible.
Et je n'ai pas réellement parlé de packaging. Il faut de toute façon
maitriser l'anglais si on veut s'atteler à
Hi,
On Wed, 22 Dec 2010, Yaroslav Halchenko wrote:
oops -- sorry for the delay -- just found this comment
and then what to do if we have not decided yet what particular humanoid
will accomplish the mission?
It doesn't matter much. You can always change the submitter afterwards.
If you have
On Wed, 22 Dec 2010, Yaroslav Halchenko wrote:
It doesn't matter much. You can always change the submitter afterwards.
nah, then we should do it upon every commit to the repository while
multiple people working on the packaging...
Of course not, my request is that the submitter is a
(Dropping bug report)
On Mon, 29 Nov 2010, Olaf van der Spek wrote:
Hence the fact that all file system developers, whether they were
btrfs developers or XFS developers or ext4 developers, made the joke
at the file system developers summit two years ago, that what the
application
Hi,
On Mon, 29 Nov 2010, Liang Guo wrote:
I will use multiple source package, but I need a symbol link to
simplify packaging works too
Why? You decide the name you give to the sub-directory in which the
supplementary tarball is unpacked.
Anyway it's currently not possible to store a symlink
Hi,
On Tue, 30 Nov 2010, Michael Biebl wrote:
Something interesting I noticed:
I created the ext4 file system on a spare partition and installed a chroot.
After running the test, I exited the chroot, immediately unmounted the
partition
and measured how long it took:
1.15.8.5: 0.4s
On Sat, 27 Nov 2010, Jonathan Nieder wrote:
c) extract(a.dpkg-new);
extract(b.dpkg-new);
extract(c.dpkg-new);
fsync(a.dpkg-new);
fsync(b.dpkg-new);
fsync(c.dpkg-new);
rename(a.dpkg-new, a);
rename(b.dpkg-new, b);
rename(c.dpkg-new, c);
(c)
Hi,
adding debian-devel, debian-boot, debian-kernel and Theodore Y. Ts'o in CC
because I'm fed up with this problem. Sorry for the massive crosspost, you
might want to follow up only on -devel and on the bug report.
Some clones/reassign should probably result from this discussion anyway.
On
Hi,
On Tue, 23 Nov 2010, Osamu Aoki wrote:
How so ... Have you read /usr/share/doc/network-manager/README.Debian
Each distro has their own rationale for the choice of default behavior.
Debian is not acting like Ubuntu is not good enough for the bug report.
Guys, this bug report is a
Hi,
On Mon, 22 Nov 2010, Steve M. Robbins wrote:
The rtupdate script has since been changed (in unstable) to avoid this
problem, but I'm not sure what can be done for stable users other than
recommending to purge the above four packages prior to upgrade. Is
there any way to do this
Hi,
On Fri, 19 Nov 2010, Holger Levsen wrote:
Result: only mail server, SSH server and standart system are
available.
Unfortunately, that's expected result. As discussed on
So let's close this bug. There is no need and gain to keep this bug report
open (against general at least),
On Tue, 02 Nov 2010, Julien Cristau wrote:
On Tue, Nov 2, 2010 at 15:02:18 +0100, Raphael Hertzog wrote:
OK, that's a reason to avoid package churn in existing source packages and
thus letting packages with new binaries sit in NEW for a while. It doesn't
apply to entirely new packages
Hi,
On Tue, 02 Nov 2010, NeuroDebian Team wrote:
Package: wnpp
Severity: wishlist
Owner: NeuroDebian Team deb...@onerussian.com
Please use your real name even if you're doing some work as part of a
team...
Cheers,
--
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]
Follow my Debian News
Hi,
On Tue, 02 Nov 2010, Alexander Reichle-Schmehl wrote:
Please note that we see your arguments and agree completely, but please
also note it's not as easy as it sounds. IIRC recently PostgreSQL 9.x
was accepted, resulting in some packages not being able to migrate to
testing.
I think
Hi,
no harsh criticism intended (I'm only slighly affected) but I agree with
Lucas.
On Sun, 31 Oct 2010, Lucas Nussbaum wrote:
I must admit that I'm not too happy about that.
Despite the freeze, I think that it is important that we continue to
support our users usually running
Hi,
On Mon, 11 Oct 2010, Dominique Dumont wrote:
On Friday 08 October 2010 15:38:22 Raphael Hertzog wrote:
While this avoids the conffile prompt in all cases, it also means that if
the new conffiguration file has changes compared to the old one, the user
doesn't get to see them... instead
On Fri, 08 Oct 2010, Sven Hoexter wrote:
http://people.apache.org/~mxmanghi/deb/
obviously only version 2.0.1-3 has all the changes that were
suggested on this list
An upload should be a -1 since the Debian archive has never seen the package
before so you've to combine the changelog
Hi,
I was reviewing how we deal with renames of conffiles as now implemented
by dpkg-maintscript-helper (itself inspired by
http://wiki.debian.org/DpkgConffileHandling) and I wonder if we're not
doing something wrong.
Currently it works like this:
- in the preinst, mark the old conffile for
Hi,
On Mon, 27 Sep 2010, Russ Allbery wrote:
Well, I don't make it a requirement to implement it right now and the
Build-Features code can certainly start with just the build-arch
stuff. But I want to make sure we gave it enough thought so that it's
not problematic later on to extend it
Hi,
On Wed, 29 Sep 2010, Ian Jackson wrote:
I wrote:
Stefano Zacchiroli writes (delegation for FTP Masters):
As it's painful to track multiple delegation mails for a single group of
people, I'm (re-)delegating all FTP masters at once. A reference to the
present delegation will shortly
Hi,
On Sun, 26 Sep 2010, Luk Claes wrote:
I think that having an official rolling release always available would
reduce the pressure of maintainers to always push the latest into the next
stable release precisely because there's an alternative... so it would
rather help concerning this
Hi,
On Mon, 27 Sep 2010, Roland Mas wrote:
What do you base this on? It does not at all seem clear to me that
rolling would not introduce maintainers who only care about rolling.
Nobody can predict the future... but my take is that the people who
only care about rolling would be the
On Mon, 27 Sep 2010, Bernhard R. Link wrote:
But this whole discussion got boring something like 10 years ago. It's
a shame there is still no proper solution for that now.
Yeah, the only one who submitted code has been Bill Allombert and he did
it without following my recommendations so I have
On Mon, 27 Sep 2010, Russ Allbery wrote:
The not-so-evident part is that I want the syntax of this field to be
sufficiently extensible so that we can encode more information like
support of hardening build flags and similar stuff that we might want to
know to adjust the behaviour at build
Hi Luk,
thanks for your valuable comments.
On Sun, 26 Sep 2010, Luk Claes wrote:
Of course there are multiple reasons. Though I think one of the most
obvious ones is that we as a project don't do a genuine stable release
often so sometimes delay the freeze willingly or not. Another reason
On Thu, 23 Sep 2010, Mehdi Dogguy wrote:
On 09/23/2010 09:00 AM, Lucas Nussbaum wrote:
Raphael's article is now published, and is probably a good basis for
discussing CUT on -de...@. Free link:
http://lwn.net/SubscriberLink/406301/bd522adc828b3461/
It's still looks weired to me
Hi,
On Wed, 22 Sep 2010, Yaroslav Halchenko wrote:
hm... did you mean
http://lwn.net/Articles/406301/
A constantly usable testing distribution for Debian?
Yes.
if indeed, taken on the reasoning that testing is a bad name and rolling
is
better, then it goes similar to what I saw behind
Hi Luk,
thanks for your comment!
On Thu, 23 Sep 2010, Luk Claes wrote:
Raphael's article is now published, and is probably a good basis for
discussing CUT on -de...@.
Free link: http://lwn.net/SubscriberLink/406301/bd522adc828b3461/
Personally I have the feeling that if we would choose
Hi all,
On Tue, 21 Sep 2010, Yaroslav Halchenko wrote:
CUT discussions at debconf10 and recent news of the birth of Linux Mint
discussions on CUT have continued after debconf on the CUT mailing. I
wrote a summary of the discussion that will be published in Linux Weekly
News before tomorrow.
On Sat, 18 Sep 2010, David Bremner wrote:
Well, OK, I see your point. But what should we do about e.g. tiny perl
modules. My/our impression was that ftp-master was not keen on having
many small packages. For example, libcatalyst-modules-perl has installed
size of 1468k, but bundles 81 modules.
On Sun, 19 Sep 2010, Steve McIntyre wrote:
CCing -devel and Joey Hess to have some input on this idea. Do you think
it would be useful ? Do you have comments and suggestions ?
I'm uncomfortable with the idea of (even more?) build-time package
settings being hidden away outside of
On Thu, 09 Sep 2010, Nicholas Bamber wrote:
I have recently looked into a number of bundle packages. All of them
have different implementations of the debian/rules although the ones
I looked at had clearly once had a common parent. Hence I have been
kept awake at night thinking how this
On Wed, 15 Sep 2010, Henrique de Moraes Holschuh wrote:
On Wed, 15 Sep 2010, Goswin von Brederlow wrote:
QUILT_PATCHES=debian/patches quilt push
will do the same. You only need QUILT_PATCHES for the first quilt call.
Is that so? That would be good news, but it doesn't match my
On Mon, 13 Sep 2010, Ian Jackson wrote:
Raphael Hertzog writes (Re: Bug#560317: dpkg-trigger complains at
dpkg-reconfigure time):
On Thu, 10 Dec 2009, Joey Hess wrote:
Does it actually make sense for dpkg-trigger to see those environment
variables when the postinst is not being run
Hi,
On Thu, 10 Dec 2009, Joey Hess wrote:
Raphael Hertzog wrote:
Because the postinst is called by dpkg-reconfigure (of debconf) and it
doesn't set the same environment variables that dpkg does set when
it calls the postinst by itself. In particular DPKG_MAINTSCRIPT_PACKAGE
is missing
Hi,
On Tue, 07 Sep 2010, Lucas Nussbaum wrote:
Now that backports are becoming official, I think that it is the right
time to reconsider the maintenance model of backports. I would
personally prefer if we had the same rules of packages ownership as for
normal packages (normal backport
Hi,
On Fri, 27 Aug 2010, Lucas Nussbaum wrote:
You assume that, if we disable most of the columns, people will think
it's surprising that this interface doesn't do more, let's search the
hidden options for more features, and thus add the additional columns
they want. I don't think that it is
Hello,
On Mon, 30 Aug 2010, D M German wrote:
After my presentation at DebConf this year I was pointed to your efforts
on the Patch Tagging Guidelines.
One thing I believe would be useful is if the patch included a
license. The simplest license would be Same as patched code but it
will
On Fri, 13 Aug 2010, Russ Allbery wrote:
Raphael Hertzog hert...@debian.org writes:
As suggested by Ian on -devel (see attachment), it would be nice to have
a way to remove files during unpack of a source package to hide non-free
files from our users without stripping them from
Package: dpkg-dev
Version: 1.15.8
Severity: wishlist
As suggested by Ian on -devel (see attachment), it would be nice to have
a way to remove files during unpack of a source package to hide non-free
files from our users without stripping them from the original tarball.
I also prefer this
On Sun, 01 Aug 2010, Stefano Zacchiroli wrote:
On Thu, Jul 22, 2010 at 03:10:16PM -0400, Joey Hess wrote:
Russ Allbery wrote:
I don't agree; I think it's very hard to say the same thing about testing.
I've noticed that linking to this page seems to kill threads, which is
not my
On Fri, 30 Jul 2010, Benjamin Drung wrote:
I could not find that submenu while installing 10.04. It's quite
possibly only in the alternate installer image nowadays (that is used
for the server edition AFAIK).
On the last step (7 of 7), there is the Advanced... button.
Yes, and there's
Hi,
On Mon, 26 Jul 2010, Michael Gilbert wrote:
On Mon, 26 Jul 2010 12:49:00 +0100, Ian Jackson wrote:
Simply, we do not need to, and should not, make reporting bugs easier.
As a point of reference, Ubuntu disabled their easy-to-find http bug
submission page because of this very problem.
On Tue, 27 Jul 2010, Josselin Mouette wrote:
Le lundi 26 juillet 2010 à 14:57 -0400, Andres Mejia a écrit :
Here's a template reportbug prints out for iceweasel.
[snip]
Versions of packages iceweasel depends on:
ii debianutils 3.4Miscellaneous utilities
On Tue, 27 Jul 2010, Wouter Verhelst wrote:
On Tue, Jul 27, 2010 at 04:56:03PM +0200, Raphael Hertzog wrote:
With a free form field called System specific information, please paste
here the output of “reportbug --template package”.
That could even be reasonable.
Except many people
On Sun, 25 Jul 2010, Teemu Likonen wrote:
* 2010-07-25 12:54 (+0200), Marc Haber wrote:
stable = release
testing = current
unstable = development
I like these. They describe the three distributions well and current
might encourage more users than testing. Advertising constantly
Hi,
On Thu, 22 Jul 2010, Benjamin Drung wrote:
Am Donnerstag, den 22.07.2010, 10:20 +0200 schrieb Yves-Alexis Perez:
On 21/07/2010 10:25, Paul Wise wrote:
They also currently have almost 20 times as many popcon submissions as
Debian and continuing growth:
http://popcon.ubuntu.com/
On Mon, 26 Jul 2010, Daniel Reurich wrote:
2) store output in a file, read it, then copy/paste on my MUA : you call
that user friendly ? ;)
No, but it's a viable solution (and I heard several people are already
doing similar stuff).
you could improve this and have it call
On Mon, 21 Jun 2010, Thomas Goirand wrote:
No, but we wrote that a free software in our view, should not depend on
a non-free software. The question is: is this an RPC call to a remote
(non-free) library. My take is: definitively yes. As we are clearly on
the line here, so I do respect other's
Hi Ted,
thanks for your answer.
On Mon, 14 Jun 2010, Ted Gould wrote:
I think this could be a good idea indeed. A team that would be very open
to the upstream Ubuntu/Canonical maintainers.
I'm unfamiliar with Debian processes so I can't comment on whether a
team is appropriate. But, I'd
On Fri, 18 Jun 2010, Philipp Kern wrote:
As documented in its manpage, at least. It looks a tad misleading, though:
| But in many cases the operation done by the program is not critical
| for the package, and instead of using a pre-dependency we can call the
program
| only if we know
On Fri, 18 Jun 2010, Stefano Zacchiroli wrote:
On Fri, Jun 18, 2010 at 04:46:15PM +0200, Michael Biebl wrote:
I assume the file in question is a conffile. If you just want to move its
location, read the section Moving a conffile at
http://wiki.debian.org/DpkgConffileHandling
Or rather
Hi,
On Mon, 14 Jun 2010, Sebastien Bacher wrote:
Could you avoid changing the packaging system when you take things to
Debian? We do use cdbs for those because it makes easier some of the
things we are doing, we could need to add a diff back for langpacks
translations for example over your
[ Bcc debian-mentors as some prospective DD might be interested in
packaging those ]
Hello,
I would like to be able to use ubuntu's indicator applets in Debian but
very few of the required packages are in Debian (only libindicator is
available).
Here are some of the design pages if you don't
On Mon, 14 Jun 2010, Evgeni Golov wrote:
I'd like too, thus I packaged libindicator (sid) and
xfce4-indicator-plugin (NEW) :)
I saw libindicator and wondered why indicator-applet was not in the same
batch and investigated and found your RFP and this led me to this mail.
:)
The missing
Hello,
what should package that require a specific device file do in their postinst ?
Many packages verify that the device does not exist and verify that
/dev/MAKEDEV exists and do cd /dev ./MAKEDEV something only in
that case.
This works well in most cases but if you're using udev when
On Wed, 09 Jun 2010, Marco d'Itri wrote:
On Jun 09, Raphael Hertzog hert...@debian.org wrote:
If you remove udev then you are on your own.
There are still cases where not using udev is fine: chroots or in
openvz containers.
I would still want the packages requiring a device file to properly
On Tue, 01 Jun 2010, Jonathan Niehof wrote:
This is a great addition; however, if the user has changed the
conffile *and* the maintainer also changes it in the same version
where it is moved, the user's file is left silently in place and the
maintainer's installed as .dpkg-new. This seems
On Sat, 29 May 2010, Charles Plessy wrote:
Thanks for the pointer. I sent a patch for the Policy to this bug report. I
agree with the comment of Manoj in message #15 that the Format field of the
Debian source control files would have better been called Src-Format or
something similar. Do you
On Thu, 27 May 2010, Charles Plessy wrote:
* In Debian changes files, Format is currently 1.8; I suppose that it
defines the meaning and syntax of the other fields. Is there a place were
the
history of this file format is defined? Is it a general format number for
what
we call
On Fri, 28 May 2010, Charles Plessy wrote:
[ Skipping the part that makes no sense to me ]
With a simple debian/rules target, for instance ‘source’, the conflict about
the source package formats can be made much milder, because it will be the
choice of the maintainer to use or not dpkg-dev,
Hi,
On Wed, 26 May 2010, Bernd Zeimetz wrote:
* dpkg-dev provides a new script called dpkg-buildflags that packages
should use in debian/rules to retrieve the default value of various
compilation flags. Bug #578597[1] has been submitted against
debian-policy. When
On Thu, 27 May 2010, Gerfried Fuchs wrote:
* Philipp Kern tr...@philkern.de [2010-05-27 09:05:39 CEST]:
But I guess we already determined that automatic detection of various
things isn't always the best choice. Making 1.0 non-native and 1.0
native explicit wouldn't sound too wrong. :P)
On Tue, 25 May 2010, Peter Samuelson wrote:
And more false positives:
possible bashism in ./configure line 44 ($BASH_SOMETHING):
if test -z $BASH_VERSION$ZSH_VERSION \
(test X`print -r -- $as_echo` = X$as_echo) 2/dev/null; then
possible bashism in ./configure line 367 (should be word
Hi,
On Thu, 20 May 2010, Santiago Vila wrote:
So I agree that the sane thing to do here is, at least, to use the
same default range as /etc/adduser.conf (which in turn is the range
defined by policy).
I've just modified base-files accordingly to use the UID range 1000-2.
I'm not sure
On Wed, 19 May 2010, Felipe Sateler wrote:
Most of the repackaging is done because we don't _want_ to redistribute
those files not because we do not have the right to redistribute them.
[citation needed]
My perception of the matter is the other way around.
Take the case of stripped RFC,
On Tue, 18 May 2010, Peter Palfrader wrote:
On Wed, 12 May 2010, Felipe Sateler wrote:
Would it be feasible to have some sort of automation surrounding this?
Breaches that are fixed by a subsequent upload will very likely contain
some strings in the changelog: strip, distributable,
On Mon, 03 May 2010, smain...@free.fr wrote:
Mais les paquets ajoutés ne peuvent malheureusement pas être installés par les
clients. La seule procédure qui fonctionne est de régénérer la clef :
Quelle est l'erreur ?
Est-ce que les clients on fait un apt-get update qui a réussi ?
Est-ce que
501 - 600 of 1749 matches
Mail list logo
