Re: RFS: teeworlds

[Francesco Poli]

On Mon, 14 Apr 2008 11:45:23 -0500 Gunnar Wolf wrote:

> Alexander Schmehl dijo [Mon, Apr 14, 2008 at 06:24:36PM +0200]:
[...]
> > Talked to Jörg Jaspert about that (you need to do something during work
> > time, don't you?), and this clause is indeed free (since it's so
> > ridiculous easy to circumvent^W fullfill).  So for the sake of gaming,
> > bundle it with any kind of script, and be done with it.

I agree that this restriction does *not* fail the DFSG, but, as said
elsewhere in this same thread, it's silly.
It can be easily circumvented, so it's useless.
See my 2-byte script example in
http://lists.debian.org/debian-legal/2006/12/msg00077.html

As usual, my disclaimers are: IANAL, TINLA, IANADD, TINASOTODP.

> 
> But please try to make this world a saner place by talking about this
> to the upstream author.

Yes, I definitely agree that upstream could be suggested to drop such a
useless restriction and adopt the plain (unmodified) zlib license.

-- 
 http://frx.netsons.org/progs/scripts/refresh-pubring.html
 New! Version 0.6 available! What? See for yourself!
..... Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpsjkiUQUiRH.pgp
Description: PGP signature

Re: RFS: teeworlds

[Francesco Poli]

On Tue, 15 Apr 2008 09:16:28 +1000 Jack Coulter wrote:

> I've spoken again to matricks, he's stated that in the next release, 
> he'll be changing the license slightly, it will still remain free, but 
> he's going to clarify the last point.

That silly restriction should not be "clarified"!  It should be
entirely dropped and the plain unmodified zlib license should be
adopted!

> 
> Aside from that, is this package suitable for inclusion? Are there any 
> changes I need to make?

As I said, the main license (zlib license + additional silly
restriction) already meets the DFSG.
However, it meets the DFSG just because the selling restriction may be
easily circumvented; that's why I suggest that the restriction is
dropped entirely from the license text: for the sake of clarity and
simplicity, no useless restrictions should be present in license
texts...

As far as the rest of the package is concerned, I didn't see any
detailed info about the licensing status of the files released under
different terms, so I cannot comment any further...

Once more, my disclaimers are: IANAL, TINLA, IANADD, TINASOTODP.
 

P.S.: please send replies to both debian-mentors and debian-legal, as
appropriate, rather than to me and debian-mentors, or otherwise other
debian-legal participants won't see your replies at all...

-- 
 http://frx.netsons.org/progs/scripts/refresh-pubring.html
 New! Version 0.6 available! What? See for yourself!
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpQInFhajsD9.pgp
Description: PGP signature

Re: are PHP license 3.0 or 3.1 compatible with Debian ?

[Francesco Poli]

On Thu, 2 Feb 2006 17:06:58 +0100 Alexander Schmehl wrote:

> I only found 3.0 and 3.01, please add license texts to your mail. 
> Makes thinks easier.
> 
> However:
> The license texts I found still contain the following point:
> 
> 
>   6. Redistributions of any form whatsoever must retain the following
>  acknowledgment:
>  "This product includes PHP, freely available from
>  <http://www.php.net/>".
> 
> 
> 
> Which means:  The license is still free, and still not suitable for
> anything but PHP itself.

I don't agree: I think that PHP license version 3.01 does not comply
with the DFSG, even when applied to PHP itself or to PHP Group software.
The problematic clause is #4.

Moreover, when the license is applied to anything else (that is to say,
software not provided by the PHP Group), a bunch of additional issues
appear.

Please, see

  http://lists.debian.org/debian-legal/2005/11/msg00271.html
  http://lists.debian.org/debian-legal/2005/11/msg00272.html

and the rest of the thread, for more details.

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
......
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp2KfqGkbmXa.pgp
Description: PGP signature

How to write a machine-readable debian/copyright file?

[Francesco Poli]

Hi everybody,
I began to study the machine-readable debian/copyright file format [1],
with the plan to adopt it for my (current and future) packages.

[1] http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

I have a question, though.

I can write a debian/copyright file by hand for small (and more or less
uniform, license-wise) packages.

But what if I have a source archive with about 12000 files having a
number of different licenses and/or copyright holders/years?

  $ licensecheck --verbose -r . | view -

helps somewhat, but I will grow old before I find the time to scroll it
all... let alone reorganize and group the collected data into a suitable
machine-readable debian/copyright file!

I suppose the way to go is auto-generating the machine-readable
debian/copyright file.

So the question is: is there any general purpose tool that scans a
directory tree, detects the copyright notice and license of each file,
reorganizes and groups everything, and writes a machine-readable
debian/copyright file?

I found libdebian-copyright-perl [2], which is however a library and
seems to be able to read/merge/write machine-readable debian/copyright
files, without any capability to collect licensing information from
source files.

I found libconfig-model-perl [3], which includes a command-line tool,
but seems to be limited to some manipulations, again without any
data-collecting capability. 

[2] http://packages.debian.org/sid/libdebian-copyright-perl
[3] http://packages.debian.org/sid/libconfig-model-perl

Am I missing anything?

Please let me know, thanks for any hint you may provide.


P.S.: I am not subscribed to debian-mentors, please Cc me on replies.
  Thanks!

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpGFqKm8Diea.pgp
Description: PGP signature

Re: How to write a machine-readable debian/copyright file?

[Francesco Poli]

On Mon, 27 Aug 2012 14:58:46 -0700 Vincent Cheng wrote:

[...]
> On Mon, Aug 27, 2012 at 2:54 PM, Francesco Poli
>  wrote:
> 
> > So the question is: is there any general purpose tool that scans a
> > directory tree, detects the copyright notice and license of each file,
> > reorganizes and groups everything, and writes a machine-readable
> > debian/copyright file?
> 
> Is this what you are looking for?
> 
> $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 >
> debian/copyright

Mmmmh, interesting... I'll give it a try!
Thank you very much for your kind reply.

I see on the debian-mentors web archive that Michael Wild suggested to
relax the file selection regex, which seems to be definitely important
(the default seems to be too narrow, maybe it should change?).
I'll try

  $ licensecheck --copyright -r . -c . | \
/usr/lib/cdbs/licensecheck2dep5 > /tmp/copyright

and then check/edit the resulting output...

