Re: State of developers-reference

[Christian Perrier]

Quoting Lucas Nussbaum (lu...@lucas-nussbaum.net):

> - When doing talks about something at Debconf or at another conference,
>   take the opportunity to review and improve the corresponding dev-ref
>   section. (That applies to the i18n chapter of dev-ref, which is
>   apparently badly outdated).


I wouldn't say so. Information about i18n that's in the DevRef is
still mostly correct. However, on top of it, many "good practices"
have emerged (such as sending call for translations) and could be
documented there.

So, more than outdated information (which would mean it is no longer
correct), this is more about information that could be more detailed.

In that specific matter, the information is actually nowhere else but
in the head of a few i18n-crazy folks such as myself. I admit it would
be better to have it in the DevRef...:). I could say "OK, I'll take a
look and update"...but that could be a promise in the wild so I'd
better say "I'm not the only person who can update things
there"and hope that someone will pick up with that part..:-)



signature.asc
Description: Digital signature

Re: shared library in binary-package?

[Steve Langasek]

On Sun, Sep 06, 2009 at 08:48:50PM +0200, Heiko Stübner wrote:

> as I was unsuccessful in finding similiar cases on the mailing lists I would 
> like some input on the handling of corner-case in packaging.

> The package is fso-usaged from the freesmartphone.org software-stack and not 
> yet in debian.

> Compilation results in a binary fsousaged, a shared library libfsousage.so* 
> and three plugins (controller.so, lowlevel_kernel26.so, lowlevel_openmoko.so).

> The plugins use libfsousage and fsousaged loads them according to its config-
> file.

> According to the debian-policy libfsousage would require the two separate 
> shared libary packages (0, -dev) but the only users are and will be fsousaged 
> and the plugins alone.

> Are there other packaging options for such a case, as libfsousage is 
> currently 
> 3,4KB and it seems like much overhead to have the library-packages when there 
> won't ever be other users of it.

> Currently I have all in one package (34KB deb / 252KB installed-size) but 
> lintian doesn't like it.

> Any pointers would be greatly appreciated.

I'm not sure Policy actually provides an exception for this case, but here
are a couple things you should take care of if you're going to ship a
private shared library in a package:

 - Don't ship anything that would belong in a -dev package.  Since you're
   not supporting it as a shared library package, you also shouldn't be
   allowing other software (packaged or local) to link against it.  If you
   think this is something you need, that's an argument for providing a
   proper shared library package.

 - Make sure you don't provide shlibs.  The only reason to have a shlibs
   file is so that packages can declare a dependency on the shared library;
   since there shouldn't be anything doing this, having the shlibs will only
   invite accidents.

I agree with the other comments that for this use case, it would be better
to just statically link the library into the daemon and let the plugins
resolve symbols against it.  While there's an architectural cleanliness to
having a shared library that both daemon and plugins link against, and it
enables use of things like LDFLAGS=-Wl,-z,defs to ensure you never have
plugins with accidentally missing symbols, I don't really think it's worth
the tradeoff of maintaining a proper shared library.

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


signature.asc
Description: Digital signature

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Manoj Srivastava]

On Mon, Sep 07 2009, Pierre Habouzit wrote:

> On Mon, Sep 07, 2009 at 10:30:14PM +0200, Raphael Hertzog wrote:

>> git format-patch alone will stil not be enough to generate a DEP3-compliant
>> header but would that resolve your concerns?
>
> It will be compatible if you relax the use of headers to pseudo headers,
> and forget about your (sorry) ridiculous request for Description to be a
> rfc822 formatted field. Not only it's never used by anyone, but it's
> also a major PITA to edit.
>
> Like I said in my other mail, you want a Subject as a summary, and what
> you call Description is all that:
>   - isn't a header
>   - isn't a recognized pseudo-header
>   - is before the patch or an optional "---\n" line.
>
> It's a pretty simple definition, rather simple to implement in any kind
> of patch parsing tool.
>
> Indeed it's not compatible with grep-dctrl or whatever, but sadly for
> you, there _IS_ a standard for patches already, and it looks like that:
>
>   - http://lkml.org/lkml/2009/8/31/369
>   - http://lkml.org/lkml/2009/8/31/40
>   - http://article.gmane.org/gmane.comp.version-control.git/126207
>   - http://article.gmane.org/gmane.comp.parsers.sparse/2001
>   - and I could go on with wine, x.org, gnome, ... patch submissions...
> damn even the glibc nowadays !
>
>> Anyway, I'd rather wait some time until people have tried using this
>> format before deciding if we must make some special case due to
>> git format-patch.
>
> It's not a special case. Kernel people, git people, gnome people, X.org
> people, all can cherry-pick patches and format-patch them away. If you
> ask them to add one missing header like the actual source or commid-id
> they took the patch from, they'll probably do it (I would at least). If
> you ask to rewrite the full stuff, then really, "go to hell" will
> probably be the (sane) answer you'll get.

(Adding SELinux mailing lists where git format-patch rules). I
 think that  git format-patch format seems to be emerging as a de facto
 standard for interchanging changesets, and if we are to create a new
 standard, we should stick close to ones that exist and are popular, and
 only differ from that if there is a compelling reason to be different.

Is there a compelling reason to differ from what git
 format-patch and git am already use?

manoj
-- 
"Every year a few research results pay the freight for all the rest."
Robert A. Frosch, General Motors
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: update-inetd migration to dpkp-triggers

[Steve Langasek]

On Tue, Sep 08, 2009 at 01:13:45AM +0200, Serafeim Zanikolas wrote:
> On Mon, Sep 07, 2009 at 01:59:48PM -0700, Steve Langasek wrote [edited]:
> > On Mon, Sep 07, 2009 at 09:40:51PM +0100, Roger Leigh wrote:
> > > but the primary benefits are making inetd support in maintainer scripts
> > > both robust and idempotent.

> > update-inetd in its present form can already be used to achieve this.

> I beg to differ. update-inetd assumes that a service name (``ftp'') is
> sufficient to enable, disable and remove a service, whereas to be certain of
> what service is selected, one has to additionally specify protocol and path to
> the server binary. This currently can be done with a little bit of imagination
> using the optional --pattern switch (which strangely though is not available
> in --remove mode)

The --remove option is specified to accept a regexp as its argument.  Does
this not work?

Perhaps packages today aren't /using/ --remove in a way that's robust and
idempotent, but again, that seems to be a documentation problem.

(The issue you've highlighted here is one I wasn't aware of, thank you for
bringing it to my attention.  The packages I maintain that use update-inetd
are the only things in the archive providing the service in question, so
I'd always considered using the service name to be unambiguous.)

> I'll keep improving update-inetd regardless of any migration but the problem
> remains: it provides too much flexibility that is naturally abused.

> And while we're at it, why does it even have the enable/disable switches?

Because inetd.conf is configuration data, and packages should not remove
these entries when the package is removed - only when the package is purged.

> Shouldn't maintainer scripts only use add and remove? (If you disagree, have a
> look at #168847)

Ah, another case that I hadn't considered because I don't have to deal with
multiple packages providing the same service.

Wouldn't it suffice to support an additional --pattern argument to
update-inetd --add?  That way packages could specify the minimal match
needed for re-enabling instead of adding a new entry.

Alternatively, packages could use --comment-chars '## ' for
enabling/disabling as part of a package removal.

Again, the problem doesn't seem to be a limitation in update-inetd, but a
lack of policy/documentation around it.

Here's a rough cut at a robust set of update-inetd calls for maintainer
scripts to use.  It's ugly, of course, and verbose - something that could
probably be remedied with only minor enhancements to update-inetd.  And it
seems to run afoul of a bug in update-inetd --remove, in that you can't use
a regexp match against the whole line.  But those issues can be solved
without redesigning the world.


package1.preinst:
if [ "x$1" = "xinstall" ] && [ -n "$2" ]; then
update-inetd --comment-chars '## ' \
--pattern 'tcp.*/usr/sbin/inetd-test\b' \
--enable inetd-test
update-inetd \
--pattern 'tcp.*/usr/sbin/inetd-test\b' \
--disable inetd-test
fi

package1.postinst:
update-inetd --group OTHER --add \

'inetd-test\t\tstream\ttcp\tnowait.400\troot\t/usr/sbin/tcpd\t/usr/sbin/inetd-test'

package1.postrm:
case $1 in
remove)
update-inetd --comment-chars '## ' \
--pattern 'tcp.*/usr/sbin/inetd-test\b' \
--disable inetd-test
;;
purge)
if [ -x /usr/sbin/update-inetd ]; then
# FIXME: why doesn't this regexp match?
update-inetd --remove \
'(## |## 
)*inetd-test.*tcp.*/usr/sbin/inetd-test\b'
fi
;;
esac

package2.postinst:
update-inetd --group OTHER --add \

'inetd-test\t\tstream\ttcp\tnowait.400\troot\t/usr/sbin/tcpd\t/usr/sbin/inetd-test2'


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


signature.asc
Description: Digital signature

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Pierre Habouzit]

On Mon, Sep 07, 2009 at 10:30:14PM +0200, Raphael Hertzog wrote:
> On Sat, 05 Sep 2009, Guido Günther wrote:
> > I tried to point that out in June:
> >  http://lists.debian.org/debian-devel/2009/06/msg00551.html
> > but failed. It'd be really helpful if DEP-3 would be compatible with the
> > git format-patch output.

I missed that thread earlier and reacted to the dda mail in
<20090907234314.ge13...@artemis.corp>

> Would it be helpful to say that From: can be an alias for Author: and
> Subject: an alias for Description:?

I made a full proposal for "header" fixes to be git/hg/... compatible.

> git format-patch alone will stil not be enough to generate a DEP3-compliant
> header but would that resolve your concerns?

It will be compatible if you relax the use of headers to pseudo headers,
and forget about your (sorry) ridiculous request for Description to be a
rfc822 formatted field. Not only it's never used by anyone, but it's
also a major PITA to edit.

Like I said in my other mail, you want a Subject as a summary, and what
you call Description is all that:
  - isn't a header
  - isn't a recognized pseudo-header
  - is before the patch or an optional "---\n" line.

It's a pretty simple definition, rather simple to implement in any kind
of patch parsing tool.

Indeed it's not compatible with grep-dctrl or whatever, but sadly for
you, there _IS_ a standard for patches already, and it looks like that:

  - http://lkml.org/lkml/2009/8/31/369
  - http://lkml.org/lkml/2009/8/31/40
  - http://article.gmane.org/gmane.comp.version-control.git/126207
  - http://article.gmane.org/gmane.comp.parsers.sparse/2001
  - and I could go on with wine, x.org, gnome, ... patch submissions...
damn even the glibc nowadays !

> Anyway, I'd rather wait some time until people have tried using this
> format before deciding if we must make some special case due to
> git format-patch.

It's not a special case. Kernel people, git people, gnome people, X.org
people, all can cherry-pick patches and format-patch them away. If you
ask them to add one missing header like the actual source or commid-id
they took the patch from, they'll probably do it (I would at least). If
you ask to rewrite the full stuff, then really, "go to hell" will
probably be the (sane) answer you'll get.

