Re: apt-get wrapper for maintaining Partial Mirrors

[Joseph Rawson]

On Friday 19 June 2009 00:27:06 Goswin von Brederlow wrote:
> Joseph Rawson  writes:
> > BTW, the subject of this thread is "apt-get wrapper for maintaining
> > Partial Mirrors".  The solution I'm proposing is "a simple tool for
> > maintaining Partial Mirrors" (which could possibly be wrapped by apt-get
> > later).
> >
> > I think that just pursuing an "apt-get wrapper" leads to some
> > complications that could be avoided by creating the "partial mirror tool"
> > first, then looking at wrapping it later.  One complication might be "how
> > do handle apt-get remove", and another might be "how to handle sid
> > libraries that disappear from official repository, yet local machines
> > must have them".
>
> Ahh, so maybe I completly misread that part.
>
It was my fault for not making this point clear, as I should've done.  FWIW, I 
would be much more interested in making a tool that would make it easier to 
manage local/partial debian mirrors (i.e. one that helped resolve the 
dependencies), rather than have an apt-get wrapper.  I also think that once 
such a tool is made, it would make it easier to build an apt-get wrapper that 
works with it.  I don't think that viewing the problem with an "apt-get 
wrapper" solution is the best way to approach it, but I do think that it 
would be valuable once the underlying problems are solved.

> Do you mean a wrapper around apt-get so that "apt-get install foo" on
> any client would automatically add "foo" to the list of packages being
> mirrored on the server?
>
It was the original poster who mentioned the apt-get wrapper, but I took it to 
mean exactly what you said above.  The tool I was envisioning would take a 
short list of packages (a text file with package names separated by newlines, 
or a collection of such text files) combined with a list of apt sources and 
generate the partial mirror from just that information.  There are still some 
things that should be explicitly included in those lists, such as either 
gamin, fam, or both, as an example.

> If so then you can configure a post invoke hook in apt that will copy
> the dpkg status file of the host to the server [as status.$(hostname)]
> and then use those on the server to generate the filter for
> reprepro. I think I still have a script for that somewhere but it is
> easy enough to rewrite.
That's good for binaries, but I don't know about the source.  It wasn't long 
ago that I noticed a problem with reprepro not obtaining the corresponding 
source packages when you use a filter list taken 
from  "dpkg --get-selections".  I remember that the source for jigdo wasn't 
in my partial mirror, because there were no binaries named "jigdo", 
rather "jigdo-file" and "jigdo-lite".  Since there were no sources with that 
name, the jigdo source was never mirrored on my partial mirror.  I don't know 
if that behavior has been fixed now, since there is now a binary named jigdo, 
instead of jigdo-lite.

Also, it's more difficult for the local repository to determine the difference 
between the automatically selected and manually selected packages in this 
type of setup, since you would be sending a longer list of "manually selected 
packages", instead of distinguishing which ones are actually selected.  I 
guess that it doesn't matter much, as a package would only be removed from 
the repository once it's not listed on any of the lists.  There were times 
when I didn't want certain packages to be removed from the repository, 
regardless of whether they were installed or not, so I used to run xxdiff on 
the packages files, so the newer ones were added.

In my way of thinking, I'm not looking to merge upstream repositories together 
in one repository.  Besides, there are already tools, such as apt-move that 
would be better for this job.  Long ago, apt-move was the primary tool that I 
used to keep a local repository, and it worked pretty well, as long as all 
the machines that were using it were on the same release.

I have found that reprepro is the absolute best tool for maintaining a debian 
mirror.  The only problem I have with it is when I want to maintain a partial 
mirror, and I don't want a merged repository, is that I have to spread the 
packages lists to different places, and when you start adding machines, you 
start adding more lists to the configuration, when it would probably be 
better to maintain a set of "master" lists that are generated from the many 
lists that come from the machines.

>
> MfG
> Goswin



-- 
Thanks:
Joseph Rawson


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

Re: apt-get wrapper for maintaining Partial Mirrors

[Joseph Rawson]

On Thursday 18 June 2009 03:17:13 Frank Lin PIAT wrote:
> On Tue, 2009-06-09 at 16:16 -0500, Joseph Rawson wrote:
> > On Tuesday 09 June 2009 13:14:53 sanket agarwal wrote:
> > > I had an idea in mind whereby the task of making mirrors for personal
> > > distributions can be automated.
>
> 
> Depending on what you want to achieve, a caching proxy might be an easy
> solution (there are a specialized in the archive already)
> 
>
Or possibly apt-move called as a post-invoke action of apt-get.