> 
> You definitely still need to manually check the copyright file
> afterwards for any errors, of course.

Definitely...
Among other things, I see that the output of licensecheck2dep5 is not
even fully compliant with the standard format (see bug #633794).


By the way, as soon as I noticed that licensecheck2dep5 is part of the
cdbs package, I wondered why it was not part of devscripts (which looks
like the most obvious package where this tool should be shipped).
Even better, I think it should be integrated as a possible output
format for licensecheck itself...

Well, it seems that I am not the only one with this opinion.
In bug #472199, a number of different people asked for this feature to
be implemented in licensecheck and some also attempted to prepare
patches. Then Jonas Smedegaard (the author of licensecheck2dep5)
expressed the intention to integrate this capability into licensecheck.
Unfortunately there seems to be no visible progress since August 2010...
I'll maybe try to ping Jonas and ask him for an update.


Anyway, thanks again for your helpful answer.
I'll try and see whether licensecheck2dep5 may fit my needs.

Bye.


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpc959G9aAoH.pgp
Description: PGP signature

Re: [...@debian.org: Re: RFS: php-clamav]

[Francesco Poli]

On Sun, 22 Nov 2009 18:54:24 +0100 Michael Tautschnig wrote:

> Hi all,

Hi!

[...]
> > Yes I have subscribe (
> > http://qa.debian.org/developer.php?login=argo...@gmail.com) but it's my
> > first upload :-).
[...]
> > For my name, sorry but I don't like show my real name on internet.
> > 
> 
> ... please clarify, whether this is acceptable at all for copyright purposes?
> (resending to debian-legal for that matter)

As far as copyright is concerned, it is my personal understanding that
anonymous and pseudonymous works are protected by copyright in all
Berne Convention signatory countries (that is to say, virtually
everywhere): see, for instance,
article 7, paragraph 3 of the Berne Convention
http://wipo.int/treaties/en/ip/berne/trtdocs_wo001.html#P127_22000
as well as article 15, paragraph 3
http://wipo.int/treaties/en/ip/berne/trtdocs_wo001.html#P192_37445


Whether the Debian Project is or is not willing to accept pseudonymous
works in its archive, it is up to the FTP Masters to decide, I think.


I hope this helps.


-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
..... Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpDqJd5OHVES.pgp
Description: PGP signature

Rescue Plan for apt-listbugs

[Francesco Poli]

Hi everybody,
I need help.

I am not a DD, nor a DM; nonetheless, I am one of the two current
co-maintainers of apt-listbugs.
The other one is Ryan Niebur.

My problem is that I've lost contact with him: he seems to be currently
(almost) MIA.
It seems that I am not the only one:
http://lists.debian.org/debian-devel/2010/08/msg00468.html
http://lists.debian.org/debian-devel/2010/08/msg00482.html

Please read the following bug report that I myself had to open against
our own package, in order to try to get in touch with him again:
http://bugs.debian.org/588636
Please note the dates of the various messages...  :-(

Ryan seems to have been unable to perform Debian-related work for quite
some time (even though he does not seem to have been completely
off-line).
Now I am short of ideas on how to proceed: I would like to take over
the maintenance of apt-listbugs (possibly with help from someone else,
see below) and get direct push access to its public git repository on
alioth.
As I said on  http://bugs.debian.org/588636#39  , I requested to join
the alioth apt-listbugs project, but got no reply from any of the
project members.

Any suggestions on how I should proceed?

Also, could someone please review the proposed git work-flow and tell
me if it is OK?

Finally, I would like to find someone else who could co-maintain the
package with me: I usually manage to deal with bug reports and go ahead
with developing work by myself, but I sometimes need help on Ruby (I am
not yet the Ruby expert I would dream to be!) or on packaging
techniques (I am still learning!).
Any volunteer?


Thanks in advance for your time!

-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp94eg7oWqNy.pgp
Description: PGP signature

Re: Rescue Plan for apt-listbugs

[Francesco Poli]

On Mon, 4 Oct 2010 23:29:28 +0200 Francesco Poli wrote:

> Hi everybody,
[...]

I forgot to add that I am not subscribed to debian-mentors or to
debian-ruby: hence, please Cc: me on replies.
Thanks again.


-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
..... Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpOeT4QQNSOR.pgp
Description: PGP signature

Re: Rescue Plan for apt-listbugs

[Francesco Poli]

On Tue, 5 Oct 2010 10:54:29 +0200 Manuel A. Fernandez Montecelo wrote:

[...]
> Just copying the reply to the original author... he already said that he's 
> not subscribed to the mailing list ;)

Thanks a lot!

[...]
> On Tuesday 05 October 2010 09:27:57 Jan Hauke Rahm wrote:
> > On Mon, Oct 04, 2010 at 11:29:28PM +0200, Francesco Poli wrote:
[...]
> > > My problem is that I've lost contact with him: he seems to be currently
> > > (almost) MIA.
> > 
> > FWIW, I have been working with him as well and found him rather inactive
> > lately. I've now contacted him and will see where this leads.

Thanks to Jan, for trying to get in touch with Ryan, even though I must
confess that I lost hope to get any useful answer from Ryan...  :-(

> > 
> > Francesco, if you fear someone's MIA, please feel free to contact (or
> > CC) the MIA team at m...@qa.debian.org. I just happened to see your
> > concerns here.

I will certainly consider contacting the MIA team sooner or later.
But, in the meanwhile, I want to rescue apt-listbugs from this impasse!


-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp1XrhveUfI7.pgp
Description: PGP signature

Re: Rescue Plan for apt-listbugs

[Francesco Poli]

On Mon, 4 Oct 2010 23:29:28 +0200 Francesco Poli wrote:

[...]
> Now I am short of ideas on how to proceed: I would like to take over
> the maintenance of apt-listbugs (possibly with help from someone else,
> see below) and get direct push access to its public git repository on
> alioth.
> As I said on  http://bugs.debian.org/588636#39  , I requested to join
> the alioth apt-listbugs project, but got no reply from any of the
> project members.

Breaking news!!!   :-)
Thanks to the intervention of Jan Hauke Rahm (of the MIA team), Ryan
got in touch with me (better late than never...) and let me join the
project on alioth.
This means that I now have direct push access to apt-listbugs public
git repository, AFAICT!

[...]
> Also, could someone please review the proposed git work-flow and tell
> me if it is OK?