-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


signature.asc
Description: Digital signature

Re: Patch Tagging Guidelines (aka DEP3)

[Pierre Habouzit]

On Mon, Sep 07, 2009 at 11:03:37PM +0200, Raphael Hertzog wrote:
> Hello,
> 
> after several rounds of discussion on -devel, we now have a
> new standard defining meta-information to integrate on patches that we
> distribute/apply in our packages:
> http://dep.debian.net/deps/dep3/

Sorry I haven't answered to the DEP before, but I've been pretty busy so
far.

FWIW I don't like it completely because it's not compatible with the
de-facto standard used by kernel-like project (that would count linux,
or git, and many other).

In git (and the idea is trivially used in any VCS that can format-patch
to mail) you use either rfc822 headers or pseudo-headers for many fields
you have re-defined.

My point is that there are _lots_ of patches that follow the kernel
conventions out there, and it should not require anything more than
grabbing the patch, possibly add an URL in it pointing to where you
grabbed it from, and be done with it. Your proposal requires an
extensive rewrite of such patches, and it kind of sucks.

Also I would like to be able to extract my patches from my git
repository just doing a git format-patch upstream..upstream+patches
e.g., and not having to touch them (hence the need for pseudo-headers).


Here are my remarks wrt individual fields:

  * Description/Subject:
Description should just be any bit of rfc822 text that isn't a
header nor a patch nor a pseudo header. What you propose for
Description is just a major hassle for any people using git/hg/...
And you should have a short description, as "Subject:". The
description should not be mandatory, the Subject should be.

Also, if the patch contains a line with exactly "---\n", then all
that follows, up to the diff is data that is _not_ part of the
Description, and should be dropped (it's where git puts its
diffstat, and this format has also become a standard nowadays too).

  * From should be an allowed synonym for Author (git uses both, with a
preference for From).

  * Reviewed-by is usually rather Acked-by.

  * Forwarded as a boolean (no/not-needed/...) field is IMHO useless,
but whatever.  Also, when the argument is an email address, Cc: is
usually preferred.

  * Instead of Last-Update, simply Date: is usually preferred. Plus the
proposed format is all but an "iso" standard. rfc822 dates are a
better idea.

Your proposal doesn't explicit what repetition of fields means. Debian
usually uses:

Foo: value1, value2,
 value3, ...

But git people usually use:

Foo: value1
Foo: value2
...

Both should be accepted and understood in the same way.

Finally, I would suggest that Author or From should be mandatory for
conforming patches, rather than Origin. And I would suggest a License:
field for people wishing to license their patch with a specific license.

FWIW, I don't believe any packager with an upstream using git will
consider adopting DEP3 without those "fixes". With those fixes though,
it's just a tiny bit of effort for them, so you'll instead probably see
quite a fast adopting rate for DEP3...

-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


signature.asc
Description: Digital signature

Re: RFC: update-inetd migration to dpkp-triggers

[Serafeim Zanikolas]

On Mon, Sep 07, 2009 at 01:59:48PM -0700, Steve Langasek wrote [edited]:
> On Mon, Sep 07, 2009 at 09:40:51PM +0100, Roger Leigh wrote:
> > but the primary benefits are making inetd support in maintainer scripts
> > both robust and idempotent.
> 
> update-inetd in its present form can already be used to achieve this.

I beg to differ. update-inetd assumes that a service name (``ftp'') is
sufficient to enable, disable and remove a service, whereas to be certain of
what service is selected, one has to additionally specify protocol and path to
the server binary. This currently can be done with a little bit of imagination
using the optional --pattern switch (which strangely though is not available
in --remove mode)

I'll keep improving update-inetd regardless of any migration but the problem
remains: it provides too much flexibility that is naturally abused.

And while we're at it, why does it even have the enable/disable switches?
Shouldn't maintainer scripts only use add and remove? (If you disagree, have a
look at #168847)

-- 
debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: State of developers-reference

[Steve Langasek]

On Mon, Sep 07, 2009 at 10:45:55PM +0200, Raphael Hertzog wrote:
> On Mon, 07 Sep 2009, Steve Langasek wrote:
> > I think the devref discussions (incl. bug traffic) need to be moved onto
> > debian-policy.  We already have any number of bugs getting redirected from
> > policy to the devref, so it's not as though there would be a massive traffic
> > increase; and it would put the right set of eyeballs on the changes to
> > ensure the result actually reflects best practices.

> I think it's a good idea, at least it's worth trying. That should however
> not mean that only delegated policy editors can maintain the package...
> maintainership should still be relatively open like it has always been.
> It might mean however that we might want to formalize the process
> somewhat.

Correct, I don't mean to imply that the policy editors should be responsible
for the devref.  I think they already have their hands full and we shouldn't
demand that they take on more.

One thing I didn't say before is that, /in theory/, I'm willing to help with
maintenance of the devref package if the problem of public-by-default change
process is addressed.  I didn't mention this because I don't want to mislead
anyone into thinking I'm committing to being active on the package - rather,
every time I've thought of volunteering to help with the devref (which I
agree is an important document), the lack of public process has been a
blocker for me.  While the people who've maintained the devref over the
years are developers whose technical judgement I have a good deal of
confidence in individually, when it comes to deciding "best practices", it's
just too small and self-selecting a set and I'm not willing to be seen as
endorsing this model by putting my own name on it.

As far as process formalization, the existing
http://wiki.debian.org/PolicyChangesProcess seems an obvious choice to me.

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


signature.asc
Description: Digital signature

Re: RFC: update-inetd migration to dpkp-triggers

[Steve Langasek]

On Mon, Sep 07, 2009 at 11:19:02PM +0200, Julien Cristau wrote:
> > On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> > > * document that local policy will live in /etc/inetd.conf.d/ and any 
> > > manual
> > >   changes will be made effective by running update-inetd

> > I think this violates the principle of least surprise (restarting the daemon
> > after making your changes has been enough to make those changes take effect
> > since the inception of these daemons), and will be displeasing to many
> > admins as a result.

> Is there any reason inetd's init script couldn't run update-inetd before
> restarting the daemon, thus not changing the way things work for admins?

That might be reasonable.  I'm not sure how many admins think 'killall -HUP
inetd' is the right way to force a config reread. :-)  (On the rare
occasions that I edit /etc/inetd.conf, this is the method I tend to use,
because it's always worked and I don't have to remember what the init script
is called this decade...)

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


signature.asc
Description: Digital signature

Re: Patch Tagging Guidelines (aka DEP3)

[maximilian attems]

On Mon, Sep 07, 2009 at 11:03:37PM +0200, Raphael Hertzog wrote:
> 
> after several rounds of discussion on -devel, we now have a
> new standard defining meta-information to integrate on patches that we
> distribute/apply in our packages:
> http://dep.debian.net/deps/dep3/

at a quick look this again seems to have degenerated in lots
of Debianism:

* Why using "Description" for subject?
  "Author" instead of From..

* Why not reqesting the patches to be "git am" appliable.
  this way quilt understands them, they can be easily be
  bounced of to upstream thanks to existing tools.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Patch Tagging Guidelines (aka DEP3)

[Raphael Hertzog]

On Mon, 07 Sep 2009, Raphael Hertzog wrote:
> after several rounds of discussion on -devel, we now have a
> new standard defining meta-information to integrate on patches that we
> distribute/apply in our packages:
> http://dep.debian.net/deps/dep3/

s/standard/standard proposal/ of course, if that was not clear by the
fact that it's only at state “CANDIDATE“.

Sorry for the mistake.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Stéphane Glondu]

Julien Cristau a écrit :
> FWIW, I'm not going to use something that I can't produce with git
> format-patch and feed to git send-email / git am since that feels like
> busy work; in particular the Author and Description fields are not
> needed given there's From and Subject with the same information.

+1

-- 
Stéphane


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: update-inetd migration to dpkp-triggers

[Julien Cristau]

On Fri, Sep  4, 2009 at 22:02:21 -0700, Steve Langasek wrote:

> On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> > * document that local policy will live in /etc/inetd.conf.d/ and any manual
> >   changes will be made effective by running update-inetd
> 
> I think this violates the principle of least surprise (restarting the daemon
> after making your changes has been enough to make those changes take effect
> since the inception of these daemons), and will be displeasing to many
> admins as a result.
> 
Is there any reason inetd's init script couldn't run update-inetd before
restarting the daemon, thus not changing the way things work for admins?

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: update-inetd migration to dpkp-triggers

[Roger Leigh]

On Fri, Sep 04, 2009 at 10:02:21PM -0700, Steve Langasek wrote:
> On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> > As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the
> > proposal below to migrate it to dpkg triggers [0]
> 
> > * update-inetd will drop its current switches to
> >   add/remove/enable/disable services;
> 
> This doesn't sound like a good idea; it sounds like a transition that's
> going to break a lot of packages (either silently or noisily, depending on
> the implementation).  How do you intend to transition away from this without
> either a) dropping existing package-provided entries on the floor, or b)
> leaving packages with no way to clean up those same entries?

This is an area that still needs work IMO.  We still need to support
uninstallation of programs which use these options, perhaps installed
or conffiles-only from a previous release, and as a result we do need
to retain these options.

In order to support removal of packages, the ability to remove
services will need to be retained (perhaps indefinitely?)

For installation of old packages, the ability to add packages
would also need retaining.  However, could this realistically
be dropped after a stable release?  It could be deprecated
and print a nasty warning for one release, which could
subsequently be updated to fail.


> > * abolish /etc/inetd.conf and /etc/xinetd.d/ and instead auto-generate
> >   /var/lib/update-inetd/inetd.conf and auto-populate fragments in
> >   /var/lib/update-inetd/xinetd.d/ using xinetd fragments installed by deamon
> >   packages in /etc/inetd.conf.d/
> 
> Likewise, then, what happens to existing entries in /etc/xinetd.d?

As mentioned in the other posts in this thread, I think these would
continue to be used, and would override the /etc/inetd.conf.d
fragments if present.

One could move the conffile in the maintainer preinst scripts once the
new system was in place, avoiding the duplicates and retaining user
changes.

> > * document that local policy will live in /etc/inetd.conf.d/ and any manual
> >   changes will be made effective by running update-inetd
> 
> I think this violates the principle of least surprise (restarting the daemon
> after making your changes has been enough to make those changes take effect
> since the inception of these daemons), and will be displeasing to many
> admins as a result.

I can't say that this part thrills me either.  However, we have as yet
not come up with a saner alternative.

