Re: some thoughts on DEP-5

[Jonas Smedegaard]

On 11-05-20 at 07:53pm, Christoph Anton Mitterer wrote:
> 1) The description of the License field says:
> >Otherwise, this field should either include the full text
> >of the license(s) or include a pointer to the license file under
> >`/usr/share/common-licenses`.
> 
> This could be interpreted as if just the pointer would be enough, 
> which is however (AFAIU) not what is meant by the policy 12.5, which 
> says a verbatim copy must be included and the pointer is (AFAIU) just 
> something that should be given in addition?!

DEP-5 is an (optional!) addition to Debian Policy: Nothing in DEP-5 
overrides requirements in Debian Policy.

I suspect such false interpretation could only occur if only reading 
DEP-5 (not Debian Policy), which is bad in itself.  It is wrong approach 
IMO to extend DEP-5 with material from Debian Policy - instead the 
relationship with Debian Policy should be emphasized if needed.


> 2) In general it might be worth suggest that pointer being given in 
> the Comment field, IMO it's not really part of the license. e.g.
> >Comment: On Debian systems, the full text of the “GNU General Public 
> >License version 3” can be found in the file 
> >“/usr/share/common-licenses/GPL-3”.
> 
> But then one would possibly also need to allow the Comment field for 
> the stand-alone License paragraphs.

Hmm - This sounds very much like my current practice.

I use the License field strictly for verbatim copied text, so as to 
allow potential future automated verifications of it. Commonly I move 
2 kind of info into a Comment field:

 a) reference to actual license when applicable
 b) reference to canonical source of license

The reason for b) is our common practice in Debian to update/replace 
that when upstream reference is obsolete - which in effect renders the 
text no longer a verbatim copy.

Is the following (from packaging of 4store, but similar to ~100 other 
packages) in violation with current DEP-5?:


License: LGPL-2.1+^GNULibC
 The GNU C Library is free software; you can redistribute it and/or
 modify it under the terms of the GNU Lesser General Public License as
 published by the Free Software Foundation; either version 2.1 of the
 License, or (at your option) any later version.
 .
 The GNU C Library is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 Lesser General Public License for more details.
Comment:
 On Debian systems the full text of the GNU Lesser General Public
 License (LGPL) version 2.1 can be found in
 '/usr/share/common-licenses/LGPL-2.1'.
 .
 You should have received a copy of the GNU Lesser General Public
 License along with this program.  If not, see
 .



