Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

My original announcement was quite cautious.  I've also recently seen
an article in LWN which was also rather cautious.  I think it's
probably a good idea to set out what the current state of play is:

dgit's current functionality seems to be in reasonably good shape, but
it lacks additional features which are important in some workflows.


dgit currently supports the following situations very well for DDs:

 * You're are not the maintainer, and want to cherry pick a patch from
   upstream, apply a patch from the BTS, or whatever.  Ie, NMUs and
   private changes.

   In this situation you do not need to know anything about the source
   code management practices of the maintainer (unless the package is
   still using some kind of hideous old debian/rules-based patch
   system).  I recommend liberal use of git-clean and git-reset.

 * The package has an existing fast-forwarding git branch whose
   content is exactly the same as (or can easily be made the same as)
   the Debian source packages.


The following situations are not currently supported well:

 * Your signing and login keys are on a host which is distant from the
   build and test host.  Ie, debsign -r and debrsign.  If you have
   enough bandwidth you can work around this by copying the git tree
   and build outputs to your signing host and running dgit push there.

   I am working on improving this; it's a SMOP but not trivial.

 * You are not a DD.  Fixing this is sadly blocked on changes in
   Debian's infrastructure including ftp-master and alioth.  I have
   started those conversations but it looks like nothing is going to
   happen quickly.

   I don't think this limitation is acceptable so if it persists I
   will perpetrate some kind of guerrilla workarounds.  But I don't
   expect improvement on this front for at least a month or two.

 * You are the maintainer and want to have a quilty kind of workflow.

   If you are the maintainer and are currently using a git-based patch
   stack system, dgit fetch will at least convert NMUs (whether made
   with dgit or not) into git commit(s) for you to incorporate into
   your patch stack (git-cherry-pick etc.), and you can then use your
   existing workflow for build and upload.

   But dgit push won't work for you because your tip git commit
   probably isn't a fast forward from the last upload.  Supporting
   this workflow well in dgit push involves some significant design
   work.  I have been thinking about this but it's not trivial.


I should also mention a non-goal:

 * I have no plans to support a workflow where dgit's git tree
   contains different contents to the source packages.

   My view is that the source code is the source code.  If something
   is not needed for [d]git users then it is not needed in the Debian
   soure package either; conversely if you need to put something in
   the Debian source package then by definition it is source code and
   should be in your vcs too.

   Furthermore, because dgit's need to bidirectionally gateway between
   git and the archive, it is difficult for dgit to do this properly.
   For example, if there are files in the source package that weren't
   in the last git commit pushed with dgit, then the git trees
   synthesised by dgit from source package (which dgit fetch/clone
   makes when the last upload was not done with dgit) would contain
   those files.  So the files would seem to have been created by the
   non-dgit-using upload.

   dgit's goal is that you should be able to use dgit's git tree in
   all situations where you could have used the source package
   directly.  If there are things in the source package which aren't
   in the dgit git tree then that's not the case.

   It may be that this means that there need to be separate git
   branches for dgit and for the sparser source.


Thanks,
Ian.


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

Re: link with -L/usr/lib

[Samuel Thibault]

Let's discuss this on debian-devel. Here is what I answered to bug
723358 about hwloc.

Samuel Thibault, le Tue 17 Sep 2013 13:01:32 +0200, a écrit :
> YunQiang Su, le Tue 17 Sep 2013 18:38:26 +0800, a écrit :
> > This package has one or more -L/usr/lib in its build system,
> 
> Err, no, it doesn't.  Please recheck your build log carefully.  And
> don't do Mass Bug Filling without extra care, which includes discussing
> about it on debian-devel first!
> 
> > which will make it ftbfs if there is libraries under /usr/lib,
> > while is not the default architecture, mips* for example.
> > 
> > On mips* systems, /usr/lib is defined as place to hold O32
> > libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.
> 
> That's not necessarily a problem: a spurious -L/usr/lib does not hurt,
> the linker will simply not take the binaries.  It's only if -L/usr/lib
> is required for proper linking that it would be a problem.  But the
> compiler already has that in its search path, so there is really no
> problem.
> 
> > Beside the way, on the multiarch system like Debian, user may install
> > libraries under /usr/lib by hand.
> 
> No, they are not supposed to be doing that.
> 
> > The attachement is the buildlog of this package on mips64el platform.
> 
> The build didn't even start...

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130917110507.ga29...@type.bordeaux.inria.fr

Re: link with -L/usr/lib

[YunQiang Su]

sorry for huge mistake bugs report.

My program met some problem. I am shutdowning the wrong bugs.

On Tue, Sep 17, 2013 at 7:05 PM, Samuel Thibault  wrote:
> Let's discuss this on debian-devel. Here is what I answered to bug
> 723358 about hwloc.
>
> Samuel Thibault, le Tue 17 Sep 2013 13:01:32 +0200, a écrit :
>> YunQiang Su, le Tue 17 Sep 2013 18:38:26 +0800, a écrit :
>> > This package has one or more -L/usr/lib in its build system,
>>
>> Err, no, it doesn't.  Please recheck your build log carefully.  And
>> don't do Mass Bug Filling without extra care, which includes discussing
>> about it on debian-devel first!
>>
>> > which will make it ftbfs if there is libraries under /usr/lib,
>> > while is not the default architecture, mips* for example.
>> >
>> > On mips* systems, /usr/lib is defined as place to hold O32
>> > libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.
>>
>> That's not necessarily a problem: a spurious -L/usr/lib does not hurt,
>> the linker will simply not take the binaries.  It's only if -L/usr/lib
>> is required for proper linking that it would be a problem.  But the
>> compiler already has that in its search path, so there is really no
>> problem.
>>
>> > Beside the way, on the multiarch system like Debian, user may install
>> > libraries under /usr/lib by hand.
>>
>> No, they are not supposed to be doing that.
>>
>> > The attachement is the buildlog of this package on mips64el platform.
>>
>> The build didn't even start...
>
> Samuel