> > > This can be stated as: if a person
> > > wants to keep a customised set of packages for usage with the
> > > distribution, the tool should be able to develop dependencies, fetch
> > > packages, generate appropriate documentation and then create the
> > > corresponding directory structure in the target mirror! The task can
> > > be extended to include packages which are currently not under one of
> > > the standard mirrors!
>
> 
> One don't have to merge the repositories, one can just declare multiple
> sources in /etc/apt/*
> 
>
Then it becomes harder to send the package to the appropriate local 
repository, since they aren't merged.  I would also prefer to not have to 
deal with a merged repository, but keep separate upstream partial mirrors, as 
they would probably be easier to manage.

> > > I think the tool can have immense utility in helping people automate
> > > the task of mantaining the repositories. Suggestions, positive and
> > > negative are invited.
> > >
> > > I have not included the impl details as I would first like to evaluate
> > > the idea at a feasibility and utility level.
>
> If the scope of your project includes being able to bootstrap systems
> from the mirror, resolving dependency is much more complex (some
> packages aren't resolved by dependencies. For instance, the right kernel
> is select by some logic in Debian-installer).
> I found some interesting logic in debian-cd package.
>
> Still, I don't consider that allowing bootstrapping is mandatory. Your
> project would still be extremely valuable without it. [for those 95% of
> the people that install from CD, as opposed to netboot].
>
The reason that I recommended tying germinate and reprepro together with a 
tool was because the original post was discussing "personal distributions".  
To me, this implies the ability to bootstrap, and also the need to have 
a "self building" source/binary repository.

I have just made some other responses to Goswin that should help explain my 
view on things a bit better.

> Regards,
>
> Franklin



-- 
Thanks:
Joseph Rawson


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

Re: apt-get wrapper for maintaining Partial Mirrors

[Joseph Rawson]

On Thursday 18 June 2009 04:47:45 Goswin von Brederlow wrote:
> Frank Lin PIAT  writes:
> > On Tue, 2009-06-09 at 16:16 -0500, Joseph Rawson wrote:
> >> On Tuesday 09 June 2009 13:14:53 sanket agarwal wrote:
> >> > This can be stated as: if a person
> >> > wants to keep a customised set of packages for usage with the
> >> > distribution, the tool should be able to develop dependencies, fetch
> >> > packages, generate appropriate documentation and then create the
> >> > corresponding directory structure in the target mirror! The task can
> >> > be extended to include packages which are currently not under one of
> >> > the standard mirrors!
> >
> > 
> > One don't have to merge the repositories, one can just declare multiple
> > sources in /etc/apt/*
> > 
>
> Lets say I want to mirror xserver-xorg from experimental. Then I would
> want it to include xserver-xorg-core (>= xyz) also from experimental
> as the dependency dictates but not include libc6 from experimental as
> the sid one is sufficient.
>
> A key point here would be flexibility.
This is something that I haven't considered yet.  This would be one of the 
problems that might occur with the "post invoke hook" that you mentioned 
earlier using dpkg status.  Actually this wouldn't be much of a problem, I 
was confused.  I was thinking you were meaning "--get-selections" which just 
returns the name of the package and "install/deinstall", but status also 
contains the version being used, and this could be matched to the appropriate 
repository in the sources list (so you get the libc from main instead of 
experimental, since the status file uses the version that's in main).

However, I don't know how to use that info with reprepro.  With reprepro, I've 
only sent "--get-selections" lists to it.  In fact, this is how I used to 
install new packages in sid, and make sure they came from the local 
repository first.


#!/bin/bash
packages=`grep-status " install ok not-installed" | grep Package | 
gawk '{print $2}'`
#packages=`aptitude search ~N | grep ^.i | gawk '{print $2}'`
touch conf/list-uninstalled.tmp
for package in $packages 
  do echo -e "$package\t\tinstall" >> conf/list-uninstalled.tmp
done
cat conf/list-uninstalled.tmp | uniq | sort > conf/list-uninstalled
rm conf/list-uninstalled.tmp


You may be able to tell by looking at the script that I'm still in the process 
of getting used to aptitude, being a longtime dselect user. ;)
Anyway, I don't know much about determining (with reprepro) which upstream 
repository holds the version of the package that I want installed.

>
> >> > I think the tool can have immense utility in helping people automate
> >> > the task of mantaining the repositories. Suggestions, positive and
> >> > negative are invited.
> >> >
> >> > I have not included the impl details as I would first like to evaluate
> >> > the idea at a feasibility and utility level.
> >
> > If the scope of your project includes being able to bootstrap systems
> > from the mirror, resolving dependency is much more complex (some
> > packages aren't resolved by dependencies. For instance, the right kernel
> > is select by some logic in Debian-installer).
> > I found some interesting logic in debian-cd package.
>
> You would include "linux-image-" in your package list. That
> isn't really a problem of the tool. Just of the input you need to provide.
> Also you would include everything udeb and everything
> essential/required for bootstraping purposes.
>
I was also thinking along those lines, too.  Same with fam/gamin and other 
packages that have "drop-in" replacements.

> Again flexibility is the key.
>
> > Still, I don't consider that allowing bootstrapping is mandatory. Your
> > project would still be extremely valuable without it. [for those 95% of
> > the people that install from CD, as opposed to netboot].
> >
> > Regards,
> >
> > Franklin
>
> MfG
> Goswin
>
> PS: the essential/required packages can already easily be filtered
> with grep-dctrl.



-- 
Thanks:
Joseph Rawson


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Lucas Nussbaum]

On 17/06/09 at 12:40 +0200, Raphael Hertzog wrote:
> Hello everybody,
> 
> I'll try to do some new proposals based on your feedback. But first let
> me address the topic of the usefulness of the proposal. While there are
> currently no tools making use of this format, I can imagine many
> interesting usage for this information. It starts with the simple stats
> (how many debian specific patch do we use?) and goes on to providing
> a nice web interface where people can browse all patches:
> - check all non-forwarded patches and help forwarding them
> - let upstream developers browse all patches which are not backports
> - let other distributions check all patches which are not debian-specific
> In any case, it's a required step IMO if we want to increase the visibility
> of our patches and ensure they are better reviewed.

It seems that for many people, the scope of this DEP is unclear. Will
our packages be RC-buggy if we don't follow that tagging? Or is it only
a recommended format? I think that this should be clarified. I
personally think that this should be a best practice, strongly
encouraged, but not something mandatory. We might want to move to
something mandatory later, though.

> On Mon, 15 Jun 2009, Mark Brown wrote:
> > On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote:
> > >   * `Signed-off-by` (optional)
> > > 
> > > This field can be used to document the fact that the patch has been
> > > reviewed by one or more persons. It should list their names and
> > > emails in the standard format (similar to the example given for
> > > the `Origin` field), separated by commas if needed.
> > 
> > For the avoidance of confusion I would suggest that this be changed to
> > Reviewed-by - the normal Linux/git Signed-off-by has a specific meaning
> > that needn't include actually doing a code review.
> 
> I started first with "Reviewed-by" and then thought that it was stupid to
> not reuse the name that is already vastly used for a similar purpose. What
> do other people think? I'm fine with both names.

I prefer Reviewed-by.

> On Tue, 16 Jun 2009, Charles Plessy wrote:
> > The dh_make template for debian/copyright induces many developers to put 
> > their
> > packaging work under the GPL, and I have already seen packages whose 
> > license is
> > otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and
> > the patch is non-trivial, then in theory if we want to respect what is 
> > written,
> > we are stuck with a GPL'ed patch. Therefore, we have an optional License 
> > field
> > to make things crystal clear if necessary.
> 
> I have no opposition against an optional License field. Can you try to word a
> description for it?
> 
> On the other side, I'm also not convinced it's really useful... if a patch
> author wants some specific licence different from upstream's license, he
> should make that explicit in the patch itself when he adds his own
> copyright notice.

Right.

> > for your effort to unifiy the format. Personally, I do not mind changing our
> > local format for the DEP3 format as long as we have one release cycle to do 
> > it.
> > Some of our packages have a very slow turnover.
> 
> There's no forced switch planned... it has not technical impact on the
> distribution, so I don't mind if not all packages are converted, after
> it's up to you to see if new lintian warnings annoy you enough or not to
> live with it. :)

See my comment above about this. It should be added to the introduction
of the DEP.

> Now I'll switch to the discussion about the Origin/Status/Patch fields.
> It seems that this set of fields is not as optimized as it could be.
> [...]

I'm fine with what came out of this discussion.

> > Also, from reading this i'm assuming that debian bugs would be identified
> > by "Bug(s)-Debian"?  that seems a bit unwieldly, esp given that there will
> > likely be more references to debian bugs than upstream/cross-stream bugs.
> > Maybe we should also add a special shorthand for "Closes: #nnn" or similar?
> > 
> > My personal preference is that Debian gets "Bug" and there's a seperate
> > "Bug(s)-Upstream" field, but maybe there are also arguments to the
> > contrary?
> 
> One of the goals is also to make it easier to share patches among
> distribution vendors. So I don't really like to make the format too much
> Debian-centric.
> 
> > > What about using Debian: (like Ubuntu's Patch Tagging Guidelines) to
> > > indicate which Debian bug is fixed by this patch?
> > 
> > Debian: could be considered a shorthand alias for Bug-Debian maybe?  I
> > guess that could also address the above issue that i mentioned.
> 
> See my answer to Lucas.

Well, you didn't answer my point:
> We could have Debian: for the Debian bug, and Bug-(Gnome|KDE|..) for
> other projects.

My concern is that Ubuntu already has a policy like this
(https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines). I
would really like ours to be compatible with theirs, so patches 

Re: RFC: DEP-3: Patch Tagging Guidelines

[Josselin Mouette]

Le mercredi 17 juin 2009 à 12:40 +0200, Raphael Hertzog a écrit :
>* `Bug-` or `Bug` (optional)
>  
> -It contains one or more URLs (space separated) pointing to the related 
> bugs
> -(possibly fixed by the patch). The `Bug` field is reserved
> -for the bug URL(s) in the upstream bug tracker.
> +It contains one URL pointing to the related bug (possibly fixed by the
> +patch). The `Bug` field is reserved for the bug URL in the upstream
> +bug tracker. Those fields can be used multiple times if several
> +bugs are concerned.

It’s already better, but for more readability, would it be possible to
have a registered list of bug tracking aliases? For example:
Bug-Debian: #12345
Bug-Ubuntu: #2356
Bug-GNOME: #5671

Otherwise, I appreciate the proposed changes. They make it less of a
problem if the information in the package is not up-to-date and follow
our maintenance process closely.

-- 
 .''`.  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: RFC: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Fri, 19 Jun 2009, Lucas Nussbaum wrote:
> > distribution, so I don't mind if not all packages are converted, after
> > it's up to you to see if new lintian warnings annoy you enough or not to
> > live with it. :)
> 
> See my comment above about this. It should be added to the introduction
> of the DEP.

Ok. I added:

--- a/web/deps/dep3.mdwn
+++ b/web/deps/dep3.mdwn
@@ -33,6 +33,17 @@ first step is to include those information in the patches 
when th
 available so that tools like the [Patch Tracking
 System](http://patch-tracking.debian.net) can display them.
 
+Scope and application
+-
+
+The usage of this format is highly recommended but as long as it's not
+endorsed by the Debian policy, it will not be required. It is however
+expected that tools like lintian will be modified to recommend adding
+those information in patches. As the technical impact on package is null,
+there's no need to organize a time-limited transition. All maintainers
+can start using this format while doing their regular uploads, there's no
+need to upload new revisions of packages just for adding those
+information.
 
 Structure
 -

> > > Debian: could be considered a shorthand alias for Bug-Debian maybe?  I
> > > guess that could also address the above issue that i mentioned.
> > 
> > See my answer to Lucas.
> 
> Well, you didn't answer my point:
> > We could have Debian: for the Debian bug, and Bug-(Gnome|KDE|..) for
> > other projects.
> 
> My concern is that Ubuntu already has a policy like this
> (https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines). I
> would really like ours to be compatible with theirs, so patches can
> freely be copied between Ubuntu and Debian. Having a different format
> sounds like a very bad idea. Have you tried contacting the people
> involved in the Ubuntu policy? It might be possible to change it.

I did not contact them yet. I expect that they will follow the outcome of
this DEP otherwise they would have to patch lintian to support the
differing field and it seems counter-productive.

I am perfectly aware that this DEP is not 100% compatible to their format
and this field is only one difference, there are others (the
way we handle the DebianSpecific tagging). So I'm not sure that we have to
do something special here.

Anyway, I'll send them a mail so that they can state their opinion here.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Paul Wise]

2009/6/19 Josselin Mouette :

> It’s already better, but for more readability, would it be possible to
> have a registered list of bug tracking aliases? For example:
>        Bug-Debian: #12345
>        Bug-Ubuntu: #2356
>        Bug-GNOME: #5671

Personally I'd prefer URLs (for all bugs, including Debian ones) for
the simple reason that no additional information is needed to access
the bugs.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Fri, 19 Jun 2009, Josselin Mouette wrote:
> Le mercredi 17 juin 2009 à 12:40 +0200, Raphael Hertzog a écrit :
> >* `Bug-` or `Bug` (optional)
> >  
> > -It contains one or more URLs (space separated) pointing to the related 
> > bugs
> > -(possibly fixed by the patch). The `Bug` field is reserved
> > -for the bug URL(s) in the upstream bug tracker.
> > +It contains one URL pointing to the related bug (possibly fixed by the
> > +patch). The `Bug` field is reserved for the bug URL in the upstream
> > +bug tracker. Those fields can be used multiple times if several
> > +bugs are concerned.
> 
> It’s already better, but for more readability, would it be possible to
> have a registered list of bug tracking aliases? For example:
> Bug-Debian: #12345
> Bug-Ubuntu: #2356
> Bug-GNOME: #5671

It should be possible. I see one problem here though. Bug-Gnome is really
"Bug" because it's the upstream bug. While we can have an URL mapping for
each vendor, it's not possible for the non-qualified entry used for the
upstream case.

> Otherwise, I appreciate the proposed changes. They make it less of a
> problem if the information in the package is not up-to-date and follow
> our maintenance process closely.

Thanks for the feedback.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Lucas Nussbaum]

On 19/06/09 at 10:49 +0200, Raphael Hertzog wrote:
> > My concern is that Ubuntu already has a policy like this
> > (https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines). I
> > would really like ours to be compatible with theirs, so patches can
> > freely be copied between Ubuntu and Debian. Having a different format
> > sounds like a very bad idea. Have you tried contacting the people
> > involved in the Ubuntu policy? It might be possible to change it.
> 
> I did not contact them yet. I expect that they will follow the outcome of
> this DEP otherwise they would have to patch lintian to support the
> differing field and it seems counter-productive.

That sounds like a pretty bad way to force them to make changes to an
existing policy.
-- 
| 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: RFC: DEP-3: Patch Tagging Guidelines

[Josselin Mouette]

Le vendredi 19 juin 2009 à 11:03 +0200, Lucas Nussbaum a écrit :
> > I did not contact them yet. I expect that they will follow the outcome of
> > this DEP otherwise they would have to patch lintian to support the
> > differing field and it seems counter-productive.
> 
> That sounds like a pretty bad way to force them to make changes to an
> existing policy.

It is just normal that such things happen given how the development
process of Ubuntu works.

When upstream implements something for which I have already a patch but
in a different way, I’m not going to complain to them if I have not
bothered earlier to forward my patch and discuss it with them so that it
is integrated. The same reasoning applies here.

-- 
 .''`.  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: RFC: DEP-3: Patch Tagging Guidelines

[Josselin Mouette]

Le vendredi 19 juin 2009 à 10:55 +0200, Raphael Hertzog a écrit :
> > It’s already better, but for more readability, would it be possible to
> > have a registered list of bug tracking aliases? For example:
> > Bug-Debian: #12345
> > Bug-Ubuntu: #2356
> > Bug-GNOME: #5671
> 
> It should be possible. I see one problem here though. Bug-Gnome is really
> "Bug" because it's the upstream bug. While we can have an URL mapping for
> each vendor, it's not possible for the non-qualified entry used for the
> upstream case.

I don’t think one of these entries should be qualified as “the”
canonical upstream bug.

When I forward a bug to epiphany, if I add a Bug: pointing to GNOME,
later it can be forwarded by them to Mozilla/Webkit because the patch
turns out to be a workaround for a bug in the engine. That would make
suddenly the Bug field turn into a Bug-GNOME, and a new Bug field would
be introduced, pointing to Mozilla/Webkit?

I think it’s bad design to rely on too much expectations based on a
particular case. The only thing that’s generic is that patches are
related to bugs that can lie in various trackers.

-- 
 .''`.  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: RFC: DEP-3: Patch Tagging Guidelines

[Mark Brown]

On Wed, Jun 17, 2009 at 12:40:01PM +0200, Raphael Hertzog wrote:

> On Mon, 15 Jun 2009, Mark Brown wrote:
> > On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote:
> > >   * `Signed-off-by` (optional)

> > For the avoidance of confusion I would suggest that this be changed to
> > Reviewed-by - the normal Linux/git Signed-off-by has a specific meaning
> > that needn't include actually doing a code review.

> I started first with "Reviewed-by" and then thought that it was stupid to
> not reuse the name that is already vastly used for a similar purpose. What
> do other people think? I'm fine with both names.

My point here is that Signed-off-by is widely used for a *different*
purpose.


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Guido Günther]

Hi Raphaël,
On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote:
> Hello,
> 
> please find below a first draft of DEP-3 that I called Patch Tagging
> Guidelines. The idea is to standardize a set of meta-information to embed
> in patches that we apply. Please review, share your comments and ideas of
> enhancements.
Having this kind of information in patches if useful. Those of us that
maintain their quilt patches on patch-queue branches in git have most of
the information already autogenerated by git-format-patch:

$ cat 0004-fix-Debian-specific-path-to-hvm-loader.patch
From: Guido Guenther 
Date: Thu, 26 Feb 2009 14:29:58 +0100
Subject: [PATCH] fix Debian specific path to hvm loader

Closes: #517059
---
 src/xen_internal.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/xen_internal.c b/src/xen_internal.c
...

So 'Description' (Subject), 'Bug' (Closes), Signed-Of-By, Origin
(Author) are already there, some of them already being used by other
tools (git-dch). Wouldn't it make sense to choose (or at least allow
for) a format that's compatbile with what git-format-patch generates?
Cheers,
 -- Guido


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Fri, 19 Jun 2009, Josselin Mouette wrote:
> > It should be possible. I see one problem here though. Bug-Gnome is really
> > "Bug" because it's the upstream bug. While we can have an URL mapping for
> > each vendor, it's not possible for the non-qualified entry used for the
> > upstream case.
> 
> I don’t think one of these entries should be qualified as “the”
> canonical upstream bug.
> 
> When I forward a bug to epiphany, if I add a Bug: pointing to GNOME,
> later it can be forwarded by them to Mozilla/Webkit because the patch
> turns out to be a workaround for a bug in the engine. That would make
> suddenly the Bug field turn into a Bug-GNOME, and a new Bug field would
> be introduced, pointing to Mozilla/Webkit?

No, the patch is against epiphany even if it's a work-around
for a mozilla/webkit bug (so it's always "Bug"). You could add a
Bug-Mozilla: if you wanted but I don't see that as a necessity. The
(epiphany|upstream) bug entry will already contain that information in
most cases.

> I think it’s bad design to rely on too much expectations based on a
> particular case. The only thing that’s generic is that patches are
> related to bugs that can lie in various trackers.

And a patch applies to a particular software. That software is what we
consider as "upstream" compared to us.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Sune Vuorela]

On 2009-06-19, Raphael Hertzog  wrote:
> +Scope and application
> +-
> +
> +The usage of this format is highly recommended but as long as it's not
> +endorsed by the Debian policy, it will not be required. It is however

"And there is no plan to make it required in the future"

> +expected that tools like lintian will be modified to recommend adding
> +those information in patches. As the technical impact on package is null,

Please do not decrease the usability of lintian even further. In linitan
speak, this should be a "pedantic" tag at most.

>  Structure
>  -

I think it should be much more focused on "Please add the following
information to your patches: What it does, where you got it from, who
wrote it" and so on. and a paragraph about "This is a way of organizing
this information to present it in a nice formatted way for interested
upstreams, other distributions and other consumers of patches"

If people choose to use this new format, tools should choke/warn if there 
was more foo: bar fields in the patch than in the specification.

I will have patches with headers like 
qt-bugs@ issue: 123
applied: yes
http://patch-tracking.debian.net/patch/series/view/qt4-x11/4.5.1-2/0225-invalidate-tabbar-geometry-on-refresh.patch
for example

and more such custom headers. And that must be fully valid.

/Sune


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

Re: Bug#533589: ITP: bt747 -- GPS data logger software, allows download, convert, and configure MTK Chipset Based Devices.

[David Paleino]

Hello,

On Fri, 19 Jun 2009 00:30:31 -0500, Gustavo Andrés Angulo wrote:

> This is a GPS data logger software, allows download, convert, and configure
> MTK Chipset Based Devices.

I own an iBlue 747a+ device, MTK-based, so here are some questions for you (I'm
currently using mtkbabel)

> # Download recorded position data from GPS Data Loggers based on the MTK
> chipset.
> # Configure MTK Chipset Based Devices and Loggers

These are covered by mtkbabel too ;).
Regarding other points:

> [..]
> # Supports handheld devices (Palm, WinCE, Mobile Phones supporting Java
> (J2ME))

In what way? Does it have some "client" software for those devices?

> # Supports Desktops (Windows, MacOSX, Linux flavors)

Err.. maybe that's not much important for us, I suppose:)

> # Upload AGPS(EPO) data to MTK II Chipset Based Devices and Loggers

Can it also download AGPS data from the Internet?


Thank you,
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: RFC: DEP-3: Patch Tagging Guidelines

[Lucas Nussbaum]

On 19/06/09 at 11:14 +0200, Josselin Mouette wrote:
> Le vendredi 19 juin 2009 à 11:03 +0200, Lucas Nussbaum a écrit :
> > > I did not contact them yet. I expect that they will follow the outcome of
> > > this DEP otherwise they would have to patch lintian to support the
> > > differing field and it seems counter-productive.
> > 
> > That sounds like a pretty bad way to force them to make changes to an
> > existing policy.
> 
> It is just normal that such things happen given how the development
> process of Ubuntu works.
> 
> When upstream implements something for which I have already a patch but
> in a different way, I’m not going to complain to them if I have not
> bothered earlier to forward my patch and discuss it with them so that it
> is integrated. The same reasoning applies here.

I agree that it was a bad thing that Ubuntu developers developed that
policy without discussing it with Debian, or even mentionning it to
Debian. That's not a reason for us to behave equally badly.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: apt-get wrapper for maintaining Partial Mirrors

[Tzafrir Cohen]

On Fri, Jun 19, 2009 at 01:52:43AM -0500, Joseph Rawson wrote:

> would be much more interested in making a tool that would make it easier to 
> manage local/partial debian mirrors (i.e. one that helped resolve the 
> dependencies), rather than have an apt-get wrapper.  I also think that once 
> such a tool is made, it would make it easier to build an apt-get wrapper that 
> works with it.  I don't think that viewing the problem with an "apt-get 
> wrapper" solution is the best way to approach it, but I do think that it 
> would be valuable once the underlying problems are solved.

And reprepro does not fit the bill because?

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Andrea Bolognani]

On Wed, 17 Jun 2009 12:40:01 +0200
Raphael Hertzog  wrote:

> > For the avoidance of confusion I would suggest that this be changed to
> > Reviewed-by - the normal Linux/git Signed-off-by has a specific meaning
> > that needn't include actually doing a code review.
> 
> I started first with "Reviewed-by" and then thought that it was stupid to
> not reuse the name that is already vastly used for a similar purpose. What
> do other people think? I'm fine with both names.

Vastly used in the git world, not as vastly used outside of it. Reviewed-by
conveys the same information and is more easily understandable IMHO.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


pgpDQfuEuDkPi.pgp
Description: PGP signature

Re: RFC: DEP-3: Patch Tagging Guidelines

[Josselin Mouette]

Le vendredi 19 juin 2009 à 10:55 +0200, Raphael Hertzog a écrit :
> > It’s already better, but for more readability, would it be possible to
> > have a registered list of bug tracking aliases? For example:
> > Bug-Debian: #12345
> > Bug-Ubuntu: #2356
> > Bug-GNOME: #5671
> 
> It should be possible. I see one problem here though. Bug-Gnome is really
> "Bug" because it's the upstream bug. While we can have an URL mapping for
> each vendor, it's not possible for the non-qualified entry used for the
> upstream case.

BTW to solve this, it is only needed to accept a little change in the
accepted syntax:
Bug-Ubuntu: #12345
Bug: GNOME #5671

-- 
 .''`.  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: RFC: DEP-3: Patch Tagging Guidelines

[Josselin Mouette]

Le vendredi 19 juin 2009 à 10:05 +, Sune Vuorela a écrit :
> > +The usage of this format is highly recommended but as long as it's not
> > +endorsed by the Debian policy, it will not be required. It is however
> 
> "And there is no plan to make it required in the future"

What is the point of introducing this spec if it is not made mandatory
at some point in the future?

-- 
 .''`.  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: RFC: DEP-3: Patch Tagging Guidelines

[Charles Plessy]

Le Wed, Jun 17, 2009 at 12:40:01PM +0200, Raphael Hertzog a écrit :
> On Tue, 16 Jun 2009, Charles Plessy wrote:
> > The dh_make template for debian/copyright induces many developers to put 
> > their
> > packaging work under the GPL, and I have already seen packages whose 
> > license is
> > otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and
> > the patch is non-trivial, then in theory if we want to respect what is 
> > written,
> > we are stuck with a GPL'ed patch. Therefore, we have an optional License 
> > field
> > to make things crystal clear if necessary.
> 
> I have no opposition against an optional License field. Can you try to word a
> description for it?
> 
> On the other side, I'm also not convinced it's really useful... if a patch
> author wants some specific licence different from upstream's license, he
> should make that explicit in the patch itself when he adds his own
> copyright notice.

Hi Raphaël,

if it is obvious for everybody that any patch for a given file is implicitely
licensed under the same license as the file, then the License: field is not
necessary. This of course makes people releasing some code under non-free terms
when they prepare a patch for non-free packages for instance, which in case of
a significant contribution could potentially be an obstacle to a relicensing to
a free license if the patch is accepted upstream and author can not be reached
later. But this is a corner case that can be resolved with a comment in the
patch or by other means.

At your option, here is nevertheless a description.

License (optional): indicates the license under which the patch is released.
Note that trivial works are anyway not copyrightable, and that in the vast
majority of the cases it is expected that the patch is released under the same
terms as the files it applies to. Nevertheless, you can use this field to
clarify ambiguous situations, for instance when the license of the packaging
work is not the same as the packaged program, or when you would like to give
permission to the upstream copyright holder(s) to relicense the patched work
later (in case the current license is problematic).


PS: I also prefer Reviewed-by to Signed-off.

Have a nice week-end,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


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

Restricting binary (sub)package from single source package

[Mathieu Malaterre]

Hi,

  Could someone let me know what I should do when a binary package is
restricting me to a subset of architecture ? For instance libvtkgdcm
requires libvtk5-dev, but not libgdcm-tools. How can I express that in
my single control file for gdcm ?

Ref:
http://packages.qa.debian.org/g/gdcm.html

Thanks

-- 
Mathieu


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Giacomo Catenazzi]

Josselin Mouette wrote:
> Le vendredi 19 juin 2009 à 10:05 +, Sune Vuorela a écrit :
>>> +The usage of this format is highly recommended but as long as it's not
>>> +endorsed by the Debian policy, it will not be required. It is however
>> "And there is no plan to make it required in the future"
> 
> What is the point of introducing this spec if it is not made mandatory
> at some point in the future?

compare internet:
- it work fine
- it doesn't mandate any RFC
- it would be a mess not having RFC.

Personally I think we are too far to mandate DEP-3
(and BTW the subject has "guideline", not "requirements"):
- we need to use the new source format
- we need to have experiences with new dpkg-source and
  new tagging, and to found problem
- and probably new discussion about real problems.

so, IMHO we need a complete guidelines and start to use
it widely. It should not be complete or 100% precise
(so not yet the right time for bike-shading).
Then from time to time we could include some mature items
in the policy and discuss improvements.

Anyway I think we will need a guideline in parallel to
the policy: the guideline could explain better the problem
and the solutions, future directions, recommendations etc.
then the policy.

ciao
cate



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

Fwd: On Wireshark and network capture in general

[Jaap Keuter]

As suggested by Thijs forwarded to the  dev list.
Please CC me as I' m not on the list.

Regards
Jaap

Begin forwarded message:


From: "Jaap Keuter" 
Date: 17 juni 2009 17:17:53 GMT+02:00
To: secur...@debian.org
Subject: On Wireshark and network capture in general




Hi,

I'm contacting you as I got thinking about network capture and the
security implications of that.

First of all, I'm a Wireshark core developer and Debian user, hence  
my interest.


What I've noticed is that Debian (still) requires the user to run
Wireshark with root credentials in order to be able to launch a  
network

capture. Otherwise the network interfaces won't even be visible.
This problem, running a massive GUI application with root  
credentials, was
identified long ago and addressed as such. The core capture  
functionality
was isolated in a capture child, so the rest (dissection, GUI, etc)  
could

be run as a normal user. This only(ahem) requires the capture engine
(dumpcap) to be installed setuid root.

This is possible, the debian packaging files in the Wireshark source
tarball provide for this, but it opens a whole other can-o-worms.  
Without
requiring root credentials everyone can start network captures,  
something

that may be less desirable.

This issue of course holds true for all network capture  
applications, so a
more generic approach would be desirable. A possible way to address  
this

is to create a group with network capture privileges, and any eligible
user would be added to that group. This provides the administrator  
tight
control over the network capture capabilities of the systems users,  
while

users do not have to run network capture as root.

Now, I accept this issue and solution to be declared total nonsense.  
But

then again, what do I know.

Thanks for your time,
Jaap

Re: apt-get wrapper for maintaining Partial Mirrors

[Joseph Rawson]

On Friday 19 June 2009 05:09:31 Tzafrir Cohen wrote:
> On Fri, Jun 19, 2009 at 01:52:43AM -0500, Joseph Rawson wrote:
> > would be much more interested in making a tool that would make it easier
> > to manage local/partial debian mirrors (i.e. one that helped resolve the
> > dependencies), rather than have an apt-get wrapper.  I also think that
> > once such a tool is made, it would make it easier to build an apt-get
> > wrapper that works with it.  I don't think that viewing the problem with
> > an "apt-get wrapper" solution is the best way to approach it, but I do
> > think that it would be valuable once the underlying problems are solved.
>
> And reprepro does not fit the bill because?
>
It fits part of the bill, as it's an excellent tool for maintaining a 
repository, but it doesn't resolve dependencies (nor should it).

> --
> Tzafrir Cohen | tzaf...@jabber.org | VIM is
> http://tzafrir.org.il || a Mutt's
> tzaf...@cohens.org.il ||  best
> ICQ# 16849754 || friend



-- 
Thanks:
Joseph Rawson


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

Re: apt-get wrapper for maintaining Partial Mirrors

[Joseph Rawson]

On Friday 19 June 2009 00:27:06 Goswin von Brederlow wrote:
> Joseph Rawson  writes:
> > BTW, the subject of this thread is "apt-get wrapper for maintaining
> > Partial Mirrors".  The solution I'm proposing is "a simple tool for
> > maintaining Partial Mirrors" (which could possibly be wrapped by apt-get
> > later).
> >
> > I think that just pursuing an "apt-get wrapper" leads to some
> > complications that could be avoided by creating the "partial mirror tool"
> > first, then looking at wrapping it later.  One complication might be "how
> > do handle apt-get remove", and another might be "how to handle sid
> > libraries that disappear from official repository, yet local machines
> > must have them".
>
> Ahh, so maybe I completly misread that part.
>
> Do you mean a wrapper around apt-get so that "apt-get install foo" on
> any client would automatically add "foo" to the list of packages being
> mirrored on the server?
>
> If so then you can configure a post invoke hook in apt that will copy
> the dpkg status file of the host to the server [as status.$(hostname)]
> and then use those on the server to generate the filter for
> reprepro. I think I still have a script for that somewhere but it is
> easy enough to rewrite.
>
When you mentioned the word "hook", I was reminded of reprepro's ability to 
use hooks.  I started testing using a ListHook script with reprepro.  I'm 
attaching the script so you can see the general idea.  The script doesn't do 
anything effective, but may be helpful in understanding more of the way I'm 
approaching the idea.  Please don't laugh too hard, I'm just playing with 
ideas now.

Among other possible reasons, there are two main reasons why this particular 
approach won't work.  One reason is that the ListHook calls a script for each 
list independently.  So, if you have a package in contrib that depends on a 
package in main, like many do, the dependency won't be resolved using this 
method.  Also, the germinator object only handles one arch at a time, so if 
you are mirroring multiple arches, you need to use a germinator object for 
each one.  One way that this problem can be countered is by running a simple 
server that holds the germinator object, and the script that ListHook 
executes would communicate with that server.  Then the server would "grow" 
the seeds and create the filter lists that would be used by reprepro.

I tried this approach because I didn't see the sense in downloading the 
packages lists more than necessary.  The way I was thinking before was to 
seed germinate (which would download the package lists), parse the output, 
create filter lists from that output, send them to reprepro, and call 
reprepro to update.  This forces all of those package lists to be downloaded 
twice, which was something I tried to avoid with this short experiment.

It also seems to be somewhat difficult to "plant the seeds" into germinate 
manually.  I'm sure that problem could be solved by looking through the code 
a bit longer.

> MfG
> Goswin



-- 
Thanks:
Joseph Rawson


testgerm
Description: application/python


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

Re: Fwd: On Wireshark and network capture in general

[Lionel Elie Mamane]

On Fri, Jun 19, 2009 at 12:54:48PM +0200, Jaap Keuter wrote:

> I'm contacting you as I got thinking about network capture and the
> security implications of that.

> What I've noticed is that Debian (still) requires the user to run
> Wireshark with root credentials in order to be able to launch a
> network capture.

> The core capture functionality was isolated in a capture child, so
> the rest (dissection, GUI, etc) could be run as a normal user. This
> only(ahem) requires the capture engine (dumpcap) to be installed
> setuid root.

How about one of the following:

 - have the gui application (run as user) use gksu to launch dumpcap

 - a wrapper script that launches dumpcap as current effective user
   (expected to be root) and the gui as $SUDO_USER (hmmm... too
   specific to usage of sudo, bad idea).

 - a wrapper script that launches dumpcap through su/sudo and the gui
   "normally"

 - a wrapper application (not suid), expected to be launched as root,
   that fork()/exec()'s dumpcap and then drops all privileges and then
   exec()'s the gui?

-- 
Lionel


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

Bug#533623: ITP: haskell-polyparse -- A variety of alternative parser combinator libraries for Haskell

[Erik de Castro Lopo]

Package: wnpp
Severity: wishlist
Owner: Erik de Castro Lopo 


* Package name: haskell-polyparse
  Version : 1.3
  Upstream Author : Malcolm Wallace, Graham Hutton and Erik Meijer
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/polyparse
* License : LGPL
  Programming Lang: Haskell
  Description : A variety of alternative parser combinator libraries for 
Haskell

 A variety of alternative parser combinator libraries, including the original
 HuttonMeijer set. The Poly sets have features like good error reporting,
 arbitrary token type, running state, lazy parsing, and so on. Finally,
 Text.Parse is a proposed replacement for the standard Read class, for better
 deserialisation of Haskell values from Strings.



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

Re: Fwd: On Wireshark and network capture in general

[Josselin Mouette]

Le vendredi 19 juin 2009 à 12:54 +0200, Jaap Keuter a écrit :
> > What I've noticed is that Debian (still) requires the user to run
> > Wireshark with root credentials in order to be able to launch a
> > network
> > capture. Otherwise the network interfaces won't even be visible.
> > This problem, running a massive GUI application with root
> > credentials, was
> > identified long ago and addressed as such. The core capture
> > functionality
> > was isolated in a capture child, so the rest (dissection, GUI, etc)
> > could
> > be run as a normal user. This only(ahem) requires the capture engine
> > (dumpcap) to be installed setuid root.

I think it’s just as bad an idea to launch dumpcap setuid root as it is
to launch the GUI as root.

Please consider supporting PolicyKit to communicate between the frontend
and the backend instead. This way the backend doesn’t have to be
installed setuid root, and the user is authenticated before starting it.

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: RFC: DEP-3: Patch Tagging Guidelines

[Josselin Mouette]

Le vendredi 19 juin 2009 à 13:01 +0200, Giacomo Catenazzi a écrit :
> > What is the point of introducing this spec if it is not made mandatory
> > at some point in the future?
> 
> so, IMHO we need a complete guidelines and start to use
> it widely. It should not be complete or 100% precise
> (so not yet the right time for bike-shading).
> Then from time to time we could include some mature items
> in the policy and discuss improvements.

“Some point in the future” does not have to be tomorrow. But if, right
from the start, the guidelines are designed so that they can’t be made
mandatory later, they must be broken somehow.

-- 
 .''`.  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: RFC: DEP-3: Patch Tagging Guidelines

[Giacomo A. Catenazzi]

Josselin Mouette wrote:

Le vendredi 19 juin 2009 à 13:01 +0200, Giacomo Catenazzi a écrit :

What is the point of introducing this spec if it is not made mandatory
at some point in the future?

so, IMHO we need a complete guidelines and start to use
it widely. It should not be complete or 100% precise
(so not yet the right time for bike-shading).
Then from time to time we could include some mature items
in the policy and discuss improvements.


“Some point in the future” does not have to be tomorrow. But if, right
from the start, the guidelines are designed so that they can’t be made
mandatory later, they must be broken somehow.


I'm not so sure, but it is not so important that we doesn't agree on
this point.

but on DEP-3?

No!

I think DEP-3 development should be stopped soon, and we should apply it.
Any thing that it will be included in the policy, it will not be DEP-3,
but based on DEP-3.

A step toward a standardization, but not a part of standard itself.

In this case I think we should use DEP-3 without discussion every details:
we need a larger user base, then we will discuss details for standardization,
but not now.

I think this was the original misunderstanding.

ciao
cate


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Fri, 19 Jun 2009, Sune Vuorela wrote:
> On 2009-06-19, Raphael Hertzog  wrote:
> > +Scope and application
> > +-
> > +
> > +The usage of this format is highly recommended but as long as it's not
> > +endorsed by the Debian policy, it will not be required. It is however
> 
> "And there is no plan to make it required in the future"

I won't put this in here. I have no reason to stop people from making it
mandatory in the future. You will have to re-raise your concerns when the
debian-policy discussion happens (if it happens).

> > +expected that tools like lintian will be modified to recommend adding
> > +those information in patches. As the technical impact on package is null,
> 
> Please do not decrease the usability of lintian even further. In linitan
> speak, this should be a "pedantic" tag at most.

I will leave that up to lintian maintainers.

> If people choose to use this new format, tools should choke/warn if there 
> was more foo: bar fields in the patch than in the specification.
> 
> I will have patches with headers like 
> qt-bugs@ issue: 123
> applied: yes
> http://patch-tracking.debian.net/patch/series/view/qt4-x11/4.5.1-2/0225-invalidate-tabbar-geometry-on-refresh.patch
> for example
> 
> and more such custom headers. And that must be fully valid.

Leave a blank line after the official headers and you'll be able to put
whatever you want. Otherwise we can also decide to have "X-" for prefix
for custom headers if you prefer.

On Fri, 19 Jun 2009, Giacomo Catenazzi wrote:
> Personally I think we are too far to mandate DEP-3
> (and BTW the subject has "guideline", not "requirements"):
> - we need to use the new source format
> - we need to have experiences with new dpkg-source and
>   new tagging, and to found problem
> - and probably new discussion about real problems.

Well, no, we don't need any of that. We already have experience with
handling patches... and we are able to define a good format now that
should not need to evolve much in the future.

> Then from time to time we could include some mature items
> in the policy and discuss improvements.

While it's possible that some gradual improvements happen over time, the
day where policy officialize this, I expect it will be mostly cut & paste
of what we have since policy should document current practice when
something is widely used already.

On Fri, 19 Jun 2009, Giacomo A. Catenazzi wrote:
> In this case I think we should use DEP-3 without discussion every details:
> we need a larger user base, then we will discuss details for standardization,
> but not now.

I prefer we take the time to think it thoroughly so that we don't have to
come back to it later. It's easier to standardize something that works and
has seen no need for substantial changes since X months rather than a
recommendation that changes every other month because it has not been well
fleshed out.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: apt-get wrapper for maintaining Partial Mirrors

[Bernhard R. Link]

* Joseph Rawson  [090619 13:23]:
> On Friday 19 June 2009 05:09:31 Tzafrir Cohen wrote:
> > On Fri, Jun 19, 2009 at 01:52:43AM -0500, Joseph Rawson wrote:
> > > would be much more interested in making a tool that would make it easier
> > > to manage local/partial debian mirrors (i.e. one that helped resolve the
> > > dependencies), rather than have an apt-get wrapper.  I also think that
> > > once such a tool is made, it would make it easier to build an apt-get
> > > wrapper that works with it.  I don't think that viewing the problem with
> > > an "apt-get wrapper" solution is the best way to approach it, but I do
> > > think that it would be valuable once the underlying problems are solved.
> >
> > And reprepro does not fit the bill because?
> >
> It fits part of the bill, as it's an excellent tool for maintaining a
> repository, but it doesn't resolve dependencies (nor should it).

Actually, I'm quite open to having some depedency handling in reprepro
and already have written some simple prototype for a related project.
The problem is that calculating a simple cover of selected packages in
the dependency graph is not enough:

Usually the cover is not unique but the existance of alternatives in
dependencies causes multiple solutions. For an initial checkout that
is no problem, as one can choose one some set by some pseudo-random
selection (like "packages with alphabetically lower names get the
first depedency in an alternative tried first" and similar things
for virtual packages). The problem is that no such criterion can be
stable against changes in the partially mirrored distribution.

So in this cases knowing what packages upstream has and what packages
are wanted is not enough but one has to take into account what packages
are currently selected. And a simply covering no longer is enough but
one needs a full resolver knowing which installed states can be easily
brought to which other installed states. (and things get even more
complicated if the currently mirrored packages allow multiple subsets
which clients using this repository might have installed)...

Hochachtungsvoll,
Bernhard R. Link


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

mpg321 package adoption

[Nanakos Chrysostomos]

Dear all,
can you please help to find the way which i can adopt an orphaned 
package. The package has recently been adopted by wnnp.

The package i want to adopt is mpg321.

Thanks in advance for your help,
Chris.


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

Re: Fwd: On Wireshark and network capture in general

[Michael Stone]

On Fri, Jun 19, 2009 at 01:56:05PM +0200, Josselin Mouette wrote:

Le vendredi 19 juin 2009 à 12:54 +0200, Jaap Keuter a écrit :

> What I've noticed is that Debian (still) requires the user to run
> Wireshark with root credentials in order to be able to launch a
> network
> capture. Otherwise the network interfaces won't even be visible.
> This problem, running a massive GUI application with root
> credentials, was
> identified long ago and addressed as such. The core capture
> functionality
> was isolated in a capture child, so the rest (dissection, GUI, etc)
> could
> be run as a normal user. This only(ahem) requires the capture engine
> (dumpcap) to be installed setuid root.


I think it’s just as bad an idea to launch dumpcap setuid root as it is
to launch the GUI as root.


Definitely as default for the install. For many people the common case 
is to use wireshark to analyze captures taken by a different tool, and 
there's no reason for them to automatically have anything setuid to 
support that case.


Mike Stone


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Giacomo A. Catenazzi]

Raphael Hertzog wrote:


On Fri, 19 Jun 2009, Giacomo A. Catenazzi wrote:

In this case I think we should use DEP-3 without discussion every details:
we need a larger user base, then we will discuss details for standardization,
but not now.


I prefer we take the time to think it thoroughly so that we don't have to
come back to it later. It's easier to standardize something that works and
has seen no need for substantial changes since X months rather than a
recommendation that changes every other month because it has not been well
fleshed out.


Yes, but:
- don't over-engineering
- don't wait to much on details (we don't want a debian/control discussion
  over one year)

and:
- most standard are done by/after usage
- we don't know the main problems and errors of "normal DDs" and the
  integration workflow with various vcs tools.

I really think that in one year we need to discuss again about some items
(License field was need? Bug is used correctly? Signed-Off is needed? Forgot
something? Team tags? Are there a lot of template text).

The main idea and structure is already given by DEP-3, and there is no
critical information, so I think it will not confuse user an update,
but such updates will clarify some aspect we now don't see.

ciao
cate


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

Re: Fwd: On Wireshark and network capture in general

[Jonathan Yu]

Maybe we can offer something via debconf during installation to ask
users if they'd like non-root users to access dumpcap. But I guess the
question there is to determine how to provide access to dumpcap (there
were some great ideas discussed above).

Having the GUI run as non-root sounds like a great idea to me, the
less code running setuid 0 the better. And that means the GUI will be
useful for analyzing things that have already been captured, as Mike
mentioned, and you won't need root for that.

So some sort of wrapper when users attempt to launch captures, perhaps
something like gksu to get permission for dumpcap...

On Fri, Jun 19, 2009 at 9:29 AM, Michael Stone wrote:
> On Fri, Jun 19, 2009 at 01:56:05PM +0200, Josselin Mouette wrote:
>>
>> Le vendredi 19 juin 2009 à 12:54 +0200, Jaap Keuter a écrit :
>>>
>>> > What I've noticed is that Debian (still) requires the user to run
>>> > Wireshark with root credentials in order to be able to launch a
>>> > network
>>> > capture. Otherwise the network interfaces won't even be visible.
>>> > This problem, running a massive GUI application with root
>>> > credentials, was
>>> > identified long ago and addressed as such. The core capture
>>> > functionality
>>> > was isolated in a capture child, so the rest (dissection, GUI, etc)
>>> > could
>>> > be run as a normal user. This only(ahem) requires the capture engine
>>> > (dumpcap) to be installed setuid root.
>>
>> I think it’s just as bad an idea to launch dumpcap setuid root as it is
>> to launch the GUI as root.
>
> Definitely as default for the install. For many people the common case is to
> use wireshark to analyze captures taken by a different tool, and there's no
> reason for them to automatically have anything setuid to support that case.
>
> Mike Stone
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
>
>


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

Re: dpkg: error processing gawk (--configure)

[Osamu Aoki]

Hi,

On Thu, Jun 18, 2009 at 10:22:55PM +0200, markus schnalke wrote:
> [2009-06-18 21:03] markus schnalke 
> > 
> > during the installation of `geda' on sid, I received following output:
> > 
> > [...]
> > Setting up gawk (1:3.1.6.dfsg-3) ...
> > update-alternatives: error: alternative nawk can't be slave of awk: it is a 
> > master alternative.
> 
> I had some deeper look and am now sure enough to consider this a bug
> in the package.
> 
> Hence, I filed a bug against gawk.

Just FYI.

alternative system is somewhat flakey.  So before blaming gawk, please
check program itself and other things.

Also, you seem to have problem with nawk per error message.  It is from
mawk package.  See:

$ type nawk
nawk is /usr/bin/nawk
$ dpkg -S /usr/bin/nawk
dpkg: /usr/bin/nawk not found.
$ grep nawk /var/lib/dpkg/info/*
/var/lib/dpkg/info/mawk.postinst:  --slave /usr/bin/nawk nawk /usr/bin/mawk \
/var/lib/dpkg/info/mawk.postinst:  --slave /usr/share/man/man1/nawk.1.gz 
nawk.1.gz /usr/share/man/man1/mawk.1.gz
/var/lib/dpkg/info/mawk.postinst:for badlink in /usr/man/man1/awk.1 
/usr/man/man1/nawk.1 /usr/share/man/man1/awk.1 /usr/share/man/man1/nawk.1; do

Please invstigate and blame package which is causing real problem.
 
> A (maybe too simple) solution is removing alore blamingl `nawk' stuff from
> debian/postinst. Then I can build the package and install it without
> problems.

$ sudo aptitude install gawk
... (I do not get error in stable)
$ grep nawk /var/lib/dpkg/info/*
/var/lib/dpkg/info/gawk.postinst:  --slave /usr/bin/nawk nawk /usr/bin/gawk \
/var/lib/dpkg/info/gawk.postinst:  --slave /usr/share/man/man1/nawk.1.gz 
nawk.1.gz /usr/share/man/man1/gawk.1.gz
/var/lib/dpkg/info/gawk.postinst:for badlink in /usr/man/man1/awk.1 
/usr/man/man1/nawk.1; do
/var/lib/dpkg/info/mawk.postinst:  --slave /usr/bin/nawk nawk /usr/bin/mawk \
/var/lib/dpkg/info/mawk.postinst:  --slave /usr/share/man/man1/nawk.1.gz 
nawk.1.gz /usr/share/man/man1/mawk.1.gz
/var/lib/dpkg/info/mawk.postinst:for badlink in /usr/man/man1/awk.1 
/usr/man/man1/nawk.1 /usr/share/man/man1/awk.1 /usr/share/man/man1/nawk.1; do
$ 

I am not sure but your conclusion seems too quick...

Good luck.

Osamu


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

Re: mpg321 package adoption

[Tzafrir Cohen]

On Fri, Jun 19, 2009 at 03:20:50PM +0300, Nanakos Chrysostomos wrote:
> Dear all,
> can you please help to find the way which i can adopt an orphaned  
> package. The package has recently been adopted by wnnp.
> The package i want to adopt is mpg321.

What does mpg321 do that mpg123 doesn't do?

Originally mpg123 was non-free (and for a long time unmaintained as
well). But this is no longer the case.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend


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

Re: dpkg: error processing gawk (--configure)

[Raphael Hertzog]

On Thu, 18 Jun 2009, markus schnalke wrote:
> Hoi,
> 
> during the installation of `geda' on sid, I received following output:
> 
> [...]
> Setting up gawk (1:3.1.6.dfsg-3) ...
> update-alternatives: error: alternative nawk can't be slave of awk: it is a 
> master alternative.
[...]
> 
> Anyone who can help me / fix the gawk package / knows what the problem
> is ...?

Yes, "rm -f /var/lib/dpkg/alternatives/nawk". The history of package
ugprades has left cruft that confuse update-alternatives (which is now
more strict that it used to be).

I'll push the same work-around in dpkg's preinst as I did for other
packages in the same case.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: mpg321 package adoption

[Nanakos Chrysostomos]

Tzafrir Cohen wrote:

On Fri, Jun 19, 2009 at 03:20:50PM +0300, Nanakos Chrysostomos wrote:
  

Dear all,
can you please help to find the way which i can adopt an orphaned  
package. The package has recently been adopted by wnnp.

The package i want to adopt is mpg321.



What does mpg321 do that mpg123 doesn't do?

Originally mpg123 was non-free (and for a long time unmaintained as
well). But this is no longer the case.

  

Hi,
First of all it uses some other packages as its bases for the mp3 
decoding and audio streaming. Its smaller , simpler and can be 
maintained. It can also be used as a front end for numerous applications 
as already did in later linux versions and flavors.
If the community that already had included this package for so many 
years thinks its obsolete and useless i can live with that!
I have already done a lot of work for the new version according the 
TODO-list and the bug list. I think that 0.2.11 version is ready for 
upload and 0.3 will be ready until the end of the year with new ideas 
and options.


Thank you all for your time reading this mail,
Chris.


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

Re: Bug#533642: dpkg-dev: dpkg-shlibdeps fails on symbols exported by libgcc_s

[Raphael Hertzog]

On Fri, 19 Jun 2009, Christoph Egger wrote:
>   Building the NEW package I'm working on (irrlicht [3]) on my
> ARM(el)[4] box (up-to-date sid pbuilder) causes dpkg-shlibdeps to
> complain about missing symbols [0]. These symbols seem to be some gcc
> internals that should be covered by libgcc_s.so which is reported as
> unused.

Ok, this is getting tricky.

In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462318 Aurélien Jarno
requested all __aeabi_* symbols to be blacklisted as they were supposed
to be internal symbols created by gcc that should not be exported to
symbols files.

As a result of this, libgcc1.symbols does not list all those symbols
even though they are properly exported by the library.

Now it seems that the irrlicht library depends on those symbols
provided by libgcc_s.so.1 (and does not define them locally contrary to
what was seen by Aurélien in libvorbis in #462318) and of course
dpkg-shlibdeps complains because they can't be found in the symbols file.

So should I revert the blacklist entirely? Or should I revert the
blacklist partially? In that case, which symbols must be blacklisted?

For reference the symbols blacklisted are:
# Many armel-specific symbols
$blacklist{"__aeabi_$_"} = 1 foreach (qw(cdcmpeq cdcmple cdrcmple cfcmpeq
cfcmple cfrcmple d2f d2iz d2lz d2uiz d2ulz dadd dcmpeq dcmpge dcmpgt
dcmple dcmplt dcmpun ddiv dmul dneg drsub dsub f2d f2iz f2lz f2uiz f2ulz
fadd fcmpeq fcmpge fcmpgt fcmple fcmplt fcmpun fdiv fmul fneg frsub fsub
i2d i2f idiv idivmod l2d l2f lasr lcmp ldivmod llsl llsr lmul ui2d ui2f
uidiv uidivmod ul2d ul2f ulcmp uldivmod unwind_cpp_pr0 unwind_cpp_pr1
unwind_cpp_pr2 uread4 uread8 uwrite4 uwrite8));

I'm not familiar at all with the armel toolchain so I need assistance
here. That's why I put porters, gcc maintainers and -devel in copy.

Did something change in the toolchain so that binaries start using the
libgcc_s version of those symbols instead of duplicating them in every
binary ?

There's a slight chance that the problem lies in the build options
used by irrlicht but I am unable to verify this possibility. People that
would like to verify this can grab the source package here:
> [3] git://git.debian.org/git/pkg-games/irrlicht.git

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: mpg321 package adoption

[Serafeim Zanikolas]

On Fri, Jun 19, 2009 at 03:20:50PM +0300, Nanakos Chrysostomos wrote [edited]:
> can you please help to find the way which i can adopt an orphaned

In http://www.debian.org/devel/wnpp/ read the parts related to ITA.

-S


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

Re: apt-get wrapper for maintaining Partial Mirrors

[Goswin von Brederlow]

Joseph Rawson  writes:

> On Friday 19 June 2009 00:27:06 Goswin von Brederlow wrote:
>> Joseph Rawson  writes:
>> If so then you can configure a post invoke hook in apt that will copy
>> the dpkg status file of the host to the server [as status.$(hostname)]
>> and then use those on the server to generate the filter for
>> reprepro. I think I still have a script for that somewhere but it is
>> easy enough to rewrite.
> That's good for binaries, but I don't know about the source.  It wasn't long 
> ago that I noticed a problem with reprepro not obtaining the corresponding 
> source packages when you use a filter list taken 
> from  "dpkg --get-selections".  I remember that the source for jigdo wasn't 
> in my partial mirror, because there were no binaries named "jigdo", 
> rather "jigdo-file" and "jigdo-lite".  Since there were no sources with that 
> name, the jigdo source was never mirrored on my partial mirror.  I don't know 
> if that behavior has been fixed now, since there is now a binary named jigdo, 
> instead of jigdo-lite.

My filter first converted the packages listed in the status file(s) to
source package names (packages with different name have a "Source:"
entry) and then output those for sources.

> Also, it's more difficult for the local repository to determine the 
> difference 
> between the automatically selected and manually selected packages in this 
> type of setup, since you would be sending a longer list of "manually selected 
> packages", instead of distinguishing which ones are actually selected.  I 
> guess that it doesn't matter much, as a package would only be removed from 
> the repository once it's not listed on any of the lists.  There were times 
> when I didn't want certain packages to be removed from the repository, 
> regardless of whether they were installed or not, so I used to run xxdiff on 
> the packages files, so the newer ones were added.

Same problem here. Esspecially build-depends. There where a lot of
packages I only needed inside my build chroots and only for the time
of the build. So they never showed up on the mirror. Then I just
resized the mirror partition and mirrored all debs.

> In my way of thinking, I'm not looking to merge upstream repositories 
> together 
> in one repository.  Besides, there are already tools, such as apt-move that 
> would be better for this job.  Long ago, apt-move was the primary tool that I 
> used to keep a local repository, and it worked pretty well, as long as all 
> the machines that were using it were on the same release.
>
> I have found that reprepro is the absolute best tool for maintaining a debian 
> mirror.  The only problem I have with it is when I want to maintain a partial 
> mirror, and I don't want a merged repository, is that I have to spread the 
> packages lists to different places, and when you start adding machines, you 
> start adding more lists to the configuration, when it would probably be 
> better to maintain a set of "master" lists that are generated from the many 
> lists that come from the machines.

Or have a proxy that adds packages that are requested.

MfG
Goswin


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

Re: Bug#533642: dpkg-dev: dpkg-shlibdeps fails on symbols exported by libgcc_s

[Paul Brook]

>Now it seems that the irrlicht library depends on those symbols
>provided by libgcc_s.so.1 (and does not define them locally contrary to
>what was seen by Aurélien in libvorbis in #462318) and of course
>dpkg-shlibdeps complains because they can't be found in the symbols file.
>...
> So should I revert the blacklist entirely? Or should I revert the
> blacklist partially? In that case, which symbols must be blacklisted?

Under normal curcumstances, I'd expect every shared library and application to 
require __aeabi_* from libgcc. Under normal circumstances these will come from  
libgcc_s.so, but if you link with --static-libgcc then you'll get your own 
copy.

These symbols are defined by the EABI and the runtime must supply in some 
form. The EABI is deliberately vague about exactly where/how, but on Linux it 
is normal for these for come from libgcc. However use of these functions is 
entirely optional, hence building them into your library instead of using 
libgcc_s.so is ok (though obviously has the same undesirable consequences as 
any sort of static library).

I'm afraid I have no clue how dpkg-shlibdeps works, so can't really guess what 
the right answer to your blacklist question is.

Paul


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

Bug#533697: ITP: vgmstream -- library for playing streamed audio from video games

[Andres Mejia]

Package: wnpp
Severity: wishlist
Owner: pkg-multimedia-maintain...@lists.alioth.debian.org

* Package name: vgmstream
  Version : r659
  Upstream Author : Adam Gashlin, Fastelbja, Ronny Elfert
* URL : http://vgmstream.sourceforge.net/
* License : ISCL
  Programming Lang: C
  Description : library for playing streamed audio from video games

vgmstream is a library for playing streamed audio from video games. It supports
various sound formats supported by various game consoles such as the PS2, PSX,
and Wii.



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

Bug#533699: ITP: nosefart -- NES sound format player

[Andres Mejia]

Package: wnpp
Severity: wishlist
Owner: pkg-multimedia-maintain...@lists.alioth.debian.org

* Package name: nosefart
  Version : 2.7
  Upstream Author : Matthew Strait 
* URL : http://nosefart.sourceforge.net/
* License : GPL
  Programming Lang: C, C++
  Description : NES sound format player

Nosefart plays NSF (NES sound format) files so you can listen to those old tunes
without actually having to play the games.



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

Re: Bug#533642: dpkg-dev: dpkg-shlibdeps fails on symbols exported by libgcc_s

[Raphael Hertzog]

On Fri, 19 Jun 2009, Paul Brook wrote:
> >Now it seems that the irrlicht library depends on those symbols
> >provided by libgcc_s.so.1 (and does not define them locally contrary to
> >what was seen by Aurélien in libvorbis in #462318) and of course
> >dpkg-shlibdeps complains because they can't be found in the symbols file.
> >...
> > So should I revert the blacklist entirely? Or should I revert the
> > blacklist partially? In that case, which symbols must be blacklisted?
> 
> Under normal curcumstances, I'd expect every shared library and application 
> to 
> require __aeabi_* from libgcc. Under normal circumstances these will come 
> from  
> libgcc_s.so, but if you link with --static-libgcc then you'll get your own 
> copy.

Well, it's been some time since armel started and it's the first time I
see that people complain about this problem. So it's probably not that
frequent that binaries depend on those symbols (or very few people notice
dpkg-shlibdeps warnings in armel build logs).

> These symbols are defined by the EABI and the runtime must supply in some 
> form. The EABI is deliberately vague about exactly where/how, but on Linux it 
> is normal for these for come from libgcc. However use of these functions is 
> entirely optional, hence building them into your library instead of using 
> libgcc_s.so is ok (though obviously has the same undesirable consequences as 
> any sort of static library).

Why do so many library embed them by default? I would have expected that
to be the exception. On armel a quick grep on symbols files shows that
the following packages have some of those symbols embedded:
heartbeat
kexi
libannodex0
libavcodec1d
libavutil1d
libbigloo2.8c
libchicken0
libcob1
libflac8
libgavl0
libgraphicsmagick1
libgs8
libhamlib2
libhdf5-lam-1.6.5-0
libhdf5-mpich-1.6.5-0
libhdf5-serial-1.6.5-0
libinsighttoolkit3.4
libjack0
libldb0
liblo0ldbl
liblo0
libmagick9
libmpcdec3
libmpeg3-1
libmysqlclient15off
libparted1.7-1.symbols
libpostproc1d
libpulsecore5
libqof1
libruby1.8
libruby1.9
libsefs1
libsilc-1.1-2
libsofia-sip-ua0
libtokyocabinet2
libtrace3
libvips12
ntop
showimg

> I'm afraid I have no clue how dpkg-shlibdeps works, so can't really guess 
> what 
> the right answer to your blacklist question is.

The only role of this blacklist is to not pollute symbols files with
symbols that are only internal to the toolchain (and that are not used by
external binaries). The idea was that those symbols were not used like
traditional libraries and were only needed by the code generated by gcc
(i.e. some sort of local lookup and not over an external lib).

In this list you have symbols like "__bss_end__", "_GLOBAL_OFFSET_TABLE_".
See
http://git.debian.org/?p=dpkg/dpkg.git;a=blob;f=scripts/Dpkg/Shlibs/SymbolFile.pm;hb=master
for more examples.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Bug#533709: ITP: libcgroup -- Initial package request

[Simmons, Christopher]

Package: libcgroup
Version: 0.33
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

*** Please type your report below this line *** 
I wish to work on creating a debian package for libcgroup-0.33

License: LGPL

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

Kernel: Linux 2.6.26-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#533708: ITP: libhugetlbfs -- Initial package request

[Simmons, Christopher]

Package: libhugetlbfs
Version: 2.4
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

*** Please type your report below this line *** 
I wish to work on creating a debian package for libhugetlbfs-2.4

License: LGPL

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

Kernel: Linux 2.6.26-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash




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

Re: Bug#533642: dpkg-dev: dpkg-shlibdeps fails on symbols exported by libgcc_s

[Matthias Klose]

Paul Brook schrieb:
>> Now it seems that the irrlicht library depends on those symbols
>> provided by libgcc_s.so.1 (and does not define them locally contrary to
>> what was seen by Aurélien in libvorbis in #462318) and of course
>> dpkg-shlibdeps complains because they can't be found in the symbols file.
>> ...
>> So should I revert the blacklist entirely? Or should I revert the
>> blacklist partially? In that case, which symbols must be blacklisted?
> 
> Under normal curcumstances, I'd expect every shared library and application 
> to 
> require __aeabi_* from libgcc. Under normal circumstances these will come 
> from  
> libgcc_s.so, but if you link with --static-libgcc then you'll get your own 
> copy.

these are not defined in libgcc_s.so, but only in libgcc.a. So when building a
shared library, you should link with both -lgcc_s and -lgcc (which current
libtool doesn't seem to support). I didn't get any feedback on what should be
the correct way to link libraries on armel. there are open reports PR40133 (the
report where I did see the problem first) and PR40134 (no feedback yet). The SH
port does use a linker script to link with both -lgcc_s and -lgcc.

  Matthias

> These symbols are defined by the EABI and the runtime must supply in some 
> form. The EABI is deliberately vague about exactly where/how, but on Linux it 
> is normal for these for come from libgcc. However use of these functions is 
> entirely optional, hence building them into your library instead of using 
> libgcc_s.so is ok (though obviously has the same undesirable consequences as 
> any sort of static library).
> 
> I'm afraid I have no clue how dpkg-shlibdeps works, so can't really guess 
> what 
> the right answer to your blacklist question is.
> 
> Paul
> 
> 


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

Re: apt-get wrapper for maintaining Partial Mirrors

[Joseph Rawson]

On Friday 19 June 2009 07:14:08 Bernhard R. Link wrote:

> Actually, I'm quite open to having some depedency handling in reprepro
That is interesting.  I've been working on the assumption that there would 
never be any dependency handling in reprepro, as I didn't consider it part of 
it's function.

> and already have written some simple prototype for a related project.
> The problem is that calculating a simple cover of selected packages in
> the dependency graph is not enough:
>
> Usually the cover is not unique but the existance of alternatives in
> dependencies causes multiple solutions. 
This is a problem across the board.  Even aptitude seems to have problems in 
automatically determining the most appropriate dependencies.  

Let's use this example.  Suppose you already have a system with apache2 
installed, but no php yet.  Next you try to install phpldapadmin, using 
aptitude (from the command line).  Aptitude will tell you that 
libapache-mod-php5 is broken, and proceed to present some alternatives that 
would resolve the dependencies.


umebo...@stdinstall:~$ sudo aptitude -s install  phpldapadmin
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
The following packages are BROKEN:
  libapache-mod-php5
The following NEW packages will be installed:
  php5-common{a} php5-ldap{a} phpldapadmin
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 3821kB of archives. After unpacking 11.8MB will be used.
The following packages have unmet dependencies:
  libapache-mod-php5: Depends: libdb4.4 which is a virtual package.
  Depends: apache-common (>= 1.3.34) which is a virtual 
package.
  Depends: php5-common (= 5.2.0-10+lenny1) but 
5.2.6.dfsg.1-1+lenny3 is to be installed.
The following actions will resolve these dependencies:

Install the following packages:
libapache2-mod-php5 [5.2.6.dfsg.1-1+lenny3 (stable)]

Keep the following packages at their current version:
libapache-mod-php5 [Not Installed]

Score is 50

Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

Install the following packages:
php5-cgi [5.2.6.dfsg.1-1+lenny3 (stable)]

Keep the following packages at their current version:
libapache-mod-php5 [Not Installed]

Score is 50

Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

Install the following packages:
libapache2-mod-php5 [5.2.6.dfsg.1-1+lenny2 (stable)]
php5-common [5.2.6.dfsg.1-1+lenny2 (stable)]
php5-ldap [5.2.6.dfsg.1-1+lenny2 (stable)]

Keep the following packages at their current version:
libapache-mod-php5 [Not Installed]

Score is -30


etc, etc, etc .

apt-get, on the other hand, seems to use the first dependency that's listed as 
an alternative.

Depends: apache2 | httpd, php5-ldap, libapache2-mod-php5 | 
libapache-mod-php5 |
 php5-cgi | php5, debconf (>= 0.5) | debconf-2.0

Here, since we already have apache2 on the system, libapache2-mod-php5 is 
chosen (I'm guessing because it's the first one listed).

> For an initial checkout that 
> is no problem, as one can choose one some set by some pseudo-random
> selection (like "packages with alphabetically lower names get the
> first depedency in an alternative tried first" and similar things
> for virtual packages). 
I think that it should be up to the maintainer of the local mirror to 
explicitly list the alternatives that are preferred.  I don't think that 
there is anyway that an automatic dependency resolver will ever be able to do 
this.  The automatic dependency resolver can make this easier by marking 
those dependencies as "automatically selected, alternative available" or 
something similar.  One of the nice things about germinate, is that it has 
a "why" column in it's output that tells why a package was selected (although 
it doesn't make it clear that it's one of many alternatives).

> The problem is that no such criterion can be 
> stable against changes in the partially mirrored distribution.
I'm not sure what you mean here.  Are you talking about an alternative that's 
selected for the local mirror, but removed from the official mirror?

>
> So in this cases knowing what packages upstream has and what packages
> are wanted is not enough but one has to take into account what packages
> are currently selected. And a simply covering no longer is enough but
> one needs a full resolver knowing which installed states can be easily
> brought to which other installed states. (and things get even more
> complicated if the currently mirrored packages allow multiple subsets
> which clients using this repository might have installed)...
>
I used to have to keep outdated libraries in my filter list

Re: apt-get wrapper for maintaining Partial Mirrors

[Tzafrir Cohen]

On Fri, Jun 19, 2009 at 06:23:08AM -0500, Joseph Rawson wrote:
> On Friday 19 June 2009 05:09:31 Tzafrir Cohen wrote:
> > On Fri, Jun 19, 2009 at 01:52:43AM -0500, Joseph Rawson wrote:
> > > would be much more interested in making a tool that would make it easier
> > > to manage local/partial debian mirrors (i.e. one that helped resolve the
> > > dependencies), rather than have an apt-get wrapper.  I also think that
> > > once such a tool is made, it would make it easier to build an apt-get
> > > wrapper that works with it.  I don't think that viewing the problem with
> > > an "apt-get wrapper" solution is the best way to approach it, but I do
> > > think that it would be valuable once the underlying problems are solved.
> >
> > And reprepro does not fit the bill because?
> >
> It fits part of the bill, as it's an excellent tool for maintaining a 
> repository, but it doesn't resolve dependencies (nor should it).

Just in case it might help, here's a script we used internally (at the
Sarge time) to maintain a dummy repository that would help us eventually
resolve an original list of packages to a complete list of packages we
ask a reprepro source to update.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend


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

Re: apt-get wrapper for maintaining Partial Mirrors

[Tzafrir Cohen]

On Fri, Jun 19, 2009 at 02:14:08PM +0200, Bernhard R. Link wrote:
> * Joseph Rawson  [090619 13:23]:
> > On Friday 19 June 2009 05:09:31 Tzafrir Cohen wrote:
> > > On Fri, Jun 19, 2009 at 01:52:43AM -0500, Joseph Rawson wrote:
> > > > would be much more interested in making a tool that would make it easier
> > > > to manage local/partial debian mirrors (i.e. one that helped resolve the
> > > > dependencies), rather than have an apt-get wrapper.  I also think that
> > > > once such a tool is made, it would make it easier to build an apt-get
> > > > wrapper that works with it.  I don't think that viewing the problem with
> > > > an "apt-get wrapper" solution is the best way to approach it, but I do
> > > > think that it would be valuable once the underlying problems are solved.
> > >
> > > And reprepro does not fit the bill because?
> > >
> > It fits part of the bill, as it's an excellent tool for maintaining a
> > repository, but it doesn't resolve dependencies (nor should it).
> 
> Actually, I'm quite open to having some depedency handling in reprepro
> and already have written some simple prototype for a related project.
> The problem is that calculating a simple cover of selected packages in
> the dependency graph is not enough:
> 
> Usually the cover is not unique but the existance of alternatives in
> dependencies causes multiple solutions. For an initial checkout that
> is no problem, as one can choose one some set by some pseudo-random
> selection (like "packages with alphabetically lower names get the
> first depedency in an alternative tried first" and similar things
> for virtual packages). The problem is that no such criterion can be
> stable against changes in the partially mirrored distribution.

While it's a good queastion, the interface I'm used to use is apt-get /
aptitude. Thus the interface I had in mind is "a list of packages to
install" (in a single installation). Using some tweaking this allows you
to get exactly what you want.

If you want your repository to include conflicting options, you should 
allow the interface to include multiple such entries. In our case we had
multiple files. Each file was a list of packages, and each file was
basically a "single apt-get command".

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend


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

Re: apt-get wrapper for maintaining Partial Mirrors

[Joseph Rawson]

On Friday 19 June 2009 12:57:25 Goswin von Brederlow wrote:
> Joseph Rawson  writes:
> > On Friday 19 June 2009 00:27:06 Goswin von Brederlow wrote:
> >> Joseph Rawson  writes:
> >> If so then you can configure a post invoke hook in apt that will copy
> >> the dpkg status file of the host to the server [as status.$(hostname)]
> >> and then use those on the server to generate the filter for
> >> reprepro. I think I still have a script for that somewhere but it is
> >> easy enough to rewrite.
> >
> > That's good for binaries, but I don't know about the source.  It wasn't
> > long ago that I noticed a problem with reprepro not obtaining the
> > corresponding source packages when you use a filter list taken
> > from  "dpkg --get-selections".  I remember that the source for jigdo
> > wasn't in my partial mirror, because there were no binaries named
> > "jigdo", rather "jigdo-file" and "jigdo-lite".  Since there were no
> > sources with that name, the jigdo source was never mirrored on my partial
> > mirror.  I don't know if that behavior has been fixed now, since there is
> > now a binary named jigdo, instead of jigdo-lite.
>
> My filter first converted the packages listed in the status file(s) to
> source package names (packages with different name have a "Source:"
> entry) and then output those for sources.
>
> > Also, it's more difficult for the local repository to determine the
> > difference between the automatically selected and manually selected
> > packages in this type of setup, since you would be sending a longer list
> > of "manually selected packages", instead of distinguishing which ones are
> > actually selected.  I guess that it doesn't matter much, as a package
> > would only be removed from the repository once it's not listed on any of
> > the lists.  There were times when I didn't want certain packages to be
> > removed from the repository, regardless of whether they were installed or
> > not, so I used to run xxdiff on the packages files, so the newer ones
> > were added.
>
> Same problem here. Esspecially build-depends. There where a lot of
> packages I only needed inside my build chroots and only for the time
> of the build. So they never showed up on the mirror. Then I just
> resized the mirror partition and mirrored all debs.
>
That was my ultimate solution to the problem.  I bought one of the new 
terabyte usb external drives and just mirrored the whole repository.  I had 
been satisfied to just call the problem solved at that point, but this thread 
resparked my interest in obtaining a better solution.  Before I bought the 
hard drive, I was seriously looking into getting germinate and reprepro 
working together, but once I bought the drive, I just set it all aside.  
Still, this external drive isn't portable, and my small portable drive is 
only 80G (which is more than enough for a partial mirror of source, i386, and 
amd64), so I do still need to solve the problem.  Besides, a month after I 
bought the drive, I discovered that I have a monthly cap on my transfers so 
it would be better, all around, to stop mirroring the complete repository.

> > In my way of thinking, I'm not looking to merge upstream repositories
> > together in one repository.  Besides, there are already tools, such as
> > apt-move that would be better for this job.  Long ago, apt-move was the
> > primary tool that I used to keep a local repository, and it worked pretty
> > well, as long as all the machines that were using it were on the same
> > release.
> >
> > I have found that reprepro is the absolute best tool for maintaining a
> > debian mirror.  The only problem I have with it is when I want to
> > maintain a partial mirror, and I don't want a merged repository, is that
> > I have to spread the packages lists to different places, and when you
> > start adding machines, you start adding more lists to the configuration,
> > when it would probably be better to maintain a set of "master" lists that
> > are generated from the many lists that come from the machines.
>
> Or have a proxy that adds packages that are requested.
When I woke up this morning, I was thinking that it might be interesting to 
have an apt method that talks directly to reprepro.  It's just a vague idea 
now, but I'll give it some more thought later.

>
> MfG
> Goswin



-- 
Thanks:
Joseph Rawson


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

Re: apt-get wrapper for maintaining Partial Mirrors

[Joseph Rawson]

On Friday 19 June 2009 20:54:28 Tzafrir Cohen wrote:
> On Fri, Jun 19, 2009 at 06:23:08AM -0500, Joseph Rawson wrote:
> > On Friday 19 June 2009 05:09:31 Tzafrir Cohen wrote:
> > > On Fri, Jun 19, 2009 at 01:52:43AM -0500, Joseph Rawson wrote:
> > > > would be much more interested in making a tool that would make it
> > > > easier to manage local/partial debian mirrors (i.e. one that helped
> > > > resolve the dependencies), rather than have an apt-get wrapper.  I
> > > > also think that once such a tool is made, it would make it easier to
> > > > build an apt-get wrapper that works with it.  I don't think that
> > > > viewing the problem with an "apt-get wrapper" solution is the best
> > > > way to approach it, but I do think that it would be valuable once the
> > > > underlying problems are solved.
> > >
> > > And reprepro does not fit the bill because?
> >
> > It fits part of the bill, as it's an excellent tool for maintaining a
> > repository, but it doesn't resolve dependencies (nor should it).
>
> Just in case it might help, here's a script we used internally (at the
> Sarge time) to maintain a dummy repository that would help us eventually
> resolve an original list of packages to a complete list of packages we
> ask a reprepro source to update.
>
Did you forget to attach it? :)

> --
> Tzafrir Cohen | tzaf...@jabber.org | VIM is
> http://tzafrir.org.il || a Mutt's
> tzaf...@cohens.org.il ||  best
> ICQ# 16849754 || friend



-- 
Thanks:
Joseph Rawson


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

Re: Fw: PLEEEEEASE - 4WARD THIS TO AS MANY AS POSSIBLE ....THANKS & GOD BLESS

[Ronnie Roddick]

Add me for get a perfect Web Solution.


Thanks

Re: apt-get wrapper for maintaining Partial Mirrors

[Tzafrir Cohen]

Actually attaching the file this time...

On Sat, Jun 20, 2009 at 01:54:28AM +, Tzafrir Cohen wrote:
> On Fri, Jun 19, 2009 at 06:23:08AM -0500, Joseph Rawson wrote:
> > On Friday 19 June 2009 05:09:31 Tzafrir Cohen wrote:
> > > On Fri, Jun 19, 2009 at 01:52:43AM -0500, Joseph Rawson wrote:
> > > > would be much more interested in making a tool that would make it easier
> > > > to manage local/partial debian mirrors (i.e. one that helped resolve the
> > > > dependencies), rather than have an apt-get wrapper.  I also think that
> > > > once such a tool is made, it would make it easier to build an apt-get
> > > > wrapper that works with it.  I don't think that viewing the problem with
> > > > an "apt-get wrapper" solution is the best way to approach it, but I do
> > > > think that it would be valuable once the underlying problems are solved.
> > >
> > > And reprepro does not fit the bill because?
> > >
> > It fits part of the bill, as it's an excellent tool for maintaining a 
> > repository, but it doesn't resolve dependencies (nor should it).
> 
> Just in case it might help, here's a script we used internally (at the
> Sarge time) to maintain a dummy repository that would help us eventually
> resolve an original list of packages to a complete list of packages we
> ask a reprepro source to update.
> 
> -- 
> Tzafrir Cohen | tzaf...@jabber.org | VIM is
> http://tzafrir.org.il || a Mutt's
> tzaf...@cohens.org.il ||  best
> ICQ# 16849754 || friend
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> 

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend
#!/bin/bash

# using bash-specific PIPESTATUS

CMD=`basename $0`

REPREPRO=reprepro
BASE_DIR=repo
APT_BASE_DIR=${BASE_DIR}/Aptdir
APT_DIR=${APT_DIR:-${APT_BASE_DIR}/unstable}
MAIN_REPO=/home/repo
PACKAGES_LIST_FILE=packages
STATIC_DIR=$MAIN_REPO/static
STATIC_INST=$MAIN_REPO/static_inst
INSTALLER_PATH=$BASE_DIR/dists/sarge/main/installer-i386/current
CD_OVERRIDE=cd-override/cd

set -e

usage() {
echo >&2 "apter: apt resolver wrapper"
echo >&2 "   (functionality varies by basename of \$0)"
echo >&2 "Usage: $0 "
}

# $1: file
# $2: condition
get_entry() {
  awk <$BASE_DIR/conf/$1 -v RS='\n\n' "/\<$2\>\n/ {print \$0}" 
  #echo >&2 "printed updates section $2."
}

# $1: file (updates/distributions)
# $2: condition
# $3: field name
get_field() {
get_entry "$1" "$2" | grep "^$3: " | cut -d: -f2-
}

dists_list() {
awk '/^Codename: / {print $2}' $BASE_DIR/conf/distributions
}

case "$CMD" in
apt-get|apt-cache|aptitude)
exec $CMD \
-o Dir=$PWD/$APT_DIR \
-o Dir::State::status=$PWD/$APT_DIR/var/lib/dpkg/status 
\
"$@"
;;
apter)
case "$1" in
setup)
for dist in `dists_list`
do
APT_DIR=$APT_BASE_DIR/$dist
export APT_DIR

for dir in \
etc/apt var/lib/apt/lists/partial \
var/lib/dpkg 
var/cache/apt/archives/partial
do mkdir -p $APT_DIR/$dir
done
touch $APT_DIR/var/lib/dpkg/status
# relevant update sources:
update_sources=`get_field distributions 
"Codename: $dist" Update`
(
for upd in $update_sources
do 
get_entry updates "Name: $upd"
echo ''
done
) | tools/updates2sources 
>$APT_DIR/etc/apt/sources.list
cat <$APT_DIR/etc/apt/preferences
# give our packages a higher priority:
Package: *
Pin: release o=Xorcom
Pin-Priority: 600
EOF
done
;;
generate)
# setup the apt wrapper:
$0 setup
$0 refresh
;;
refresh) 
rm -rf $BASE_DIR/{db,dists,lists,pool}
$0 refresh-nodel
;;
upgrade|refresh-nodel) 
apt_cmd=`dirname $0`/apt-get
for file in `ls $ST

Re: RFC: DEP-3: Patch Tagging Guidelines

[Ben Finney]

Raphael Hertzog  writes:

> Merging all those ideas, I suggest we drop Status/Commit/Patch and use
> the following format:
> 
> Origin:  : 

I'd still suggest having the extra information optional in the case of
anything but “other”:

"Origin: upstream" [ ": "  ]
"Origin: backport" [ ": "  ]
"Origin: vendor" [ ": "  ]
"Origin: other: " 

In other words, a keyword is required, and extra information is optional
except for “other”.

> Forwarded: >

Again, I'll warn against specifying “one of these keywords, or whatever
you like” since that begs for collisions in future when trying to
introduce new keywords.

Instead, I would specify ‘Forwarded’ similar to the above, with:

"Forwarded: yes" [ ": "  ]
"Forwarded: no" [ ": "  ]
"Forwarded: not-needed: " 

-- 
 \“When you go in for a job interview, I think a good thing to |
  `\  ask is if they ever press charges.” —Jack Handey |
_o__)  |
Ben Finney


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

Bug#519941: Remove Policy permission for packages to modify ld.so.conf

[Russ Allbery]

In Policy Bug#519941, it was proposed to remove the Policy permission
for packages to modify ld.so.conf in exceptional circumstances.  The
implication would be that all packages which do this will need to either
move their libraries into a standard library directory like /usr/lib if
they're really intended to be public or compile with an RPATH setting.
Permission for packages to modify the global library search order to
include a non-standard directory would be removed.

The rationale as stated by Steve Langasek:

| This recommendation needs to be elminated entirely.  It is *not* ok
| for packages that provide libraries to stick extra linker paths in the
| global configuration, whether by modifying ld.so.conf or by adding to
| /etc/ld.so.conf.d.  Either the libraries provided by the packages are
| meant to be public, in which case they should be installed to the
| standard library path instead of needlessly adding another directory
| that's going to be globally visible anyway; or they should not, and
| the cooperating packages should use rpath instead.
| 
| Use of rpath should still be discouraged, but if someone is bound and
| determined to violate the FHS with their library paths in order to
| have private libraries, they should make them really private with
| rpath instead of using this "compromise" solution that takes the worst
| of each approach.

Note that using a separate directory and modifying ld.so.conf does not
usefully resolve name conflicts, since all the libraries end up on the
same global search path anyway and one still has to use RPATH to select
which of two conflictingly-named libraries one wants to load.

This has already recieved the support of six Debian Developers, which is
more than enough to make this change in Policy.  However, due to the
broader effects, I wanted to make sure that people were aware of this
discussion and had a chance to review and weigh in.  I'm also copying
the maintainers of all packages that apt-file says include files in
/etc/ld.so.conf.d except for libc6 and friends.  I have not individually
checked these packages to understand why they include an ld.so.conf.d
fragment, and this doesn't include any packages that modify
/etc/ld.so.conf.

This is the proposed modification to Policy:

--- a/policy.sgml
+++ b/policy.sgml
@@ -7011,17 +7011,6 @@ strip --strip-unneeded your-lib

 

- Packages containing shared libraries that may be linked to
- by other packages' binaries, but which for some
- compelling reason can not be installed in
- /usr/lib directory, may install the shared library
- files in subdirectories of the /usr/lib directory,
- in which case they should arrange to add that directory in
- /etc/ld.so.conf in the package's post-installation
- script, and remove it in the package's post-removal script.
-   
-
-   
  An ever increasing number of packages are using
  libtool to do their linking.  The latest GNU
  libtools (>= 1.3a) can take advantage of the metadata in the

Please copy 519...@bugs.debian.org on all discussion.

-- 
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: RFC: DEP-3: Patch Tagging Guidelines

[Raphael Geissert]

Joerg Jaspert wrote:

> On 11782 March 1977, Raphael Hertzog wrote:
> 
>> This is a proposal to formalize a set of meta-information
>> to be embedded in patches applied to Debian packages. Most
>> patch systems allow for a free-from description preceeding
>> the content of the patch and the plan is to make use of that
>> space to embed some structured content.
> 
> It does sound a *little* overengineered for no good reason. (IMO).

I usually tend to like and support some changes even if they are a "big"
change, but in this case I agree with you Joerg.

I mean, often the patch name already says enough about it, at times patches
are just trivial (a typo fix doesn't need four or five lines to be
described), at times they are forwarded as soon as the new package is
uploaded, at times they are $VCS commits from upstream. And mandating or
even recommending to add all that documentation is useless in those, and
probably more, cases.

The only part I consider worth to keep is the one where the status regarding
forwarding the patch to upstream is recorded.
Something as simple as:

Status: forwarded to f...@bar.com
Status: forwarded to http://some.bts.foo.com/bar?id=moo
Status: not forwarded
Status: not forwarded, Debian-specific

It's perfectly human and machine readable, and is pretty simple.

Cheers,
Raphael Geissert



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

Re: RFS: kernelcheck

[Ben Finney]

[moving to debian-devel as this is a topic broader than debian-mentors]

Master Kernel  writes:

> Ben Finney  writes:
> 
> > [To be likely to have your package sponsored,] You will need to
> > identify yourself; “Master Kernel” is hardly likely to be your real
> > name.
> 
> Is there *any way* that I don't have to disclose this information? I
> was contacted by a packager a while ago when this issue came up. He
> said it would be possible to work around it.

Well, if that person says it can be done, you'd be best to ask them for
the details.

I am all in favour of allowing people their anonymity, but the flip side
of that is anonymity is directly at odds with reputation: reputation
requires consistent use of an identity. If you want to operate with
Debian you are operating in a society built primarily on trust and
reputation. For that, we require identity to which that reputation and
trust can be associated.

Also, your expressive work is (whether you choose it or not) subject to
copyright, and you as a legal entity are the copyright holder; for
Debian to make use of your work under copyright law, we take on the
burden of assuring we have license to do so.

I'm not an ftpmaster, but I would be surprised if they want to take the
risk of distributing works for which the copyright provenance is
essentially unknown. I would imagine many prospective sponsors feel the
same way. I don't know, though, so I'm inviting further input.

-- 
 \   “Even if the voices in my head are not real, they have pretty |
  `\   good ideas.” —anonymous |
_o__)  |
Ben Finney


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

Re: RFS: kernelcheck

[David Paleino]

On Sat, 20 Jun 2009 16:25:20 +1000, Ben Finney wrote:

> [moving to debian-devel as this is a topic broader than debian-mentors]
> 
> Master Kernel  writes:
> 
> > Ben Finney  writes:
> > 
> > > [To be likely to have your package sponsored,] You will need to
> > > identify yourself; “Master Kernel” is hardly likely to be your real
> > > name.
> > 
> > Is there *any way* that I don't have to disclose this information? I
> > was contacted by a packager a while ago when this issue came up. He
> > said it would be possible to work around it.
> 
> Well, if that person says it can be done, you'd be best to ask them for
> the details.

It was me, IIRC.
And no, I didn't package kernelcheck anymore.

I based my statement on the fact that the "john" package has "Solar
Designer" (whis is NOT the realname) as copyright holder (and that's in main)

  http://packages.debian.org/changelogs/pool/main/j/john/current/copyright

> [..]
> Also, your expressive work is (whether you choose it or not) subject to
> copyright, and you as a legal entity are the copyright holder; for
> Debian to make use of your work under copyright law, we take on the
> burden of assuring we have license to do so.
> 
> I'm not an ftpmaster, but I would be surprised if they want to take the
> risk of distributing works for which the copyright provenance is
> essentially unknown. I would imagine many prospective sponsors feel the
> same way. I don't know, though, so I'm inviting further input.

I didn't consider this aspect, at the time :(

Is material copyrightable under a nickname, instead of a realname?
The same question applies to work © by a team (an example involving me directly
-- bash-completion)

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