> 3) Just a cosmetic/perfectionist issue:
> People would probably simply use the examples in DEP5 for the 
> formulation of their pointers, currently:
> >On Debian systems, the full text of the GNU General Public License 
> >version 2 can be found in the file 
> >`/usr/share/common-licenses/GPL-2'.
> may I suggest, as we have UTF-8 and so anyway to use the "right" 
> quotation marks, and perhaps also to quote the name of the license, so 
> that we'd have:
> >On Debian systems, the full text of the “GNU General Public License 
> >version 2” can be found in the file 
> >“/usr/share/common-licenses/GPL-2”.

Good point.  I like that.  Just as that suddle change of implicitly 
using it in examples - not explicitly encouraging it in text.

...but not a strong point: I suggest to keep this in mind for a later 
revision of DEP-5, and let the current one become final as-is.


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Sponsorship in Debian (Re: Ubuntu-originated packages in Debian (Re: ubuntu keyring?))

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Jonas,

sorry for my late answer, but you ended up in my spam filter :)

On 20.05.2011 17:06, Jonas Smedegaard wrote:
> An alternative is to seek team members rather than mentors.  Only one 
> team member in each team needs to have upload rights.

While I didn't mention it explicitly, I don't see a problem in forming a
team, with whomever interested to co-maintain my package(s)*, especially
not if that person has upload permissions.

If someone wants to join me, fine - if not, I'm fine all alone as well.
Hence I didn't ask explicitly for it, as the likelihood in finding a
permanent team member maybe is even smaller. On the other hand, I think,
everyone interested can always write and help me anyway regardless I'm
actively looking for someone or not. I don't think there do exist (m)any
packaging teams in Debian, which would decline offers to help at all,
whether they are searching for someone or not.

* unless already in a team, but this is not where my critics applies.

- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJN13m9AAoJEMcrUe6dgPNtWpEP/11HzWLRiaukOaTqsz5kPsLk
5QMDoUw1TsZFNxnnGGMeFi6QcrhYVewjZ7FTu4Ga/V1gLz5lqQMa3r8/mC4/aPp+
UKwLHsJ2S20Lsp7ElQKNSyUO/TCeyyrTpGKF3d0voVv4SDKfhcUCxNLXmqt3rJzK
znX7+nkKp6AA7KedJ+CjCkH2HqJSJrn3X8VID3fTnKJOKRiHsLpVijLOhubn0ert
jzaadAoqmaEnzOreUodagn1N590VFl4V+1Q+7xWMpLgbbpSmQc5GEB/UrBn5oITO
2BmcT+dtDwR2G0FBlpN42Jws28WleB5cq0tEM3i/TscCsurb4z3WmMUfWe8FqzGj
RXHVA/CLeNB8T3K2ugcXntZP7xpJGfFqcdJbmb7g16jtsW7WfmO7zh0P8UJkgyM4
2vIgJOlieouRrXn0ztpKCftFFNlEX7GEuroHxuB2RCWv/7MamPNkfIK2KhnerqTe
Iv1wpZHQtc8rabiHGp/MNEw7QfnwZq8GHJxV/1Yzo6Z8L+LLJ8KK7IgeiQgfhyXU
QjOXTzpGOQ/iHg9s9FCFrzSD75IYqxdHAidDW7Mvfl0246GllFaUyPtODbd99qwl
zMEc2Sfq8dT+0oVYztumyc+Nw8oxeeVSTWD4mt/AscMXhlibD62UDhMVCpL+C3Ba
72xPtqOzCkz4pMovYff5
=NJuw
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dd779be.3080...@toell.net

Re: Sponsorship in Debian (Re: Ubuntu-originated packages in Debian (Re: ubuntu keyring?))

[Holger Levsen]

Hi Joey,

On Freitag, 20. Mai 2011, Joey Hess wrote:
> > I'm not in the position to judge this, but the DM application /seems/ to
> > be understand as proof the applicant "knows advanced packaging(tm)".
> This is entirely backwards. A DM who is not maintaining shared libraries
> does not need to know how to package shared libraries. A DM who is not
> maintaining a daemon does not need to know how to package a daemon. A DM
> who is not maintaining an Essential package does not need to know how to
> make robust Essential packages. Each NEW package a Debian Maintainer
> makes has to be vetted by some DD, so it's entirely fine for them to start
> off with only enough knowledge to maintain the single package they have
> in the archive.

Right. Thanks for reminding us! So how do we fix this again?
 
I'm the DD Arno mentioned, who would advocate him for DD but not for DM. 
Reading this thread I'm thinking about changing my mind...


cheers,
Holger


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201105211154.25888.hol...@layer-acht.org

Re: some thoughts on DEP-5

[Andrei Popescu]

On Sb, 21 mai 11, 09:55:48, Jonas Smedegaard wrote:
> On 11-05-20 at 07:53pm, Christoph Anton Mitterer wrote:
> 
> > 3) Just a cosmetic/perfectionist issue:
> > People would probably simply use the examples in DEP5 for the 
> > formulation of their pointers, currently:
> > >On Debian systems, the full text of the GNU General Public License 
> > >version 2 can be found in the file 
> > >`/usr/share/common-licenses/GPL-2'.
> > may I suggest, as we have UTF-8 and so anyway to use the "right" 
> > quotation marks, and perhaps also to quote the name of the license, so 
> > that we'd have:
> > >On Debian systems, the full text of the “GNU General Public License 
> > >version 2” can be found in the file 
> > >“/usr/share/common-licenses/GPL-2”.
> 
> Good point.  I like that.  Just as that suddle change of implicitly 
> using it in examples - not explicitly encouraging it in text.
> 
> ...but not a strong point: I suggest to keep this in mind for a later 
> revision of DEP-5, and let the current one become final as-is.