-- 
YunQiang Su


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cakcpw6xvyjuh5qb6wfggum1h6ft-eqmbebjhqflf-upoyqw...@mail.gmail.com

Re: link with -L/usr/lib

[Samuel Thibault]

YunQiang Su, le Tue 17 Sep 2013 19:06:54 +0800, a écrit :
> sorry for huge mistake bugs report.
> 
> My program met some problem.

Please discuss here before starting any automated bug filling.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130917111026.gj5...@type.bordeaux.inria.fr

Re: link with -L/usr/lib

[Samuel Thibault]

YunQiang Su, le Tue 17 Sep 2013 19:06:54 +0800, a écrit :
> I am shutdowning the wrong bugs.

You mean only the wrong bugs, not completely all of them?  If your
program had troubles submitting the right ones, I'm afraid it will have
troubles closing the wrong ones.  Just close all of them and submit your
program here with rationale before starting it.

Also, I'm really unconvinced -L/usr/lib does really bring any problem
anyway, see what I wrote:

On Tue, Sep 17, 2013 at 7:05 PM, Samuel Thibault  wrote:
> > which will make it ftbfs if there is libraries under /usr/lib,
> > while is not the default architecture, mips* for example.
> >
> > On mips* systems, /usr/lib is defined as place to hold O32
> > libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.
>
> That's not necessarily a problem: a spurious -L/usr/lib does not hurt,
> the linker will simply not take the binaries.  It's only if -L/usr/lib
> is required for proper linking that it would be a problem.  But the
> compiler already has that in its search path, so there is really no
> problem.
>
> > Beside the way, on the multiarch system like Debian, user may install
> > libraries under /usr/lib by hand.
>
> No, they are not supposed to be doing that.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130917112330.gm5...@type.bordeaux.inria.fr

Re: link with -L/usr/lib

[YunQiang Su]

On Tue, Sep 17, 2013 at 7:23 PM, Samuel Thibault  wrote:
> YunQiang Su, le Tue 17 Sep 2013 19:06:54 +0800, a écrit :
>> I am shutdowning the wrong bugs.
>
> You mean only the wrong bugs, not completely all of them?  If your
> program had troubles submitting the right ones, I'm afraid it will have
> troubles closing the wrong ones.  Just close all of them and submit your
> program here with rationale before starting it.
There is about 200 true bugs report, while another about 300 is invaild

>
> Also, I'm really unconvinced -L/usr/lib does really bring any problem
> anyway, see what I wrote:
Yes, we can talk about it here.

Say sorry again.
>
> On Tue, Sep 17, 2013 at 7:05 PM, Samuel Thibault  wrote:
>> > which will make it ftbfs if there is libraries under /usr/lib,
>> > while is not the default architecture, mips* for example.
>> >
>> > On mips* systems, /usr/lib is defined as place to hold O32
>> > libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.
>>
>> That's not necessarily a problem: a spurious -L/usr/lib does not hurt,
>> the linker will simply not take the binaries.  It's only if -L/usr/lib
>> is required for proper linking that it would be a problem.  But the
>> compiler already has that in its search path, so there is really no
>> problem.
>>
>> > Beside the way, on the multiarch system like Debian, user may install
>> > libraries under /usr/lib by hand.
>>
>> No, they are not supposed to be doing that.
>
> Samuel



-- 
YunQiang Su


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKcpw6X6-8WazWV1XxG_zogwX71Fv4KZCRfXYNoA5b=rzbv...@mail.gmail.com

Re: tlsa for smtp to bugs.debian.org

[Thorsten Glaser]

Ian Jackson  chiark.greenend.org.uk> writes:

> > Curiously, the optional ephemeral Diffie-Hellman part of the TLS
> > protocol runs in plaintext, which means that it can be attacked
> > directly, without bothering to attack the RSA part.  As a result, that

> I diagree.  Forward secrecy is generally an important improvement.

Only if it provides secrecy.

If one of the communication partners (say, the client, because it’s
on a mobile) uses a guessable secret (say, due to lack of entropy),
the session is lost.