However, I still need confirmation that the git work-flow I am planning
to follow won't mess everything up.
Could someone please review it (see <http://bugs.debian.org/588636#39>)?

> 
> Finally, I would like to find someone else who could co-maintain the
> package with me: I usually manage to deal with bug reports and go ahead
> with developing work by myself, but I sometimes need help on Ruby (I am
> not yet the Ruby expert I would dream to be!) or on packaging
> techniques (I am still learning!).
> Any volunteer?

Since Ryan will no longer be involved in apt-listbugs maintenance, I am
still looking for a co-maintainer.
Thanks in advance to anyone who volunteers for this task.


-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpBTQo8YDiic.pgp
Description: PGP signature

Re: Rescue Plan for apt-listbugs

[Francesco Poli]

[I wasn't Cc:ed, hence I see your message only now, and I am replying
after manually quoting the text from the web archive and manually
setting the In-Reply-To field: I hope this won't break the thread;
apologies if it does!]


On Sat, 9 Oct 2010 12:02:15 +0800 Paul Wise wrote:

> On Sat, Oct 9, 2010 at 4:58 AM, Francesco Poli  wrote:
> 
> > However, I still need confirmation that the git work-flow I am planning
> > to follow won't mess everything up.
> > Could someone please review it (see <http://bugs.debian.org/588636#39>)?
> 
> A few minor issues, but it looks good.

Thanks a lot for the review!   :-)

> 
> > $ git clone git://git.debian.org/git/apt-listbugs/apt-listbugs.git
> > $ git remote add alioth 
> > ssh://git.debian.org/git/apt-listbugs/apt-listbugs.git
> 
> You should not need to add a second remote, it feels weird to have two
> remotes to the same repository. I would just do the initial clone over
> ssh.

What if I already have the cloned repository (I've used it so far to
prepare patches that I've sent to Ryan via e-mail...) and it was cloned
via the git protocol at the time?
Please take into account that I also already have a local branch
waiting to be pushed to the public repository as a new series of
commits for the "master" branch...

Should I start from scratch, clone the public repository over ssh, and
then somehow transfer my local commits from my old cloned repository to
the newly cloned one? How?

Or is there a better way to deal with this situation?

> 
> > $ git checkout -b $MY_COOL_BRANCH_NAME origin
> 
> You want origin/master here.

I thought that "origin" was a shortcut for "origin/HEAD":
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#how-git-stores-references
and "origin/HEAD" seems to be equivalent to "origin/master" on my
cloned repository:

$ git branch -r
  origin/HEAD -> origin/master
  origin/compare-version-accelerator
  origin/make_list_work
  origin/master
  origin/try-index-with-soap
  origin/update-po
  origin/vimbts

Anyway, if I understand correctly, your suggestion is to use
"origin/master", since it is a more general strategy.
Right?

> 
> > $ git checkout $MY_COOL_BRANCH_NAME && git rebase origin
> 
> Probably s/origin/master/

"origin" and "master" should be identical at this point, since I've
just pulled while on branch "master".
Or am I wrong?

Anyway, since I am then going to pull the rebased branch on the
"master" branch, you're probably right that the most correct rebase is
a "git rebase master".
Could you please confirm that this is what you meant? 

> 
> > $ git push alioth ${MY_COOL_BRANCH_NAME}:master
> 
> I've never used that syntax before, interesting.

I hope it works as intended!  ;-)

> 
> I would also suggest that before you push, either judicious use of git
> add -p for preparing commits into logical changes or use of git rebase
> -i after the fact to reorganise them into logical changes. Also,
> ensuring that each commit builds and passes any test suite helps folks
> doing bisects etc on the repo at a later date.

I'll do my best to ensure this!  ;-)


-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpKE5bWh74iB.pgp
Description: PGP signature

Re: Rescue Plan for apt-listbugs

[Francesco Poli]

On Mon, 11 Oct 2010 14:30:27 +0800 Paul Wise wrote:

> On Sun, Oct 10, 2010 at 1:22 AM, Francesco Poli  wrote:
> > [I wasn't Cc:ed, hence I see your message only now, and I am replying
> > after manually quoting the text from the web archive and manually
> > setting the In-Reply-To field: I hope this won't break the thread;
> > apologies if it does!]
> 
> CCed you.

Thanks!

> 
> > What if I already have the cloned repository (I've used it so far to
> > prepare patches that I've sent to Ryan via e-mail...) and it was cloned
> > via the git protocol at the time?
[...]
> I would delete the remote that clones over git:// and rename the other one.
> 
> git remote rm origin
> git remote rename alioth origin

Thanks, I will consider this option, even though I must admit that
having two remotes (one over ssh to push to, and one origin over the
git protocol to pull from) does not sound so weird to me.
The origin remote was created when I initially cloned the repository
over the git protocol: I had no push permissions at the time, hence I
could not clone over ssh (right?).
Now that I got push permissions, I can add a special "alioth" remote
over ssh, in order to push...

> 
> >> > $ git checkout -b $MY_COOL_BRANCH_NAME origin
> >>
> >> You want origin/master here.
> >
> > I thought that "origin" was a shortcut for "origin/HEAD":
> > http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#how-git-stores-references
> > and "origin/HEAD" seems to be equivalent to "origin/master" on my
> > cloned repository:
> 
> When I do your proposed command I get this:
> 
> $ git checkout -b test origin
> fatal: git checkout: updating paths is incompatible with switching branches.
> Did you intend to checkout 'origin' which can not be resolved as commit?

It has always worked for me...

> 
> > $ git branch -r
> >  origin/HEAD -> origin/master
> >  origin/compare-version-accelerator
> >  origin/make_list_work
> >  origin/master
> >  origin/try-index-with-soap
> >  origin/update-po
> >  origin/vimbts
> >
> > Anyway, if I understand correctly, your suggestion is to use
> > "origin/master", since it is a more general strategy.
> > Right?
> 
> Hmm, I don't have origin/HEAD on the test repo I was using:
> 
> $ git branch -r
>   origin/master

This may perhaps explain why the above mentioned command does not work
for you.

> 
> >> > $ git checkout $MY_COOL_BRANCH_NAME && git rebase origin
> >>
> >> Probably s/origin/master/
> >
> > "origin" and "master" should be identical at this point, since I've
> > just pulled while on branch "master".
> > Or am I wrong?
> >
> > Anyway, since I am then going to pull the rebased branch on the
> > "master" branch, you're probably right that the most correct rebase is
> > a "git rebase master".
> > Could you please confirm that this is what you meant?
> 
> Yep.

Good, thanks for confirming!

Paul, I would like to thank you for all the help you provided.
It's really appreciated.


-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpr0DpFo6mNK.pgp
Description: PGP signature

Re: Rescue Plan for apt-listbugs

[Francesco Poli]

On Fri, 8 Oct 2010 22:58:42 +0200 Francesco Poli wrote:

> On Mon, 4 Oct 2010 23:29:28 +0200 Francesco Poli wrote:
[...]
> > Also, could someone please review the proposed git work-flow and tell
> > me if it is OK?
> 
> However, I still need confirmation that the git work-flow I am planning
> to follow won't mess everything up.
> Could someone please review it (see <http://bugs.debian.org/588636#39>)?

Thanks to Paul Wise's help, I was able to fine tune my planned git
work-flow and managed to perform my first direct pushes to the public
git repository.
Hence this part of the issue is also solved!   :-)

> 
> > 
> > Finally, I would like to find someone else who could co-maintain the
> > package with me: I usually manage to deal with bug reports and go ahead
> > with developing work by myself, but I sometimes need help on Ruby (I am
> > not yet the Ruby expert I would dream to be!) or on packaging
> > techniques (I am still learning!).
> > Any volunteer?
> 
> Since Ryan will no longer be involved in apt-listbugs maintenance, I am
> still looking for a co-maintainer.
> Thanks in advance to anyone who volunteers for this task.

I will probably open a RFH bug report for this.


Bye and thanks to anyone who was, has been or will be helpful!

-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgppxjBgMCB3b.pgp
Description: PGP signature

Re: Rescue Plan for apt-listbugs

[Francesco Poli]

On Sat, 16 Oct 2010 18:26:51 +0200 Francesco Poli wrote:

> On Fri, 8 Oct 2010 22:58:42 +0200 Francesco Poli wrote:
[...]
> > Since Ryan will no longer be involved in apt-listbugs maintenance, I am
> > still looking for a co-maintainer.
> > Thanks in advance to anyone who volunteers for this task.
> 
> I will probably open a RFH bug report for this.

For the record, I filed the RFH bug report: it's #600879 ...

-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
..... Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpsNzNbVAtlX.pgp
Description: PGP signature

Re: Parsing output = derivative work? (was: RFS: gnetworktester)

[Francesco Poli]

On Sun, 6 Mar 2011 12:04:35 +0100 W. Martin Borgert wrote:

> (out of curiosity moved to debian-legal)

(I guess you intended to ask to keep the other recipients in Cc: if so,
you should ask explicitly)

> 
> On 2011-03-05 23:46, Timo Juhani Lindfors wrote:
> > gnetworktester seems to parse the output of nmap and nmap upstream at
> > http://insecure.org/nmap/data/COPYING gives me the impression that
> > gnetworktester would thus be "derivative work".
> 
> IANAL, but since when parsing the output of another program
> constitutes a derivative work?

IANAL either, but I don't think that parsing the output of a program
creates a derivative-base relationship...

> Indeed, the forementioned file
> says, a program would be a derivate in the authors
> interpretation of the GPL, if it
> 
> """
>  o Executes Nmap and parses the results (as opposed to typical shell or
>execution-menu apps, which simply display raw Nmap output and so are
>not derivative works.)
[...]
> """
> 
> What do the legal experts think about this, especially the
> parsing aspect?

It looks awkward, at least to me.

Even the FSF's interpretation (which stretches the definition of
derivative work quite a bit, in the attempt to defend the copyleft
mechanism of the GNU GPL) seems to assert that there's no derivation
going on, when the two programs "communicate at arms length" [1].

[1] http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem

I would say that two programs communicate "at arms length", when one
executes the other and parses its output... 

Let's anyway wait for the opinion of other debian-legal regulars.


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpotHwUdSUIx.pgp
Description: PGP signature

Re: RFS: apt-listbugs (updated package)

[Francesco Poli]

On Tue, 22 Mar 2011 12:20:10 +0100 Serafeim Zanikolas wrote:

> Hi,
> 
> > I am looking for a sponsor for the new version 0.1.4
> 
> I'll look at it this evening.

Thanks a lot!

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpeSMHfFIebh.pgp
Description: PGP signature

How to startx inside a pbuilder-managed chroot?

[Francesco Poli]

Hello,
I am not sure which list I should direct this question to: it's a
problem I am facing because I need to try and reproduce some bugs
inside a throw-away test environment (without risking to crash my real
boxes).
If there's a better Debian list where I can ask this question, please
suggest: I apologize in advance, if this is the case.

What I am trying to do (and failing miserably at) is to start an X
session inside a throw-away sid chroot environment.

The chroot environment has already been set up long ago and I keep it
updated.
A description of how I set up the sid chroot environment (by using
pbuilder) may be found at
http://www.inventati.org/frx/doc/nanodocs/testing_workstation_programming.html#setting-up-chroots-for-building-debian-packages

Here's what I tried. I closed my real X session, and logged in on my
first virtual console. From there, I logged into my sid chroot (in a
throw-away manner):

  $ sudo pbuilder login --configfile ~/.pbuilder/sid.conf

Then, inside the chroot, I installed the needed packages, among which:

  # aptitude install xorg
  # aptitude install fluxbox

I created a temporary regular user:

  # adduser --disabled-login niceguy
  # adduser niceguy video
  # adduser niceguy adm
  # passwd niceguy

and prepared a simple ~/.xsession file:

  # cat ~niceguy/.xsession
  fluxbox & MANAGERPID=$!
  xset r rate 400 40
  xset b off
  wait $MANAGERPID
  savelog -p -c 4 ~/.xsession-errors

I changed "allowed_users=console" into "allowed_users=anybody"
in /etc/X11/Xwrapper.config and then became the regular user
(but please note that I got the same errors as root!):

  # su - niceguy
  $ startx

I got an error that told me that X could not open tty0.
Indeed there's no /dev/tty0 in my sid chroot: it seems that
only /dev/tty is present.
Please note that I don't have external directories bind-mounted in the
chroot environment, since the pbuilder documentation seems to say that
it is considered harmful for the throw-away mode:
http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#chroot

I tried to manually create the device file:

  # mknod /dev/tty0 c 4 0
  # chown niceguy:tty /dev/tty0

After that, X refused to start with a different error message: cannot
open virtual console 7...


Please, someone more knowledgeable than me, tell me where I went
wrong!
I searched the web about running X inside chroot environments, but I
failed to find useful hints about my issue.
Thanks for any help you may provide!


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpTQAhrx2zbH.pgp
Description: PGP signature

Re: How to startx inside a pbuilder-managed chroot?

[Francesco Poli]

On Sat, 10 Sep 2011 22:07:21 +0200 Francesco Poli wrote:

> Hello,
[...]

I forgot to add that I am not subscribed to the list, hence please Cc:
me on replies.
Thanks!

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp2BOsi2rq8U.pgp
Description: PGP signature

Re: How to startx inside a pbuilder-managed chroot?

[Francesco Poli]

On Sun, 18 Sep 2011 02:42:54 +0900 Osamu Aoki wrote:

> Hi,

Hi Osamu, thanks a lot for your kind reply!

> 
> On Sat, Sep 10, 2011 at 10:07:21PM +0200, Francesco Poli wrote:
[...]
> > What I am trying to do (and failing miserably at) is to start an X
> > session inside a throw-away sid chroot environment.
> 
> I used to do this long time ago (4-5 years ago, I had methods in
> 
> Since X requires many devices to be shared, virtual environment seems to
> be realistic and simple for this.
> 
> Use kvm, qemu, virtualbox-ose, etc.  These are much safer through away
> environment with less complication.

I thought I could use a virtual machine, like, say, kvm, but there's a
problem, it seems.

If I understand correctly, with kvm, the guest system runs on a virtual
machine with virtual hardware that is not identical to the actual
hardware the host system runs on.
The most important tests I have to perform involve the
xserver-xorg-video-intel package: I need to run Intel video drivers
on an Intel integrated graphics chip, with DRI 3D acceleration
activated. If kvm makes the guest system see an emulated video card,
the guest system won't run Intel video drivers, and I won't be able
to reproduce the bugs...

Did I misunderstand something?
May I run Intel video drivers on my actual hardware from inside a kvm
virtual machine?

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpoPW6WotNa1.pgp
Description: PGP signature

Re: How to startx inside a pbuilder-managed chroot?

[Francesco Poli]

On Sun, 18 Sep 2011 03:22:24 +0300 Georgios M. Zarkadas wrote:

> Hi,

Hi everyone!

First of all: thanks to Georgios and to Osamu for their kind replies.

I have good news: I managed to start X inside my pbuilder-managed
chroot environment!   :-)
It was tricky and dirty, but it worked.
Moreover, the X session was not fully functional (xterm was not able to
start, as getpty returned an error: I had to start GVim and type in
commands through its :! shell...).
Anyway, I was able to perform the tests I had in mind.

If someone is interested in what was missing in my previous attempts,
I had to do the following (before  su - niceguy ):

  # mount -t sysfs sysfs /sys
  # vim /etc/init.d/udev
  (turn the first if statement in mount_tmpfs() into a comment, so that
   the script does not attempt to remount /dev after incorrectly
   assuming it is already mounted)
  # /etc/init.d/udev start

For this to succeed, I also had to stop udev *outside* the chroot
environment:

  # /etc/init.d/udev stop
  # umount /dev

All in all, it was very unpractical and dirty.
I would *not* recommend this procedure to anyone...

> 
> From the answers of the other participants of this thread so far, I
> think that the simpler solution for your case is to: 
> 
> i) Make a minimal sid installation in a usb hard disk with only the
> packages contained in the chroot plus the ones you want to test.
> 
> ii) Boot the real hardware (the box with the graphics card) from the usb
> disk, start X the usual way and perform the tests.
[...]
> This does not answer your original question of course (I don't have a
> good answer to that either) but it will allow you to do the job, with a
> different type of throw-away test environment.