While I'm a strong supporter of UTF-8[1] I don't think it's a good idea 
to use non-ASCII characters unless really needed[2], since things will 
look ugly non-UTF-8 systems, and this does *not* help speed up adoption 
of UTF-8.

[1] none of the legacy ISO-* encodings has full support for my native 
language, including quotation marks
[2] Author names would be a good reason to use UTF-8

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Conditional Recommends

[Josselin Mouette]

Hi all,

in Debian many packages have a fine granularity, which is a very good
thing. Unfortunately there is a drawback; when you install two programs
A and B that are designed to interact together, often the piece of code
that makes them interact together is in a separate package (A-plugin-B)
that depends on both. When you install A and B, they don’t interact
together and you have to understand you also need A-plugin-B.

Therefore, I’m wondering whether it would be possible to extend the
syntax of Recommends to allow for conditional dependencies. For example,
in this case:
Package: A
Recommends: A-plugin-B {B}
APT would be made to install A-plugin-B by default, but only if B is
installed too. In addition, it would also have to install it while
pulling B if A is already here.

This has numerous use cases in desktop environment packages. It would
also solve the problem of language packs, and you could ensure that when
installing OOo or iceweasel it would also come with the language packs
corresponding to the installed language tasks on your system.

I’m not familiar at all with the APT internals, so I’d appreciate if
knowledgeable people could answer my questions. 
  * Does it make any sense at all? 
  * If so, how hard would it be to implement? 
  * Does it need changes outside APT? 
  * Do you think it would be useful? 
  * If not, what could be done for the aforementioned issues?

Cheers,
-- 
.''`.  Josselin Mouette
: :' :
`. `'
  `-


signature.asc
Description: This is a digitally signed message part

Bug#627510: ITP: python-seqdiag -- seqdiag generate sequence-diagram image file from spec-text file.

[Kouhei Maeda]

Package: wnpp
Severity: wishlist
Owner: Kouhei Maeda 


* Package name: python-seqdiag
  Version : 0.3.4
  Upstream Author : Takeshi Komiya 
* URL : https://bitbucket.org/tk0miya/seqdiag
* License : Apache
  Programming Lang: Python
  Description : generate sequence-diagram image file from spec-text file.

 Generate sequence-diagram from dot like text (basic feature).
 Multilingualization for node-label (utf-8 only).
 You can get some examples and generated images on 
 http://tk0miya.bitbucket.org/seqdiag/build/html/index.html



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110521112548.5189.68574.report...@silicon.palmtb.net

Re: Conditional Recommends

[Sune Vuorela]

On 2011-05-21, Josselin Mouette  wrote:
>   * Does it make any sense at all?=20
>   * Do you think it would be useful?=20

I do think it makes sense and is useful.

>   * If not, what could be done for the aforementioned issues?

I have mostly thought about the 'translation pack' issues, and I guess
it needs some sort of relation in the package.
I was thinking in lines of a new field:
Package: konqueror
Translations: kde-l10n-XX
or 
Package: konq-plugins
Translations: konq-plugins-l10n

where apt would substitute XX with configured language codes and try to
install that, and apt in the latter case if configured to pull in
translations, pull in that package.

But maybe I like your more generic approach better.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnitfaqp.p7v.nos...@sshway.ssh.pusling.com

Re: [pkg-cryptsetup-devel] Bug#626641: Bug#626641: cryptsetup: bug #587220 re-introduced

[Jonas Meurer]

Hey,

On 20/05/2011 Christoph Anton Mitterer wrote:
> On Tue, 2011-05-17 at 13:48 +0200, Jonas Meurer wrote:
> > - cryptsetup is not the only userspace tool which manages dm-crypt
> >   devices. Low-level tools like dmsetup, udev, hal; commandline tools
> >   like cryptmount and gui applications like gnome-mount etc. might
> >   unlock/lock encrypted devices as well.
> That's a good point, I've completely forgot, when I've said in another
> email, that I _could_ live with a cryptsetup package whose removal fails
> if the are still open devices left.
> 
> 
> > - the cryptdisks initscript only manages dm-crypt devices which are
> >   listed in the crypttab. Therefore otherwise unlocked devices are
> >   ignored.
> Though this is another issue:
> Wouldn't it make sense to try at the very end "just before
> shutdown/reboot" to close any remaining _non managed_ dm-crypt devices?