IMHO TLS should be changed to encrypt the DHE part (possibly with
an anon RSA key on the client side (which may be short- or medium-
lived) plus the server RSA key, *and* each party should send some
entropy to the other party before DHE kex happens (which the other
side may/should stir into their own RNG).

Of course, using a medium-lived RSA key for _that_ on the server
side (say, one regenerated every week) will provide additional
secrecy, as it can’t be forced out even by LEOs if it no longer
exists (has been properly purged after the week).

But looking at the sad state in SChannel… no chance.

Florian, what about switching to sign-only RSA server certs and
letting the server use ephemeral RSA encryption keypairs for the
actual session? Haven’t thought too long on that yet. (Probably
even slower, but then we’ve at least got an established slider
between fast and secure.)

bye,
//mirabilos, who wanted to write this up weeks ago and never
got around to do so


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20130917t145055-...@post.gmane.org

Re: detecting autopkgtest

[Ian Jackson]

Enrico Tassi writes ("Re: detecting autopkgtest"):
> On Mon, Sep 16, 2013 at 03:08:12PM +0200, Jakub Wilk wrote:
> > There's a hidden assumption here that adt is the only thing that
> > will ever run the tests.
> 
> Correct me if I'm wrong, but given http://dep.debian.net/deps/dep8/
> any implementation of DEP8 should define ADTTMP, sadt included.

Yes.  I guess you might be worried, though, that ADTTMP might be set
in some other circumstances.  And testing for that variable does seem
to be something of a bodge: having the behaviour of the tests changed
so radically due to setting a vaguely-TMPDIR-like variable doesn't
seem very pretty.  So I can see why you don't want to do that.

For now I recommend the solution suggested by Niels Thykier.

If you want another variable then that would be a spec change for the
DEP8 test declaration spec, and you'd probably want to define a new
restriction for it.

> The variable name may be badly chosen, since it is named after a
> particular test runner.

I didn't distinguish the name of the test runner from the name of what
is now thought of as the DEP-8 spec.  I think this was the right
choice at the time, compared to the alternative which would then have
been to have two names for two aspects of what at the time was one
thing.

I suggest that we should continue to conflate the names of the initial
runner implementation and of the test specification format.  Indeed
"sadt" has borrowed autopkgtest's "adt" name, entirely properly IMO.

Thanks,
Ian.


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

Re: link with -L/usr/lib

[Osamu Aoki]

Hi,

Now I see he really filed many similar bugs ...  I saw it for libucimf:
 http://bugs.debian.org/722802

It did not make sense to me.

This libucimf package was not multiarch.  So use of -L/usr/lib/ made
sense.  I took it as a wishlist request to convert package to multiarch.
So I made it as multiarch after his bug report and closed his bug.

Please note we can not always call -L/usr/lib or similar to be wrong for
multiarch.

I have "Multiarch: same" package (ibus-anthy) installs files like 
   /usr/lib/ibus/ibus-setup-anthy

I have "Multiarch: foreign" package (libucimf0) installs files like
   /usr/lib/x86_64-linux-gnu/libucimf.so.0.0.0

I used --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) in debian/rules for the
second case just to be safe.  But I think with debhelper compat level 9,
this may be the default.  Please cut out strange logic around mips
etc...  

The mass bug filing should be done only after people agree to file such
bugs.  I think adding lintian warnings may be better at this moment.

If you file, please make such requests as wishlist to convert package to
multiarch.  
  (You may add reminder that -L and --libexecdir with /usr/lib 
   in debian/rules may needs to be changed for such conversion.)
Point people to read:
  https://wiki.debian.org/Multiarch/Implementation

Regards,

Osamu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130917142432.GB10796@goofy.localdomain

Re: tlsa for smtp to bugs.debian.org

[Russ Allbery]

Thorsten Glaser  writes:

> Only if it provides secrecy.

> If one of the communication partners (say, the client, because it’s on a
> mobile) uses a guessable secret (say, due to lack of entropy), the
> session is lost.

I think that statement is somewhat too absolute.  There are levels of
protection that you can get, and guessable secrets still require someone
do the work of guessing.  Even if you're using a straight pseudorandom
number generator, the attacker still has to do some non-trivial work.

If you, specifically, are a target of a government agency, that probably
isn't going to help.  However, if you're just interested in avoiding
getting sucked into the casual dragnet, it helps quite a bit, since it
puts the complexity of an attack over the value of your data.

Schneier made this point recently and it's worth repeating: security isn't
about making your data perfectly secure.  Security is about increasing the
cost of getting at your data to more than your data is worth to the
attacker.  While strong security is obviously better since it's easier to
satisfy that requirement, weaker security is not worthless.

That said, your suggestions for making the security stronger are certainly
welcome, and that's always what we should strive for.  I just wanted to
make a minor point here about not letting the best be the enemy of the
good.  While we're working on something better, it's still worthwhile to
deploy the tools we have.

-- 
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
Archive: http://lists.debian.org/87ioxzmnws@windlord.stanford.edu

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Russ Allbery writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> Ian Jackson  writes:
> > I should also mention a non-goal:
...
> >  * I have no plans to support a workflow where dgit's git tree
> >contains different contents to the source packages.
...
> I believe, if I understand this correctly, this will cause problems for
> the use of local-options and local-patch-header to set single-debian-patch
> for maintainer uploads.

I'm not sure what you mean, but I don't think so.  Mind you I haven't
actually tested this with any such package.

If you have one you wouldn't mind me uploading to experimental, I
could try it.

Ian.


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

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Julien Cristau]

On Tue, Sep 17, 2013 at 11:43:29 +0100, Ian Jackson wrote:

> I should also mention a non-goal:
> 
>  * I have no plans to support a workflow where dgit's git tree
>contains different contents to the source packages.
> 
To me the tree that matters is the one after debian/rules clean, not
dpkg-source -x.  For most of the packages I touch, a lot of files get
removed by debian/rules clean.  Does the above mean that dgit will only
look at the tree as extracted by dpkg-source?

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Steve Langasek]

On Tue, Sep 17, 2013 at 10:54:57AM -0700, Russ Allbery wrote:
> Ian Jackson  writes:
> > Russ Allbery writes:

> >> debian/source/local-options and debian/source/local-patch-header are
> >> included in the working Git repository for the package but are not
> >> included in the source package as uplaoded to Debian.  (Yes, this means
> >> that they're somewhat directly contrary to the whole point of dgit.
> >> However, they're the best available mechanism to use a single patch for
> >> all changes with the 3.0 (quilt) package format if one doesn't want to
> >> attempt to track changes as separate patches.)

> > So dpkg-source strips these options files out when it builds the
> > package ?

> Correct.

> > Surely then if someone does an NMU based on the source package the
> > "single debian patch"ness will be lost ?

> Correct, and that's partly the point.  It means that the maintainer
> changes are collected into one patch, but NMU patches are kept separate
> from that one patch.  (So I guess I misspoke -- it's not exactly like the
> 1.0 format patch situation.  It's like that for the maintainer, but
> maintains separate NMU patches.)

