❦ 11 mai 2013 22:08 CEST, Josselin Mouette j...@debian.org :
I can't agree with having no choice with regard to init. We aren't
all using GNOME, and Debian is used in an extremely diverse set of
fields for a multitude of different purposes. No one init is
appropriate for all of these
Hi,
Now that Wheezy is released, I'd like to get an opinion from fellow
project members if it is okay to add apport to the Debian unstable queue
so that we can see it in time for Jessie.
Apport [1] is an automated crash reporting tool. It could also be used
as a bug reporting tool, but there are
On Du, 12 mai 13, 20:31:08, John Paul Adrian Glaubitz wrote:
The difference between a shell and an init system is that the former
is directly exposed to the user while the latter will only be
visible to developers and admins most of the time. It makes sense to
be able to customize your user
Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez arturo.borrero.g...@gmail.com
* Package name: libiptables-nftables
Version : 1.0.0
Upstream Author : Pablo Neira Ayuso pa...@netfilter.org
* URL : http://git.netfilter.org/iptables-nftables/
* License
On Mon, May 13, 2013 at 02:31:02AM +0200, Marco d'Itri wrote:
On May 13, Holger Levsen hol...@layer-acht.org wrote:
actually, while it has been brought up as a theoretical/wrong argument,
that
we cannot switch our linux installation ship with $this init system, while
the
kfreebsd
Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez arturo.borrero.g...@gmail.com
* Package name: libnftables
Version : 1.0
Upstream Author : Pablo Neira Ayuso pa...@netfilter.org
* URL : http://git.netfilter.org/libnftables/
* License : GPL2
Package: wnpp
Severity: wishlist
Owner: Tobias Quathamer to...@debian.org
* Package name: laborejo
Version : 0.7
Upstream Author : Nils Gey i...@laborejo.org
* URL : http://www.laborejo.org/
* License : GPL-3
Programming Lang: Python
Description :
Hi,
with wheezy released and development on jessie started the problem with
binNMUs for multiarch-enabled packages is back: binNMU'ed packages have
different changelog entries and upgrades fail (for example [1]).
[1] http://bugs.debian.org/708097
It's quite annoying as the problem is only
Paul Wise p...@debian.org writes:
On Mon, May 13, 2013 at 1:01 AM, Philip Hands wrote:
I don't know about you, but I find it quite reassuring to be able to
confirm that the first half of an install is going pretty well when I
get to see the useless dummy page from Apache. I'd imagine
On Mon, May 13, 2013 at 5:20 PM, Philip Hands wrote:
It looks to me as though your apache and rsyncd suggestions are straying
into the forbidden territory of using debconf as a registry.
I didn't advocate storing such info in debconf.
PS: I'm subscribed.
--
bye,
pabs
On Tue, Apr 16, 2013 at 09:09:06PM +0200, Helmut Grohne wrote:
On Tue, Apr 16, 2013 at 03:04:20PM +0200, Goswin von Brederlow wrote:
Will that also detect files in multiarch packages that are not identical?
No, it does not do this at the moment. The main reason here is that
currently only
On Mon, May 13, 2013 at 3:06 PM, Ritesh Raj Sarraf wrote:
Apport for Debian currently resides in experimental with a whopping
popcon stat of 11000+ installs. In the past, I have blogged [2] about
apport's state in Debian, where I received some constructive feedback.
The popcon stats are
Marco d'Itri m...@linux.it writes:
On May 13, Holger Levsen hol...@layer-acht.org wrote:
actually, while it has been brought up as a theoretical/wrong argument, that
we cannot switch our linux installation ship with $this init system, while
the
kfreebsd port uses $that init system, I'd
]] Paul Wise
Another issue is privacy; backtraces may contain private information
that should not leave the system and there is no automated way to
determine that. How does Ubuntu deal with that?
IIRC, they mark the bugs as private on submission, then they have a
server-side process that
Am Montag, den 13.05.2013, 12:00 +0200 schrieb Tollef Fog Heen:
]] Paul Wise
Another issue is privacy; backtraces may contain private information
that should not leave the system and there is no automated way to
determine that. How does Ubuntu deal with that?
IIRC, they mark the bugs
On Thu, May 09, 2013 at 04:59:28PM +0100, Wookey wrote:
+++ Goswin von Brederlow [2013-05-09 11:39 +0200]:
On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote:
On 2013-05-09 07:56, Paul Wise wrote:
On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote:
I just noticed
Hi,
On 13.05.2013 09:06, Ritesh Raj Sarraf wrote:
Apport [1] is an automated crash reporting tool. It could also be used
as a bug reporting tool, but there are certain features missing (a text
input to add user description), not making it a candidate for reporting
bugs. For crashes, apport
On Wed, May 08, 2013 at 04:51:14PM +0100, Ian Jackson wrote:
* Consider other ways in which our RC-bug-fixing efforts can be
improved, especially during the latter part of the freeze.
I think one way to improve hard to reproduce bugs or bugs in uncommon
package would be to get more users
On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
I agree for these services (though Apache is useless after just
being installed, as one just has a dummy web page).
So useful, since you can then put files into the docroot and serve those
files.
But the admin
On Sun, May 12, 2013 at 11:53:46AM +0200, Vincent Lefevre wrote:
On 2013-05-10 02:01:15 +0800, Thomas Goirand wrote:
Seems nobody is picking-up on the topic, so I'll try
once more, because I'm convince there's something
we could do here. How about replacing epoch separator
char : by @ in
]] Vincent Lefevre
On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
But not for postfix, which can reject mail by default without an
initial configuration. Since it is not working by default, and loses
mail, the daemon shouldn't be enabled by default.
IIRC,
On Mon, May 13, 2013 at 12:36:39AM -0500, Steve Langasek wrote:
This sounds almost exactly like what dh-make already does, with a few
incremental enhancements. Why should we have this in the archive as a
separate package, instead of improving the existing tool? Dividing efforts
between two
]] Goswin von Brederlow
On Sun, May 12, 2013 at 11:53:46AM +0200, Vincent Lefevre wrote:
On 2013-05-10 02:01:15 +0800, Thomas Goirand wrote:
Seems nobody is picking-up on the topic, so I'll try
once more, because I'm convince there's something
we could do here. How about replacing
On 2013-05-07 23:54:36 +0800, Thomas Goirand wrote:
On 05/07/2013 04:00 AM, Vincent Lefevre wrote:
This can be fine for some daemons/servers. For instance, for a web
server, displaying a default web page is harmless. But what about a
mail server? Any default config would probably lead to
Vincent Lefevre vinc...@vinc17.net writes:
On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
I agree for these services (though Apache is useless after just
being installed, as one just has a dummy web page).
So useful, since you can then put files into the
On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
But not for postfix, which can reject mail by default without an
initial configuration. Since it is not working by default, and loses
Package: wnpp
Severity: wishlist
Owner: Tzafrir Cohen tzaf...@debian.org
* Package name: pjsip
Version : 2.1.0.0.ast20130312
Upstream Author : http://www.teluu.com/
* URL : http://pjsip.org/
* License : GPL2+ (with OpenSSL exceptions)
Programming Lang: C
]] Vincent Lefevre
On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
But not for postfix, which can reject mail by default without an
initial configuration. Since it is not
On 2013-05-13 12:02:31 +0100, Philip Hands wrote:
Vincent Lefevre vinc...@vinc17.net writes:
My only use of Apache on some machine is because of sensord. But
it may happen that in a few months, I would no longer need sensord
and may remove the package. In this case, it would make sense to
On 05/09/2013 11:59 AM, Wookey wrote:
+++ Goswin von Brederlow [2013-05-09 11:39 +0200]:
I would say that a foreign dependency on a library is never right.
That's too strong. It can make sense for cross-tools, or maybe
emulators, which genuinely need a foreign-arch library to operate.
But
On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote:
So you configured it through debconf, in a non-default way, and it
refused mails according to how you configured it.
AFAIK, debconf is the *only* choice.
Hi,
On Mon, May 13, 2013 at 12:36:39AM -0500, Steve Langasek wrote:
On Fri, May 10, 2013 at 01:40:39AM +0900, Osamu Aoki wrote:
This package helps you to convert a upstream source package (or VCS
contents) into the Debian package by adding files required for the Debian
source package.
On Mon, May 13, 2013 at 11:14:07AM +0200, Ansgar Burchardt wrote:
Hi,
with wheezy released and development on jessie started the problem with
binNMUs for multiarch-enabled packages is back: binNMU'ed packages have
different changelog entries and upgrades fail (for example [1]).
[1]
Am Montag, den 13.05.2013, 21:06 +0900 schrieb Osamu Aoki:
This may be still buggy and may needs some more work. I was thinking to
update maint-guide using this so I need to be less wordy and the debmake
program does more.
Should packaging-dev recommend debmake?
--
Benjamin Drung
Debian
Package: wnpp
Severity: wishlist
Owner: tstri...@rootcu.be
* Package name: bcache-tools
Version : 1.0
Upstream Author : Kent Overstreet kent.overstr...@gmail.com
* URL : http://bcache.evilpiepirate.org/
* License : GPL
Programming Lang: C
Description :
Goswin von Brederlow goswin-...@web.de (13/05/2013):
Please don't. That just eats up developer time to implement, more time
to un-implement when the real solution comes and probably delays the
real solution because nobody wants to break the temporary fix.
No. What eats up user and developer
]] Vincent Lefevre
On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote:
So you configured it through debconf, in a non-default way, and it
refused mails according to how you configured it.
AFAIK,
On Fri, May 10, 2013 at 10:07:18AM +0200, Marc Haber wrote:
On Thu, 9 May 2013 18:17:29 +0200, m...@linux.it (Marco d'Itri) wrote:
On May 09, Bernhard R. Link brl...@debian.org wrote:
Or in other words: to make essential functionality not available if
/usr is broken.
Again: this is not we
On 05/13/2013 08:33 AM, Tollef Fog Heen wrote:
]] Vincent Lefevre
On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote:
No, it does not, since the default configuration («Local only»)
sets
This is not the default configuration, just the default choice (it
is not written Default
On Thu, May 09, 2013 at 12:03:43PM +0100, Roger Leigh wrote:
On Thu, May 09, 2013 at 11:50:31AM +0200, Goswin von Brederlow wrote:
If you make /usr a symlink to / then there will be to distinct paths
to each file and that will confuse dpkg.
The first problem that comes to mind is package
On 05/13/2013 14:12, Goswin von Brederlow wrote:
On Mon, May 13, 2013 at 11:14:07AM +0200, Ansgar Burchardt wrote:
For this sbuild should add binary-only=yes to the changelog[4] and
dh_installchangelogs split such entries into a separate file (will file
a bug soon).
[4]
On Mon, May 13, 2013 at 12:36:39AM -0500, Steve Langasek wrote:
The debmake command invoked in the upstream source tree without
any option can generate template files which is good enough to
create a single arch=any Debian binary package for local use.
This sounds almost exactly like
Hi!
On Mon, 2013-05-13 at 11:14:07 +0200, Ansgar Burchardt wrote:
There have been previous discussions how to fix this[2]. The dpkg
maintainers would like to treat changelogs and copyright files as
metadata and move them out of /usr/share/doc[3].
[2]
On Mon, May 13, 2013 at 11:48:06AM +0200, Goswin von Brederlow wrote:
Both cases would need data for multiple archs.
For the second case if identical files are in all foo_arch.deb then
those should be in foo-common_all.deb. A dedup across archs instead of
across packages.
Thanks for
On Mon, May 13, 2013 at 15:16:57 +0200, Guillem Jover wrote:
I've mentioned this before, I find this completely unsatisfactory,
because (at least):
1) the changelog stops representing the actual changelog of the
package.
Irrelevant, that's already the case today for anything but the
On Monday 13 May 2013 03:55 PM, Arno Töll wrote:
note that, unlike Ubuntu we do not provide automated debug packages.
Hence many crash reports aren't usable at all when they are generated on
Debian systems.
This could be a start. It could help users request debug packages from
package
On Monday 13 May 2013 03:22 PM, Paul Wise wrote:
Another issue is privacy; backtraces may contain private information
that should not leave the system and there is no automated way to
determine that. How does Ubuntu deal with that?
Unfortunately, there's no intelligence in apport client to
Vincent Lefevre vinc...@vinc17.net writes:
On 2013-05-13 12:02:31 +0100, Philip Hands wrote:
Vincent Lefevre vinc...@vinc17.net writes:
My only use of Apache on some machine is because of sensord. But
it may happen that in a few months, I would no longer need sensord
and may remove the
On 2013-05-12 21:31, m...@linux.it wrote:
Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make
udev
depend on either upstart or systemd.
do you have a link to a presentation, blog post, or whatever explaining
the rationale behind this?
i didn't found anything on FOSDEM
On Mon, May 13, 2013 at 7:33 PM, Vincent Lefevre wrote:
Yes, but similarly, there's no way to do this automatically.
apt-get autoremove is automatic, or if you want that earlier you could
remove sensord using aptitude which will automatically remove unused
dependencies.
There's also a problem
+++ The Wanderer [2013-05-13 07:55 -0400]:
On 05/09/2013 11:59 AM, Wookey wrote:
+++ Goswin von Brederlow [2013-05-09 11:39 +0200]:
I would say that a foreign dependency on a library is never right.
That's too strong. It can make sense for cross-tools, or maybe
emulators, which
On Sun, May 12, 2013 at 1:15 PM, Johannes Schauer wrote:
Should a dependency of a source package src:A on src:foo not mean that src:A
also automatically build depends on the build dependencies of src:foo?
Not necessarily, src:A could be building with a different set of build
options. For
On 2013-05-13 08:48:33 -0400, The Wanderer wrote:
On 05/13/2013 08:33 AM, Tollef Fog Heen wrote:
]] Vincent Lefevre
On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote:
No, it does not, since the default configuration («Local only»)
sets
This is not the default configuration, just
On Mon, 2013-05-13 at 14:12:14 +0200, Goswin von Brederlow wrote:
Isn't the reason this was on hold the wheezy release and now that is
out work on this can continue?
The main reason to not deploy any actual solution at the time was that
it would imply possible unexpected breakage on extractors
On 05/13/2013 09:46 AM, Wookey wrote:
+++ The Wanderer [2013-05-13 07:55 -0400]:
For the full 64+32 Wine, I don't believe this is possible - or if
it is possible, no way of doing it has yet been documented that I
know of. The official Wine documentation of how to build that
configuration
On 2013-05-13 14:37:28 +0100, Philip Hands wrote:
Vincent Lefevre vinc...@vinc17.net writes:
There's also a problem that the man pages are in the package:
$ dpkg -L apache2.2-common | grep /man/
/usr/share/man/man8
/usr/share/man/man8/apache2.8.gz
/usr/share/man/man8/a2ensite.8.gz
On 2013-05-13 16:26:58 +0200, Vincent Lefevre wrote:
One could imagine the same thing but with testing directories...
Something like in the /etc/default/ file:
test -f some_dir || ENABLED=0
But this method needs an ENABLED variable!
Actually, that would be more like
ENABLED=0
test -f
On 05/13/2013 10:22 AM, The Wanderer wrote:
On 05/13/2013 09:46 AM, Wookey wrote:
Hmm. Do the parts of the 64-bit tree that the 32-bit side compiles
against end up installed in a final installation (as libraries?) or
are they really just intermediate 'during build' items?
They do end up
On Mon, May 13, 2013 at 12:05:59AM +0200, Josselin Mouette wrote:
Having a rock-stable PID 1 is nice and all, but it doesn???t help you if
something important crashes. On a production server, if apache crashes
and fails to reload properly because the scripts don???t get the ordering
right, it
On 2013-05-13 21:42:20 +0800, Paul Wise wrote:
On Mon, May 13, 2013 at 7:33 PM, Vincent Lefevre wrote:
Yes, but similarly, there's no way to do this automatically.
apt-get autoremove is automatic, or if you want that earlier you could
remove sensord using aptitude which will automatically
On 05/13/2013 10:31 AM, The Wanderer wrote:
On 05/13/2013 10:22 AM, The Wanderer wrote:
On 05/13/2013 09:46 AM, Wookey wrote:
Hmm. Do the parts of the 64-bit tree that the 32-bit side
compiles against end up installed in a final installation (as
libraries?) or are they really just
+++ The Wanderer [2013-05-13 10:22 -0400]:
On 05/13/2013 09:46 AM, Wookey wrote:
+++ The Wanderer [2013-05-13 07:55 -0400]:
For the full 64+32 Wine, I don't believe this is possible - or if
it is possible, no way of doing it has yet been documented that I
know of. The official Wine
Le 13/05/2013 15:51, Paul Wise a écrit :
[...] as long
as there is a way to build-depend on the build-dependencies for a
source package, that should be fine. As a bonus we can get rid of
mk-build-deps :)
How so?
--
Stéphane
--
To UNSUBSCRIBE, email to
On 05/13/2013 11:00 AM, Wookey wrote:
+++ The Wanderer [2013-05-13 10:22 -0400]:
On 05/13/2013 09:46 AM, Wookey wrote:
OK. I'd like to understand some more about this, as it's a
similar issue to other cross-compiler toolchains, and if we can't
solve both the same way then our design is
Guillem Jover writes (Re: Temporary solution for changelog problem in
binNMUs):
dpkg supports --control-show and --control-list (already in wheezy), which
can be used for stuff like:
$ dpkg-query --control-show dpkg changelog
for installed packages, for example. Or:
$ dpkg-deb --info
Hi,
On Montag, 13. Mai 2013, Guillem Jover wrote:
The only thing the metadata solution would need now, is changing
packaging helper, all packages not using a helper, and changelog and
copyright extractors to look first in the new place, and fallback to
the old one for backwards compatibility.
On Mon, May 13, 2013 at 06:21:24PM +0530, Ritesh Raj Sarraf wrote:
On Monday 13 May 2013 03:55 PM, Arno Töll wrote:
note that, unlike Ubuntu we do not provide automated debug packages.
Hence many crash reports aren't usable at all when they are generated on
Debian systems.
This could be a
Le lundi 13 mai 2013 15:37:28, Philip Hands a écrit :
If you must see the man page from a particular package:
dget apache2.2-common
mkdir -p ./tmp/apache2.2-common
dpkg -X apache2.2-common_2.2.22-13_amd64.deb ./tmp/apache2.2-common
JTYI, you could also use debman -p apache2.2-common
On Mon, 2013-05-13 at 17:04:51 +0100, Ian Jackson wrote:
The real problem is that these changelog files are primarily intended
for human beings. They should live in /usr/share/doc, and their
location should be transparent.
The fact that parts of it might be mostly consumable by human beings,
+++ Steve Langasek [2013-05-13 11:22 -0500]:
On Mon, May 13, 2013 at 06:21:24PM +0530, Ritesh Raj Sarraf wrote:
On Monday 13 May 2013 03:55 PM, Arno Töll wrote:
note that, unlike Ubuntu we do not provide automated debug packages.
Hence many crash reports aren't usable at all when they are
On Mon, 2013-05-13 at 18:04:58 +0200, Holger Levsen wrote:
On Montag, 13. Mai 2013, Guillem Jover wrote:
The only thing the metadata solution would need now, is changing
packaging helper, all packages not using a helper, and changelog and
copyright extractors to look first in the new place,
On Sat, 11 May 2013 11:39:28 +0200, Goswin von Brederlow goswin-...@web.de
wrote:
On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote:
The big issue which crops up then isn't so much the directory structure's
impact on the build process, but rather its impact on the packaging
Hi,
On Sun, Apr 01, 2012 at 02:59:24AM +0100, Ben Hutchings wrote:
Thanks for your work, but isn't it time we quietly got rid of this
library? Video memory and mode setting should be managed by the kernel,
not by applications. It's bad enough that we had the X server doing
this for years
On Mon, May 13, 2013 at 05:56:25PM +0100, Wookey wrote:
+++ Steve Langasek [2013-05-13 11:22 -0500]:
On Mon, May 13, 2013 at 06:21:24PM +0530, Ritesh Raj Sarraf wrote:
On Monday 13 May 2013 03:55 PM, Arno Töll wrote:
note that, unlike Ubuntu we do not provide automated debug packages.
On May 13, gustavo panizzo gfa g...@zumbi.com.ar wrote:
On 2013-05-12 21:31, m...@linux.it wrote:
Maybe kfreebsd will do, but as I explained at FOSDEM I plan to
make udev depend on either upstart or systemd.
do you have a link to a presentation, blog post, or whatever
explaining the
On May 13, Philip Hands p...@hands.com wrote:
No matter what the technical merits, the inevitable flame war regarding
copyright assignment seems very likely to render upstart a non-starter
as an essential element of Debian.
I think that this is a reasonable element to consider in our decision
On 05/13/2013 03:06 PM, Ritesh Raj Sarraf wrote:
1) Duplicate bug reports: There are high possibilities that we could see
a sudden increase in the number of bug reports, many duplicates. This is
something I'm not sure how we want to evaluate. We could give apport a
try, and leave it to the
On 13/05/13 18:26, Stephen Kitt wrote:
Yes, but that's not the problem. Take the premise that the target
directory structure is as described above, so most library
development packages ship as many headers as possible in
/usr/include. For now we'll assume all mingw-w64-...-dev headers
are in
Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar georg...@debian.org
* Package name: clonezilla
Version : 3.3.10
Upstream Author : 2007-2013 Steven Shiau ste...@nchc.org.tw
2007-2013 Blake, Kuo-Lien Huang Huang klha...@gmail.com
2007-2013 Ceasar Sun
On Mon, 13 May 2013 11:43:05 -0400, The Wanderer wande...@fastmail.fm wrote:
On 05/13/2013 11:00 AM, Wookey wrote:
OK. And is 32-bit wine (to be installed on amd64) an amd64 binary
that understands i386 code or is it actually i386 code? If the latter
to what degree are wine32:amd64 and
Philip Hands p...@hands.com writes:
No matter what the technical merits, the inevitable flame war regarding
copyright assignment seems very likely to render upstart a non-starter
as an essential element of Debian.
Debian already uses many packages as part of its essential set that
require
On Monday 13 May 2013 11:04 PM, Steve Langasek wrote:
From past discussions, I think there's a very clear consensus in favor of
doing this; it's now a SMOP.
The requirements are, in order:
- implement the changes necessary to ensure all binary packages in the
archive are built on the
On Mon, May 13, 2013 at 11:14:58AM -0700, Russ Allbery wrote:
When evaluating relative merits, I think the relative sizes of the
development communities and the integration with other important
subsystems (like desktop environments) are more relevant reasons to be
concerned about upstart
Package: rsync
Severity: minor
Version: 3.0.9-4
On Sun, 12 May 2013, Philip Hands wrote:
The current state of rsyncd is probably my fault (as initial packager
of rsync). One _could_ have an rsyncd package, containing just a
commented out example /etc/rsyncd.conf and the init.d script, but I
Package: wnpp
Severity: wishlist
Owner: Florian Schlichting f...@debian.org
* Package name: libcatalyst-dispatchtype-regex-perl
Version : 5.90032
Upstream Author : Catalyst Contributors, Mark Grimes mgri...@cpan.org
* URL :
On Mon, May 13, 2013 at 08:46:23AM +0100, Roger Leigh wrote:
There is no need for udev to be dependent upon a specific init
system, other than laziness.
Except if you want to receive device plug events as triggers to start
up / shut down services. The separation then gets quite blurry with
whom
Hi,
Ian Jackson wrote:
The real problem is that these changelog files are primarily intended
for human beings. They should live in /usr/share/doc, and their
location should be transparent.
I was convinced of this until I remembered that package descriptions
are very similar in this respect.
2013/5/13 Philipp Kern pk...@debian.org:
On Mon, May 13, 2013 at 08:46:23AM +0100, Roger Leigh wrote:
There is no need for udev to be dependent upon a specific init
system, other than laziness.
Except if you want to receive device plug events as triggers to start
up / shut down services. The
2013/5/14 Игорь Пашев pashev.i...@gmail.com:
2013/5/13 Philipp Kern pk...@debian.org:
On Mon, May 13, 2013 at 08:46:23AM +0100, Roger Leigh wrote:
There is no need for udev to be dependent upon a specific init
system, other than laziness.
Except if you want to receive device plug events as
Hi fellow Debian Developers and Maintainers,
this is just a mail to notice you of upcoming libgd2-dev transition.
Two things has happened with GD Library:
1. I have dropped the {xpm,noxpm} dichotomy and there's only
libgd2-dev now. There are transitional packages which are ment
to help
On Mon, May 13, 2013 at 13:14:51 -0700, Jonathan Nieder wrote:
One problem that that doesn't solve is what to do when a package would
be able to borrow its /doc/package directory from another package
(using a symlink) but for the changelog and copyright (which gets even
harder when binnmus
Hi,
[ dropped -release and -wb-team, added 681289@bugs.d.o ]
Guillem Jover guil...@debian.org writes:
On Mon, 2013-05-13 at 17:04:51 +0100, Ian Jackson wrote:
The real problem is that these changelog files are primarily intended
for human beings. They should live in /usr/share/doc, and their
Hi,
[ dropped -release and -wb-team ]
Jonathan Nieder jrnie...@gmail.com writes:
One problem that that doesn't solve is what to do when a package would
be able to borrow its /doc/package directory from another package
(using a symlink) but for the changelog and copyright (which gets even
Sadly
On 13 May 2013 00:00, Sune Vuorela nos...@vuorela.dk wrote:
How many hours of developer time is it worth to spend to accomplish
these, in my opinion, real fringe use cases ?
Let me start out by saing that I'm not at all a fan of the machine readable
copyright files - it seems to me
Le lundi 13 mai 2013 à 12:34 -0500, Steve Langasek a écrit :
- implement the changes necessary to ensure all binary packages in the
archive are built on the buildds, not on developers' systems[1]
This is not even necessary.
- deploy centralized infrastructure, outside of the main
Le Mon, May 13, 2013 at 03:16:57PM +0200, Guillem Jover a écrit :
On Mon, 2013-05-13 at 11:14:07 +0200, Ansgar Burchardt wrote:
There have been previous discussions how to fix this[2]. The dpkg
maintainers would like to treat changelogs and copyright files as
metadata and move them out of
Jonathan Nieder writes (Re: Temporary solution for changelog problem in
binNMUs):
I was convinced of this until I remembered that package descriptions
are very similar in this respect. My gut feeling to expect to find
changelogs in /usr/share/doc/package is actually mostly due to
habit, I
Le Tue, May 14, 2013 at 09:31:00AM +1200, Robert Collins a écrit :
Sadly
On 13 May 2013 00:00, Sune Vuorela nos...@vuorela.dk wrote:
How many hours of developer time is it worth to spend to accomplish
these, in my opinion, real fringe use cases ?
Let me start out by saing that I'm not
Ian Jackson wrote:
Jonathan Nieder writes (Re: Temporary solution for changelog problem in
binNMUs):
One problem that that doesn't solve is what to do when a package would
be able to borrow its /doc/package directory from another package
(using a symlink) but for the changelog and copyright
On Mon, May 13, 2013 at 11:17 PM, Stéphane Glondu wrote:
Le 13/05/2013 15:51, Paul Wise a écrit :
[...] as long
as there is a way to build-depend on the build-dependencies for a
source package, that should be fine. As a bonus we can get rid of
mk-build-deps :)
How so?
In my case, I already
1 - 100 of 222 matches
Mail list logo
