Re: Cannot log into people.debian.org

On Tue, May 14, 2013 at 2:09 PM, Norbert Preining wrote: > I have copied the new ssh id_rsa.pub key to the authorized_keys debian.org hosts do not pay attention to ~/.ssh/authorized_keys, you need to set them up through the LDAP mail gateway: https://db.debian.org/doc-mail.html -- bye, pabs h

Cannot log into people.debian.org

Hi fellow DDs, can anyone explain me why I cannot log into people.debian.org from my new computer, while from my old laptop it works? I have copied the new ssh id_rsa.pub key to the authorized_keys file on travel, but still it simply tells me: $ ssh -v ... ... debug1: Offering RSA public key: /ho

Re: Switching default dpkg-deb compressor to xz

Ben Hutchings writes: > John D. Hendrickson and Sara Darnell wrote: >> It's too new to say if it has no long term problems (ie, such as >> support issues). > xz has been supported in Debian for some time, with no problems that I'm > aware of. It's also being widely adopted by upstreams and is

Re: wheezy postmortem re rc bugfixing

On Mon, 2013-05-13 at 21:41 -0400, John D. Hendrickson and Sara Darnell wrote: > Yea? When are you filing a patch that corrects it? > > complaining does nothing. we all know what would be > better and move toward it > > and your forgetting the by-law: you don't fix what > you think is better by

Re: Switching default dpkg-deb compressor to xz

On Mon, 2013-05-13 at 21:53 -0400, John D. Hendrickson and Sara Darnell wrote: > I'm complaining. > > Why are you fixing something that isn't broken and isn't an issue ? It's not broken, but there is an issue: it's getting hard to fit a generally useful set of packages and tasks on CD#1, and xz c

Re: wheezy postmortem re rc bugfixing

Yea? When are you filing a patch that corrects it? complaining does nothing. we all know what would be better and move toward it and your forgetting the by-law: you don't fix what you think is better by breaking software that works unless you can really prevent all breakage after all. what y

Re: Switching default dpkg-deb compressor to xz

I'm complaining. Why are you fixing something that isn't broken and isn't an issue ? Are you trying to cause problems with free software? Are you playing favorites? It's too new to say if it has no long term problems (ie, such as support issues). How is shipping (ie kernel) in all three of .gz

Re: parsable copyright format 1.0 (jessie release goals)

On Tue, May 14, 2013 at 5:31 AM, Robert Collin wrote: > Wearing my HP hat - ... This is a large component of why Fossology > was born - http://www.fossology.org/projects/fossology/wiki/About_Us. While you are wearing a HP/Fossology hat, how about reintroducing fossology to Debian? I guess discus

Re: jessie release goals

On Mon, May 13, 2013 at 10:36 PM, Vincent Lefevre wrote: > But there isn't a dependency (and currently all the config needs > to be done manually, as described in the sensord(8) man page). > So, this won't work. That sounds like a suboptimal package, -- bye, pabs http://wiki.debian.org/PaulWis

Re: Source build-dependencies

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,

Re: Temporary solution for changelog problem in binNMUs

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/ directory from another package >> (using a symlink) but for the changelog and copyrig

Re: parsable copyright format 1.0 (jessie release goals)

Le Tue, May 14, 2013 at 09:31:00AM +1200, Robert Collins a écrit : > Sadly > On 13 May 2013 00:00, "Sune Vuorela" 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

Re: Temporary solution for changelog problem in binNMUs

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/ is actually mostly due to > habit, I susp

Re: Temporary solution for changelog problem in binNMUs

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

Re: Apport for Debian

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 arch

Re: parsable copyright format 1.0 (jessie release goals)

Sadly On 13 May 2013 00:00, "Sune Vuorela" 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 there has to b

Re: Temporary solution for changelog problem in binNMUs

Hi, [ dropped -release and -wb-team ] Jonathan Nieder writes: > One problem that that doesn't solve is what to do when a package would > be able to borrow its /doc/ directory from another package > (using a symlink) but for the changelog and copyright (which gets even > harder when binnmus are i

Re: Temporary solution for changelog problem in binNMUs

Hi, [ dropped -release and -wb-team, added 681289@bugs.d.o ] Guillem Jover 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 >> location s

Re: Temporary solution for changelog problem in binNMUs

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/ directory from another package > (using a symlink) but for the changelog and copyright (which gets even > harder when binnmus are in

Upcoming libgd2-{xpm,noxpm}-dev -> libgd2-dev transition

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 wi

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)

2013/5/14 Игорь Пашев : > 2013/5/13 Philipp Kern : >> 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 /

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)

2013/5/13 Philipp Kern : > 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 separati

Re: Temporary solution for changelog problem in binNMUs

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 respec

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)

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 who

Bug#708179: ITP: libcatalyst-dispatchtype-regex-perl -- Regex DispatchType for Catalyst

Package: wnpp Severity: wishlist Owner: Florian Schlichting * Package name: libcatalyst-dispatchtype-regex-perl Version : 5.90032 Upstream Author : Catalyst Contributors, Mark Grimes * URL : http://search.cpan.org/dist/Catalyst-DispatchType-Regex/ * License :

Bug#708177: Rsync should default to ENABLE=TRUE and test for the existence of /etc/rsyncd.conf as it already does

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

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh

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 c

Re: Apport for Debian

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

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh

Philip Hands 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 copyright assig

Re: Depends: libfoo:foreign ???

On Mon, 13 May 2013 11:43:05 -0400, The Wanderer 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 wine32:i386 any di

Bug#708171: ITP: clonezilla -- bare metal backup and recovery of disk drives

Package: wnpp Severity: wishlist Owner: Georges Khaznadar * Package name: clonezilla Version : 3.3.10 Upstream Author : 2007-2013 Steven Shiau 2007-2013 Blake, Kuo-Lien Huang Huang 2007-2013 Ceasar Sun 2007-2013 Jazz Wang 2007-2013

Re: jessie release goals

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

Re: Apport for Debian

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

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)

On May 13, Philip Hands 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 process. -

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)

On May 13, "gustavo panizzo " 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 rationale behind thi

Re: Apport for Debian

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 pac

Re: Bug#666490: O: svgalib -- console SVGA display libraries

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

Re: jessie release goals

On Sat, 11 May 2013 11:39:28 +0200, Goswin von Brederlow 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 > > process. If the

Re: Temporary solution for changelog problem in binNMUs

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

Re: Apport for Debian

+++ 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

Re: Temporary solution for changelog problem in binNMUs

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

Re: jessie release goals

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-c

Re: Apport for Debian

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 cou

Re: Temporary solution for changelog problem in binNMUs

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 compatibili

Re: Temporary solution for changelog problem in binNMUs

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 --in

Re: Depends: libfoo:foreign ???

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 poor

Re: Source build-dependencies

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 debian-devel-requ...@lists.debian

Re: Depends: libfoo:foreign ???

+++ 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 officia

Re: Depends: libfoo:foreign ???

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 intermedi

Re: jessie release goals

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 automatica

Re: /bin/sh (was Re: jessie release goals)

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,

Re: Depends: libfoo:foreign ???

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 get

Re: jessie release goals

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

Re: jessie release goals

On 2013-05-13 14:37:28 +0100, Philip Hands wrote: > Vincent Lefevre 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 > > /usr/

Re: Depends: libfoo:foreign ???

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 invo

Re: Temporary solution for changelog problem in binNMUs

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

Re: jessie release goals

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

Re: Source build-dependencies

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 exam

Re: Depends: libfoo:foreign ???

+++ 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, w

Re: jessie release goals

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 proble

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)

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 website

Re: jessie release goals

Vincent Lefevre writes: > On 2013-05-13 12:02:31 +0100, Philip Hands wrote: >> Vincent Lefevre 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 w

Re: Apport for Debian

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 d

Re: Apport for Debian

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 mainta

Re: Temporary solution for changelog problem in binNMUs

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 t

Re: detailed lists with archive contents - more than just Contents

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 exp

Re: Temporary solution for changelog problem in binNMUs

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]

Re: Bug#707601: ITP: debmake -- helper script to make the Debian source package

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

Re: Temporary solution for changelog problem in binNMUs

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]

Re: Merging / and /usr (was: jessie release goals)

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

Re: jessie release goals

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 configurat

Re: Merging / and /usr (was: jessie release goals)

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" wrote: > >> Or in other words: to make essential functionality not available if > >> /usr is broken. > >Again: this is not we are di

Re: jessie release goals

]] 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. >

Re: Temporary solution for changelog problem in binNMUs

Goswin von Brederlow (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 time is useless d

Bug#708132: ITP: bcache-tools -- These are the userspace tools required for bcache.

Package: wnpp Severity: wishlist Owner: tstri...@rootcu.be * Package name: bcache-tools Version : 1.0 Upstream Author : Kent Overstreet * URL : http://bcache.evilpiepirate.org/ * License : GPL Programming Lang: C Description : These are the userspace t

Re: Bug#707601: ITP: debmake -- helper script to make the Debian source package

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 &

Re: Temporary solution for changelog problem in binNMUs

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

Re: Bug#707601: ITP: debmake -- helper script to make the Debian source package

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 p

Re: jessie release goals

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 *onl

Re: Depends: libfoo:foreign ???

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 I

Re: jessie release goals

On 2013-05-13 12:02:31 +0100, Philip Hands wrote: > Vincent Lefevre 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 > > stop the

Re: jessie release goals

]] 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. S

Bug#708122: ITP: pjsip -- VoIP library implementing SIP and related protocols

Package: wnpp Severity: wishlist Owner: Tzafrir Cohen * 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 Description : VoI

Re: jessie release goals

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,

Re: jessie release goals

Vincent Lefevre 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 docroot a

Re: jessie release goals

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

Re: epoch fix?

]] 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 r

Re: Bug#707601: ITP: debmake -- helper script to make the Debian source package

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 tw

Re: jessie release goals

]] 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.

Re: epoch fix?

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 :

Re: jessie release goals

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 a

Re: wheezy postmortem re rc bugfixing

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 i

Re: Apport for Debian

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

Re: Depends: libfoo:foreign ???

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: > > > > > > >

Re: Apport for Debian

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

Re: Apport for Debian

]] 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 p

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)

Marco d'Itri writes: > On May 13, Holger Levsen 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 say nobody is seriously sa

Re: Apport for Debian

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 pro

Re: detailed lists with archive contents - more than just Contents

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 o

Re: jessie release goals

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 http://wiki.debian.or

  1   2   >