> > How to Get There
> 
> > The migration could(?) be done within one stable release, but I assume a 
> > more
> > conservative approach over two releases.
> 
> > * squeeze
> > * all deamon packages that use update-inetd [1]:
> > * should version-depend in the update-inetd version that is shipped 
> > in
> >   squeeze (so that /etc/inetd.conf.d/ is in place)
> > * should install xinetd fragments in /etc/inetd.conf.d/ (and in
> >   /etc/xinetd.d/ if they did so already)
> > * must continue calling update-inetd in postinst/prerm scripts as
> >   before
> > * update-inetd will:
> > * install /etc/inetd.conf.d/ and declare file-trigger interest in it
> > * keep the old functionality, but additionally to updating
> >   /etc/inetd.conf, also update /var/lib/update-inetd/* using as 
> > input
> >   both /etc/inetd.conf and /etc/inetd.conf.d (and /etc/xinetd.d if
> >   installed)
> 
> So with these packages that are calling update-inetd *and* installing a
> snippet, what ends up being copied to /var/lib?

This is a combination of the old inetd.conf (or xinetd files) and new
xinetd-format fragments, with the old configuration taking precedence
where duplicate service entries exist.  This will guarantee user
changes still take precedence, and allow a smooth transition since
the old and new systems will continue to function as inetd-using
packages migrate over to fragments.

> > * update-inetd must:
> > * sync effective inetd configurations based on /etc/inetd.conf.d/ 
> > and
> >   reload inetd when invoked without any arguments
> > * only run as as result of being triggered by a deaemon
> >   (un)installation, or an explicit user invocation
> > * drop the old functionality and print a warning but otherwise 
> > succeed
> >   when invoked with any of the old command line switches
> 
> So: silent failure of update-inetd invocations.
> 
> Noisy would be better.  Silent failures hide bugs.

If --add or --remove are used, but update-inetd no longer takes
any action, should package installation still succeed?  One
wouldn't want any broken maintainer scripts which result in
non-removable packages on purge.

At the very least, the old options would be deprecated but continue to
function exactly as before for at least one stable release.  The hard
question here is if the old functionality should be disabled or full

Re: RFC: update-inetd migration to dpkp-triggers

[Steve Langasek]

On Mon, Sep 07, 2009 at 09:40:51PM +0100, Roger Leigh wrote:
> It's not just about supporting xinetd, as I hope the initial post
> made clear.  It's using the xinetd syntax certainly (why reinvent
> the wheel when you can reuse the format as the superset used by all
> existing inetds?), but the primary benefits are making inetd support
> in maintainer scripts both robust and idempotent.

update-inetd in its present form can already be used to achieve this.

Unfortunately, the runes to accomplish it are rather underdocumented; but
I think the right way to address that is with better documentation.

(Once upon a time, I started drafting a blog entry shortly after I worked
through how to fit update-inetd into the maintainer script state machine;
unfortunately I didn't finish that draft before the details fled my short
term memory, and I don't even remember which package I was looking at. :( )

> The current update-inetd implementation is flaky junk which is used both
> incorrectly and inconsistently, and can cause loss of system
> customisation by the sysadmin as a result.

I don't believe that the proposed replacement is immune to the possibility
of misuse.

> > > * document that local policy will live in /etc/inetd.conf.d/ and any 
> > > manual
> > >   changes will be made effective by running update-inetd
> > I also consider not acceptable that manual configuration changes are
> > ignored unless some program is run.

> There are many obvious examples of update-foo scripts which behave in
> this manner.  The requirement to run a script to update the working
> configuration is nothing new in Debian.

The only obvious example I have of an update-* script that a user has to run
to effect changes to their config is update-grub.

And update-grub has been an unqualified disaster.

(Some of the reasons for which don't apply in this case, I'll grant you -
but I certainly wouldn't agree that there are good precedents for this in
Debian.)

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


signature.asc
Description: Digital signature

Bug#545532: ITP: ocamlviz -- Ocamlviz gives the ability to instrument an existing code, in real time, with lightweight monitoring annotations

[Mehdi Dogguy]

Package: wnpp
Severity: wishlist
Owner: Mehdi Dogguy 

* Package name: ocamlviz
  Version : 1.0
  Upstream Author : Julien ROBERT, Guillaume VON TOKARSKI, FILLIATRE 
Jean-Christophe, CONCHON Sylvain and LE FESSANT Fabrice
* URL : http://ocamlviz.lri.fr/
* License : LGPL-2
  Programming Lang: OCaml
  Description : real-time profiling tools for Objective Caml


Ocamlviz gives the ability to instrument an existing code, in real
time, with lightweight monitoring annotations. Ocamlviz can also be
used as a debugging tool.

Here are a few possibilities provided by Ocamlviz:

  * observe details about the garbage collector
  * observe how many times the program goes through a point
  * make a set of values (any) and count its cardinal number and its
size in the heap
  * observe how much time passed between two points of the program
  * observe the value of integers, floating-point numbers, booleans
and strings
  * observe details about hash tables, like the number of empty
buckets, or the filling rate
  * etc ...

Ocamlviz offers two sorts of client output:

  * an ASCII client, the monitoring is displayed in a file
  * a Graphical User Interface, using Lablgtk2, that allows, for
instance, displaying data in a graph



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: State of developers-reference

[Raphael Hertzog]

On Mon, 07 Sep 2009, Lucas Nussbaum wrote:
> - There are many open bugs, about things that should really be fixed or
>   added in dev-ref, but I don't have time to address them (I'm doing
>   "please provide a patch and I'll integrate it"-maintainance).

As a co-maintainer, I must recognize that I have not been very active
on it. I worked by burst on it a long time ago and since then I have simply
kept the part concerning the PTS and Alioth up-to-date.

And I applied patches that were ready as well. Much like Debian's policy,
I believe it's the right workflow, we should not have to draft everything
but we should ensure that what gets commited reflects sane and accepted
good practice.

> First, we need to decide whether we want to continue to maintain
> developers-reference.

Yes, I really think that we need such a document.

> If we decide to continue to maintain developers-reference, we should all
> participate.

Ack, unfortunately much like DeveloperNews, asking to participate doesn't
work very well.

On Mon, 07 Sep 2009, Steve Langasek wrote:
> I think the devref discussions (incl. bug traffic) need to be moved onto
> debian-policy.  We already have any number of bugs getting redirected from
> policy to the devref, so it's not as though there would be a massive traffic
> increase; and it would put the right set of eyeballs on the changes to
> ensure the result actually reflects best practices.

I think it's a good idea, at least it's worth trying. That should however
not mean that only delegated policy editors can maintain the package...
maintainership should still be relatively open like it has always been.
It might mean however that we might want to formalize the process
somewhat.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Adrian Perez]

+1 for SCM compatibility. 
Since version control is a best practice for packaging IMHO, I think we
should be able to apply those processes cleanly enough to let us
continue with them. 
When we import patches from upstream, I think most adhere to some kind
of format, what is standard is where the patch came From: and what's
it's Subject:.
When we export patches too.
What I think is that an alias would do the work. Since I've been
maintaining a patches branch just for adding metadata, given the fact
I'm using tg2quilt, as many of us are, I think it's an unnecessary
pain. 
That's only my considerations, but hope made a point.

On Mon, 2009-09-07 at 22:30 +0200, Raphael Hertzog wrote:
> On Sat, 05 Sep 2009, Guido Günther wrote:
> > I tried to point that out in June:
> >  http://lists.debian.org/debian-devel/2009/06/msg00551.html
> > but failed. It'd be really helpful if DEP-3 would be compatible with the
> > git format-patch output.
> 
> Would it be helpful to say that From: can be an alias for Author: and
> Subject: an alias for Description:?
> 
> git format-patch alone will stil not be enough to generate a DEP3-compliant
> header but would that resolve your concerns?
> 
> Is that really better over (auto-)duplicating those fields when needed?
> 
> Anyway, I'd rather wait some time until people have tried using this
> format before deciding if we must make some special case due to
> git format-patch.
> 
> Cheers,
> -- 
> Raphaël Hertzog
> 
> 
-- 
Best regards,
Adrian Perez 


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

Re: RFC: update-inetd migration to dpkp-triggers

[Roger Leigh]

On Sun, Sep 06, 2009 at 11:30:25PM +0200, Marco d'Itri wrote:
> On Sep 04, Serafeim Zanikolas  wrote:
> 
> > As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the
> > proposal below to migrate it to dpkg triggers [0]
> Maybe you could have discussed it with the former maintainer, so I could
> have explained why I never implemented the changes you are proposing.

I suggested that Serafeim post the proposal to -devel for wider
discussion, after it got to the point where it was reasonably
complete and coherent and would benefit from wider criticism.  I'm
not sure what private discussion would have achieved that -devel would
not; the proposal does affect a number of packages, and other people
may have insights in addition to your input as the ex-maintainer.

> For a start, (x)inetd is used by less and less programs, are the changes
> you are planning justified considering that we have lived with the
> current limitations for 15 years without significant troubles?
> And do we really need all the complexity to support xinetd, which is
> installed by 3.8% of the users?

It's not just about supporting xinetd, as I hope the initial post
made clear.  It's using the xinetd syntax certainly (why reinvent
the wheel when you can reuse the format as the superset used by all
existing inetds?), but the primary benefits are making inetd support
in maintainer scripts both robust and idempotent.  The current
update-inetd implementation is flaky junk which is used both
incorrectly and inconsistently, and can cause loss of system
customisation by the sysadmin as a result.

> > * abolish /etc/inetd.conf and /etc/xinetd.d/ and instead auto-generate
> This is unacceptable, and I say this as the openbsd-inetd maintainer
> (which is another reason why you should have discussed this first with
> the other maintainers involved).
> /etc/inetd.conf is a well known UNIX interface and it must continue to
> be supported, at least for locally-configured services.

As Serafeim mentioned, this will continue to be supported.  If
present, any entries in /etc/inetd.conf will take precedence
over any fragment for the same service (it will warn in this
case that there are duplicates).

This would be the case for at least Squeeze+1 and, if this is a
requirement, could be kept indefinitely.

If it wasn't clear from the initial post and replies, update-inetd,
in addition to continuing to perform its traditional role, will
read /etc/inetd.conf *plus* the fragments in /etc/inetd.conf.d,
and generate the inetd configuration file under /var from the
combination of the two.  This will allow a smooth migration as
both old and new sources are used.

> > * document that local policy will live in /etc/inetd.conf.d/ and any manual
> >   changes will be made effective by running update-inetd
> I also consider not acceptable that manual configuration changes are
> ignored unless some program is run.

There are many obvious examples of update-foo scripts which behave in
this manner.  The requirement to run a script to update the working
configuration is nothing new in Debian.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Sat, 05 Sep 2009, Guido Günther wrote:
> I tried to point that out in June:
>  http://lists.debian.org/debian-devel/2009/06/msg00551.html
> but failed. It'd be really helpful if DEP-3 would be compatible with the
> git format-patch output.

Would it be helpful to say that From: can be an alias for Author: and
Subject: an alias for Description:?

git format-patch alone will stil not be enough to generate a DEP3-compliant
header but would that resolve your concerns?

Is that really better over (auto-)duplicating those fields when needed?

Anyway, I'd rather wait some time until people have tried using this
format before deciding if we must make some special case due to
git format-patch.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: update-inetd migration to dpkp-triggers

[Serafeim Zanikolas]

tag 8927 + wontfix
thanks

On Sun, Sep 06, 2009 at 11:30:25PM +0200, Marco d'Itri wrote [edited]:
> On Sep 04, Serafeim Zanikolas  wrote:
> > * abolish /etc/inetd.conf and /etc/xinetd.d/ and instead auto-generate
> This is unacceptable, and I say this as the openbsd-inetd maintainer
> (which is another reason why you should have discussed this first with
> the other maintainers involved).
> /etc/inetd.conf is a well known UNIX interface and it must continue to
> be supported, at least for locally-configured services.

Actually, my initial goal was to just cleanup update-inetd (which I'm doing
anyway), but at some point I bought into the idea of a clean rewrite. It
helped that ``rewrite'' is plastered all over update-inetd's bug reports,
including from you. But anyway that's no excuse for changing the traditional
way of making changes to inetd, and indeed not consulting beforehand with you
and Pierre Habouzit.

> And do we really need all the complexity to support xinetd, which is
> installed by 3.8% of the users?

AFAICS we can't support transparent switching between inetd and xinetd, while
we keep the traditional configuration files as the authoritative ones. Since
the latter is more important, I tag #8927 wontfix. I'll happily untag it when
someone comes along with a plan that satisfies everyone (but I won't hold my
breath)

> > [1] 40: the number of update-inetd's rdeps in main/unstable, excluding
> > ``Provides: inet-superserver'' packages
> Feel free to file bugs.

I'll instead go the (recommended by devref) lintian way.

-- 
debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DeviceKit and /usr

[Gabor Gombas]

On Mon, Sep 07, 2009 at 04:36:53PM +0200, Josselin Mouette wrote:

> Case 1:
> char *foo;
> if (asprintf(&foo, "%s equals %i", somestring, someint) < 0) {
> fprintf(stderr, "Failed to allocate memory");
> abort();
> }
> 
> Case 2:
> char *foo = g_strdup_printf ("%s equals %i", somestring,
> someint);

That shows exactly why glib cannot be used for low-level stuff and
daemons: it aborts unconditionally if a memory allocation fails. It's
rather sad, otherwise I love to use glib.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: State of developers-reference

[Russ Allbery]

Steve Langasek  writes:

> I think the devref discussions (incl. bug traffic) need to be moved onto
> debian-policy.  We already have any number of bugs getting redirected
> from policy to the devref, so it's not as though there would be a
> massive traffic increase; and it would put the right set of eyeballs on
> the changes to ensure the result actually reflects best practices.

I wouldn't mind, although unfortunately the lack of manpower problem
applies to Policy as well.  But maybe there will be some synergy that will
help both teams get more done.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: State of developers-reference

[Stefano Zacchiroli]

On Mon, Sep 07, 2009 at 08:57:54PM +0200, David Paleino wrote:
> > Lucas Nussbaum, le Mon 07 Sep 2009 18:28:11 +0200, a écrit :
> > > We could simply decide that it's deprecated, and use a set of wiki
> > > pages to document our procedures.
> > 
> > I would like to raise the fact that Internet is not available
> > everywhere, so at least an easy way to get an offline copy of these
> > would be useful.
> 
> Or use the developers-reference package, which you can install anytime (and
> which is the best choice IMHO).

Given the quote, Samuel's comment was about the proposal of having a
set of wiki pages; he is probably aware of the developers-reference
package containing the outcome of the current way of maintaining
devref.

I'm sure people like Holger can argue that, starting from Moin, you
can easily have a product that is packageable to use offline, by
exploiting the docbook rendering.  While this is true, my preference
is with the current state of affair, as I really fear losing the
important role of "editors" for documents like devref.  That
notwithstanding, I'm not in the condition of volunteering myself as a
co-maintainer of the devref.

Lucas, out of curiosity, have you tried to simple sent out an
announcement for co-maintainers to try continuing the "old style"
maintenance?

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: DeviceKit and /usr

[Adam Borowski]

On Mon, Sep 07, 2009 at 03:51:54PM +0200, Bjørn Mork wrote:
> Do you really need the g_utf16_to_utf8 unicode translation? You could
> just as well let udev export the raw utf16 value and leave the
> conversion up to the users.  They may want something different than utf8
> anyway.

man 3 iconv

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: State of developers-reference

[Steve Langasek]

On Mon, Sep 07, 2009 at 06:28:11PM +0200, Lucas Nussbaum wrote:

> First, we need to decide whether we want to continue to maintain
> developers-reference. We could simply decide that it's deprecated, and
> use a set of wiki pages to document our procedures. I see some value to
> a (mostly) self-contained documentation, but, if it helps getting
> contributions from more people, we could simply move to wiki.d.o. (or to
> a ikiwiki instance). I'm not a big fan of wikis, so I wouldn't continue
> to "maintain" dev-ref, but I'm open to the idea.

I don't think wiki pages are a suitable replacement for the
developers-reference.

Over the years, one of my complaints about the devref has been the lack of a
formal and public review process for changes.  A wiki would move in
precisely the wrong direction; no one is going to subscribe to all the
wiki.debian.org changes to keep tabs on devref changes.

I think the devref discussions (incl. bug traffic) need to be moved onto
debian-policy.  We already have any number of bugs getting redirected from
policy to the devref, so it's not as though there would be a massive traffic
increase; and it would put the right set of eyeballs on the changes to
ensure the result actually reflects best practices.

> If we decide to continue to maintain developers-reference, we should all
> participate. I'm not asking everybody to become co-maintainers (some
> help is probably needed, and would be welcomed, but I don't think that
> the main problem is here).

I think moving the process "out into the open" would really help with this
problem.

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


signature.asc
Description: Digital signature

Re: The future of the boot system in Debian

[Florian Kriener]

On Monday 07 September 2009 20:27:24 Henrique de Moraes Holschuh wrote:
> On Mon, 07 Sep 2009, Josselin Mouette wrote:
> > Le lundi 07 septembre 2009 à 08:39 +0200, Petter Reinholdtsen a 
écrit :
> > > I guess we were a bit unclear.  The point is to use it for
> > > upgrades (ie when it exist), while not installing /etc/inittab
> > > for new installs, thus slowly getting rid of the file while
> > > ensuring the switch do not affect upgrades negatively. :)
> >
> > Please also think of removing it without asking if the file was not
> > modified. This will handle at least 90% of installs.
> 
> That could be done, yes.  We just need a copy or sha1 and md5 sigs of
>  the inittabs used in the last two or three releases (and with some
>  luck, it they haven't changed at all across some releases, and we
>  will need just one).
> 

My SHA-1 of the inittab file is e5f5d38c21efdd1c4529b85302271a1d7a60a52d
from 2008-04-06 to now and e88a8ad513a5edfd06cb0026857af26395818ea0 from 
2006-07-02 to 2008-01-06. But I'm not sure if I changed it back then, 
however here is the diff:

@@ -2,7 +2,7 @@
 # $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $

 # The default runlevel.
-id:3:initdefault:
+id:2:initdefault:

 # Boot-time system configuration/initialization script.
 # This is run first except when booting in emergency (-b) mode.
@@ -67,10 +67,3 @@
 #
 #T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3

-#-- isdnutils begin
-# Change the line below for your local requirements and uncomment them.
-# Use "init q" to reread inittab.
-# look at the mgetty manpage for more information (mgetty isn't 
standard!)
-#
-#I0:2345:respawn:/sbin/mgetty -D -m '"" ATZ OK AT&Eyourmsnhere OK 
AT&B512 OK' -s 38400 ttyI0
-#-- isdnutils end


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: State of developers-reference

[David Paleino]

On Mon, 7 Sep 2009 18:40:44 +0200, Samuel Thibault wrote:

> Lucas Nussbaum, le Mon 07 Sep 2009 18:28:11 +0200, a écrit :
> > We could simply decide that it's deprecated, and use a set of wiki
> > pages to document our procedures.
> 
> I would like to raise the fact that Internet is not available
> everywhere, so at least an easy way to get an offline copy of these
> would be useful.

Or use the developers-reference package, which you can install anytime (and
which is the best choice IMHO).

I'm looking at the BTS, and see how I can help.

David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: The future of the boot system in Debian

[Henrique de Moraes Holschuh]

On Mon, 07 Sep 2009, Josselin Mouette wrote:
> Le lundi 07 septembre 2009 à 08:39 +0200, Petter Reinholdtsen a écrit : 
> > I guess we were a bit unclear.  The point is to use it for upgrades
> > (ie when it exist), while not installing /etc/inittab for new
> > installs, thus slowly getting rid of the file while ensuring the
> > switch do not affect upgrades negatively. :)
> 
> Please also think of removing it without asking if the file was not
> modified. This will handle at least 90% of installs.

That could be done, yes.  We just need a copy or sha1 and md5 sigs of the
inittabs used in the last two or three releases (and with some luck, it they
haven't changed at all across some releases, and we will need just one).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: udev and /usr

[Henrique de Moraes Holschuh]

Hi Julien!

On Mon, 07 Sep 2009, Julien Cristau wrote:

> On Mon, Sep  7, 2009 at 14:59:44 -0300, Henrique de Moraes Holschuh wrote:
> 
> > khazad-dum:~$ lsusb ; ls -l /dev/serial/by-id/*
> > Bus 004 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA
> > Modem / E270 HSDPA/HSUPA Modem
> > lrwxrwxrwx 1 root root 13 2009-09-07 14:56
> > /dev/serial/by-id/usb-HUAWEI_Technologies_HUAWEI_Mobile-if00-port0 ->
> > ../../ttyUSB0
> > lrwxrwxrwx 1 root root 13 2009-09-07 14:56
> > /dev/serial/by-id/usb-HUAWEI_Technologies_HUAWEI_Mobile-if01-port0 ->
> > ../../ttyUSB1
> > 
> 60-persistent-serial.rules from sid's udev:
> 
> IMPORT="usb_id --export %p"
> ENV{ID_SERIAL}=="", GOTO="persistent_serial_end"
> SUBSYSTEMS=="usb", ENV{ID_IFACE}="$attr{bInterfaceNumber}"
> ENV{ID_IFACE}=="", GOTO="persistent_serial_end"
> ENV{ID_PORT}=="", 
> SYMLINK+="serial/by-id/$env{ID_BUS}-$env{ID_SERIAL}-if$env{ID_IFACE}"
> ENV{ID_PORT}=="?*", 
> SYMLINK+="serial/by-id/$env{ID_BUS}-$env{ID_SERIAL}-if$env{ID_IFACE}-port$env{ID_PORT}"

Yeah, and it looks like here is no problem with that because usb_id only
reads data from the kernel, and the kernel protects that data's stability
under the strong userspace ABI rules.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: udev and /usr

[Henrique de Moraes Holschuh]

On Mon, 07 Sep 2009, Steve Langasek wrote:
> On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 07 Sep 2009, Julien Cristau wrote:
> > > On Mon, Sep  7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > > > From what I can see in /lib/udev/rules.d, the ids files are only used 
> > > > to setup
> > > > the (udev) environment variable ID_VENDOR_FROM_DATABASE
> > > > (75-net-description.rules, 75-tty-description.rules, 
> > > > 78-sound-card.rules).
> 
> > > > There are no symlinks created in /dev based on that information.
> 
> > Oh yes, there are.  Either Unstable's udev or something else does this for
> > USB at the very least.  Noticed it when playing with a Huawei E220 HSDPA USB
> > modem, the usb.ids information ended up in /dev/serial/by-id.
> 
> The changes in question aren't even in unstable yet.  So something else must
> be to blame.

Found them on /lib/udev.  This is in udev 141.

There is /lib/udev/usb_id, and /lib/udev/60-persistent-serial (and a few
other scripts in there) that use usb_id to make symlinks.

A quick look at the usb_id source tells me aparently there is NOTHING WRONG
with it.  It doesn't seem to use usb.ids, just whatever information the
kernel provides from the device (and device driver) knowledge about itself,
which is a lot more static than usb.ids, and protected by the kernel stable
ABI rules.

So, I am _happy_ to correct myself and state that currently, usb.ids
information is NOT used anywhere by udev scripts I know of.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: udev and /usr

[Julien Cristau]

On Mon, Sep  7, 2009 at 14:59:44 -0300, Henrique de Moraes Holschuh wrote:

> khazad-dum:~$ lsusb ; ls -l /dev/serial/by-id/*
> Bus 004 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA
> Modem / E270 HSDPA/HSUPA Modem
> lrwxrwxrwx 1 root root 13 2009-09-07 14:56
> /dev/serial/by-id/usb-HUAWEI_Technologies_HUAWEI_Mobile-if00-port0 ->
> ../../ttyUSB0
> lrwxrwxrwx 1 root root 13 2009-09-07 14:56
> /dev/serial/by-id/usb-HUAWEI_Technologies_HUAWEI_Mobile-if01-port0 ->
> ../../ttyUSB1
> 
60-persistent-serial.rules from sid's udev:

IMPORT="usb_id --export %p"
ENV{ID_SERIAL}=="", GOTO="persistent_serial_end"
SUBSYSTEMS=="usb", ENV{ID_IFACE}="$attr{bInterfaceNumber}"
ENV{ID_IFACE}=="", GOTO="persistent_serial_end"
ENV{ID_PORT}=="", 
SYMLINK+="serial/by-id/$env{ID_BUS}-$env{ID_SERIAL}-if$env{ID_IFACE}"
ENV{ID_PORT}=="?*", 
SYMLINK+="serial/by-id/$env{ID_BUS}-$env{ID_SERIAL}-if$env{ID_IFACE}-port$env{ID_PORT}"

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: udev and /usr

[Henrique de Moraes Holschuh]

On Mon, 07 Sep 2009, Steve Langasek wrote:
> On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 07 Sep 2009, Julien Cristau wrote:
> > > On Mon, Sep  7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > > > From what I can see in /lib/udev/rules.d, the ids files are only used 
> > > > to setup
> > > > the (udev) environment variable ID_VENDOR_FROM_DATABASE
> > > > (75-net-description.rules, 75-tty-description.rules, 
> > > > 78-sound-card.rules).

> > > > There are no symlinks created in /dev based on that information.

> > Oh yes, there are.  Either Unstable's udev or something else does this for
> > USB at the very least.  Noticed it when playing with a Huawei E220 HSDPA USB
> > modem, the usb.ids information ended up in /dev/serial/by-id.
> 
> The changes in question aren't even in unstable yet.  So something else must
> be to blame.

Ok.  I am trying to track it down.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: udev and /usr

[Steve Langasek]

On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 07 Sep 2009, Julien Cristau wrote:
> > On Mon, Sep  7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > > From what I can see in /lib/udev/rules.d, the ids files are only used to 
> > > setup
> > > the (udev) environment variable ID_VENDOR_FROM_DATABASE
> > > (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules).

> > > There are no symlinks created in /dev based on that information.

> Oh yes, there are.  Either Unstable's udev or something else does this for
> USB at the very least.  Noticed it when playing with a Huawei E220 HSDPA USB
> modem, the usb.ids information ended up in /dev/serial/by-id.

The changes in question aren't even in unstable yet.  So something else must
be to blame.

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


signature.asc
Description: Digital signature

Re: udev and /usr

[Michael Biebl]

Henrique de Moraes Holschuh wrote:
> On Mon, 07 Sep 2009, Julien Cristau wrote:
>> On Mon, Sep  7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
>>> From what I can see in /lib/udev/rules.d, the ids files are only used to 
>>> setup
>>> the (udev) environment variable ID_VENDOR_FROM_DATABASE
>>> (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules).
>>>
>>> There are no symlinks created in /dev based on that information.
> 
> Oh yes, there are.  Either Unstable's udev or something else does this for
> USB at the very least.  Noticed it when playing with a Huawei E220 HSDPA USB
> modem, the usb.ids information ended up in /dev/serial/by-id.

Could you investigate which udev rules file does that?
The files I mentioned above clearly don't and I haven't found any other rules
file on my laptop which either used pci-db/usd-db or ID_VENDOR_FROM_DATABASE.

-- 
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: DeviceKit and /usr

[Giacomo A. Catenazzi]

Steve Langasek wrote:

On Mon, Sep 07, 2009 at 04:36:53PM +0200, Josselin Mouette wrote:
Le lundi 07 septembre 2009 à 13:40 +0200, Bernhard R. Link a écrit : 

For the record: Noone sane would replace g_strdup_printf with snprintf,
but with asprintf.



Case 1:
char *foo;
if (asprintf(&foo, "%s equals %i", somestring, someint) < 0) {
fprintf(stderr, "Failed to allocate memory");
abort();
}



Case 2:
char *foo = g_strdup_printf ("%s equals %i", somestring,
someint);



Pick your choice.


Case 1, please.  Either case 2 fails to handle the allocation error, or glib
is doing its own abort.  Neither is acceptable.



and BTW the function seems not documented (I don't find the relevant 
manpage).


ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: udev and /usr

[Henrique de Moraes Holschuh]

On Mon, 07 Sep 2009, Julien Cristau wrote:
> On Mon, Sep  7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > From what I can see in /lib/udev/rules.d, the ids files are only used to 
> > setup
> > the (udev) environment variable ID_VENDOR_FROM_DATABASE
> > (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules).
> > 
> > There are no symlinks created in /dev based on that information.

Oh yes, there are.  Either Unstable's udev or something else does this for
USB at the very least.  Noticed it when playing with a Huawei E220 HSDPA USB
modem, the usb.ids information ended up in /dev/serial/by-id.

Here's the proof (output edited for brevity):

khazad-dum:~$ lsusb ; ls -l /dev/serial/by-id/*
Bus 004 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA
Modem / E270 HSDPA/HSUPA Modem
lrwxrwxrwx 1 root root 13 2009-09-07 14:56
/dev/serial/by-id/usb-HUAWEI_Technologies_HUAWEI_Mobile-if00-port0 ->
../../ttyUSB0
lrwxrwxrwx 1 root root 13 2009-09-07 14:56
/dev/serial/by-id/usb-HUAWEI_Technologies_HUAWEI_Mobile-if01-port0 ->
../../ttyUSB1

Now, I am not claiming it it is not useful.  However, IMO it would be useful
*and* safe if I had a by-id link using the proper USB ID *numbers* instead,
which I could use on /etc/ppp/peers/* for example.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DeviceKit and /usr

[Steve Langasek]

On Mon, Sep 07, 2009 at 04:36:53PM +0200, Josselin Mouette wrote:
> Le lundi 07 septembre 2009 à 13:40 +0200, Bernhard R. Link a écrit : 
> > For the record: Noone sane would replace g_strdup_printf with snprintf,
> > but with asprintf.

> Case 1:
> char *foo;
> if (asprintf(&foo, "%s equals %i", somestring, someint) < 0) {
> fprintf(stderr, "Failed to allocate memory");
> abort();
> }

> Case 2:
> char *foo = g_strdup_printf ("%s equals %i", somestring,
> someint);

> Pick your choice.

Case 1, please.  Either case 2 fails to handle the allocation error, or glib
is doing its own abort.  Neither is acceptable.

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


signature.asc
Description: Digital signature

Re: Moving init script from one package to another

[Marco d'Itri]

On Sep 07, "Roberto C. Sánchez"  wrote:

> As part of the shorewall package reorganization, the
> /etc/init.d/shorewall init script (and the symlinks to it) has moved
> from the shorewall-common package to the shorewall package.  However,
> after the upgrade of shorewall-common (which has become a dummy
> package), and the installation of the new shorewall binary package, it
> is not possible to purge the shorewall-common package.
Maybe there is a solution, but I could not find it when I packaged
openbsd-inetd to replace netkit-inetd. They is why the init script has a
stupid name...

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: State of developers-reference

[Samuel Thibault]

Lucas Nussbaum, le Mon 07 Sep 2009 18:28:11 +0200, a écrit :
> We could simply decide that it's deprecated, and use a set of wiki
> pages to document our procedures.

I would like to raise the fact that Internet is not available
everywhere, so at least an easy way to get an offline copy of these
would be useful.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Moving init script from one package to another

[Roberto C . Sánchez]

As part of the shorewall package reorganization, the
/etc/init.d/shorewall init script (and the symlinks to it) has moved
from the shorewall-common package to the shorewall package.  However,
after the upgrade of shorewall-common (which has become a dummy
package), and the installation of the new shorewall binary package, it
is not possible to purge the shorewall-common package.

The error I get is this:

Purging configuration files for shorewall-common ...
update-rc.d: /etc/init.d/shorewall exists during rc.d purge (use -f to force)
dpkg: error processing shorewall-common (--remove):

Is there some magic I can put into a prerm/postrm script that will
handle that?

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

State of developers-reference

[Lucas Nussbaum]

Hi,

I'm quite concerned about the state of developers-reference.

- I've basically been the only active maintainer for over a year.

- There are many open bugs, about things that should really be fixed or
  added in dev-ref, but I don't have time to address them (I'm doing
  "please provide a patch and I'll integrate it"-maintainance).

- There are more and more places where documentation about Debian
  development is being published: wiki pages, blogs, d-d-a, etc. While
  it might be good to keep developers informed, it's clearly not a good
  thing on the long term: you end up having to google for many d-d-a
  posts.

We really need to do something about this. Documentation about Debian
development plays an important role in the way we are perceived as
"welcoming" to newcomers. Our procedures are getting more and more
complex (use of packaging helpers like cdbs and dh7, use of VCSes), but
our documentation doesn't improve.

First, we need to decide whether we want to continue to maintain
developers-reference. We could simply decide that it's deprecated, and
use a set of wiki pages to document our procedures. I see some value to
a (mostly) self-contained documentation, but, if it helps getting
contributions from more people, we could simply move to wiki.d.o. (or to
a ikiwiki instance). I'm not a big fan of wikis, so I wouldn't continue
to "maintain" dev-ref, but I'm open to the idea.

If we decide to continue to maintain developers-reference, we should all
participate. I'm not asking everybody to become co-maintainers (some
help is probably needed, and would be welcomed, but I don't think that
the main problem is here).

Ideas:

- When announcing a change of procedure to d-d-a, or information that is
  useful on the long term, prepare a patch for dev-ref at the same time.
  It doesn't need to be in docbook-xml (plain text or html would do).

- When doing talks about something at Debconf or at another conference,
  take the opportunity to review and improve the corresponding dev-ref
  section. (That applies to the i18n chapter of dev-ref, which is
  apparently badly outdated).

- Contributing to dev-ref could become a part of the NM process. We
  already have a "fix two RC bugs" question. We could have a "fix two
  dev-ref bugs" one.

Any comments?
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: udev and /usr

[Josselin Mouette]

Le lundi 07 septembre 2009 à 17:29 +0200, Michael Biebl a écrit : 
> > So, again, why can't the programs that want to display this do the
> > lookup themselves?  Both libpciaccess and libpci provide API for this as
> > far as I can tell.
> 
> I am sure, they could. My guess is, it was added to udev to make porting apps
> from HAL to lib(g)udev easier and more convenient as you only have one API to
> write against (as you had with HAL)
> To get the information from pci.ids/usb.ids, you'd need to link to both libpci
> (and libusb, I guess) and write different code for the usb and pci case.
> A
> char *vendor = g_udev_device_get_property (device, "ID_VENDOR_FROM_DATABASE");
> is certainly a lot easier.

Wouldn’t it be possible to let libgudev itself do the job? OTOH it would
then link to libpci and libusb, but that may be a better solution.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Bug#545502: ITP: srcml -- srcML: A document-oriented XML representation of source code

[Mathieu Malaterre]

Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 


* Package name: srcml
  Version : 20061109
  Upstream Author : Dr. Michael Collard, Jonathan Maletic
* URL : http://www.sdml.info/projects/srcml/
* License : GPL
  Programming Lang: C++
  Description : srcML: A document-oriented XML representation of source code

srcML is a combination of source code (text) and selective AST information 
(tags) in a single XML document.
.
The focus is to construct a document representation in XML instead of a more 
traditional data representation of the source code. The representation of 
source code as semi-structured text supports a programmer-centric rather than a 
compiler-centric view, providing full access to the source code at the lexical, 
documentary (e.g., comments, white space), structural (e.g., classes, 
functions), and syntactic (e.g., statement) levels.

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DeviceKit and /usr

[Josselin Mouette]

Le lundi 07 septembre 2009 à 17:32 +0200, Mike Hommey a écrit : 
> Nobody has advised to strip them down from the library. Just to stop
> using glib in a small udev binary that only uses glib wrappers.

And I still believe this advice is wrong.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: DeviceKit and /usr

[Mike Hommey]

On Mon, Sep 07, 2009 at 05:15:44PM +0200, Josselin Mouette wrote:
> Le lundi 07 septembre 2009 à 16:56 +0200, Hendrik Sattler a écrit : 
> > So no trying to convince glib upstream to reduce wrapper bloat? *sigh*
> 
> What you are calling wrapper bloat is critical for portability of many
> applications, since it behaves the same on all systems where Glib has
> been ported. Just because some of them are not useful for writing a udev
> wrapper is not a good reason for stripping them down from the library.

Nobody has advised to strip them down from the library. Just to stop
using glib in a small udev binary that only uses glib wrappers.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: udev and /usr

[Michael Biebl]

Julien Cristau wrote:
> On Mon, Sep  7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> 
>> From what I can see in /lib/udev/rules.d, the ids files are only used to 
>> setup
>> the (udev) environment variable ID_VENDOR_FROM_DATABASE
>> (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules).
>>
>> There are no symlinks created in /dev based on that information.
>>
>> Given the name of the rules file, it indeed looks to be intended to be used 
>> for
>> display/descriptive purposes.
>>
> So, again, why can't the programs that want to display this do the
> lookup themselves?  Both libpciaccess and libpci provide API for this as
> far as I can tell.

I am sure, they could. My guess is, it was added to udev to make porting apps
from HAL to lib(g)udev easier and more convenient as you only have one API to
write against (as you had with HAL)
To get the information from pci.ids/usb.ids, you'd need to link to both libpci
(and libusb, I guess) and write different code for the usb and pci case.
A
char *vendor = g_udev_device_get_property (device, "ID_VENDOR_FROM_DATABASE");
is certainly a lot easier.

But that is just guessing. Maybe we should simply ask udev upstream (CCed)

@Kay: the start of the discussion is at [1]

Cheers,
Michael

[1] http://lists.debian.org/debian-devel/2009/09/msg2.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: DeviceKit and /usr

[Josselin Mouette]

Le lundi 07 septembre 2009 à 16:56 +0200, Hendrik Sattler a écrit : 
> So no trying to convince glib upstream to reduce wrapper bloat? *sigh*

What you are calling wrapper bloat is critical for portability of many
applications, since it behaves the same on all systems where Glib has
been ported. Just because some of them are not useful for writing a udev
wrapper is not a good reason for stripping them down from the library.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: DeviceKit and /usr

[Hendrik Sattler]

Zitat von Josselin Mouette :


Le lundi 07 septembre 2009 à 15:51 +0200, Bjørn Mork a écrit :

I'm suggesting that the utility uses lots of "g_" prefixed functions
while it's obvious that the author never ever evaluated the need for
these. I assume that's because the author is used to them always being
available.

Well, in the context of udev helpers, they are not.


Starting from the next glib2.0 upload, they will be. End of problem.


So no trying to convince glib upstream to reduce wrapper bloat? *sigh*

HS



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DeviceKit and /usr

[Josselin Mouette]

Le lundi 07 septembre 2009 à 15:51 +0200, Bjørn Mork a écrit : 
> I'm suggesting that the utility uses lots of "g_" prefixed functions
> while it's obvious that the author never ever evaluated the need for
> these. I assume that's because the author is used to them always being
> available. 
> 
> Well, in the context of udev helpers, they are not.

Starting from the next glib2.0 upload, they will be. End of problem.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: DeviceKit and /usr

[Josselin Mouette]

Le lundi 07 septembre 2009 à 13:40 +0200, Bernhard R. Link a écrit : 
> For the record: Noone sane would replace g_strdup_printf with snprintf,
> but with asprintf.

Case 1:
char *foo;
if (asprintf(&foo, "%s equals %i", somestring, someint) < 0) {
fprintf(stderr, "Failed to allocate memory");
abort();
}

Case 2:
char *foo = g_strdup_printf ("%s equals %i", somestring,
someint);

Pick your choice.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Bug#545489: ITP: mon-client -- modules for interfacing with the mon package

[Dario Minnucci (midget)]

Package: wnpp
Severity: wishlist
Owner: "Dario Minnucci (midget)" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: mon-client
  Version : 1.2.0
  Upstream Author : Jim Trocki 
* URL : http://mon.wiki.kernel.org/index.php/Download
* License : GPL-2+
  Programming Lang: Perl
  Description : modules for interfacing with the mon package

 (Replacement for current 'libmon-perl' package)

 These are the perl module for interfacing with the mon system monitoring
 package. It is intended to be used in conjuction with the mon 1.2.x server.
 Currently only the client interface is implemented, but more things like
 special logging routines and persistent monitors are being considered.

 "mon" is a tool for monitoring the availability of services.
 More information can be found at http://www.kernel.org/software/mon/


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJKpRIgAAoJEPyEGy2CyLcRHzQP/RxP8cLfZTH8K8TdkntVUa9L
zZAkjVNG8eO9xhtUn7Tqei5yomVncIdhWO3FkQ492HKPWBETlaiX9zT+UcD2o2Px
Wst1gSgbblypu9W4PDYO1+gDEw0OrpddkxGfWuIxEaI5Od6iCfEZkgyaoKqWGwck
fZ98rdY8nd6Z4iAJuhcWYDydHxXMEssdaePiRbpuGTUNshuw3uJin+juDNzhoyZ4
7+Q3edrIoUQiqQTCVywmP8SwwQfV/LKAzseQ3egKiXKZbD2vnok7Qk5JF9OClejy
TIySRUkym5L9/Q6tjRnV/17mwthWY9FXHG1fXYVrqNCq+NVrp5roq68bHmRiFBW8
1vL1jtqtsZ3SqST+9SDHDBTtcjQPJyz4WtSwV1xzBrv7eI9GZacvZ4ugT0Eibkn5
DdRPCZFknFjkDWuGBipWbsd+Ss94pZAQifmRHMgoznYXqVJa/A55IUqpzb70kReI
yrcMOtxN90wcm0BC9bWRYTEf3aatAk+pRtR/mfHuOFMY5q++xR0UdX3mlYLQN4nP
tOU/K7+ZHkAJJF2+sVkXtS+eDIVkHOpPo+EPQOOkN2aAzjwehBKbcQW0BJ322vZQ
8R3jVJt7RJCO85J5tvTeXza2qHywthnwy17WgjHxT5y2/cUNyGuLtYuxpnf5hBKu
C5BgYuNg1ROPdQrmcSlw
=lbQv
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [DSE-Dev] The future of the boot system in Debian

[Manoj Srivastava]

On Mon, Sep 07 2009, Gabor Gombas wrote:

> Hi,
>
> On Sun, Sep 06, 2009 at 06:21:33PM -0500, Manoj Srivastava wrote:
>
>> Right. I did not copy the upstream. I also think that we have
>>  invested a lot of effort in Debian in order to make Squeeze SELinux
>>  compliant, and make it so that turning on SELinux is fairly easy. I
>>  have asked the release managers to consider making Squeeze have SELinux
>>  working out of the box a release goal, and so far there has been no
>>  denial; and I consider the patch consistent with the choices we have
>>  made as a project in the past.
>> 
>> I am also saying that I would be willing to maintain the SELinux
>>  patches  in sysvinit/upstart, if it comes to that, and the "burden" of
>>  keeping the patch around would be fairly small (it is a small patch,
>>  and  fairly self contained).
>
> The original announcement said that Fedora is already using upstart.
> AFAIK Fedora is also commited to using SELinux. Do they use a similar
> patch? Can they help convincing upstream?

http://cvs.fedoraproject.org/viewvc/F-11/upstart/ does not seem
 to have any SELinux patches, and
http://cvs.fedoraproject.org/viewvc/EL-5/ does not have any
 upstart packages (I do not see a repository for RHEL-6).

I am going to send in the patch to the SELinux devel list for
 comment, and there are a lot of Red Hat folks over there.

manoj
-- 
When does summertime come to Minnesota, you ask?  Well, last year, I
think it was a Tuesday.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DeviceKit and /usr

[Bjørn Mork]

Josselin Mouette  writes:
> Le lundi 07 septembre 2009 à 11:48 +0200, Bjørn Mork a écrit : 
>> You're not seriously suggesting that DeviceKit-disks usage of g_print
>> instead of printf is actually adding anything useful?
>
> Yeah sure, just look at g_print and not at the other symbols used by
> devkit-disks-part-id :
> g_free g_slist_free g_print g_strdup g_printerr g_slist_append
> g_strdup_printf g_fprintf g_vfprintf g_strchomp g_strjoinv
> g_slist_length g_malloc0 g_build_filename g_file_get_contents
> g_utf16_to_utf8 g_strfreev g_slist_nth_data
>
> Are you suggesting that such an utility should implement its own linked
> list structure, and unicode translation functions?

I'm suggesting that the utility uses lots of "g_" prefixed functions
while it's obvious that the author never ever evaluated the need for
these. I assume that's because the author is used to them always being
available. 

Well, in the context of udev helpers, they are not.

Do you really need the g_utf16_to_utf8 unicode translation? You could
just as well let udev export the raw utf16 value and leave the
conversion up to the users.  They may want something different than utf8
anyway.



Bjørn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#545480: ITP: libnet-epp-perl -- EPP XML frame system built on top of XML::LibXML

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: libnet-epp-perl
  Version : 0.12
  Upstream Author : CentralNic Ltd - http://www.centralnic.com/
* URL : http://search.cpan.org/dist/Net-EPP/
* License : Perl
  Programming Lang: Perl
  Description : EPP XML frame system built on top of XML::LibXML

 EPP is the Extensible Provisioning Protocol. EPP (defined in RFC 4930) is an
 application layer client-server protocol for the provisioning and management
 of objects stored in a shared central repository. Specified in XML, the
 protocol defines generic object management operations and an extensible
 framework that maps protocol operations to objects. As of writing, its only
 well-developed application is the provisioning of Internet domain names,
 hosts, and related contact details.

 EPP uses XML documents called "frames" send data to and from clients and
 servers. Net::EPP implements a subclass of the XML::LibXML::Document module
 that simplifies the process of creation of these frames. It is designed to be
 used alongside the Net::EPP::Client module.

I intend to maintain this package within the Debian Perl group.


pgpBDMdFeMgQ6.pgp
Description: PGP signature

Re: shared library in binary-package?

[Gabor Gombas]

On Mon, Sep 07, 2009 at 03:19:19PM +0200, Stéphane Glondu wrote:

> Do you have an example of such OS that is likely to be supported by
> freesmartphone.org ?

I know nothing about freesmartphone.org so I have no idea what they want
to support.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: shared library in binary-package?

[Stéphane Glondu]

Gabor Gombas a écrit :
> That won't work if upstream wants to support OSes other than Linux. My
> memory is getting hazy but I had to use the same technique in the past
> because not all OSes are capable of letting plugins resolve symbols from
> the main binary, at least not without extra complications.

Do you have an example of such OS that is likely to be supported by
freesmartphone.org ?


Cheers,

-- 
Stéphane


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: For the grub maintainers II

[Felix Zielcke]

Am Montag, den 07.09.2009, 13:30 +0200 schrieb Vincent Danjean:
> Gabor Gombas wrote:
> > On Sat, Sep 05, 2009 at 03:03:40PM +0200, Felix Zielcke wrote:
> > 
> >> Robert filed already after the upload of grub-legacy a RC bug so it
> >> doestn't migrate after the usual 10 days to testing.
> >>
> >> Note that we only Suggests: os-prober and not Recommend: it like Ubuntu
> >> does because of 491872
> >> So if anyone want to help that we Recommend it again, then help the
> >> os-prober maintainers to fix that bug.
> > 
> > I don't know the specifics, but wouldn't it be possible for os-prober to
> > create its own private mount name space (see clone(2), CLONE_NEWNS),
> > and do the probing inside that name space? That way the desktop
> > environments would not be able to intercept it.
> 
> Please, take care with auto mounting of most partitions:
> some of my serveur are Xen or kvm host. And some of their partitions
> (mostly LVs) are used by running guest. These partitions MUST NOT be
> mounted on the host. I even change /etc/lvm/lvm.conf so that PV
> for guests are not detected (and activated) on the host.
> 

There's already a report open on os-prober to make it really read-only
#417407
IIRC Colin Watson already thought in an Ubuntu bug report about
implementing a blacklist for os-prober.

-- 
Felix Zielcke
Proud Debian Maintainer


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Of the use of native packages for programs not specific to Debian.

[Wouter Verhelst]

On Mon, Sep 07, 2009 at 11:22:30AM +0200, Giacomo A. Catenazzi wrote:
> We have a lot of troubles when upstreams ship a debian/ directory
> in upstream tarball, thus I'll expect derivatives will have similar
> problems

I don't see it that way.

The reason why we have 'a lot of troubles' when upstreams ship a debian/
directory, is because upstreams usually supply that directory as a
courtesy to make life 'easier' for those people who want to build a
Debian package out of their SCM repository, and that as a result, they
are usually not even remotely Policy-compliant. Thus, we need to do a
*lot* of work to get them integrated properly; and any files that keep
lying around in debian/ might interfere with other things.

Debian packages from the Debian distribution usually are
policy-compliant and maintained, so this kind of problem does not
manifest itself as often for our downstreams

(of course there are packages that are not maintained nor
policy-compliant, but then they don't tend to live long in the
distribution).

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: library-related policy question

[Reinhard Tartler]

Steve Langasek  writes:

>> We have done this in the past in Debian without changing the SONAME in
>> places where compatibility of SONAME with other distributions is
>> important.  Specifically, libkrb53 removed several private symbols and we
>> didn't change the SONAME.  *However*, if you're thinking about doing that,
>> you have to both be quite sure that the number of packages using that
>> symbol is very limited and rare *and* coordinate that change with all of
>> those packages, which will probably mean adding Breaks to the new version
>> of the shared library.
>
> And if the symbols in question were exported in a header (else how did
> mplayer come to depend on them?), it can be very difficult to be sure you
> know the complete set of reverse-dependencies.

ffmpeg has "installed" headers and headers that are just in the ffmpeg
source tree. since mplayer ships its own copy of ffmpeg, it can include
these private headers in addition to the jheaders that are supposed to
be installed in the package.

yes, mplayer upstream is not supposed to use these headers, but they do
it anyways. this has historic reasons, and I have the impression they
slowly try to get away from this as ffmpeg matures more and more.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: library-related policy question

[Reinhard Tartler]

"Nikita V. Youshchenko"  writes:

> As of today, debian does not contain this bug, because ffmpeg with this 
> brakage happened not to be uploaded yet to debian. However, once it is, 
> the bug will be in debian, and will have to be handled somehow.

mplayer is really meant to be using the internal ffmpeg that it ships
with. what marillat does is really insane for a distribution, but works
if you like staying on a moving target. The debian mplayer and ffmpeg
package track the release branches for a reason!

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DeviceKit and /usr

[Hendrik Sattler]

Zitat von Josselin Mouette :


Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit :
It rather needs to raise the question why simple low-level tools   
use something

like libglib?


I’d rather raise the question why each of our simple low-level tools
implement its data structures and basic routines in its own fashion,
leading to bugs and security issues sometimes, instead of re-using the
ones from Glib.


You mean useless functions like those only wrap standard functions and  
add no value except a (build-)dependency to libglib? Very exciting.
There may be lots of useful stuff in libglib but some may only be  
useful as portability wrapper (but some not even for that). Get rid of  
all of those and I may agree. I fully disagree for using libglib as  
wrapper around libc.


HS



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DeviceKit and /usr

[Bernhard R. Link]

* Josselin Mouette  [090907 12:37]:
> Are you suggesting that such an utility should implement its own linked
> list structure, and unicode translation functions? Are you aware of the
> security implications of using snprintf instead of g_strdup_printf?

For the record: Noone sane would replace g_strdup_printf with snprintf,
but with asprintf.

Hochachtungsvoll,
Bernhard R. Link
-- 
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: For the grub maintainers II

[Mike Hommey]

On Mon, Sep 07, 2009 at 09:53:30AM +0100, Colin Watson wrote:
> On Sat, Sep 05, 2009 at 08:32:02PM +0200, Gabor Gombas wrote:
> > On Sat, Sep 05, 2009 at 03:03:40PM +0200, Felix Zielcke wrote:
> > > Note that we only Suggests: os-prober and not Recommend: it like Ubuntu
> > > does because of 491872
> > > So if anyone want to help that we Recommend it again, then help the
> > > os-prober maintainers to fix that bug.
> > 
> > I don't know the specifics, but wouldn't it be possible for os-prober to
> > create its own private mount name space (see clone(2), CLONE_NEWNS),
> > and do the probing inside that name space? That way the desktop
> > environments would not be able to intercept it.
> 
> Excellent idea, thanks; I'm looking into doing this now.

FYI, using unshare(2) is easier than clone(2) for this purpose.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: For the grub maintainers II

[Vincent Danjean]

Gabor Gombas wrote:
> On Sat, Sep 05, 2009 at 03:03:40PM +0200, Felix Zielcke wrote:
> 
>> Robert filed already after the upload of grub-legacy a RC bug so it
>> doestn't migrate after the usual 10 days to testing.
>>
>> Note that we only Suggests: os-prober and not Recommend: it like Ubuntu
>> does because of 491872
>> So if anyone want to help that we Recommend it again, then help the
>> os-prober maintainers to fix that bug.
> 
> I don't know the specifics, but wouldn't it be possible for os-prober to
> create its own private mount name space (see clone(2), CLONE_NEWNS),
> and do the probing inside that name space? That way the desktop
> environments would not be able to intercept it.

Please, take care with auto mounting of most partitions:
some of my serveur are Xen or kvm host. And some of their partitions
(mostly LVs) are used by running guest. These partitions MUST NOT be
mounted on the host. I even change /etc/lvm/lvm.conf so that PV
for guests are not detected (and activated) on the host.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DeviceKit and /usr

[Josselin Mouette]

Le lundi 07 septembre 2009 à 11:48 +0200, Bjørn Mork a écrit : 
> You're not seriously suggesting that DeviceKit-disks usage of g_print
> instead of printf is actually adding anything useful?

Yeah sure, just look at g_print and not at the other symbols used by
devkit-disks-part-id :
g_free g_slist_free g_print g_strdup g_printerr g_slist_append
g_strdup_printf g_fprintf g_vfprintf g_strchomp g_strjoinv
g_slist_length g_malloc0 g_build_filename g_file_get_contents
g_utf16_to_utf8 g_strfreev g_slist_nth_data

Are you suggesting that such an utility should implement its own linked
list structure, and unicode translation functions? Are you aware of the
security implications of using snprintf instead of g_strdup_printf?

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: udev and /usr

[Julien Cristau]

On Mon, Sep  7, 2009 at 05:15:19 +0200, Michael Biebl wrote:

> From what I can see in /lib/udev/rules.d, the ids files are only used to setup
> the (udev) environment variable ID_VENDOR_FROM_DATABASE
> (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules).
> 
> There are no symlinks created in /dev based on that information.
> 
> Given the name of the rules file, it indeed looks to be intended to be used 
> for
> display/descriptive purposes.
> 
So, again, why can't the programs that want to display this do the
lookup themselves?  Both libpciaccess and libpci provide API for this as
far as I can tell.

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: For the grub maintainers II

[Frans Pop]

Colin Watson wrote:
> On Sat, Sep 05, 2009 at 10:55:42PM +0200, Frans Pop wrote:
>> I would not recommend having os-prober installed for this.
> 
> We should make it more efficient and less intrusive, but that's
> perfectly feasible in os-prober itself and would be a good idea anyway.

My main point was that in its current form it's not suitable for the 
purpose for which was being suggested.

Of course, if os-prober is significantly improved and would (besides the 
improvements you suggested) e.g. support a configuration file that allows 
to specify either a whitelist or blacklist of devices to scan, that would 
change the situation.

>> Relying on os-prober to migrate from grub1 to grub2 is bad anyway as it
>> will in no way preserve any existing manually added/changed boot menu
>> entries. Migrating existing "other os" entries really needs to be
>> solved in a different way.
> 
> I don't see this as solving the migration issue, but as a perfectly good
> configuration mechanism in its own right.

I'm not so sure. For some users maybe. But for most what OSes they have 
installed is fairly static.

They may e.g. prefer to chainload another bootloader on a different 
disk/partition for other Linux OSes rather than have these included in 
the primary bootloader (for example to test the correct installation of 
that bootloader...).

> Migration is a separate and harder problem; it's really a language
> translation problem in some ways, with the added wrinkle that really, we
> only want to migrate custom entries.

Why is that so hard? In menu.lst that's simply everything after the line:
### END DEBIAN AUTOMAGIC KERNELS LIST

> Anything that's basically a modified version of one of the
> system-provided entries would be *much* better catered for by making the
> appropriate adjustments to /etc/default/grub and letting the new
> grub-mkconfig configuration system take care of it.

Definitely. No argument there.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DeviceKit and /usr

[Bjørn Mork]

Josselin Mouette  writes:
> Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit : 
>> It rather needs to raise the question why simple low-level tools use 
>> something 
>> like libglib?
>
> I’d rather raise the question why each of our simple low-level tools
> implement its data structures and basic routines in its own fashion,
> leading to bugs and security issues sometimes, instead of re-using the
> ones from Glib.

Oh, come on...

Exactly what does glib add here:

#define G_GNUC_PRINTF( format_idx, arg_idx )\
  __attribute__((__format__ (__printf__, format_idx, arg_idx)))

voidg_print (const gchar*format,
 ...) G_GNUC_PRINTF (1, 2);



You're not seriously suggesting that DeviceKit-disks usage of g_print
instead of printf is actually adding anything useful?

The fact is that glib is nothing but a libc wrapper for the low-level
usage we're talking about here.  And as such, completely unnecessary. I
wouldn't have cared if we were discussing ordinary desktop utilities.
glib is of course available for them, and it doesn't matter whether you
use the printf wrapper or not.  But it is not an argument for moving
glib to /lib.  There is already a printf() in /lib.  Use it.

Or do you want to take your argument to the kernel as well?  Maybe it
should use the glib wrappers to avoid bugs and security issues?  Right.



Bjørn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Of the use of native packages for programs not specific to Debian.

[Giacomo A. Catenazzi]

Goswin von Brederlow wrote:


I also would rather have a native package in Debian and then have
Debian derivatives convert the package using Debians tar.gz as
orig.tar.gz and put their derivate specific changes into diff.gz.

Shipping a source with 0 byte diff.gz in Debian seems stupid and
shipping a all of debian/ as diff.gz in Debian means the changes
derivatives do get lost in a huge diff. Seems to me like a native
package in Debian and non-native in a derivative is the best way.


We have a lot of troubles when upstreams ship a debian/ directory
in upstream tarball, thus I'll expect derivatives will have similar
problems (if they do something more than a raw copy of our sources).

If we pack non debian-specific packages as native, I'll have more
trouble in explaining upstreams that it is bad to ship debian/ dir.

[I'm really waiting for dpkg-source 3.0 for this reason!]

And derivatives will have more difficulties if they want to change
the helper (to dh 7, to cdbs, ...).

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: For the grub maintainers II

[Colin Watson]

On Sat, Sep 05, 2009 at 08:32:02PM +0200, Gabor Gombas wrote:
> On Sat, Sep 05, 2009 at 03:03:40PM +0200, Felix Zielcke wrote:
> > Note that we only Suggests: os-prober and not Recommend: it like Ubuntu
> > does because of 491872
> > So if anyone want to help that we Recommend it again, then help the
> > os-prober maintainers to fix that bug.
> 
> I don't know the specifics, but wouldn't it be possible for os-prober to
> create its own private mount name space (see clone(2), CLONE_NEWNS),
> and do the probing inside that name space? That way the desktop
> environments would not be able to intercept it.

Excellent idea, thanks; I'm looking into doing this now.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: For the grub maintainers II

[Colin Watson]

On Sat, Sep 05, 2009 at 11:03:10PM +0200, Frans Pop wrote:
> On Saturday 05 September 2009, Frans Pop wrote:
> > It has never been intended to be used as part of an update-grub script
> > and to be run every time the bootloader configuration is updated
> > because a new/updated kernel was installed or one of the packages that
> > affect an initrd (udev, mdcfg, lvm, ...) are updated.
> 
> Basically: you do not want to have some script load every available file 
> system kernel module available on the system at random moments,

We could, and should, address this in os-prober by making use of smart
file system detection if available (e.g. blkid). This would make it much
faster in d-i, too.

> nor do you want to have that script regularly scan all partitions on
> your system, including any removable storage medium.

Again, this is an implementation detail. I don't know offhand what the
right default is, and it could do with discussion, but it'd be entirely
feasible to make os-prober optionally skip removable devices.

Other similar issues in os-prober really are just bugs in os-prober. I
don't think they're fundamental design issues with something outside the
installer using os-prober.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: For the grub maintainers II

[Colin Watson]

On Sat, Sep 05, 2009 at 10:55:42PM +0200, Frans Pop wrote:
> Philipp Kern wrote:
> > Do you have os-prober installed?
> 
> I would not recommend having os-prober installed for this. os-prober has 
> always been intended to be run only _once_, mostly when a new system is 
> installed. It exists as a .deb to be used for example after a debootstrap 
> installation of a system (i.e. an install that did not use D-I).

Of course, os-prober is collaboratively maintained by the d-i team
rather than by a single person. Personally, I have no problem with grub2
using it. Right now, given that grub2's configuration file format is
still changing in small ways from time to time, it's a lot more
straightforward to probe this on each update-grub run than it is to
probe it statically - in other words I think the latter would cause
*more* problems, not fewer.

We should make it more efficient and less intrusive, but that's
perfectly feasible in os-prober itself and would be a good idea anyway.

> Relying on os-prober to migrate from grub1 to grub2 is bad anyway as it 
> will in no way preserve any existing manually added/changed boot menu 
> entries. Migrating existing "other os" entries really needs to be solved 
> in a different way.

I don't see this as solving the migration issue, but as a perfectly good
configuration mechanism in its own right.

Migration is a separate and harder problem; it's really a language
translation problem in some ways, with the added wrinkle that really, we
only want to migrate custom entries. Anything that's basically a
modified version of one of the system-provided entries would be *much*
better catered for by making the appropriate adjustments to
/etc/default/grub and letting the new grub-mkconfig configuration system
take care of it.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: The future of the boot system in Debian

[Josselin Mouette]

Le lundi 07 septembre 2009 à 08:39 +0200, Petter Reinholdtsen a écrit : 
> I guess we were a bit unclear.  The point is to use it for upgrades
> (ie when it exist), while not installing /etc/inittab for new
> installs, thus slowly getting rid of the file while ensuring the
> switch do not affect upgrades negatively. :)

Please also think of removing it without asking if the file was not
modified. This will handle at least 90% of installs.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: DeviceKit and /usr

[Josselin Mouette]

Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit : 
> It rather needs to raise the question why simple low-level tools use 
> something 
> like libglib?

I’d rather raise the question why each of our simple low-level tools
implement its data structures and basic routines in its own fashion,
leading to bugs and security issues sometimes, instead of re-using the
ones from Glib.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: shared library in binary-package?

[Gabor Gombas]

On Mon, Sep 07, 2009 at 02:12:52PM +0800, Paul Wise wrote:

> Sounds like upstream should be persuaded to move the shared library
> code into the daemon since there is no reason for it to be in a
> library.

That won't work if upstream wants to support OSes other than Linux. My
memory is getting hazy but I had to use the same technique in the past
because not all OSes are capable of letting plugins resolve symbols from
the main binary, at least not without extra complications. So there are
two options:

- design a complicated plugin interface that contains function pointers
  for every function in the main program you want to use in a plugin, or

- implement the service as a library, and let the daemon and the plugins
  all link to this library.

The second method results in much cleaner code. The first method is
preferred if you expect to have 3rd party modules since (when done
right) it makes it easier to maintain module ABI stability.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: The future of the boot system in Debian

[Petter Reinholdtsen]

[Rene Mayrhofer]
> Please don't. As you correctly pointed out, the current Debian init
> architecture is one of the most painful and outdated (not to say
> broken) parts in the whole system. It's really time to move away
> from old cruft (and I consider inittab to be cruft of little use at
> this time) and start using something that will not cause more pain
> in the future.

I guess we were a bit unclear.  The point is to use it for upgrades
(ie when it exist), while not installing /etc/inittab for new
installs, thus slowly getting rid of the file while ensuring the
switch do not affect upgrades negatively. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: amarok 2 in squeeze

[Sune Vuorela]

On 2009-09-07, Andrew R Kelley  wrote:
> --000e0cd3b27cf19d880472f5f8d4
> Content-Type: text/plain; charset=ISO-8859-1
>
> Can we have amarok 1.4 as an option to use? in my opinion, amarok 2 is not
> usable yet. I decided to give it a try when it replaced 1.4 in squeeze, but
> it's missing many 1.4 features and has many unstable glitches that were not
> present in 1.4.

You are most welcome to package amarok 1.4 seperately and
non-conflicting with the amarok package, and take care of all related
bugs.  Don't expect any help from the debian kde people though.

>
> Currently when I run amarok I get a dcop no reply error message. I can't
> even run the program. It worked for a while, kind of, and then died.

There is no dcop in anything using kdelibs from kde4.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: The future of the boot system in Debian

[Gabor Gombas]

Hi,

On Sun, Sep 06, 2009 at 06:21:33PM -0500, Manoj Srivastava wrote:

> Right. I did not copy the upstream. I also think that we have
>  invested a lot of effort in Debian in order to make Squeeze SELinux
>  compliant, and make it so that turning on SELinux is fairly easy. I
>  have asked the release managers to consider making Squeeze have SELinux
>  working out of the box a release goal, and so far there has been no
>  denial; and I consider the patch consistent with the choices we have
>  made as a project in the past.
> 
> I am also saying that I would be willing to maintain the SELinux
>  patches  in sysvinit/upstart, if it comes to that, and the "burden" of
>  keeping the patch around would be fairly small (it is a small patch,
>  and  fairly self contained).

The original announcement said that Fedora is already using upstart.
AFAIK Fedora is also commited to using SELinux. Do they use a similar
patch? Can they help convincing upstream?

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org