Or patches in a downstream distribution.  I consider local-options to be a
horrible misfeature in the current dpkg-source.

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


signature.asc
Description: Digital signature

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Russ Allbery writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> Ian Jackson  writes:
> > I guess that you think I'm saying that the series of git commits in the
> > dgit history must correspond to the series of patches found in the
> > source package.
> 
> debian/source/local-options and debian/source/local-patch-header are
> included in the working Git repository for the package but are not
> included in the source package as uplaoded to Debian.  (Yes, this means
> that they're somewhat directly contrary to the whole point of dgit.
> However, they're the best available mechanism to use a single patch for
> all changes with the 3.0 (quilt) package format if one doesn't want to
> attempt to track changes as separate patches.)

So dpkg-source strips these options files out when it builds the
package ?  Surely then if someone does an NMU based on the source
package the "single debian patch"ness will be lost ?

> Feel free to experiment with krb5-sync in experimental, since I'm about to
> release a new version, so there will be an upload that will clear out any
> NMUs in experimental as out of date before too much longer.

I'll see if I can take a look at this this evening.

Ian.


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

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Russ Allbery]

Ian Jackson  writes:

> Does dpkg-source provide a way to collapse all the patches into one ?
> If so you could use that before doing dgit push, and have much the same
> effect.

Well, you can always run dpkg-source with --single-debian-patch and figure
out how to plug that into your local build system.  That doesn't help with
the patch header, though; if you create a file called source/patch-header,
then that header will be applied by default to any patches created by
dpkg-source.  Which is probably not appropriate.

> Or you could simply ignore the format `3.0 (quilt)' thing entirely and
> allow it to automatically accumulate one diff per upload, and presumably
> clean it out occasionally.

I think what happens there is that the version number of the patch keeps
changing, but for my workflow I never full-circle the built Debian package
back to the Git repository, so there's nothing to clean out.  But the
patch header will be wrong.

-- 
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
Archive: http://lists.debian.org/87y56vjpa9@windlord.stanford.edu

Bug#723591: ITP: libcatmandu-perl -- suite of Perl modules to ease the import, storage, retrieval, export and transformation of metadata records

[Vasudev Kamath]

Package: wnpp
Severity: wishlist
Owner: Vasudev Kamath 

* Package name: libcatmandu-perl
  Version : 0.7002
  Upstream Author : Nicolas Steenlant 
* URL : https://metacpan.org/module/Catmandu
* License : Artistic or GPL-1+
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description :  metadata tool kit

 Catmandu provides a suite of Perl modules to ease the import, storage,
 retrieval, export and transformation of metadata records. Combine
 Catmandu modules with web application frameworks such as PSGI/Plack,
 document stores such as MongoDB and full text indexes such as Solr to
 create a rapid development environment for digital library services such
 as institutional repositories and search engines.


-- 
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4  C96B 6C8F 74AE 8770 0B7E


signature.asc
Description: Digital signature

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Julien Cristau writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> On Tue, Sep 17, 2013 at 11:43:29 +0100, Ian Jackson wrote:
> > I should also mention a non-goal:
> > 
> >  * I have no plans to support a workflow where dgit's git tree
> >contains different contents to the source packages.
> >
> To me the tree that matters is the one after debian/rules clean, not
> dpkg-source -x.  For most of the packages I touch, a lot of files get
> removed by debian/rules clean.  Does the above mean that dgit will only
> look at the tree as extracted by dpkg-source?

Yes.  The "tree of the source package" is the what you get from
dpkg-source -x.

TBPH I think it's a bug if build followed by clean doesn't restore the
package to the state you got out of dpkg-source.  I don't want to
argue that as a policy change right now, but I don't have much
interest in adding code to dgit to better support the maintainers of
packages which are broken in this way.

You can just use git clean and git reset of course, so this doesn't
stop you using dgit.

In particular, if the package you are working with leaves droppings in
the source tree which its clean target doesn't pick up,
  dgit sbuild -wg
will use git-clean to remove them before building the source package.
So your source package won't contain the droppings.

Or do you mean that you have files in your git branch which are
removed by debian/rules clean ?  (I'm no longer ruling anything out
merely on the grounds that it would be utterly insane...)

Ian.


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

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Ian Jackson writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> In particular, if the package you are working with leaves droppings in
> the source tree which its clean target doesn't pick up,
>   dgit sbuild -wg
> will use git-clean to remove them before building the source package.
> So your source package won't contain the droppings.

I mean
  dgit -wg sbuild

Ian.


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

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Russ Allbery writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> Ian Jackson  writes:
> > Or you could simply ignore the format `3.0 (quilt)' thing entirely and
> > allow it to automatically accumulate one diff per upload, and presumably
> > clean it out occasionally.
> 
> I think what happens there is that the version number of the patch keeps
> changing, but for my workflow I never full-circle the built Debian package
> back to the Git repository, so there's nothing to clean out.  But the
> patch header will be wrong.

dgit push runs dpkg-source --commit and automatically generates a new
patch name and a new patch header.

NMUers not using dgit have to run dpkg-source --commit themselves.

In either case you get a _new_ patch for each upload, I think.

But really, this kind of history should be being extracted from git,
not from the source package.  The whole point of dgit is not to have
to care about the archive's (and now dpkg-source's) strange ideas
about source package formats.

Ian.


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

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Russ Allbery]

Steve Langasek  writes:
> On Tue, Sep 17, 2013 at 10:54:57AM -0700, Russ Allbery wrote:

>> Correct, and that's partly the point.  It means that the maintainer
>> changes are collected into one patch, but NMU patches are kept separate
>> from that one patch.  (So I guess I misspoke -- it's not exactly like
>> the 1.0 format patch situation.  It's like that for the maintainer, but
>> maintains separate NMU patches.)

