On Mon, Aug 18, 2014 at 07:28:51PM -0400, Barry Warsaw wrote:
> Also, it makes me somewhat uncomfortable to assume that a git tag in the
> upstream repo will always be equivalent to their released tarball. In fact,
> it's often not, as is the case with Python packages containing a MANIFEST.in.
I
Marc Haber wrote:
> On Sun, 17 Aug 2014 23:14:33 -0500, Josh Triplett
> wrote:
> >Why a requirement to not improve upstream? Ideally, the Debian patches
> >for a piece of software should trend to zero over time, as fixes make
> >their way upstream.
>
> Imagine an upstream author having the coop
I've been looking at the RFS process [1]. Some of this was in the
debian-mentors list about a year ago, albeit using corrupt data.
First the good news:
- About 1000 RFS submissions have led to accepted packages since January 2012
- The package acceptance rate has consistently been about 2/3
- Abo
Hei Sven,
On 18/08/14 18:10, Sven Bartscher wrote:
> If we have a package, which doesn't migrate to testing, we usually
> check the "Why does package X not in testing yet?" page or the PTS.
> Usually they do a great job in telling us why our package doesn't
> migrate.
>
> But sometimes you have p
Barry Warsaw writes:
> It makes more sense when you're a pure upstream, as master might be
> where you do all your cutting edge development, and there isn't usually
> a clear alternative naming scheme (e.g. code names). 'trunk' might be
> better anyway. But in Debian's case, all packaging work
On Aug 16, 2014, at 04:28 PM, Thomas Goirand wrote:
>Why?!? Is there some sort of religion around tarballs? Shouldn't it be
>the same stuff that "git archive" does? If it isn't, why is this the
>case? Shouldn't one be able to use what's in the Git repository anyway?
>Why can't it be fixed? Aren't
On Aug 17, 2014, at 08:47 PM, Henrique de Moraes Holschuh wrote:
>It is not meaningless in the sense that it is a widely used convention in
>git repositories.
>
>And that's actually quite relevant.
It makes more sense when you're a pure upstream, as master might be where you
do all your cutting e
On Aug 16, 2014, at 01:15 AM, Thomas Goirand wrote:
>As in, always use pristine-tar? No! The point of using git packaging is
>also to be able to use upstream git repo.
What about cases where upstream doesn't use git but you still want to use git
for your packaging branch?
Also, it makes me somew
On Aug 17, 2014, at 11:19 AM, Thomas Goirand wrote:
>By the way, I try to always avoid using "master" as a branch name. This
>doesn't express anything at all.
+1
In the context of Ubuntu (and when it works ) I really like the approach
taken for UDD branches. I can always branch the version of t
Le Thu, Aug 14, 2014 at 09:36:50PM +0900, Charles Plessy a écrit :
> Package: debian-policy
> Version: 3.9.5
> Severity: wishlist
>
> Hi Guillem and everybody,
>
> thanks for adding direct support for the Testsuite field in Dpkg.
>
> Here is a patch to update the Policy accordingly. Do you have
Le Mon, Aug 18, 2014 at 02:16:55PM +0200, Jakub Wilk a écrit :
>
> FWIW, "rc-buggy" is not the codename for experimental:
>
> $ wget -q -O- http://http.debian.net/debian/dists/experimental/Release | grep
> -m1 ^Codename:
> Codename: experimental
Excellent news !
So seems that I have been confu
> From: Sven Bartscher
Hi again Sven,
>
> Greetings,
>
> If we have a package, which doesn't migrate to testing, we usually
> check the "Why does package X not in testing yet?" page or the PTS.
> Usually they do a great job in telling us why our package doesn't
> migrate.
>
> But sometimes y
Marc Haber (2014-08-18):
> And others removed. Or do you actually claims that the systemd
> migration didn't actually break things? Not all of them, but a
> noticeable number.
(I don't think Russ claimed anything along those lines, no.)
Anyway: things get broken, bugs get reported, bugs get fixe
On 2014-08-17 16:20:34 +0800 (+0800), Thomas Goirand wrote:
> But then in which way will you check that the said upstream tarball,
> without any upstream checksum, is valid? At least tags are
> signed...
You keep coming back to the assumption that upstreams don't provide
signed lists of checksums.
On 2014-08-16 16:28:40 +0800 (+0800), Thomas Goirand wrote:
[...]
> If I prefer to use their git repository, and create my
> own orig.tar.xz out of a signed git tag, what is the problem, as
> long as I use the tag they provided by upstream?
[...]
Mainly that the checksums for your orig.tar.{g,x}z
On Mon, 18 Aug 2014 09:31:37 -0700, Russ Allbery
wrote:
>could we tone down the assumption that people with
>differing preferences want to break everything you do? It's just a few
>additional options.
And others removed. Or do you actually claims that the systemd
migration didn't actually break
On Sun, 2014-08-17 at 09:00 +0200, Raphael Hertzog wrote:
> On Sun, 17 Aug 2014, Thomas Goirand wrote:
> > Well, I have nothing against derivative/downstream distros, but if
> > you're about to do a new DEP, please consider Debian first. In such
> > case, debian/unstable makes a lot more sense than
On Mon, Aug 18, 2014 at 09:31:37AM -0700, Russ Allbery wrote:
> More generally (and this part is not pointed at Thomas), I realize it's
> become de rigueur in any thread about systemd to reply to "hm, you could
> consider getting a dog" with "WHY DO YOU WANT TO KILL MY KITTENS?!?!?",
> but seriousl
On Sun, 17 Aug 2014, Marc Haber wrote:
> Please. The attitute of requiring Debian maintainers to modify
> upstream software instead of having simple two-line extension to an
> init script is really unfriendly. Why do only systemd friends keep
> recommending this?
Using my sysvinit hat, I've always
Russ Allbery wrote:
> No, I'm pretty sure that currently works. But I don't know how much that
> relies on modifications to Debian's tar package.
It doesn't matter what tar was used to create the original tarball; as
long as we know the files present in it, we can use a (necessarily
stable versio
Hi,
> I do think that this is quite common, and my preferred way of doing
> things. It is easy for newcomers to handle, easy for me to handle, no
> need to learn a lot of git specific tools or helpers, you can mostly
> ignore git if you want to.
>
> I've a couple of times tried to get myself to a
On Sun, 17 Aug 2014, Thomas Goirand wrote:
> > Obviously, when upstream are already doing everything correctly, creating
> > the upstream/ tag should not become some administrative chore but
> > it could be done automatically as part of a some "gbp upstream-merge
> > " command for example.
>
> Ah,
On Mon, 18 Aug 2014, Don Armstrong wrote:
> On Mon, 18 Aug 2014, Thorsten Glaser wrote:
> > This does not work in Debian: you always need the .orig.tar.* file,
> > at least for the upload, for non-native packages.
>
> You need it from somewhere, but the whole point of pristine-tar is that
> you ca
2014-08-18 14:27:15 Thorsten Glaser:
> On Sun, 17 Aug 2014, Jonathan Dowland wrote:
> > On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote:
> > > - encoding (due to git restrictions):
> > > ":" -> "%"
> > > "~" -> "_"
>
> I’d rather have something that sorts like Debian versi
Thomas Goirand writes:
> On 08/18/2014 01:36 AM, Russ Allbery wrote:
>> The upstream source *can* be changed and improved for everyone.
> Truth, but not always practical. If I was going to fix all the defects
> of software I package, I don't think I'd have enough time to sleep even
> one hour pe
On Mon, Aug 18, 2014 at 02:27:15PM +0200, Thorsten Glaser wrote:
> I’d rather have something that sorts like Debian versions
> in “git tag” output…
If that proves too hard to achieve with a mapping scheme, it would
be trivial to write a filter to implement it. It does sound useful.
> Yikes!
>
>
Thomas Goirand writes:
> On 08/18/2014 01:49 AM, Russ Allbery wrote:
>> Joey took various approaches to work around this, including shipping
>> some of the older versions of the compressors in the package. However,
>> the issue also applies to tar, and so far has been addressed by
>> modifying t
Greetings,
If we have a package, which doesn't migrate to testing, we usually
check the "Why does package X not in testing yet?" page or the PTS.
Usually they do a great job in telling us why our package doesn't
migrate.
But sometimes you have packages, which have complicated dependencies,
that d
On 08/18/2014 01:36 AM, Russ Allbery wrote:
> The upstream source *can* be changed and improved for everyone.
Truth, but not always practical. If I was going to fix all the defects
of software I package, I don't think I'd have enough time to sleep even
one hour per night.
Thomas Goirand (zigo)
On Mon, 18 Aug 2014, Thorsten Glaser wrote:
> This does not work in Debian: you always need the .orig.tar.* file,
> at least for the upload, for non-native packages.
You need it from somewhere, but the whole point of pristine-tar is that
you can generate the orig.tar.* from information in the git
Hi Moritz,
On 18.08.2014 14:05, Moritz Mühlenhoff wrote:
Andreas Cadhalpun schrieb:
On 18.08.2014 08:36, Thomas Goirand wrote:
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same thing
On Sat, Aug 16, 2014 at 01:59:46PM +0200, Raphael Hertzog wrote:
> Hi,
>
> On Fri, 15 Aug 2014, Guido Günther wrote:
> > The gbp manual has a recommended branch layout:
> >
> >
> > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.BRANCH.NAMING
> >
> > which co
On Sun, 17 Aug 2014, Jonathan Dowland wrote:
> On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote:
> > - encoding (due to git restrictions):
> > ":" -> "%"
> > "~" -> "_"
I’d rather have something that sorts like Debian versions
in “git tag” output…
> "_" -> "_5f"
>
Hi *,
Il Lunedì 18 Agosto 2014 10:20, Andrew Kelley ha scritto:
>
thanks to all for the useful replies!
So I will subscribe through the PTS interface, it is the best solution (I was
already wondering that) ;)
>
>You can also check this page periodically:
>https://qa.debian.org/developer
* Charles Plessy , 2014-08-17, 19:39:
for suites that are never released, I think that it is fine to not use
the codename. Otherwise, people will be confused with debian/rc-buggy.
FWIW, "rc-buggy" is not the codename for experimental:
$ wget -q -O- http://http.debian.net/debian/dists/experime
On Sun, 17 Aug 2014, Neil Williams wrote:
> > The vast majority (all?) of git packaging repositories have the
> > upstream sources.
>
> No. None of mine do, or will.
I’m working with some which also don’t, and find it would be easier
if there were a way to extract a .orig.tar.gz in the same way
On Sun, 17 Aug 2014, Thomas Goirand wrote:
> Like I wrote in another post, "master" doesn't express anything.
ACK.
> All of this is error prone. Using upstream tags and merging them rather
> than branches avoid troubles. I have yet to see a case where using
> upstream tags wasn't practical.
The
Andreas Cadhalpun schrieb:
> Hi Thomas,
>
> On 18.08.2014 08:36, Thomas Goirand wrote:
>> There's been a very well commented technical reason stated here: the
>> release team don't want to deal with 2 of the same library that are
>> doing (nearly) the same things, with potentially the same securit
On Fri, 15 Aug 2014, Russ Allbery wrote:
> m...@linux.it (Marco d'Itri) writes:
> > The first step is to determine which problem you are trying to solve.
Surprisingly insightful, this one.
> I want to be able to check out a git repository and do packaging work and
> an upload, without having to
On Mon, Aug 18, 2014 at 01:19:55AM -0700, Andrew Kelley wrote:
> You can also check this page periodically:
> https://qa.debian.org/developer.php?login=costamagnagianfra...@yahoo.it
Alternatively
https://udd.debian.org/dmd/
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSU
On Sat, 16 Aug 2014, Thomas Goirand wrote:
> Why would you tag the upstream release? I mean, it's upstream's job to
Yeah, if upstream uses git at least it should NOT be done by
the packager.
If not, it depends.
> > - shall we standardize the "pristine-tar" branch?
>
> As in, always use pristin
Le primidi 1er fructidor, an CCXXII, Thomas Goirand a écrit :
> The problem was enforcing patch review policies.
No, it never was.
> There's been a very well commented technical reason stated here: the
> release team don't want to deal with 2 of the same library that are
> doing (nearly) the same
Hi Thomas,
On 18.08.2014 08:36, Thomas Goirand wrote:
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things, with potentially the same security
issues that we'd have to fix twice rat
Hi,
On 18.08.2014 07:20, Dominik George wrote:
the libfreerdp1 package changed its soname without a transition and
without introducing a new package.
That broke binary compatibility of at least remmina and
libguac-client-rdp0 [0].
The bug report about this is:
https://bugs.debian.org/757926
On Sun, Aug 17, 2014 at 01:13:36PM +0200, Marc Haber wrote:
> On Sun, 17 Aug 2014 01:40:27 -0700, Josh Triplett
> wrote:
> >Ludovico Cavedon wrote:
> >> I am writing a systemd service file for a daemon (ntopng) and I would
> >> like to know what you think is the best way to load some
> >> configur
Package: wnpp
Severity: wishlist
Owner: "Shih-Yuan Lee (FourDollars)"
* Package name: ibus-zhuyin
Version : 0.1.0
Upstream Author : Shih-Yuan Lee (FourDollars)
* URL : https://github.com/fourdollars/ibus-zhuyin
* License : GPLv3
Programming Lang: C
Descrip
You can also check this page periodically:
https://qa.debian.org/developer.php?login=costamagnagianfra...@yahoo.it
On Sun, Aug 17, 2014 at 11:28 PM, Gianfranco Costamagna <
costamagnagianfra...@yahoo.it> wrote:
> Hi DD folks!
>
> recently a bug has been opened against a package I maintain (debia
On 2014-08-18 8:18, Adam Borowski wrote:
On Mon, Aug 18, 2014 at 07:28:46AM +0100, Gianfranco Costamagna wrote:
recently a bug has been opened against a package I maintain (debian
science is the maintainer, while I'm the only uploader), but I did not
notice with a mail, because:
A) I forgot to s
On Sat, Aug 16, 2014 at 09:51:21PM +0200, Bastien ROUCARIES wrote:
> On Sat, Aug 16, 2014 at 1:59 PM, Raphael Hertzog wrote:
> > Hi,
> >
> > On Fri, 15 Aug 2014, Guido Günther wrote:
> >> The gbp manual has a recommended branch layout:
> >>
> >>
> >> http://honk.sigxcpu.org/projects/git-buildpa
Le Mon, Aug 18, 2014 at 08:53:12AM +0200, Olivier Sallou a écrit :
>
> do you know, by chance, what is the difference between samtools and the
> net.sf.samtools Java lib of picard-tools ? They look quite the same.
>
> The HTSlib fix an issue forigv (on SAMFileWriterFactory), but
> SAMFileWriterF
On Mon, Aug 18, 2014 at 07:28:46AM +0100, Gianfranco Costamagna wrote:
> recently a bug has been opened against a package I maintain (debian
> science is the maintainer, while I'm the only uploader), but I did not
> notice with a mail, because:
> A) I forgot to subscribe to debian-science archives
On 08/18/2014 03:08 PM, Thomas Goirand wrote:
> On 08/18/2014 01:49 AM, Russ Allbery wrote:
>> Joey took various approaches to work around this, including shipping some
>> of the older versions of the compressors in the package. However, the
>> issue also applies to tar, and so far has been addres
On 08/18/2014 01:49 AM, Russ Allbery wrote:
> Joey took various approaches to work around this, including shipping some
> of the older versions of the compressors in the package. However, the
> issue also applies to tar, and so far has been addressed by modifying tar
> to add a backword-compatibil
On 08/18/2014 07:47 AM, Henrique de Moraes Holschuh wrote:
> On Sun, 17 Aug 2014, Thomas Goirand wrote:
>> On 08/17/2014 03:52 AM, Raphael Hertzog wrote:
>>> On Fri, 15 Aug 2014, Henrique de Moraes Holschuh wrote:
> - the above layout is for the traditional case of non-native packages,
>
❦ 18 août 2014 14:20 +0800, Thomas Goirand :
>> What? Most patches are posted inline (with git-send-email).
>
> Even worse then! It makes it hard to copy to your local fs.
The whole email is a valid patch in this case.
--
Follow each decision as closely as possible with its associated action.
55 matches
Mail list logo