I agree with Georgios' suggestion: next time I need something like
this, I'll look into live-build and try to create a custom Debian Live
with the packages I need.
Once this customized Debian Live image is written to a USB stick, I
will be able to boot the real hardware from the USB mass storage device
and perform all the tests I want.


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpfy55iYqSAH.pgp
Description: PGP signature

Re: fbpdf license doubt

[Francesco Poli]

On Fri, 09 Jan 2015 13:35:49 +1100 Riley Baird wrote:

[...]
> And third, pure technical problem is that package
> provides binaries `fbpdf` and `fbpdf2`, functionally identical, but
> having different dependencies. I am not sure what to do with it.
[...]

I would suggest to prepare two distinct binary packages, one for fbpdf
and the other for fbpdf2, with different dependencies.
The two binary packages could be built from the same source package or
from two distinct source packages, whichever solution you prefer.

I think the separation into two distinct binary packages is important,
especially for such a minimalistic program, because it would avoid
pulling unneeded dependencies, when you install one package on a
resource-limited system and you only want to use one of the two program
variants...



-- 
 http://www.inventati.org/frx/
 fsck is a four letter word...
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpcac7Vak1gc.pgp
Description: PGP signature

Re: fbpdf license doubt

[Francesco Poli]

On Fri, 09 Jan 2015 14:00:27 +1100 Ben Finney wrote:

> Riley Baird 
> writes:
[...]
> > First, it have no LICESNSE file, only main source file mention
> > modified BSD. I twice mailed author, but seems that he ignored my
> > request to add full-fledged LICENSE file.
> 
> The Debian Project should ideally have, not only license terms, but an
> explicit grant of license. Without that, there is reasonable doubt about
> whether in fact the recipient actually has any license in the work.
> 
> This is best done by a statement such as:
> 
> This is ‘fnordlib’. This work is free software: you are free to
> perform, modify, and/or reproduce this work, under the terms of the
> Apache License 2.0. See the file ‘LICENSE.ASF-2’ for exact terms.
[...]

I agree with what Ben wrote in his reply.

I would just like to make it clear that the Apache License v2.0 was
just an example of acceptable license: it's *not* the only choice to be
made for the package to be considered acceptable for inclusion in the
Debian archive!

The "Modified BSD" license is perfectly fine too, assuming that the
author of fbpdf means the 3-clause BSD license [1][2] when he/she says
"Modified BSD" license.

[1] https://spdx.org/licenses/BSD-3-Clause
[2] http://directory.fsf.org/wiki/License:BSD_3Clause

Moreover, any other license that makes the software comply with the
DFSG will do.

I hope this helps to clarify.
Bye.


-- 
 http://www.inventati.org/frx/
 fsck is a four letter word...
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpnMKTD0vIUV.pgp
Description: PGP signature