> Or patches in a downstream distribution.

Indeed, which is what I want as maintainer.

-- 
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
Archive: http://lists.debian.org/87txhjjoif@windlord.stanford.edu

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Russ Allbery writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> Ian Jackson  writes:
> > So dpkg-source strips these options files out when it builds the
> > package ?
> 
> Correct.

Oh my god.

> > Surely then if someone does an NMU based on the source package the
> > "single debian patch"ness will be lost ?
> 
> Correct, and that's partly the point.  It means that the maintainer
> changes are collected into one patch, but NMU patches are kept separate
> from that one patch.  (So I guess I misspoke -- it's not exactly like the
> 1.0 format patch situation.  It's like that for the maintainer, but
> maintains separate NMU patches.)

I think the answer is that in this situation the maintainer can't use
dgit push.  I think the idea that dgit push should do different things
for the maintainer and an NMUer is pretty repulsive.  It is this kind
of craziness that I was trying to get away from.

Does dpkg-source provide a way to collapse all the patches into one ?
If so you could use that before doing dgit push, and have much the
same effect.

Or you could specify the single Debian patch in debian/options rather
than local-options, and pick up NMUs out of git.  dgit fetch will make
commit(s) containing the NMU changes for you, although currently
you may end up with multiple NMUs squashed into a single git commit.

Or you could simply ignore the format `3.0 (quilt)' thing entirely and
allow it to automatically accumulate one diff per upload, and
presumably clean it out occasionally.

Ian.


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

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Russ Allbery]

Ian Jackson  writes:

> Or do you mean that you have files in your git branch which are removed
> by debian/rules clean ?  (I'm no longer ruling anything out merely on
> the grounds that it would be utterly insane...)

This is common.  Usually it's because upstream ships generated files in
the upstream tarball as well as source files.  As part of building the
Debian package from source, one wants to remove all generated files and
recreate them.  Deleting those files in debian/rules clean is an obvious
way to go about this.

Munging the upstream source to remove all the generated files means
diverging from the upstream source tarball and losing verifiability, etc.

See xfonts-jmk for a complex example.  See shibboleth-sp2 for a package
that has one generated file also included in the package which is changed
as part of the build process.  I don't want to keep carrying a diff for
that file, so I remove it in debian/rules clean.  This means that
debian/rules clean doesn't restore the source to exactly the same state as
an unpack, but it's in *functionally* the same state since that file will
be regenerated as part of a build and no useful information has been lost.

Saving all the build products and restoring them on debian/rules clean is
more trouble than I have any interest in doing, although patches are
welcome, I suppose.

There used to be far more of these, but dh-autoreconf goes to the effort
of stashing the files and restoring them on debian/rules clean, since
someone did the effort of centralizing that support in one place.  But
it's a lot of work to expect individual maintainers to do for one-off
cases.

-- 
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
Archive: http://lists.debian.org/87pps7jocj@windlord.stanford.edu

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Ian Jackson]

Ian Jackson writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
Debian branches)"):
> Russ Allbery writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
> Debian branches)"):
> > Ian Jackson  writes:
> > > I should also mention a non-goal:
> ...
> > >  * I have no plans to support a workflow where dgit's git tree
> > >contains different contents to the source packages.
> ...
> > I believe, if I understand this correctly, this will cause problems for
> > the use of local-options and local-patch-header to set single-debian-patch
> > for maintainer uploads.
> 
> I'm not sure what you mean, but I don't think so.

Ah, wait, I think maybe I can speculate as to what you mean.

I guess that you think I'm saying that the series of git commits in
the dgit history must correspond to the series of patches found in the
source package.

But no, that's not what I mean.  I just mean that the git tree object
referenced by the commit (that is, the set of files and directories in
that commit) must be identical to the tree yielded by unpacking the
source package.

There is no requirement on the shape of the history of the commit on
which you run dgit push, other than that it is a fast-forward on the
dgit suite branch.  Specifically the commit you push must be a
descendant of dgit's idea of the current state of the archive (which
might be a synthetic commit representing a non-dgit upload, or a
commit previously subjected to dgit push).

Ian.


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

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Julien Cristau]

On Tue, Sep 17, 2013 at 19:19:22 +0100, Ian Jackson wrote:

> Julien Cristau writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
> Debian branches)"):
> > On Tue, Sep 17, 2013 at 11:43:29 +0100, Ian Jackson wrote:
> > > I should also mention a non-goal:
> > > 
> > >  * I have no plans to support a workflow where dgit's git tree
> > >contains different contents to the source packages.
> > >
> > To me the tree that matters is the one after debian/rules clean, not
> > dpkg-source -x.  For most of the packages I touch, a lot of files get
> > removed by debian/rules clean.  Does the above mean that dgit will only
> > look at the tree as extracted by dpkg-source?
> 
> Yes.  The "tree of the source package" is the what you get from
> dpkg-source -x.
> 
> TBPH I think it's a bug if build followed by clean doesn't restore the
> package to the state you got out of dpkg-source.  I don't want to
> argue that as a policy change right now, but I don't have much
> interest in adding code to dgit to better support the maintainers of
> packages which are broken in this way.
> 
> You can just use git clean and git reset of course, so this doesn't
> stop you using dgit.
> 
> In particular, if the package you are working with leaves droppings in
> the source tree which its clean target doesn't pick up,
>   dgit sbuild -wg
> will use git-clean to remove them before building the source package.
> So your source package won't contain the droppings.
> 
> Or do you mean that you have files in your git branch which are
> removed by debian/rules clean ?  (I'm no longer ruling anything out
> merely on the grounds that it would be utterly insane...)
> 
No, I mean the upstream tarball contains autotools-generated files that
debian/rules deletes (and that aren't in my, or upstream's, git tree).
dpkg-source ignores removals when generating the debian diff, so they're
extracted by dpkg-source -x, but since the first step after that is
pretty much always debian/rules clean, they're irrelevant.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Russ Allbery]

Ian Jackson  writes:
> Russ Allbery writes:

>> debian/source/local-options and debian/source/local-patch-header are
>> included in the working Git repository for the package but are not
>> included in the source package as uplaoded to Debian.  (Yes, this means
>> that they're somewhat directly contrary to the whole point of dgit.
>> However, they're the best available mechanism to use a single patch for
>> all changes with the 3.0 (quilt) package format if one doesn't want to
>> attempt to track changes as separate patches.)

> So dpkg-source strips these options files out when it builds the
> package ?

Correct.

> Surely then if someone does an NMU based on the source package the
> "single debian patch"ness will be lost ?

Correct, and that's partly the point.  It means that the maintainer
changes are collected into one patch, but NMU patches are kept separate
from that one patch.  (So I guess I misspoke -- it's not exactly like the
1.0 format patch situation.  It's like that for the maintainer, but
maintains separate NMU patches.)

-- 
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
Archive: http://lists.debian.org/874n9jl4em@windlord.stanford.edu

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Adam Borowski]

On Tue, Sep 17, 2013 at 07:02:04PM +0100, Ian Jackson wrote:
> Does dpkg-source provide a way to collapse all the patches into one ?
> If so you could use that before doing dgit push, and have much the
> same effect.
> 
> Or you could specify the single Debian patch in debian/options rather
> than local-options, and pick up NMUs out of git.  dgit fetch will make
> commit(s) containing the NMU changes for you, although currently
> you may end up with multiple NMUs squashed into a single git commit.
> 
> Or you could simply ignore the format `3.0 (quilt)' thing entirely and
> allow it to automatically accumulate one diff per upload, and
> presumably clean it out occasionally.