I much prefer the solution that the cryptdisks initscripts manage only
the devices they're taught to take care of. In other words only the
devices listed in crypttab.

I see the point that devices might be open that aren't closed properly
at shutdown, but first I assume that kernel closes them, and second I
don't want to start messing around with devices which are not properly
closed by other software for whatever reason.

> > Sorry Christoph, but this is simply not an option.
> Out of curiosity: Did someone from the policy guys came and request this
> from you? Cause we had it that way for some time now.

Not "policy guys" as these don't exist. every maintainer is responsible
for keeping her/his packages policy compliant. but yes, there was a
bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625468

Greetings,
 jonas


signature.asc
Description: Digital signature

Bug#627515: ITP: gnome-shell-extensions -- Extensions to extend functionality of GNOME Shell

[Bilal Akhtar]

Package: wnpp
Severity: wishlist
Owner: Bilal Akhtar 


* Package name: gnome-shell-extensions
  Version : 3.0.2
* URL : http://live.gnome.org/GnomeShell/Extensions
* License : GPLv2
  Programming Lang: JavaScript, CSS
  Description : Extensions to extend functionality of GNOME Shell

The GNOME Shell redefines user interactions with the GNOME desktop. In
particular, it offers new paradigms for launching applications,
accessing documents, and organizing open windows in GNOME. Later, it
will introduce a new applets eco-system and offer new solutions for
other desktop features, such as notifications and contacts management.
The GNOME Shell is intended to replace functions handled by the GNOME
Panel and by the window manager in previous versions of GNOME. The GNOME
Shell has rich visual effects enabled by new graphical technologies.
.
This package contains a set of extensions which add functionality and/or
add to the looks of the GNOME Shell desktop.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110521123532.2513.86125.reportbug@bilal-dell

How to solve race condition between IPv6 ifup and start of services?

[Marc Haber]

Hi,

with the increasing deployment of IPv6 I begin to see an issue
icreasingly often: When an interface is configured for IPv6, it takes
a few seconds before the IPv6 address actually becomes available.
Services that are started in this time window won't listen on IPv6,
which may be unintended behavior. Many people see this behavior as a
bug in the distribution, which is why I am addressing this issue here
on -devel.

Unfortunately, it is non-trivial to find out whether my IPv6
configuration has completed or not. How many addresses will be
assigned to us via stateless autoconfig? Are we running with privacy
extensions? Do we have additional static configuration?

The most "clean" solutions for this issue would be
(a) Modify the services to notice when additional IP addresses come up
and listen there if the service is configured for that IP address
(b) Parse the configuration of each service in the init script and
wait for the configured IP addresses to actually come up.

Both solutions are rather expensive to implement.

Is there a widely accepted method to do things any easier? It is
clearly not acceptable to have to manually log in to a newly booted
server to restart service, neither do I like the idea of changing
runlevels five minutes after reboot to kick IPv6 services to life.

Any more ideas?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qnloj-0003k1...@swivel.zugschlus.de

Re: some thoughts on DEP-5

[Charles Plessy]