Bug#912736: RFS: apt-listbugs/0.1.25

[Francesco Poli]

On Sat, 3 Nov 2018 18:58:04 +0100 David Kalnischkies wrote:

> Hi,

Hello David, nice to see your reply!   :-)

> 
> On Sat, Nov 03, 2018 at 11:11:29AM +0100, Francesco Poli (wintermute) wrote:
> > Could someone please build the package from commit
> > [999e167ed8a45ce97283977ec534657b90d808fe],
> > and sponsor its upload to sid?
> 
>   Uploading apt-listbugs_0.1.25.dsc: done.
>   Uploading apt-listbugs_0.1.25.tar.xz: done.
>   Uploading apt-listbugs_0.1.25_amd64.buildinfo: done.
>   Uploading apt-listbugs_0.1.25_source.changes: done.
> Successfully uploaded packages.
> 
> Thanks for your contribution to Debian!

Thanks to you for your super-prompt response to my request for
sponsorship!

> 
> 
> Some "unrelated" remarks still:
> 
> >   * updated Homepage field in debian/control to point to the new home on
> > salsa.debian.org
> 
> Given you use the salsa URI as homepage I would suggest at least moving
> the ./debian/README.Debian to ./README.md if not writing a dedicated
> README.

That sounds like a reasonable suggestion: how can I still ship it in
the binary package? I guess I should add a debian/apt-listbugs.docs
file having "README.md" as its only line.
Is that right?