There's more to "3.0 (quilt)" than just quilt:
* multiple tarballs (good)
* a way to include binaries without uuencode (good)
* upstream debian/ is nuked (sometimes good, at worst a minor waste of
  space and a minor inconvenience)

Here's one way:
rm -rf .pc debian/patches
echo single-debian-patch >>debian/source/options

The rm needs to be repeated, either in the "clean" target or perhaps by
dgit.

This turns "3.0 (quilt)" into "3.0 (sane)" and allows using version
control without having to go out of your way to work around quilt.

And since dgit is all about version control, I guess this is what you
want.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130917190652.ga22...@angband.pl

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Colin Watson]

On Tue, Sep 17, 2013 at 11:27:08AM -0700, Russ Allbery wrote:
> There used to be far more of these, but dh-autoreconf goes to the effort
> of stashing the files and restoring them on debian/rules clean, since
> someone did the effort of centralizing that support in one place.

Sadly, it doesn't - it just remembers which ones were changed, and
removes them on clean.  I think this is a bug, although it hasn't
stopped me using dh-autoreconf since it's such an improvement on what I
was doing before in just about every other way.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130917192958.ga11...@riva.ucam.org

Bug#723609: ITP: blogofile-blog -- Blogofile plugin implementing a basic blog engine

[Jakob Haufe]

Package: wnpp
Severity: wishlist
Owner: Jakob Haufe 

* Package name: blogofile-blog
  Version : 0.8b1
  Upstream Author : Ryan McGuire 
* URL : http://www.blogofile.com/
* License : MIT
  Programming Lang: Python
  Description : Blogofile plugin implementing a basic blog engine

 This is a plugin for Blogofile that impleents a basic blog engine.

 It provides a collection of Mako template files along with CSS and ancillary
 files, all derived from the HTML5Boilerplate project.
 It also provided Blogofile_ configuration, controllers, filters, and commands
 to allow you to create a simple blog engine that requires no database and no
 special hosting environment.

 The templates include features like:

 * Custom web fonts from Google
 * Disqus comments
 * Google Analytics tracking code stub
 * seaofclouds jQuery twitter plugin







   * plugin


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

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Russ Allbery]

Colin Watson  writes:
> On Tue, Sep 17, 2013 at 11:27:08AM -0700, Russ Allbery wrote:

>> There used to be far more of these, but dh-autoreconf goes to the
>> effort of stashing the files and restoring them on debian/rules clean,
>> since someone did the effort of centralizing that support in one place.

> Sadly, it doesn't - it just remembers which ones were changed, and
> removes them on clean.  I think this is a bug, although it hasn't
> stopped me using dh-autoreconf since it's such an improvement on what I
> was doing before in just about every other way.

Oh, I thought it did.  So yeah, there's still a *ton* of that in the
archive.  I use dh-autoreconf for every package that I have that uses
autotools, for example.

-- 
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
Archive: http://lists.debian.org/874n9jxmhc@windlord.stanford.edu

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Russ Allbery]

Ian Jackson  writes:

> I should also mention a non-goal:

>  * I have no plans to support a workflow where dgit's git tree
>contains different contents to the source packages.

>My view is that the source code is the source code.  If something
>is not needed for [d]git users then it is not needed in the Debian
>soure package either; conversely if you need to put something in
>the Debian source package then by definition it is source code and
>should be in your vcs too.

>Furthermore, because dgit's need to bidirectionally gateway between
>git and the archive, it is difficult for dgit to do this properly.
>For example, if there are files in the source package that weren't
>in the last git commit pushed with dgit, then the git trees
>synthesised by dgit from source package (which dgit fetch/clone
>makes when the last upload was not done with dgit) would contain
>those files.  So the files would seem to have been created by the
>non-dgit-using upload.