Le Sat, May 21, 2011 at 01:43:25AM -0400, Joey Hess a écrit :
> Christoph Anton Mitterer wrote:
> > 1) The description of the License field says:
> > >Otherwise, this field should either include the full text of the
> > >license(s) or include a pointer to the license file under
> > >`/usr/share/common-licenses`.
> > 
> > This could be interpreted as if just the pointer would be enough, which is
> > however (AFAIU) not what is meant by the policy 12.5, which says a verbatim
> > copy must be included and the pointer is (AFAIU) just something that should
> > be given in addition?!
> 
>  Packages distributed under the Apache license (version 2.0), the
>  Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL
>  (versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3) should
>  refer to the corresponding files under `/usr/share/common-licenses',[1]
>  rather than quoting them in the copyright file.

Actually, the Policy does not contain all our requirements for debian/copyright
files (#462996) and the following announce suggests that when license headers
are available, they should be reproduced:

http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110521132602.gb5...@merveille.plessy.net

Re: How to solve race condition between IPv6 ifup and start of services?

[Ben Hutchings]

On Sat, 2011-05-21 at 15:01 +0200, Marc Haber wrote:
> Hi,
> 
> with the increasing deployment of IPv6 I begin to see an issue
> icreasingly often: When an interface is configured for IPv6, it takes
> a few seconds before the IPv6 address actually becomes available.
> Services that are started in this time window won't listen on IPv6,
> which may be unintended behavior. Many people see this behavior as a
> bug in the distribution, which is why I am addressing this issue here
> on -devel.
> 
> Unfortunately, it is non-trivial to find out whether my IPv6
> configuration has completed or not. How many addresses will be
> assigned to us via stateless autoconfig? Are we running with privacy
> extensions? Do we have additional static configuration?
> 
> The most "clean" solutions for this issue would be
> (a) Modify the services to notice when additional IP addresses come up
> and listen there if the service is configured for that IP address
> (b) Parse the configuration of each service in the init script and
> wait for the configured IP addresses to actually come up.
[...]

(c) Set the IP_FREEBIND socket option before binding.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: How to solve race condition between IPv6 ifup and start of services?

[Michael Biebl]

Am 21.05.2011 15:01, schrieb Marc Haber:
> 
> The most "clean" solutions for this issue would be
> (a) Modify the services to notice when additional IP addresses come up
> and listen there if the service is configured for that IP address
> (b) Parse the configuration of each service in the init script and
> wait for the configured IP addresses to actually come up.
> 
> Both solutions are rather expensive to implement.

A similar issue (not directly IPv6 related) was discussed on fedora-devel not
very long ago. It was about the more "dynamic" nature of NetworkManager and how
certain services currently don't cope with the network not being up and fully
configured, when they start up. [1]

See some suggestions how to address this are at [2].

HTH,
Michael

[1] http://lists.fedoraproject.org/pipermail/devel/2011-May/151254.html
[2] http://lists.fedoraproject.org/pipermail/devel/2011-May/151272.html
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Conditional Recommends

[Carsten Hey]

* Josselin Mouette [2011-05-21 13:24 +0200]:
> Therefore, I’m wondering whether it would be possible to extend the
> syntax of Recommends to allow for conditional dependencies. For example,
> in this case:
> Package: A
> Recommends: A-plugin-B {B}

The following would be more general:

Package: A
Recommends: !B | A-plugin-B


If we have had this syntax a lot earlier, for example "Build-Conflicts:
X" could have been written as "Build-Depends: !X".  But we already
invented all those fields and the number of additional use cases for
exclamation marks as negation in package relationship fields seems to be
rather limited.


With above exclamation mark syntax, we could also express "weak
conflicts", e.g.:

Package: X
Recommends: !Y

Apt would remove Y by default if X gets installed, but users could
overwrite this.


Is there any need for such a weak conflict, e.g., to get rid of gcc-4.4
if gcc-4.5 gets installed?  Apt's autoremove feature presumably already
handles most of these cases.

If we add conditional recommends and there is a need for weak conflicts,
I think we should choose a syntax that allows us to express both.


Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110521155628.ga4...@furrball.stateful.de

Re: How to solve race condition between IPv6 ifup and start of services?

[Marc Haber]

On Sat, 21 May 2011 14:31:45 +0100, Ben Hutchings
 wrote:
>On Sat, 2011-05-21 at 15:01 +0200, Marc Haber wrote:
>> with the increasing deployment of IPv6 I begin to see an issue
>> icreasingly often: When an interface is configured for IPv6, it takes
>> a few seconds before the IPv6 address actually becomes available.
>> Services that are started in this time window won't listen on IPv6,
>> which may be unintended behavior. Many people see this behavior as a
>> bug in the distribution, which is why I am addressing this issue here
>> on -devel.
>> 
>> Unfortunately, it is non-trivial to find out whether my IPv6
>> configuration has completed or not. How many addresses will be
>> assigned to us via stateless autoconfig? Are we running with privacy
>> extensions? Do we have additional static configuration?
>> 
>> The most "clean" solutions for this issue would be
>> (a) Modify the services to notice when additional IP addresses come up
>> and listen there if the service is configured for that IP address
>> (b) Parse the configuration of each service in the init script and
>> wait for the configured IP addresses to actually come up.
>[...]
>
>(c) Set the IP_FREEBIND socket option before binding.

What does this do? And it needs changes to the software as well.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qnqvo-0002lu...@swivel.zugschlus.de

Re: How to solve race condition between IPv6 ifup and start of services?

[Marc Haber]

On Sat, 21 May 2011 17:22:05 +0200, Michael Biebl 
wrote:
>A similar issue (not directly IPv6 related) was discussed on fedora-devel not
>very long ago. It was about the more "dynamic" nature of NetworkManager and how
>certain services currently don't cope with the network not being up and fully
>configured, when they start up. [1]
>
>See some suggestions how to address this are at [2].

That article says that servers should use FREEBIND or subscribe to
netlink for changes. This is a major effort which needs upstream
cooperation or local patches.

The third option suggests that the network manager option mentioned
there is what one would need for ifupdown, and I don't have the
slightest idea how one could guess whether the networks is "done" now.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qnrf3-0003gd...@swivel.zugschlus.de

Re: new scripts and patches for devscripts

[Tshepang Lekhonkhobe]

On Thu, 2011-03-10 at 00:26 +0100, Benjamin Drung wrote:
> Am Mittwoch, den 09.03.2011, 12:26 -0500 schrieb James Vega:
> > On Tue, Mar 8, 2011 at 7:12 PM, Benjamin Drung  wrote:
> > > Am Mittwoch, den 09.03.2011, 00:05 + schrieb Roger Leigh:
> > >> On Tue, Mar 08, 2011 at 11:01:12PM +0100, Benjamin Drung wrote:
> > >> > Should these script moved from ubuntu-dev-tools into devscripts?
> > >> >
> > >> > Most of the script are written in Python. Rewriting them to get them
> > >> > included in devscripts is too much work without benefit. devscripts
> > >> > would depend on python then.
> > >>
> > >> Most of the scripts are short.  Rewriting would be fairly simple, and
> > >> may be beneficial in removing the Ubuntu-specific bits.
> > >
> > > What speaks against having these script in python? Is python too heavy
> > > for a _development_ machine?
> > 
> > It's not just about a package dependency.  It's more about restricting
> > the knowledge base required for those maintaining the package.
> > 
> > Considering that scripts are contributed to devscripts and the support
> > burden is then commonly left on the shoulders of those maintaining
> > devscripts instead of the original script author, it's in our interest
> > to maintain a consistent set of languages that we are willing to
> > support.  This is currently Perl and shell.
> > 
> > So yes, IMO, accepting scripts written in Python (or any other language)
> > is too heavy.  Not for a "_development_ machine", but for a maintenance
> > team.  If people choose to ignore our requirement and develop scripts in
> > other languages, then they can deal with the consequences.
> 
> Stefano Rivera (stefanor) and I offer to maintain the Python scripts in
> devscripts. Is it enough to have at two DDs to support Python?

Has this issue been resolved? Has this question been answered by
devscripts maintainers?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1306006865.6282.1.camel@debian.tauspace.local

Re: Bug#627515: ITP: gnome-shell-extensions -- Extensions to extend functionality of GNOME Shell

[Josselin Mouette]

Le samedi 21 mai 2011 à 18:05 +0530, Bilal Akhtar a écrit : 
> Package: wnpp
> Severity: wishlist
> Owner: Bilal Akhtar 
> 
> 
> * Package name: gnome-shell-extensions
>   Version : 3.0.2
> * URL : http://live.gnome.org/GnomeShell/Extensions
> * License : GPLv2
>   Programming Lang: JavaScript, CSS
>   Description : Extensions to extend functionality of GNOME Shell

I think it would make sense to put this package in the pkg-gnome
repository. Would that be OK with you?

> This package contains a set of extensions which add functionality and/or
> add to the looks of the GNOME Shell desktop.

The only problem with that package is that there is still no extension
manager, unfortunately. I guess it could be written as an extension
(like epiphany does).

In the meantime we could probably agree upon a set of extensions enabled
by default (at the very least, we need alternative-status-menu) and let
users enable the others in dconf.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


signature.asc
Description: This is a digitally signed message part

Re: Conditional Recommends

[Ian Jackson]

Josselin Mouette writes ("Conditional Recommends"):
> Therefore, I?m wondering whether it would be possible to extend the
> syntax of Recommends to allow for conditional dependencies. For example,
> in this case:
> Package: A
> Recommends: A-plugin-B {B}
> APT would be made to install A-plugin-B by default, but only if B is
> installed too. In addition, it would also have to install it while
> pulling B if A is already here.

Simpler than this, and simpler than constructions involving negations
(which would be very troublesome for the resolution algorithms), would
be:

  Package: A-plugin-B
  Depends: A, B
  Recommended-When: A, B

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19928.9057.476390.698...@chiark.greenend.org.uk

Re: How to solve race condition between IPv6 ifup and start of services?

[Ben Hutchings]

On Sat, 2011-05-21 at 20:29 +0200, Marc Haber wrote:
> On Sat, 21 May 2011 14:31:45 +0100, Ben Hutchings
>  wrote:
> >On Sat, 2011-05-21 at 15:01 +0200, Marc Haber wrote:
> >> with the increasing deployment of IPv6 I begin to see an issue
> >> icreasingly often: When an interface is configured for IPv6, it takes
> >> a few seconds before the IPv6 address actually becomes available.
> >> Services that are started in this time window won't listen on IPv6,
> >> which may be unintended behavior. Many people see this behavior as a
> >> bug in the distribution, which is why I am addressing this issue here
> >> on -devel.
> >> 
> >> Unfortunately, it is non-trivial to find out whether my IPv6
> >> configuration has completed or not. How many addresses will be
> >> assigned to us via stateless autoconfig? Are we running with privacy
> >> extensions? Do we have additional static configuration?
> >> 
> >> The most "clean" solutions for this issue would be
> >> (a) Modify the services to notice when additional IP addresses come up
> >> and listen there if the service is configured for that IP address
> >> (b) Parse the configuration of each service in the init script and
> >> wait for the configured IP addresses to actually come up.
> >[...]
> >
> >(c) Set the IP_FREEBIND socket option before binding.
> 
> What does this do? And it needs changes to the software as well.

It allows the socket to be bound to an address that is not (yet) local.
It should be a relatively simple code change.  The down-side is that a
typo in the configured bind address no longer results in an error on
startup.

Network interfaces can come and go dynamically, and our packages should
not assume otherwise.  As an example, I configure lighttpd to listen on
lo and on a local bridge to VM guests.  The bridge is created only when
I actually start some guests, but I don't want lighttpd to wait for it
to be created, nor do I want to have to restart it after the bridge is
created (as I do now).

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: How to solve race condition between IPv6 ifup and start of services?

[Goswin von Brederlow]

Marc Haber  writes:

> Hi,
>
> with the increasing deployment of IPv6 I begin to see an issue
> icreasingly often: When an interface is configured for IPv6, it takes
> a few seconds before the IPv6 address actually becomes available.
> Services that are started in this time window won't listen on IPv6,
> which may be unintended behavior. Many people see this behavior as a
> bug in the distribution, which is why I am addressing this issue here
> on -devel.
>
> Unfortunately, it is non-trivial to find out whether my IPv6
> configuration has completed or not. How many addresses will be
> assigned to us via stateless autoconfig? Are we running with privacy
> extensions? Do we have additional static configuration?
>
> The most "clean" solutions for this issue would be
> (a) Modify the services to notice when additional IP addresses come up
> and listen there if the service is configured for that IP address
> (b) Parse the configuration of each service in the init script and
> wait for the configured IP addresses to actually come up.
>
> Both solutions are rather expensive to implement.
>
> Is there a widely accepted method to do things any easier? It is
> clearly not acceptable to have to manually log in to a newly booted
> server to restart service, neither do I like the idea of changing
> runlevels five minutes after reboot to kick IPv6 services to life.
>
> Any more ideas?
>
> Greetings
> Marc

(c) Modify ifupdown to notice when additional IP addresses come up (or
go away) and run the ifup.d (ifdown.d) scripts for it.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ei3rd6wg.fsf@frosties.localnet

Bug#627557: general: programs are not unistalled when that option is selected in the soft center

[Miguel M. R.]

Package: general
Severity: normal

programs are not unistalled when that option is selected in the soft center



-- System Information:
Debian Release: 6.0.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110521224408.5631.23446.report...@miguel.miguel.com

Re: How to solve race condition between IPv6 ifup and start of services?

[Steve Langasek]

On Sat, May 21, 2011 at 03:01:39PM +0200, Marc Haber wrote:
> with the increasing deployment of IPv6 I begin to see an issue
> icreasingly often: When an interface is configured for IPv6, it takes
> a few seconds before the IPv6 address actually becomes available.
> Services that are started in this time window won't listen on IPv6,
> which may be unintended behavior. Many people see this behavior as a
> bug in the distribution, which is why I am addressing this issue here
> on -devel.

> Unfortunately, it is non-trivial to find out whether my IPv6
> configuration has completed or not. How many addresses will be
> assigned to us via stateless autoconfig? Are we running with privacy
> extensions? Do we have additional static configuration?

> The most "clean" solutions for this issue would be
> (a) Modify the services to notice when additional IP addresses come up
> and listen there if the service is configured for that IP address
> (b) Parse the configuration of each service in the init script and
> wait for the configured IP addresses to actually come up.

> Both solutions are rather expensive to implement.

> Is there a widely accepted method to do things any easier? It is
> clearly not acceptable to have to manually log in to a newly booted
> server to restart service, neither do I like the idea of changing
> runlevels five minutes after reboot to kick IPv6 services to life.

> Any more ideas?

With an event-based init system such as upstart, you could also set up the
service not to start until the specified interface is fully configured.  But
in general, I agree that upstream software should be intelligent about doing
the right thing when started before the network is up.

Apache, for one, seems to fail at this currently; I have an apache instance
running on my laptop which I want to bind to ipv6, but of course since it's
a roaming laptop, there isn't always an ipv6 address available at startup;
apache thinks this means it should open ipv4-only sockets, requiring a
restart once I'm on an ipv6 network. :/

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110521224251.gb29...@virgil.dodds.net

Re: How to solve race condition between IPv6 ifup and start of services?

[Ian Jackson]

Marc Haber writes ("How to solve race condition between IPv6 ifup and start of 
services?"):
> Unfortunately, it is non-trivial to find out whether my IPv6
> configuration has completed or not. How many addresses will be
> assigned to us via stateless autoconfig? Are we running with privacy
> extensions? Do we have additional static configuration?

This kind of thing is indeed annoying.

In the situation where you know what the IPv6 address is going to be,
you can create a dummy interface (eg lo:0) with that known address,
with fairly straightforward runes in /etc/network/interfaces.

That will enable your programs to bind to the address before
connectivity is available.  Of course you may prefer to simply specify
the static IP address for the actual ethernet interface.

> Is there a widely accepted method to do things any easier? It is
> clearly not acceptable to have to manually log in to a newly booted
> server to restart service, neither do I like the idea of changing
> runlevels five minutes after reboot to kick IPv6 services to life.

I set the machine's address statically; this is usually more
appropriate for a server anyway.  I do have some local addresses which
are provided by vpn machinery which takes a while to get going, and
for those addresses I have a lo:0 alias so that services can bind to
it in advance.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19928.25252.454915.279...@chiark.greenend.org.uk

Processed: reassign 627557 to software-center

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # Automatically generated email from bts, devscripts version 2.10.35lenny7
> reassign 627557 software-center
Bug #627557 [general] general: programs are not unistalled when that option is 
selected in the soft center
Bug reassigned from package 'general' to 'software-center'.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
627557: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627557
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.130603160426106.transcr...@bugs.debian.org