Or maybe I should split debian/README.Debian into a general README.md
and some more specialized doc/*.md documents (and list all of them in
debian/apt-listbugs.docs)...

> 
> Also, having some LICENSE file in ./ instead of relying on
> debian/copyright would give that URI more an image of a "homepage" of
> a native tool rather than a second Vcs-Browse of some packaging.

I had thought about doing so, but I could not figure out how to handle
the situation: what information should the LICENSE file contain?
Pretty the same as debian/copyright, I guess.

If this is indeed the case, then I would rather avoid keeping them
consistent (or even identical by copying one into the other) by hand.
But I have to keep debian/copyright in the source package, in order to
comply with Debian Policy (at least, it seems to me that there is a
"should" rule in [Policy 12.5]). At the same time, the LICENSE file
should committed to the git repository (otherwise Salsa will not see
it...). Hence, neither file can be generated at build time by copying
from the other.

Do you have a good solution for this impasse?!?

[Policy 12.5]: 
<https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile>

[...]
> > Thanks for your time and helpfulness!
> 
> Have we talked in the past about moving apt-listbugs under the APT team
> umbrella? Not sure if anyone of us speaks ruby enough to be of
> considerable help in this regard, but we have apt-file and even aptitude
> there, too.

Thanks a lot for offering this: what would it mean, exactly, from a
practical point of view? 

> 
> If you think that might be a good idea feel free to drop us a line on
> IRC #debian-apt or the mailinglist de...@lists.debian.org.

I will sure consider it as an option, depending on what you reply to
the above question.

> 
> 
> Oh and btw: You seem to maintain apt-listbugs for quite a while without
> issues, have you considered applying for DM?

Yes, I have considered applying for the DM status.
I just need to make up my mind, so thank you for encouraging me!   ;-p



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpBnEmNeHI9u.pgp
Description: PGP signature

Bug#912736: RFS: apt-listbugs/0.1.25

[Francesco Poli]

On Sat, 03 Nov 2018 19:40:09 + Dmitry Bogatov wrote:

> 
> [2018-11-03 11:11] "Francesco Poli (wintermute)" 
> > Hello everybody,
> > my usual sponsor has some blocking issues and is currently unable to
> > upload packages on my behalf.
> >
> > I prepared a new version of apt-listbugs (0.1.25): it is ready to be
> > uploaded.
> > Could someone please build the package from commit
> > [999e167ed8a45ce97283977ec534657b90d808fe],
> > and sponsor its upload to sid?
> 
> Sure. Uploaded.

Thanks for doing so, even though the upload had already been done by
David...

> Please consider makeing dep-5 `debian/copyright'.

Yes, I have been meaning to do so for quite some time (thanks anyway
for the suggestion!). First, I want to get rid of some obsolete stuff
(like some of the old tests, which should be replaced with more
autopkgtest tests)... Then I will definitely want to create a machine
readable debian/copyright file.

> Since you seems to be sole author, it should not be hard.

Well, it's not that simple, actually.
I am the sole current maintainer, but I am not the original author and
there have been a number of previous maintainers, co-authors,
contributors...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpKrhSpOoRsr.pgp
Description: PGP signature

Bug#912736: RFS: apt-listbugs/0.1.25

[Francesco Poli]

On Mon, 5 Nov 2018 00:39:48 +0100 Francesco Poli wrote:

[...]
> I had thought about doing so, but I could not figure out how to handle
> the situation: what information should the LICENSE file contain?
> Pretty the same as debian/copyright, I guess.
> 
> If this is indeed the case, then I would rather avoid keeping them
> consistent (or even identical by copying one into the other) by hand.
> But I have to keep debian/copyright in the source package, in order to
> comply with Debian Policy (at least, it seems to me that there is a
> "should" rule in [Policy 12.5]). At the same time, the LICENSE file
> should committed to the git repository (otherwise Salsa will not see
> it...). Hence, neither file can be generated at build time by copying
> from the other.
> 
> Do you have a good solution for this impasse?!?

After taking a look at how the same situation is handled in apt,
I guess I could:

 • only commit the LICENSE file to the git repository

 • then add the following lines to the debian/rules file:

 override_dh_clean:
 cp LICENSE debian/copyright
 dh_clean -O--buildsystem=ruby


That way, the debian/copyright file will not be stored in the git
repository, but will be present (as a copy of the LICENSE file) in the
Debian source package, thus complying with Debian Policy.

Did I get it right?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpSS9bwSXupE.pgp
Description: PGP signature

Bug#912736: RFS: apt-listbugs/0.1.25

[Francesco Poli]

On Wed, 14 Nov 2018 16:47:31 +0100 David Kalnischkies wrote:

[...]
> On Mon, Nov 05, 2018 at 12:39:48AM +0100, Francesco Poli wrote:
[...]
> > That sounds like a reasonable suggestion: how can I still ship it in
> > the binary package? I guess I should add a debian/apt-listbugs.docs
> > file having "README.md" as its only line.
> > Is that right?
> 
> Yes, that should work.

OK, I will try.

And then perhaps I will try and split the document into a general
README.md and some more specialized doc/*.md documents (and list all of
them in debian/apt-listbugs.docs), as I said...

[...]
> > what information should the LICENSE file contain?
> > Pretty the same as debian/copyright, I guess.
> 
> My remark was triggered by salsa proclaiming "No license. All rights
> reserved" which can be fixed just by having the GPL-2 text in a LICENSE
> file; so you don't need to maintain two files just an embedded copy of
> the text as "You should have received a copy of the GNU General Public
> License along with this program".

Well, but the LICENSE file should still be a correct summary of the
debian/copyright file: that's why I was assuming they should be two
copies of the same file (in order to avoid the burden of always having
to remember to check that a distinct LICENSE file still constitutes an
accurate summary of the licensing status...).

[...]
> You found out how apt is doing this in a later mail… but apt is really
> not a role-model here. In fact, it confuses salsa also, just less so.

How does this strategy confuse salsa?

> 
> src:apt should rename COPYING.GPL to COPYING and the original COPYING
> perhaps merged with AUTHORS while a dep5 debian/copyright is written…
> oh look, a butterfly! How pretty! … What was I talking about again?
> So yeah, it kinda works what apt is doing, but that doesn't mean its
> a good idea – it should in fact be changed, but there seem to be always
> better ways to "waste" our time. ;)

I am not sure I understand what are you suggesting me to do.
What would be the best practice?

[about the APT team umbrella]
> > Thanks a lot for offering this: what would it mean, exactly, from a
> > practical point of view?
> 
> Well, not sure given there are a lot of possibilities. Being in a team
> namespace rather than a user namespace has the advantage that it "looks"
> more official and access can be e.g. more easily granted to others in
> case of MIAs (but that of course never happens, thankfully). If the team
> would also be the "maintainer" we would have de...@lists.debian.org for
> discussion/bugs rather than a personal private mail inbox: The hoped for
> most practical change might be increased "cross-pollination" in
> bugreports then.

If the maintainer field is set to , then I would
obviously need to subscribe to that list, and the e-mail traffic
related to apt-listbugs would be intermingled with the rest of
the messages directed there. I am not sure I can afford such an
increase in my incoming e-mail traffic... Not in the short term, at
least...

Other than that, what else could formally show the moving of
apt-listbugs under the APT umbrella?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpn3JoJxyEed.pgp
Description: PGP signature

Bug#912736: RFS: apt-listbugs/0.1.25

[Francesco Poli]

On Fri, 16 Nov 2018 00:25:00 +0100 Francesco Poli wrote:

[...]
> If the maintainer field is set to , then I would
> obviously need to subscribe to that list, and the e-mail traffic
> related to apt-listbugs would be intermingled with the rest of
> the messages directed there. I am not sure I can afford such an
> increase in my incoming e-mail traffic... Not in the short term, at
> least...

On a second thought, I could set the maintainer field to ,
without subscribing to the mailing list, and then subscribe my e-mail
address to the apt-listbugs package tracker notifications...

That way, I would receive the e-mail traffic related to apt-listbugs,
as I currently do, but not the rest of  traffic.
At the same time, all the e-mail traffic related to apt-listbugs would
be directed to , so that bug reports would get more
visibility and others could have an opportunity to comment on them, etc.

Would that be OK with you?
Or is that too asymmetrical, perhaps?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpIsfzbBmXrs.pgp
Description: PGP signature

Bug#916658: closed by Bart Martens (closing RFS: apt-listbugs/0.1.26)

[Francesco Poli]

On Mon, 17 Dec 2018 22:25:35 + Bart Martens wrote:

> Package apt-listbugs version 0.1.26 is in unstable now.
> https://packages.qa.debian.org/apt-listbugs

Yes, I must thank Dmitry Bogatov for kindly sponsoring my upload!

Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpNIzABet48J.pgp
Description: PGP signature

Bug#916658: RFS: apt-listbugs/0.1.26

[Francesco Poli]

On Tue, 18 Dec 2018 13:18:59 + Dmitry Bogatov wrote:

[...]
> Uploaded.

Thanks a lot!  :-)

> You are not DM yet, aren't you?

Not yet, actually.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpKUtehREuSB.pgp
Description: PGP signature

Bug#919131: RFS: apt-listbugs/0.1.27

[Francesco Poli]

On Mon, 14 Jan 2019 16:42:28 + Dmitry Bogatov wrote:

[...]
> Uploaded.

Thank you so much, again!

> Still no dep5?

Unfortunately no... sorry.
I still have to find the time to tidy up the test suite a bit and then
I want to switch to the machine readable debian/copyright format.

Bye!

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpEJphYgwEEC.pgp
Description: PGP signature

How to properly drop an obsolete directory from a package

[Francesco Poli]

Hello Debian mentors,
I have a simple (or maybe not so simple) question I have not been able
to find documentation about.

I am the maintainer of the apt-listbugs package.
In some remote past (before year 2008), the program used to download
some indices which were stored in /var/cache/apt-listbugs/

Now those indices are no longer needed and there is some code to clean
them up in the postinst script:

# remove obsolete index files
for OLDFILE in /var/cache/apt-listbugs/*indices*
do
if test -f "$OLDFILE"
then
echo -n "Removing obsolete $OLDFILE ... "
rm -f "$OLDFILE"
echo "done"
fi
done

This cleanup code has been in place since 2009.
Hence I think that, at this point, no index file has probably survived
on any user's system.
But some user could have placed some other extraneous file
into /var/cache/apt-listbugs/
If this extraneous file does not include the string "indices" in its
name, it could have survived...


Now, I realized that this directory (/var/cache/apt-listbugs/) is still
created at package install time, since it is listed in the debian/dirs
file: 

  $ grep cache debian/dirs 
  var/cache/apt-listbugs/

but is currently useless (and has probably been so for a long time!).

I would like to drop this directory from the next version of
apt-listbugs.
How can I get rid of it?

Is dropping it from the debian/dirs file enough?

Will dpkg gracefully handle an upgrade for a user who has extraneous
files in /var/cache/apt-listbugs/ ?
Will it issue a warning saying "directory not empty, so not removed"?
Is this the Right Thing™ to do, when dealing with this kind of
situations?

Please take into account that the postrm script, when called with the
"purge" argument, removes the directory, along with all its content,
with the following command:

rm -rf /var/cache/apt-listbugs/

Should this be kept in the postrm script?

Or should it be moved to the postinst script, to replace the
above-mentioned index cleanup code?


Could you please clarify?
Thanks for your time and patience!


P.S.: Please Cc me on replies, as I am not subscribed to
  debian-mentors. Thanks!

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpuHPAwoTgjk.pgp
Description: PGP signature

Re: How to properly drop an obsolete directory from a package

[Francesco Poli]

On Fri, 30 Aug 2019 14:19:43 +0200 Dominique Dumont wrote:

> On Friday, 23 August 2019 23:04:30 CEST Francesco Poli wrote:
> > Please take into account that the postrm script, when called with the
> > "purge" argument, removes the directory, along with all its content,
> > with the following command:
> > 
> > rm -rf /var/cache/apt-listbugs/
> > 
> > Should this be kept in the postrm script?
> > 
> > Or should it be moved to the postinst script, to replace the
> > above-mentioned index cleanup code?
> 
> I would choose this solution and keep the cleanup code until next Debian 
> release.

Thanks for your answer, I'll try this way and see how it goes.

Bye!

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp9awS285Cv_.pgp
Description: PGP signature

Bug#912736: RFS: apt-listbugs/0.1.25

[Francesco Poli (wintermute)]

Package: sponsorship-requests
Severity: normal

Hello everybody,
my usual sponsor has some blocking issues and is currently unable to
upload packages on my behalf.

I prepared a new version of apt-listbugs (0.1.25): it is ready to be
uploaded.
Could someone please build the package from commit
[999e167ed8a45ce97283977ec534657b90d808fe],
and sponsor its upload to sid?

[999e167ed8a45ce97283977ec534657b90d808fe]: 


The changes since the last upload are:

  * updated VCS URLs to new salsa.debian.org locations in debian/control and
debian/copyright files, and in man page, as well
  * updated Homepage field in debian/control to point to the new home on
salsa.debian.org
  * updated Dutch translation, thanks to Frans Spiesschaert! (Closes: #900588)
  * bumped Standards-Version to 4.2.1: no changes needed
  * enhanced dealing with ignore_bugs files containing characters which cannot
be represented in the current locale (this is meant to be a fix for
the old bug #834557)


Thanks for your time and helpfulness!
Bye.

Bug#916658: RFS: apt-listbugs/0.1.26

[Francesco Poli (wintermute)]

Package: sponsorship-requests
Severity: normal

Hello everybody!

I prepared a new version of the apt-listbugs package (0.1.26):
it is ready to be uploaded to Debian unstable.
Could someone please build the package from commit
[c04fcb88ed8ba0f87c62d5711f394dd455231754], and sponsor its upload to
sid?

[c04fcb88ed8ba0f87c62d5711f394dd455231754]: 


The changes since the last upload are:

  * fixed "executes xdg-open as root user": implemented a way to drop root
privileges when invoking querybts or a browser, if we can figure out
which regular user became root (via "su -", "sudo", ...) and if
package s6 is installed (Closes: #910122)
  * added xdg-open to the list of possible ways to invoke an appropriate
web browser
  * enhanced interface consistency regarding external program (querybts
and web browser) invocation
  * enhanced error handling consistency regarding external program invocation
  * converted README.Debian into README.md (in markdown syntax) and
improved the document a bit
  * created FAQ.md by taking some parts from README.md
  * updated German translation, thanks to Chris Leick! (Closes: #914703)
  * updated Russian translation, thanks to Sergey Alyoshin! (Closes: #915374)
  * updated Portuguese translation, thanks to Miguel Figueiredo!
(Closes: #915802)
  * updated Italian translation, thanks to Luca Monducci!
  * updated Dutch translation, thanks to Frans Spiesschaert! (Closes: #916365)
  * updated Danish translation, thanks to Morten Bo Johansen! (Closes: #916384)
  * updated French translation, thanks to Jean-Baka Domelevo Entfellner!
(Closes: #916509)


Thank you so much for your time and dedication!
Bye.

Bug#919131: RFS: apt-listbugs/0.1.27

[Francesco Poli (wintermute)]

Package: sponsorship-requests
Severity: normal

Hi!

I have just finished preparing a new version of the apt-listbugs
package (0.1.27): it is ready to be uploaded to Debian sid.
Could someone please build the package from commit
[eb4d507254f84432405d36a8f563226a4f145522], and sponsor its upload
to unstable?

[eb4d507254f84432405d36a8f563226a4f145522]: 


The changes since the last upload are:

  * fixed "New error message /etc/cron.daily/apt-listbugs: logname: no
login name": enhanced logic to better cope with cases where logname
(or whoami) is not able to determine the user login (or effective)
name (Closes: #917059)
  * bumped Standards-Version to 4.3.0: no changes needed
  * updated Spanish translation, thanks to Jonatan Porras!
  * updated Swedish translation, thanks to Martin Bagge! (Closes: #918001)
  * bumped debhelper compatibility version to 12 by using the new method
based on versioned build-dependency on debhelper-compat: no other
changes needed
  * updated Norwegian Bokmål translation, thanks to Hans Fredrik Nordhaug!


Thanks a lot to anyone who will help!
Bye.

Bug#921228: RFS: apt-listbugs/0.1.28

[Francesco Poli (wintermute)]

Package: sponsorship-requests
Severity: normal

Hello!

Since I have received one late translation update, I thought I could
prepare a new version of the apt-listbugs package (0.1.28):
it is ready to be uploaded to Debian sid.
Could someone please build the package from commit
[18eb13976d33dc6f041255c74e3a8f55047f229b], and sponsor its upload
to unstable?

[18eb13976d33dc6f041255c74e3a8f55047f229b]: 


The only change since the last upload is:

   * updated Japanese translation, thanks to "victory"!


Thank you so much for your patience and helpfulness!
Bye.