I believe, if I understand this correctly, this will cause problems for
the use of local-options and local-patch-header to set single-debian-patch
for maintainer uploads.

-- 
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
Archive: http://lists.debian.org/87mwnbmo57@windlord.stanford.edu

Re: UTF-8 in jessie

[Jakub Wilk]

* Adam Borowski , 2013-08-12, 02:51:

Detecting non-UTF files is easy:
* false positives are impossible
* false negatives are extremely unlikely: combinations of letters that would 
happen to match a valid utf character don't happen naturally, and even if they 
did, every single combination in the file tested would need to match valid 
utf.


Not+IAo-quite. While 7-bit encodings different than ASCII are all endangered 
species, some of them can still be seen in the wild, and they excellently 
disguise themselves as UTF-8. (We had to add special code to detect ISO-2022 
encodings to Lintian not that long ago.)


Anyway, it you want to help UTF-8-ize the world, you could start by providing 
patches for these bugs:

http://lintian.debian.org/tags/debian-changelog-file-uses-obsolete-national-encoding.html
http://lintian.debian.org/tags/debian-copyright-file-uses-obsolete-national-encoding.html
http://lintian.debian.org/tags/doc-base-file-uses-obsolete-national-encoding.html

--
Jakub Wilk


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

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Steve Langasek]

On Tue, Sep 17, 2013 at 07:19:22PM +0100, Ian Jackson wrote:
> Julien Cristau writes ("Re: Status of dgit (good for NMUs and fast-forwarding 
> Debian branches)"):
> > On Tue, Sep 17, 2013 at 11:43:29 +0100, Ian Jackson wrote:
> > > I should also mention a non-goal:
> > > 
> > >  * I have no plans to support a workflow where dgit's git tree
> > >contains different contents to the source packages.
> > >
> > To me the tree that matters is the one after debian/rules clean, not
> > dpkg-source -x.  For most of the packages I touch, a lot of files get
> > removed by debian/rules clean.  Does the above mean that dgit will only
> > look at the tree as extracted by dpkg-source?

> Yes.  The "tree of the source package" is the what you get from
> dpkg-source -x.

> TBPH I think it's a bug if build followed by clean doesn't restore the
> package to the state you got out of dpkg-source.  I don't want to
> argue that as a policy change right now, but I don't have much
> interest in adding code to dgit to better support the maintainers of
> packages which are broken in this way.

My understanding is that the current policy implies that the 'dpkg-source -x'
-> './debian/rules clean' -> 'dpkg-source -b' round-trip should be
idempotent for all practical purposes, just as the './debian/rules build' ->
'./debian/rules clean' round-trip should be.  So if ./debian/rules clean
does something to a checkout of your branch, then that branch seems not to
be a complete representation of the source package.

There are various reasons this might be the case - for instance,
autogenerated autotools output that you want shipped in the source package
but don't store in the repository - but these all still amount to imperfect
representations of the source package, and dgit shouldn't cater to them.
Either debian/rules clean should be fixed to not leave droppings, or if the
output is not 'droppings', it should be part of the VCS history.

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


signature.asc
Description: Digital signature

Decision on R datasets

[Joerg Jaspert]

Hi,

it came to our attention[0] that most R packages ship data files (*.Rda,
*.Rdata), which can contain a lot of different kind of data, from
command line instructions, to huge data tables, or even extra modules
loaded by means of install.packages() function.

It is common practice for R packages to fully document the content of
the data files in .Rd files shipped in the source tarball[1], so it
becomes easier to determine which kind of information those data files
provide.

Data files can contain modules loaded at runtime, for which we do not
usually have corresponding source code shipped in the package (or even
anywhere, if it was modified and saved without keeping the source file),
or can contain malicious code as well. This is a very extreme corner
case, but you cannot know it in advance.

This is an example of a R library without source code:

> install.packages("sig")
[snip]
> library("sig")
> save(sig, file="mydata")
>

When users load the data file, they have a sourceless library in their
environment:

> before <- loadedNamespaces()
> load("mydata")
> setdiff(loadedNamespaces(), before)
[1] "sig"
>


This is an example of malicious code:

> old_print <- print
> print <- function(...)
+ {
+ unlink('the_most_important_file.txt')
+ old_print('Say goodbye to your file!')
+ }
> save.image("mydata")
>

When users load the data file, and try to execute a simple print
statement, they can have their files removed:

> load("mydata")
> list.files()
[1] "mydata"  "the_most_important_file.txt"
> print('Hello world!')
[1] "Say goodbye to your file!"
> list.files()
[1] "mydata"

This just shows that there exist cases where .Rda files are *not* the
prefered form of modification, such as placing code (or even whole
libraries) into *.Rda files to be loaded.

Therefore, we shall consider these data files as preferred form of
modification if the data was captured in this format from a scientific
instrument, created manually and painstakingly by hand (this is not the
common case), or otherwise not generated. If the data was generated, or
converted by a script or series of scripts, the .Rda file is likely not
the prefered form, and needs to be rebuilt at build-time from source (as
we do with any binary in the archive).

[0] http://lists.debian.org/<20130805005735.ge22...@falafel.plessy.net>
[1] http://cran.r-project.org/doc/manuals/R-exts.html#Documenting-data-sets

-- 
bye, Joerg
on behalf of the FTP Team


signature.asc
Description: PGP signature

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Charles Plessy]

Le Tue, Sep 17, 2013 at 11:43:29AM +0100, Ian Jackson a écrit :
> 
> dgit's current functionality seems to be in reasonably good shape, but
> it lacks additional features which are important in some workflows.

Dear Ian,

for a small native package that I prepared, I would like to indicate dgit's
repository as VCS in its source control file (Vcs-Browser and Vcs-Git fields).

However, it does not clone nor browse well:

 - 
‘http://anonscm.debian.org/gitweb/?p=dgit-repos/repos/pv-grub-menu.git;a=tree’
   gives ‘404 - Reading tree failed’.

 - ‘git clone git://anonscm.debian.org/dgit-repos/repos/pv-grub-menu.git’ gives
   ‘warning: remote HEAD refers to nonexistent ref, unable to checkout.’

Do you think it is problems that are possible to solve ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Cyril Brulebois]

Charles Plessy  (2013-09-18):
> Dear Ian,
> 
> for a small native package that I prepared, I would like to indicate dgit's
> repository as VCS in its source control file (Vcs-Browser and Vcs-Git fields).
> 
> However, it does not clone nor browse well:
> 
>  - 
> ‘http://anonscm.debian.org/gitweb/?p=dgit-repos/repos/pv-grub-menu.git;a=tree’
>gives ‘404 - Reading tree failed’.
> 
>  - ‘git clone git://anonscm.debian.org/dgit-repos/repos/pv-grub-menu.git’ 
> gives
>‘warning: remote HEAD refers to nonexistent ref, unable to checkout.’

HEAD probably points to master, and there's no branch at all, just two tags.

I suspect that explains both issues.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Russ Allbery]

Ian Jackson  writes:
> Ian Jackson writes:

>>> I believe, if I understand this correctly, this will cause problems
>>> for the use of local-options and local-patch-header to set
>>> single-debian-patch for maintainer uploads.

>> I'm not sure what you mean, but I don't think so.

> Ah, wait, I think maybe I can speculate as to what you mean.

> I guess that you think I'm saying that the series of git commits in the
> dgit history must correspond to the series of patches found in the
> source package.

debian/source/local-options and debian/source/local-patch-header are
included in the working Git repository for the package but are not
included in the source package as uplaoded to Debian.  (Yes, this means
that they're somewhat directly contrary to the whole point of dgit.
However, they're the best available mechanism to use a single patch for
all changes with the 3.0 (quilt) package format if one doesn't want to
attempt to track changes as separate patches.)

Feel free to experiment with krb5-sync in experimental, since I'm about to
release a new version, so there will be an upload that will clear out any
NMUs in experimental as out of date before too much longer.

-- 
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
Archive: http://lists.debian.org/87fvt3l4va@windlord.stanford.edu

Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)

[Russ Allbery]

Steve Langasek  writes:

> My understanding is that the current policy implies that the
> 'dpkg-source -x' -> './debian/rules clean' -> 'dpkg-source -b'
> round-trip should be idempotent for all practical purposes,

This is idempotent for many packages because dpkg-source -b ignores file
deletions.

> just as the './debian/rules build' -> './debian/rules clean' round-trip
> should be.  So if ./debian/rules clean does something to a checkout of
> your branch, then that branch seems not to be a complete representation
> of the source package.

I don't believe that follows.  Both the Git branch and the source package
can contain files that will be immediately removed with debian/rules
clean.

-- 
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
Archive: http://lists.debian.org/878uyvjnou@windlord.stanford.edu

Re: Bug#723307: flash-kernel link with -L/usr/lib

[Dmitrijs Ledkovs]

Dear YunQiang Su,

It looks like this class of problems is reported against a lot of
packages now. Did you consult on debian-devel before doing this mass
bug filing?

Regards,

Dmitrijs.


On 17 September 2013 11:34, YunQiang Su  wrote:
> Package: flash-kernel
> Version: 3.11
> X-Debbugs-CC: wzss...@gmail.com
>
> This package has one or more -L/usr/lib in its build system,
> which will make it ftbfs if there is libraries under /usr/lib,
> while is not the default architecture, mips* for example.
>
> On mips* systems, /usr/lib is defined as place to hold O32
> libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.
>
> Beside the way, on the multiarch system like Debian, user may install
> libraries under /usr/lib by hand.
>
> Please use the default search path if you can, and please consider fix
> this.
>
> I will try to fix this bug, while if you can help to fix it,
> It will be very appreciative.
>
> The attachement is the buildlog of this package on mips64el platform.


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

Re: Bug#723307: flash-kernel link with -L/usr/lib

[Dmitrijs Ledkovs]

please ignore this thread.
I've now noticed these bug reports were raised to debian-devel in the
" link with -L/usr/lib" thread.

Regards,

Dmitrijs.

On 18 September 2013 02:54, Dmitrijs Ledkovs  wrote:
> Dear YunQiang Su,
>
> It looks like this class of problems is reported against a lot of
> packages now. Did you consult on debian-devel before doing this mass
> bug filing?
>
> Regards,
>
> Dmitrijs.
>
>
> On 17 September 2013 11:34, YunQiang Su  wrote:
>> Package: flash-kernel
>> Version: 3.11
>> X-Debbugs-CC: wzss...@gmail.com
>>
>> This package has one or more -L/usr/lib in its build system,
>> which will make it ftbfs if there is libraries under /usr/lib,
>> while is not the default architecture, mips* for example.
>>
>> On mips* systems, /usr/lib is defined as place to hold O32
>> libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.
>>
>> Beside the way, on the multiarch system like Debian, user may install
>> libraries under /usr/lib by hand.
>>
>> Please use the default search path if you can, and please consider fix
>> this.
>>
>> I will try to fix this bug, while if you can help to fix it,
>> It will be very appreciative.
>>
>> The attachement is the buildlog of this package on mips64el platform.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANBHLUhf=BO=u=6mknot2fcz8qwrdwkqahvfuuyiennctix...@mail.gmail.com