Re: Uploading python-xstatic-* packages in Debian

[Thomas Goirand]

On 08/15/2014 12:28 AM, Jonas Smedegaard wrote:
> Quoting Thomas Goirand (2014-08-14 09:26:05)
>> Note that the XStatic python modules aren't just meta packages, they 
>> also offer a mechanism for a Python script to discover where to find a 
>> given static file in the system (which really, isn't obvious, as the 
>> Debian archive is a bit messy in this regard, especially when dealing 
>> with static files that aren't javascript like .css or .less files).
> 
> You are quite welcome to propose tp relevant teams streamlining which 
> could ease your packaging.  A cleanup might take time to coordinate, and 
> agreeing on tidying the structure may take time too, but that shouldn't 
> discourage you from initiating that process :-)
> 
> I recommend to discuss that in those smaller teams rather than here.

Well, unfortunately, I'm not sure there's a solution, or at least, I
don't have it. Things are the way they are because upstream decided to
put this or that file in this or that folder, and then every upstream
has his own convention. Then we just follow upstream, and that is a good
thing. But at the end, we end up with no convention. A more broad
standard should, at some point, be establish, so that everyone (and by
this, I mean also upstream authors...) sorts files in the same way.

Anyway, this was just a few thoughts, I didn't intend to start a troll
thread about this. :)

>> For some XStatic packages, the embedded static files are not present 
>> in Debian. That is the case for example with python-xstatic-hogan, 
>> python-xstatic-jasmine, or python-xstatic-bootstrap-scss. For the 
>> above 3 packages, the upstream source code is part of a much larger 
>> project.
> 
> Please don't embed reusable non-Python code into Python-specific 
> packages - then you end up with same problem as you ran into yourself 
> with ruby-bootstrap-sass (see right below).  Instead, package (or 
> request others like the Javascript ot Sass team) to package those which 
> you need.

I'm doing the libjs-* packages whenever that's not too big, and
manageable by myself. I did that for libjs-twitter-bootstrap-datepicker
for example, then I just depend on that package.

>> See for example bootstrap-scss, which comes with a huge Ruby 
>> framework. I have no intention to package all of that...
> 
> I guess you mean ruby-bootstrap-sass - please see bug#739783.

Oh, swt! What I need is in compass-bootstrap-sass-plugin :)
Thanks a lot for the pointer, Jonas. This is really helpful.

Indeed, #739783 is important to be fixed for me as well, as I wont be
using ruby at all, and I don't think it's reasonable to get 10MB of
non-useful ruby stuff for Horizon ! :)

>> As I know very little about packaging of some upstream code (for 
>> example, I have never maintained ruby or nodejs packages), and that I 
>> don't need them anyway (I only need a few javascript files from them, 
>> I will have no use of Ruby or nodejs code), then I decided to *not* 
>> package the full upstream package, and leave the embedded copy inside 
>> the python-xstatic-* packages. This is until someone needs the full 
>> upstream package, at which point I will remove the embedded copy, and 
>> point to the relevant files inside the recently uploaded package.
> 
> Please don't postpone proper packaging until others eventually steps up.

Theoretically, you are right. Unfortunately, this isn't practical.

I'm sorry, but I just can't package stuff that I have no use for, or for
which I have no knowledge (ruby is a good example of this). This will be
bad work, and I don't want to upload crap which I wont even be able to
check by myself. It would also sometimes be too much work, for which I
wont have time for.

I also don't believe that just writing an RFP will make it happen. If
this was the case, I'd just do that, always, and stop doing any sort of
packaging myself...

So, I'm going to do this only as much as I can, when possible. I hope
you'll understand.

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53edb61c.7050...@debian.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Paul Wise]

On Fri, Aug 15, 2014 at 2:53 PM, Thomas Goirand wrote:

> Hum... Well, to me, what's important is that the code gets
> peer-reviewed.

... by both humans and by automatically by computers; compiler
warnings, static analysis tools, fuzz testers etc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6E5Ow=ywhmzjqt-wotwolikj6_cveeqyyzzk4rxno4...@mail.gmail.com

Re: Uploading python-xstatic-* packages in Debian

[Jonas Smedegaard]

Quoting Thomas Goirand (2014-08-15 09:26:20)
> On 08/15/2014 12:28 AM, Jonas Smedegaard wrote:
>> Quoting Thomas Goirand (2014-08-14 09:26:05)
>>> Note that the XStatic python modules aren't just meta packages, they 
>>> also offer a mechanism for a Python script to discover where to find 
>>> a given static file in the system (which really, isn't obvious, as 
>>> the Debian archive is a bit messy in this regard, especially when 
>>> dealing with static files that aren't javascript like .css or .less 
>>> files).
>> 
>> You are quite welcome to propose tp relevant teams streamlining which 
>> could ease your packaging.  A cleanup might take time to coordinate, 
>> and agreeing on tidying the structure may take time too, but that 
>> shouldn't discourage you from initiating that process :-)
>> 
>> I recommend to discuss that in those smaller teams rather than here.
>
> Well, unfortunately, I'm not sure there's a solution, or at least, I 
> don't have it.

I don't expect you to have solutions, only - maybe - ideas.

That s exactly why I suggest doing it as teamwork :-)


>> Please don't embed reusable non-Python code into Python-specific 
>> packages - then you end up with same problem as you ran into yourself 
>> with ruby-bootstrap-sass (see right below).  Instead, package (or 
>> request others like the Javascript ot Sass team) to package those 
>> which you need.
[...]
>> Please don't postpone proper packaging until others eventually steps up.
>
> Theoretically, you are right. Unfortunately, this isn't practical.
>
> I'm sorry, but I just can't package stuff that I have no use for, or 
> for which I have no knowledge (ruby is a good example of this). This 
> will be bad work, and I don't want to upload crap which I wont even be 
> able to check by myself. It would also sometimes be too much work, for 
> which I wont have time for.
> 
> I also don't believe that just writing an RFP will make it happen. If 
> this was the case, I'd just do that, always, and stop doing any sort 
> of packaging myself...
> 
> So, I'm going to do this only as much as I can, when possible. I hope 
> you'll understand.

What I suggest is that you package stuff you have no use for, nor that 
you just write RFPs.  What I suggest is that you collaborate with teams.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Reverting to GNOME for jessie's default desktop

[Svante Signell]

Please don't top post!

On Thu, 2014-08-14 at 15:12 +0100, envite wrote:
> Why not MATE for all and put a11y into it?
> 
> Makes more sense for e.g. small computers like those in 3rd World talked 
> before. 
> 
> Enviado de Samsung Mobile

I'm all for it, and am willing to help making it happen. With MATE all
architectures could have the same desktop default. Who are the packaging
teams to join?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1408093348.2372.5.camel@PackardBell-PC

Re: Uploading python-xstatic-* packages in Debian

[Thorsten Glaser]

On Thu, 14 Aug 2014, Thomas Goirand wrote:

> What would probably work better would be to add the python library
> inside upstream code.

That would work as well.

> But then we have another issue: the Python module is supposed to be
> packaged as python-, and the JS libs are supposed to be
> packaged as libjs-. So we'd have to break one or the other
> convention.

No. Provides exist for a reason.

> I don't think that's desirable to do. We don't want to break automatic
> dependency calculation by dh_python{2,3} either.

You can add those to the libjs-* source packages.

> The important bit is that upstream requires version X of
> python-xstatic-jquery because it needs version X of jquery. When we have

That is *even more* reason to merge the packaging of the
xstatic things with the packaging of the libraries they
provide!

> The XStatic package itself doesn't contain much but the Python
> wrapper, so it's not a big deal (it's very simplistic Python code).

That’s a good argument in favour of integrating the python
side into the Debian packages of the upstreams of the xstatic
packages.

> static files libraries. In fact, XStatic has been created upstream with
> distributions in mind, and I find it very nice of them. It's indeed
> solving the problem, even if that's some non-negligible work at first to
> do the python-xstatic-* packaging.

That doesn’t mean we have to implement the API the same way.
Integrating something into the libjs-* packages to provide
xstatic would also fulfil that, and use the very nice thing
upstream made, just not the same way to there.

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1408151115370.23...@tglase.lan.tarent.de

Re: First steps towards source-only uploads

[Johannes Schauer]

Hi,

Quoting Guillem Jover (2014-08-13 13:48:11)
> On Tue, 2014-08-12 at 13:27:38 +0200, Ansgar Burchardt wrote:
> > There are also other problems that need to be eventually addressed: as far
> > as I know there are some source packages producing arch:all binaries that
> > cannot be built on all architectures. A Build-Architecture-Indep field was
> > proposed to indicate where it should be built in this case[1], but for now
> > I think we can require that maintainers have to upload the arch:all
> > packages in this case.
> 
> I think all proposed field names in that thread are rather confusing.
> In Debian packaging lingo build means several things, it can mean at
> least the build machine (!= host machine), or it can mean the act of
> building.
> 
> In the case of Build-Depends style fields, it's referring to the act
> of building, but Architecture is related to the host system/compiler,
> so mixing the different meanings would be messy, think for example
> about cross-compiling.

But is the question not *on* which architecture arch:all packages are built,
and would the term "build" in Build-Architecture-Indep thus not be correct in
both of its meanings (as "the architecture I'm building *on*" as well as "the
act of building")?

cheers, josch


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815092700.14069.93664@hoothoot

Bug#758195: ITP: solarus -- Open-source Zelda-like game engine

[Pierre Rudloff]

Package: wnpp
Severity: wishlist
Owner: Pierre Rudloff 

* Package name: solarus
  Version : 1.2.1
  Upstream Author : Nathan Moore 
* URL : http://www.solarus-games.org/
* License : GPL
  Programming Lang: C++
  Description : Open-source Zelda-like game engine


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140815093459.24742.51928.report...@home.rudloff.pro

Re: Reverting to GNOME for jessie's default desktop

[Mike Gabriel]

Hi Svante, hi all,

On  Fr 15 Aug 2014 11:02:28 CEST, Svante Signell wrote:


Please don't top post!

On Thu, 2014-08-14 at 15:12 +0100, envite wrote:

Why not MATE for all and put a11y into it?

Makes more sense for e.g. small computers like those in 3rd World  
talked before.


Enviado de Samsung Mobile


I'm all for it, and am willing to help making it happen. With MATE all
architectures could have the same desktop default. Who are the packaging
teams to join?


The DDPO page is found at [1].

Active DDs in the MATE team are John Paul Adrian Glaubitz and $me.

The MATE packaging is also supported by several non-DDs. The MATE team  
intensely cooperates with those people bringing MATE into Ubuntu. One  
of the main upstream devs (Stefano Karapetsas) is also member of the  
MATE packaging team.


We meet&work on Freenode (#debian-mate) and plan to migrate smoothly  
to OFTC sooner or later (#debian-mate).


Greets,
Mike

[1]  
https://qa.debian.org/developer.php?login=pkg-mate-t...@lists.alioth.debian.org#mate-power-manager

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgp5nvdrW1as7.pgp
Description: Digitale PGP-Signatur

Re: First steps towards source-only uploads

[Hector Oron]

Hello,

2014-08-13 22:59 GMT+02:00 Philipp Kern :
> On 2014-08-13 14:34, Raphael Hertzog wrote:
>> On Wed, 13 Aug 2014, Colin Watson wrote:

>>> I don't think there's a good reason to build them separately, and some
>>> good reasons not to (for example, it would waste a good deal of buildd
>>> time for a number of packages without very hygienic separation of their
>>> build rules).  My suggestion would be to just build them along with the
>>> architecture-dependent binaries for some nominated architecture, which
>>> could be package-specific or not depending on what you all have time
>>> for, and be done with it.

>> In kali, that's exactly what I have been doing. Any package that builds
>> an arch: all is sent to an amd64 buildd and sbuild on the amd64 buildd
>> gets
>> called with -A.
>>
>> It doesn't matter whether it builds only the arch: all or another package
>> too.

> We need to convey if the arch:all is actually needed, though, otherwise dak
> will reject the package. Or could we simply build it always and have it
> discarded if the maintainer's copy had been accepted?

Even building arch:all packages in one architecture might solve the
issue, I do not like that approach, as it holds other arches from
building until that "primary" arch has built arch:all packages. It
also leads to not fully buildable packages for the rest of
architectures, i.e. #690260 (openjdk-7: build empty doc packages on
arm).

Building arch:all on every architecture can also be seen as a waste of
build time but effective.

Another approach would be to find out if arch:all packages are
available for build, if not, then build them along package in
whichever architecture, otherwise skip them. That looks the most fair
approach to me, but it can possibly lead to interesting races,
depending on implementation.

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caodfwegv40bnpuj_u5i-4nzvr5ua4wdo5wy+8xj+7wqs1lu...@mail.gmail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Michael Niedermayer]

On Fri, Aug 15, 2014 at 02:53:09PM +0800, Thomas Goirand wrote:
> On 08/14/2014 11:59 PM, The Wanderer wrote:
> > On 08/14/2014 11:27 AM, Thomas Goirand wrote:
> > 
> >> On 08/13/2014 07:53 AM, Kieran Kunhya wrote:
> > 
> >> On 08/13/2014 06:30 AM, Michael Niedermayer wrote:
> > 
> >>> Also ive offered my resignation in the past. I do still offer to
> >>> resign from the FFmpeg leader position, if it resolves this split
> >>> between FFmpeg and Libav and make everyone work together again.
> > 
> >> Why not just take the offer, and move on?
> > 
> > Probably because of the condition he attached to it, which also dates
> > back to the arguments preceding the original split:
> > 
> >>> The part i insist on though is that everyone must be able to work
> >>> on their code without people uninvolved in that specific parts
> >>> maintaince or authorship being able to block their work.
> > 
> > In other words, as I think I understand it from the discussion back
> > then: people not involved with a particular area of the code can't NACK
> > the work of someone who is working on it, and someone who works on a
> > particular area of the code doesn't have to wait on review of people who
> > aren't involved with that area of the code.
> > 
> > Since one of the motivations of the people behind the libav side of the
> > split seems, IIRC, to have been "no code gets in without having been
> > reviewed by someone other than the author", this was apparently deemed
> > an unacceptable condition.
> 
> Hum... Well, to me, what's important is that the code gets
> peer-reviewed.

Yes, the tricky part in FFmpeg and Libav in relation to this is that
theres quite a bit of code that is only well understood by a single
person even if you would combine both projects together.
So if that person posts a patch for review, theres noone who could
do a real review


> Setting-up something like gerrit may help, as it can be
> setup in a way that review becomes mandatory. Then discussing who's
> core-reviewer and can approve this or that part of the code can be setup
> within gerrit. This should be discussed, and setup based on technical merit.

Not commenting about gerrit as i dont have experience with it, but
FFmpeg currently uses a simple file in main ffmpeg git that lists
which part is maintained by whom, and these developers would in the
rare case of a dispute have the final say in each area.

OTOH, Libav early deleted their forked version of this file, and
iam not aware of any replacement. But others should explain how it
works in Libav ...


> 
> Having a NACK review is often disappointing. It goes the wrong way if
> there's only a NACK with no comments on how to improve things, so that
> the code becomes acceptable.

> Absolutely everyone should *always* be able
> to leave comments, be it positive or negative.

yes, i fully agree and this also was always so in FFmpeg. In that
sense everyone is welcome to subscribe to ffmpeg-devel and review and
comment patches. That of course includes Libav developers and everyone
else. And more reviewers would also certainly help, so yeah anyone
reading this and wanting to help review patches, you are welcome!

Thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


signature.asc
Description: Digital signature

Re: First steps towards source-only uploads

[Raphael Hertzog]

On Fri, 15 Aug 2014, Hector Oron wrote:
> Even building arch:all packages in one architecture might solve the
> issue, I do not like that approach, as it holds other arches from
> building until that "primary" arch has built arch:all packages.

I understand the concern at the philosophical level but on a practical
level, using the fastest architecture we have is actually the way to
ensure that all arches get their arch all packages in the fastest possible
way.

> It also leads to not fully buildable packages for the rest of
> architectures, i.e. #690260 (openjdk-7: build empty doc packages on
> arm).

Those are bugs that can be found as part of QA activities, we don't have
to complicate our build infrastructure just to ensure that this specific
class of bugs gets found during build.

On the contrary, this is a sure way to create unexpected problems (by
letting bad arch all packages enter the archive) that
maintainers won't be able to anticipate as they do test-build their packages
on i386/amd64 mainly.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140815130004.gc17...@x230-buxy.home.ouaza.com

Re: First steps towards source-only uploads

[Henrique de Moraes Holschuh]

On Fri, 15 Aug 2014, Raphael Hertzog wrote:
> On Fri, 15 Aug 2014, Hector Oron wrote:
> > Even building arch:all packages in one architecture might solve the
> > issue, I do not like that approach, as it holds other arches from
> > building until that "primary" arch has built arch:all packages.
> 
> I understand the concern at the philosophical level but on a practical
> level, using the fastest architecture we have is actually the way to
> ensure that all arches get their arch all packages in the fastest possible
> way.

And any package that cannot build arch:all on a released arch for which it
produces binary packages potentially has a FTBFS bug, anyway, which can be
reported by any interested parties.  Exceptions would be arches that are too
resource-constrained to build it in the first place.

IMHO, it is NOT the job of the autobuilders to track down and find every
FTBFS bug in Debian.  They cannot be expected to waste resources tracking
down FTBFS bugs that have no effect on the current operations of the
autobuilder network.

> > It also leads to not fully buildable packages for the rest of
> > architectures, i.e. #690260 (openjdk-7: build empty doc packages on
> > arm).
> 
> Those are bugs that can be found as part of QA activities, we don't have
> to complicate our build infrastructure just to ensure that this specific
> class of bugs gets found during build.

Agreed.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815133712.gc26...@khazad-dum.debian.net

Re: First steps towards source-only uploads

[Ondřej Surý]

On Fri, Aug 15, 2014, at 15:37, Henrique de Moraes Holschuh wrote:
> And any package that cannot build arch:all on a released arch for which
> it produces binary packages potentially has a FTBFS bug, anyway, which
> can be reported by any interested parties.  Exceptions would be arches
> that are too resource-constrained to build it in the first place.

I have encountered a situation where the FTBFS bug was caused
by segfault in other package. This has forced me to split opendnssec-doc
to arch:all package (which was good thing anyway), so there are cases
where you want to build the arch:all on most stable and fastest arch.

Could we just pick amd64 and be done? :)

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1408111452.213427.153089893.5c8a7...@webmail.messagingengine.com

Re: First steps towards source-only uploads

[Henrique de Moraes Holschuh]

On Fri, 15 Aug 2014, Ondřej Surý wrote:
> On Fri, Aug 15, 2014, at 15:37, Henrique de Moraes Holschuh wrote:
> > And any package that cannot build arch:all on a released arch for which
> > it produces binary packages potentially has a FTBFS bug, anyway, which
> > can be reported by any interested parties.  Exceptions would be arches
> > that are too resource-constrained to build it in the first place.
> 
> I have encountered a situation where the FTBFS bug was caused
> by segfault in other package. This has forced me to split opendnssec-doc
> to arch:all package (which was good thing anyway), so there are cases
> where you want to build the arch:all on most stable and fastest arch.
> 
> Could we just pick amd64 and be done? :)

Yes, please :-)

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815140823.ga1...@khazad-dum.debian.net

Standardizing the layout of git packaging repositories

[Raphael Hertzog]

Hello,

while git is the most popular VCS for packaging, there's no clear rules
on what you can expect in a random git packaging repository listed
in Vcs-Git. I would like to fix this so that:
- we can extract more useful data from the git repositories
- we can more easily share our git repositories with upstreams
  and downstreams
- we start to converge on some conventions even though we might
  continue to use different git helper tools

I want to use the DEP process for this. But before I can write a first
draft I would like to have your ideas of what we should include
in such a document.

Some initial questions and possible answers:

- how do we name the various branches?

  - /master for the main development trunk (aka unstable in Debian)
  - / for alternate versions

  The goal here is to be able to host in the same repository the branches for
  multiple cooperating distributions (at least so that downstream can
  clone the debian respository and inject their branches next to the
  debian branches).

- how do we tag the upstream releases?

  - upstream/
  (note: we don't need an "upstream" branch, having the good tag for any
  release that the distros are packaging is enough, it can point to a
  synthetic commit built with tools like git-import-orig or to a real
  upstream commit)

- how do we tag the package releases?

  - pkg/
  (note: git-buildpackage uses debian/ but I find this confusing
  as we then also have the "debian/" prefix for ubuntu or kali uploads, we
  don't need the vendor prefix as the usual versioning rules embed the
  downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
  any conflict on the namespace, keeping a prefix is important to easily
  differentiate tags created by upstream developers from tags created
  by packagers)

- where should the HEAD point to in the public repository?

- shall we standardize the "pristine-tar" branch?

- the above layout is for the traditional case of non-native packages,
  what would be the layout for native packages? how can be differentiate
  between native/non-native layout?
  
-  encoding (due to git restrictions):
":" -> "%"
"~" -> "_"

- are there other important things to standardize?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140815141601.ga11...@x230-buxy.home.ouaza.com

Re: Standardizing the layout of git packaging repositories

[Matteo F. Vescovi]

Hi!

On 2014-08-15 at 16:16 (CEST), Raphael Hertzog wrote:
> [...] 
> - are there other important things to standardize?
 
Well, I don't know but I love this idea.

+1 for me.

Cheers.


-- 
Matteo F. Vescovi | Debian Maintainer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: Digital signature

Bug#758222: ITP: libjs-jsencrypt -- RSA Encryption in JavaScript

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libjs-jsencrypt
  Version : 2.0.0+dfsg1
  Upstream Author : Travis Tidwell 
* URL : http://travistidwell.com/jsencrypt/
* License : Expat
  Programming Lang: JavaScript
  Description : RSA Encryption in JavaScript

 JSEncrypt provides a simple wrapper around the fantastic work done by Tom Wu
 for RSA Encryption in JavaScript (ie: the jsbn Javascript library). JSEncrypt
 works hand-in-hand with openssl.
 .
 With JSEncrypt, you can generate private and public keypairs (it takes less
 than 6 seconds for generating a 2048 bits keypair on my laptop), then use them
 to encrypt and decrypt.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140815144422.24811.23525.report...@buzig.gplhost.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Thomas Goirand]

On 08/15/2014 08:20 PM, Michael Niedermayer wrote:
> Yes, the tricky part in FFmpeg and Libav in relation to this is that
> theres quite a bit of code that is only well understood by a single
> person even if you would combine both projects together.

Hum... Hang on here then! Does this mean that, in FFmpeg and/or Libav,
there's some parts of the code which are understood by no-one? Scary!

> So if that person posts a patch for review, theres noone who could
> do a real review

Then the person who posts the patch can leave it for review for a while
(you should define a policy so that "for a while" means something: for
example 2 or 3 weeks), and then if there's no negative review, he can
self-approve his patch.

>> Absolutely everyone should *always* be able
>> to leave comments, be it positive or negative.
> 
> yes, i fully agree and this also was always so in FFmpeg. In that
> sense everyone is welcome to subscribe to ffmpeg-devel and review and
> comment patches. That of course includes Libav developers and everyone
> else. And more reviewers would also certainly help, so yeah anyone
> reading this and wanting to help review patches, you are welcome!

Well, using a mailing list to review patches is something we were doing
10 years ago. You should really consider using Gerrit (or something
equivalent, but I don't know anything that works the way Gerrit does).
The workflow will influence a lot the way contributors interact with
each other. Almost certainly in a *good* way.

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ee25d9.7020...@debian.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/15/2014 11:23 AM, Thomas Goirand wrote:

> On 08/15/2014 08:20 PM, Michael Niedermayer wrote:

>>> Absolutely everyone should *always* be able to leave comments, be
>>> it positive or negative.
>> 
>> yes, i fully agree and this also was always so in FFmpeg. In that
>> sense everyone is welcome to subscribe to ffmpeg-devel and review
>> and comment patches. That of course includes Libav developers and
>> everyone else. And more reviewers would also certainly help, so
>> yeah anyone reading this and wanting to help review patches, you
>> are welcome!
> 
> Well, using a mailing list to review patches is something we were
> doing 10 years ago.

It's also something the Linux kernel is still doing, with apparent
success.

I for one consider it to be a much more public, transparent, and
discoverable way to let proposed patches and the review of same be open
to public view, compared to the way various other projects seem to do
it.

Making sure everything passes through the mailing list, and most if not
all substantive discussion happens on the mailing list, is a lot better
than having some discussion on the mailing lists and some on a bug
tracker and some on IRC and some via private mail and so on. (The most
ridiculously extreme example of this fragmentation that I know of is
probably the Mozilla project.)

There's nothing wrong with having discussion in those various areas, of
course; it's probably inevitable, and it's even a good thing. It's just
that it's a lot harder for someone not intimately involved with the
project to follow discussion if it happens in such a variety of places,
and there's value to be found in making sure that everything passes
through one central (discussion-enabled) point before landing.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJT7izqAAoJEASpNY00KDJr8PwP+gNPrmz3G1SDFBP0WPW7WEn/
BBFAFkWXEkezThYnjqYfHxUjwHBZOOpLfykfhlx7uV5O+nqy5BDDMHLzBxVEvaKp
5On9SaRB6/DYzAf9HvSJm+teHqRtNP0xKrcjRI+AgQ9n3Meax3OWi7jiNSIijAlX
srvhfjqgRAdNIB+dAnv8uhWhsAbN0njAPqegolFunAG8ZlWA4kcA5zt5uVaQrWPZ
y8LqZ/bB7xYbqTAO+kENhNoMzItqANUKZNhJKW/Fk6Dln/kIKWYE5Uiiil2BOHc7
KNyPxvrfjAj/LYdazgknu2tcAlgHbPBbbjjqYFivkc2sG+9s1t5QkEdkdJw7w3v8
OQpUwwF3gRGHebp1ODtyCuVC8jsmtBAwM+s0H5aqF0Tp6NyjgYFxtYrfHvvnvXmX
1lew8VW6WogIlJ1wDXCS8057gR877wMa8r61d6XbdHXcnARxoFYI1ngUUsKYjXyU
YJkRgxTZTtUZ9QNfex8sdja1PiIw96m4XLeW1uTozRR0EcQRBarphBCscQhmp0Sm
pdopwrFYMnZtNOE2nEqbwQtkNm1AXmABG18GbhcPX7LqEXsys6Odn8o1zqJYpx2h
7aQzpXbhjHUwihelR5yV6dASRt1LBD3icCR0uoWaAb80b0Li9cdV07FLon20XExS
mwURtzhiqxowV931+Bvh
=Jxa+
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ee2cea.1080...@fastmail.fm

Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

[Michael Biebl]

Am 15.08.2014 17:47, schrieb Gerrit Pape:
> Package: rsyslog
> Version: 8.2.2-3
> Severity: serious
> Justification: Policy 2.5
> 
> Hi, the current rsyslog package version in testing is priority important
> and depends on packages with priority extra.  Policy 2.5 states:
> 
> "Packages must not depend on packages with lower priority values
> (excluding build-time dependencies)."
> 
> $ apt-cache show rsyslog |grep -E '^Version:|^Priority|^Depends'
> Version: 8.2.2-3
> Depends: libc6 (>= 2.17), libestr0 (>= 0.1.4), libjson-c2 (>= 0.10), 
> liblogging-stdlog0 (>= 1.0.2), liblognorm1 (>= 0.3.0), libuuid1 (>= 2.16), 
> zlib1g (>= 1:1.1.4), init-system-helpers (>= 1.18~), lsb-base (>= 3.2-14), 
> initscripts (>= 2.88dsf-13.3)
> Priority: important
> $ apt-cache show libestr0 libjson-c2 liblognorm1 init-system-helpers |grep 
> ^Priority
> Priority: extra
> Priority: extra
> Priority: extra
> Priority: extra
> $ 
> 
> Regards, Gerrit.
> 


I'm going to re-assign this bug to debian-policy as I want clarification
why debian-policy demands this.
So far, nobody was able to explain that requirement to me and the policy
text doesn't either.

That this rule is violated in hundreds of cases [1] clearly shows that
there is something wrong which needs to be addressed in a more idiomatic
way.

Michael


[1] https://qa.debian.org/debcheck.php?dist=sid&list=priority&arch=ANY
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Standardizing the layout of git packaging repositories

[Christian Kastner]

On 2014-08-15 16:16, Raphael Hertzog wrote:
>   - pkg/
>   (note: git-buildpackage uses debian/ but I find this confusing
>   as we then also have the "debian/" prefix for ubuntu or kali uploads, we
>   don't need the vendor prefix as the usual versioning rules embed the
>   downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
>   any conflict on the namespace, keeping a prefix is important to easily
>   differentiate tags created by upstream developers from tags created
>   by packagers)

On the contrary, I believe the argument can be made that mixing tags
from different distributions under one prefix -- as you propose -- would
be much more confusing.

Ideally speaking, debian/ currently tells me that every tag in
there corresponds to a Debian upload, and vice versa. Consequently, I
don't want to see a tag in there from downstream distros, as that
relationship would no longer hold.

That argument also holds from a downstream distro's POV.
ubuntu/1.0-0ubuntu1 might look redundant, but I find the upload<->tag
relationship much more important that having slightly prettier tag names.

I think / is the way to go.

> - are there other important things to standardize?

"dfsg" branches are also common.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ee30f7.7090...@kvr.at

Re: Standardizing the layout of git packaging repositories

[Alessandro Ghedini]

On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote:
> - how do we tag the package releases?
> 
>   - pkg/
>   (note: git-buildpackage uses debian/ but I find this confusing
>   as we then also have the "debian/" prefix for ubuntu or kali uploads, we
>   don't need the vendor prefix as the usual versioning rules embed the
>   downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
>   any conflict on the namespace, keeping a prefix is important to easily
>   differentiate tags created by upstream developers from tags created
>   by packagers)

Letting aside the fact that "pkg/..." looks really ugly IMO, you are breaking
backwards "compatibility" with most git-buildpackage repositories for no real
benefit. If adopting this policy means that I have to somehow convert all my
repositories (possibly losing mildly useful information such as tag creation
date, tagger identity, tagger gpg signature, etc...), I'm not gonna do it.

Yes, if someone uses "debian/..." for e.g. ubuntu tags too (or uses some other
tag naming scheme), they'd have to change them, but I think it would be a much
smaller subset of both repositories and tags within a repsoitory.

Obviously one wouldn't be forced to convert their repositories to be compliant
to this policy, but if e.g. tooling based on this proposal is developed for
extracting information from repositories, and if there are very few repositories
actually compliant because it's too much of a PITA to convert, it's all gonna
be pretty useless.

Additionally, using the / scheme would allow for very simple
enumeration of debian vs. ubuntu vs. other with something like "git tag | grep
^/" without the need to actually parse debian/changelog or the specific
version of the tag (dunno if this would actually be useful for anything, but
it's a possibiliy).

Also, does every downstream distribution actually embed the distribution name
in the upload version or is it just ubuntu? Do they use the same scheme? Would
it be ok for this policy to "depend" on this?

> - where should the HEAD point to in the public repository?

Not sure what you mean by this.

> - shall we standardize the "pristine-tar" branch?

While I use pristine-tar, I feel like it's more of an implementation detail of
the building tools for the "how to generate the orig tarball" problem, than
something that should be standardized.

Also FWIW, pristine-tar is orphaned (see #737871, which contains some reasoning
about why using pristine-tar may not be a good idea).

> - the above layout is for the traditional case of non-native packages,
>   what would be the layout for native packages? how can be differentiate
>   between native/non-native layout?

I've never maintained a native package so I don't really know what are the
common practices, but AFAICT the only difference would be missing "upstream/..."
tags. Would that be enough for differentiating them?

> - are there other important things to standardize?

GPG signatures for tags? Although, I'm not sure if mandating signing tags would
be a good idea.

Cheers


signature.asc
Description: Digital signature

Re: Standardizing the layout of git packaging repositories

[Henrique de Moraes Holschuh]

On Fri, 15 Aug 2014, Raphael Hertzog wrote:
> - how do we tag the package releases?
> 
>   - pkg/
>   (note: git-buildpackage uses debian/ but I find this confusing

> - shall we standardize the "pristine-tar" branch?

IMHO it should be reserved for pristine-tar usage (as in "don't use it for
something else"), but use of the pristine-tar tool should be optional at
best.

pristine-tar has been orphaned *upstream*, it has design problems, and lots
of real world issues.  I'm seriously considering a "git branch -D
pristine-tar" on my packages :(

> - the above layout is for the traditional case of non-native packages,
>   what would be the layout for native packages? how can be differentiate
>   between native/non-native layout?

Please don't.  It would be Really Troublesome should a package need to
switch from native to non-native, or the opposite.

If you're worried about an useless "master" branch, one can do away with it
with help of git symbolic-ref on bare repositories:

git symbolic-ref HEAD refs/heads/debian/master

will change a bare repo's default branch to "debian/master", you can remove
the "master" branch after that.

> -  encoding (due to git restrictions):
> ":" -> "%"
> "~" -> "_"
> 
> - are there other important things to standardize?

What to do with packages that already adopt other schemes?  A lot of
packages already use dgit, git-buildpackage, etc and have signed tags they
might want to preserve.

Also, tag namespace is shared with upstream, so it has to be somewhat
flexible in case the recommended scheme cannot be used.

What about commit and tag signing?  Release tags ought to always be signed
really, but should we recommend something about commits or just ignore that?

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815162930.ga2...@khazad-dum.debian.net

Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

[Michael Biebl]

Am 15.08.2014 18:10, schrieb Michael Biebl:
> Am 15.08.2014 17:47, schrieb Gerrit Pape:
>> Severity: serious
>> Justification: Policy 2.5

[..]

> That this rule is violated in hundreds of cases [1] clearly shows that
> there is something wrong which needs to be addressed in a more idiomatic
> way.

> [1] https://qa.debian.org/debcheck.php?dist=sid&list=priority&arch=ANY

Gerrit, I see you started filing RC bugs for this.

Let's see if what the release team thinks about having an additional
~1800 RC bugs.


Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

[Bill Allombert]

On Fri, Aug 15, 2014 at 06:31:39PM +0200, Michael Biebl wrote:
> Am 15.08.2014 18:10, schrieb Michael Biebl:
> > Am 15.08.2014 17:47, schrieb Gerrit Pape:
> >> Severity: serious
> >> Justification: Policy 2.5
> 
> [..]
> 
> > That this rule is violated in hundreds of cases [1] clearly shows that
> > there is something wrong which needs to be addressed in a more idiomatic
> > way.
> 
> > [1] https://qa.debian.org/debcheck.php?dist=sid&list=priority&arch=ANY
> 
> Gerrit, I see you started filing RC bugs for this.

Please do not report RC bug for this. Priorities are adjusted by the FTP master
team by batch using the overrides file. There is no need to report bugs against
the packages.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815165144.GB27464@yellowpig

Re: Standardizing the layout of git packaging repositories

[Henrique de Moraes Holschuh]

On Fri, 15 Aug 2014, Christian Kastner wrote:
> On 2014-08-15 16:16, Raphael Hertzog wrote:
> >   - pkg/
> >   (note: git-buildpackage uses debian/ but I find this confusing
> >   as we then also have the "debian/" prefix for ubuntu or kali uploads, we
> >   don't need the vendor prefix as the usual versioning rules embed the
> >   downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
> >   any conflict on the namespace, keeping a prefix is important to easily
> >   differentiate tags created by upstream developers from tags created
> >   by packagers)
> 
> On the contrary, I believe the argument can be made that mixing tags
> from different distributions under one prefix -- as you propose -- would
> be much more confusing.
> 
> Ideally speaking, debian/ currently tells me that every tag in
> there corresponds to a Debian upload, and vice versa. Consequently, I
> don't want to see a tag in there from downstream distros, as that
> relationship would no longer hold.

FWIW, I agree with you.  I'd also prefer to keep downstream release tags in
the / namespace.  Using /
for the downstream release tags is not that likely to clash with upstream,
as that's already somewhat common practice.

And IME it is no trouble to have /* branches and /* tags,
they rarely clash and they *are* on separate namespaces (if you specify the
full ref/ path, anyway).

> That argument also holds from a downstream distro's POV.
> ubuntu/1.0-0ubuntu1 might look redundant, but I find the upload<->tag
> relationship much more important that having slightly prettier tag names.

Indeed.

And there is nothing confusing about ubuntu/master and debian/master
cross-merging, or merging from a common feature/development branch.  It
works well.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815170914.gb2...@khazad-dum.debian.net

Bug#758238: RFP: cool-old-term -- eye-candy terminal emulator which mimics old cathode displays

[Axel Beckert]

Package: wnpp
Severity: wishlist

* Package name: cool-old-term
  Version : no released version yet as it seems
  Upstream Author : Filippo Scognamiglio 
* URL or Web page : https://github.com/Swordifish90/cool-old-term
* License : GPLv3+ (some parts seem also GPLv2)
  Description : eye-candy terminal emulator which mimics old cathode 
displays

cool-old-term is a terminal emulator which tries to mimic the look and
feel of the old cathode tube screens. It has been designed to be
eye-candy, customizable, and reasonably lightweight.

It uses the Konsole engine(*) which is powerful and mature.

This terminal emulator requires Qt 5.2 or higher to run.

(*) Some more details about this seem on

https://swordfishslabs.wordpress.com/2014/07/29/brace-yourself-cool-old-term-is-coming/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761htllww@kiva6.ethz.ch

Re: Standardizing the layout of git packaging repositories

[Thomas Goirand]

On 08/15/2014 10:16 PM, Raphael Hertzog wrote:
> Some initial questions and possible answers:
> 
> - how do we name the various branches?
> 
>   - /master for the main development trunk (aka unstable in Debian)
>   - / for alternate versions
> 
>   The goal here is to be able to host in the same repository the branches for
>   multiple cooperating distributions (at least so that downstream can
>   clone the debian respository and inject their branches next to the
>   debian branches).

I generally use debian/unstable, but sometimes, it's best to follow
upstream (for OpenStack, I use debian/icehouse, debian/juno, etc.), so
there's no one-size-fit-all here.

> - how do we tag the upstream releases?
> 
>   - upstream/
>   (note: we don't need an "upstream" branch, having the good tag for any
>   release that the distros are packaging is enough, it can point to a
>   synthetic commit built with tools like git-import-orig or to a real
>   upstream commit)

Why would you tag the upstream release? I mean, it's upstream's job to
do so, and it's natural to use their git tagging and their git
repository, no?

> - how do we tag the package releases?
> 
>   - pkg/
>   (note: git-buildpackage uses debian/ but I find this confusing
>   as we then also have the "debian/" prefix for ubuntu or kali uploads, we
>   don't need the vendor prefix as the usual versioning rules embed the
>   downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
>   any conflict on the namespace, keeping a prefix is important to easily
>   differentiate tags created by upstream developers from tags created
>   by packagers)

Shouldn't ubuntu or kali use ubuntu/ and kali/? I
don't see a problem here.

> - where should the HEAD point to in the public repository?

IMO, it should point to the packaging branch for Sid, but YMMV. Why is
this important?

> - shall we standardize the "pristine-tar" branch?

As in, always use pristine-tar? No! The point of using git packaging is
also to be able to use upstream git repo.

> - the above layout is for the traditional case of non-native packages,
>   what would be the layout for native packages? how can be differentiate
>   between native/non-native layout?

Sorry, which layout are you talking about? With pristine-tar? Well, I
don't think using pristine-tar is in any way "traditional", it's just
one of the workflow, which I always avoid if upstream is using Git and
has correct tagging.

> -  encoding (due to git restrictions):
> ":" -> "%"
> "~" -> "_"

I do use "~" -> "_" myself. Very useful.

> - are there other important things to standardize?

Yes. Producing orig.tar.xz out of upstream tag should be industrialized,
and written in "some" tools, which we would all be using. I currently
do: ./debian/rules gen-orig-xz, but that shouldn't be specific to my own
packages.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ee4041.2090...@debian.org

Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

[Henrique de Moraes Holschuh]

On Fri, 15 Aug 2014, Michael Biebl wrote:
> Am 15.08.2014 17:47, schrieb Gerrit Pape:
> > Package: rsyslog
> > Version: 8.2.2-3
> > Severity: serious
> > Justification: Policy 2.5
> > 
> > Hi, the current rsyslog package version in testing is priority important
> > and depends on packages with priority extra.  Policy 2.5 states:
> > 
> > "Packages must not depend on packages with lower priority values
> > (excluding build-time dependencies)."

This rule was once really useful when we had tools that could not do
dependency resolution very well by themselves to sort out what needs to go
into d-i images, etc.

I am not sure it is still relevant, though, as the tools are a lot better
now.  This question should be asked in debian-boot@l.d.o, debian-cd@l.d.o,
and maybe even debian-release@l.d.o.

> That this rule is violated in hundreds of cases [1] clearly shows that
> there is something wrong which needs to be addressed in a more idiomatic
> way.

Maybe update the policy text to match reality?

"Any packages depended upon by a higher priority package are, effectively,
raised to that package's priority."

That said, AFAIK the current text was also supposed to get people to think
twice before adding new dependencies to high-priority packages, and to get
some external input before they do it.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815172233.gc2...@khazad-dum.debian.net

Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

[Gerrit Pape]

On Fri, Aug 15, 2014 at 06:51:44PM +0200, Bill Allombert wrote:
> Please do not report RC bug for this. Priorities are adjusted by the FTP 
> master
> team by batch using the overrides file. There is no need to report bugs 
> against
> the packages.

Hi, I filed three bugs for the extreme, where priority required depends
on priority extra in current jessie.  No fear, I won't do mass filing.

I queried all the numbers on this beforehand.  And I don't think it's
good to solve all this through ftp master's override[0].  This will
bloat the installations using high priority packages more and more.

In stable we have the following violations (packages)
 important: 8
 required: 2
 standard: 21
In current testing:
 important: 15
 required: 5
 standard: 43

It's not hundreds, or thousands.  Keep cool.
rsyslog was fine when we raised its priority in wheezy.

I personally don't care that much about the standard priority, but for
the higher ones, and definitely think we should stop this trend before
it's too late.

You can play with the tiny dash script attached, it was fun to write
it, call
 ./check-prio required
 ./check-prio required important
 ./check-prio required important standard

Regards, Gerrit.

[0] current signs are that this will pull perl into the required
packages set:
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-August/thread.html#3161
#!/bin/sh
set -e

priorities=${*:=required important standard optional}

aptitudeprios=$(for i in $priorities; do echo ~p$i\ ; done)
aptitude search $aptitudeprios -F%p | sed -e's/^ *//;s/ *$//' |
while read package; do
  depends=$(apt-cache show $package |grep '^Depends: ' || :)
  depends=${depends#Depends: }
  buggy=; broken=
  IFS=,
  for dep in $depends; do
dep=${dep%%| *}
dep=${dep##[ *]}; dep=${dep%%[ *]}
dep=${dep%% (*)}; dep=${dep%%\[*\]}; dep=${dep%% (*)}
prio=$(apt-cache show $dep |grep '^Priority: ' |head -n1)
test -n "$prio" ||
  { echo \ warning: $package: depends $dep: no priority; continue; }
prio=${prio#Priority: }
broken=yes
IFS=\ 
for i in $priorities; do
  test "$prio" != "$i" || broken=
done
test -z "$broken" ||
  { echo \ broken: $package: depends $dep, priority $prio.; buggy=yes; }
  done
  test -z "$buggy" || echo buggy: $package
done

Python 3.4

[Diogene Laerce]

Hi,

Does someone have any clue or hint on the upgrade of Debian to Python3
natively ?

Thank you,

-- 
“One original thought is worth a thousand mindless quotings.”
“Le vrai n'est pas plus sûr que le probable.”

  Diogene Laerce





signature.asc
Description: OpenPGP digital signature

Re: Python 3.4

[Paul Tagliamonte]

On Fri, Aug 15, 2014 at 07:28:06PM +0200, Diogene Laerce wrote:
> Hi,
> 
> Does someone have any clue or hint on the upgrade of Debian to Python3
> natively ?
> 
> Thank you,

Hey Diogene,

Python 3.4 is in Jessie, ready for action. I can confirm it works great,
It's all I use for my personal projects (in fact, I actually complain a
lot when I have to use Python 2 for some reason).

the /usr/bin/python command is unlikely to change soon; more information
on how this should be treated on UNIX like systems can be found at PEP 0394.


There's currently a big push to ensure we're all Python 3 compatable,
but that's something distinct from changing /usr/bin/python to point at
/usr/bin/python3.


Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Debian Installer Jessie Beta 1 release

[Stephen Allen]

On Wed, Aug 13, 2014 at 06:15:05PM +0200, Cyril Brulebois wrote:
> The Debian Installer team[1] is pleased to announce the first beta
> release of the installer for Debian 8 "Jessie".

Thanks.
 
[ ...] 
> 
> Known bugs in this release
> ==
> 
>  * Firmware handling: udev no longer reports missing firmware
>(#725714), and patches for the kernel need polishing before we are
>able to restore support for loading missing firmware.
>  * GNU/kFreeBSD installation images suffer from various important bugs
>(#757985, #757986, #757987, #757988). Porters could surely use some
>helping hands to bring the installer back into shape!
> 
> See the errata[2] for details and a full list of known issues.

[ ...]
 
> 
>  1. http://wiki.debian.org/DebianInstaller/Team
>  2. http://www.debian.org/devel/debian-installer/errata
>  3. http://www.debian.org/devel/debian-installer

---end quoted text---

Any changes between alpha errata to beta?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815175903.GA32385@Jessie

Re: Standardizing the layout of git packaging repositories

[Simon McVittie]

On 15/08/14 15:16, Raphael Hertzog wrote:
> Some initial questions and possible answers:

I've been hesitating on whether to ask this because it gets into
questions of workflow and repo structure that are very much a matter of
taste and don't have a single widely-declared-to-be-good answer, but I
think one of the important questions is: what is actually on the vendor
(e.g. Debian) branch?

The big question is "are vendor patches pre-applied or not?" but a
follow-up question, for 3.0 (quilt) packages, is "does .pc reflect that?"

I use gbp-pq for my own packages, so I would appreciate it if people who
actively use the other repo structures/helper tools could correct my
mistakes and discuss their advantages and disadvantages.

gbp-pq (from git-buildpackage), with imported tarballs in git
-

gbp-pq encourages the answer to be "pristine contents of tarball plus a
debian/ directory containing a quilt patch series, those patches are
*not* applied to the upstream sources as they appear in the repo, .pc
does not exist". This is the policy in all the teams in which I'm active
(possibly excluding pkg-games which might not have an overall policy)
and the one I personally prefer, at least at the moment. It has the
advantage that you don't have to rebase a published branch (which is
Bad™) in order to rebase the vendor patches onto new upstream versions
(which is something you'll be doing all the time in most packages). It
has the disadvantage that you can't just cherry-pick an upstream commit,
you have to do non-git-ish things like dropping a git-format-patch into
debian/patches or using gbp-pq.

systemd's current README.source
 is a
good set of instructions for doing common maintainer/NMUer things in a
gbp-pq tree. You can also build from such a tree with a plain
`dpkg-buildpackage`.

I conjecture that maintainers who are used to things that are not git
(particularly svn, as used by pkg-perl, pkg-gnome, pkg-python-* etc.)
will also feel at home with this structure: it is entirely possible to
not use gbp-pq, and instead apply/unapply patches with quilt.

git-import-orig knows how to merge upstream VCS tags into an upstream
branch that is otherwise based on imported tarballs, so it is possible
to have the upstream/* commits reflect what was in imported tarballs but
still have your upstream's git commits as an ancestor.

gbp-pq (from git-buildpackage), with upstream git as base
-

As long as you don't need to patch any files that do not exist in
upstream git but only in the tarball (e.g. use dh-autoreconf instead of
patching Makefile.in), and you don't have to drop any upstream files
(e.g. for DFSG reasons), it is possible to use upstream git as your
basis for branching, instead of importing tarballs. That's how systemd
is packaged at the moment.

git-buildpackage --git-export, with only debian/ in git
---

It is possible to use git-buildpackage with --git-export (either
explicitly, or configured in debian/gbp.conf) for packages that only
keep debian/ in git. In this situation, the only possibility is to have
patches *not* pre-applied, because there is nothing there to patch. This
matches how teams like pkg-gnome have traditionally used svn.

I would strongly recommend having upstream source in git, not just
debian/, with one exception: packages like openarena-data, which mostly
contain giant binary files that cannot meaningfully be patched.

git-dpm
---

git-dpm encourages the contents of the vendor branch to be "exactly the
source that will be built, vendor patches *are* applied" and uses a
relatively elaborate merging structure to avoid rebasing
(). I don't know whether .pc is
typically present in the tree for 3.0 (quilt) packages or not, or
whether users of git-dpm avoid 3.0 (quilt) format altogether.

gitpkg
--

As far as I can tell, gitpkg encourages the answer to be "exactly the
source that will be built, vendor patches *are* applied, but .pc is not
present in git". However, I could be wrong. When I tried to apply
downstream patches to a version of systemd that used gitpkg, I got
confused enough to just give up on using the maintainers' git tree and
re-import it with git-import-dsc instead.

(systemd has since switched to the gbp-pq layout, which I found much
easier to deal with.)

dgit


dgit encourages the answer to be "exactly the source that will be built,
vendor patches *are* applied, if the package uses 3.0 (quilt) then .pc
also exists and reflects the state of the tree". I'm not sure what
techniques dgit users use to deal with non-native packages that have
vendor patches without rebasing a published branch - git-dpm seems like
it might be a good fit?

There seems to be a strong correlation between happy dgit users, and
those who e

Bug#758245: ITP: libcli-framework-perl -- standardized, flexible, testable CLI applications framework for Perl

[Bálint Réczey]

Package: wnpp
Owner: Balint Reczey 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcli-framework-perl
  Version : 0.05
  Upstream Author : Karl Erisman 
* URL : https://metacpan.org/release/CLI-Framework
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : standardized, flexible, testable CLI applications
framework for Perl

 CLI::Framework ("CLIF") provides a framework and conceptual pattern for
 building full-featured command line applications. It intends to make
 this process simple and consistent. It assumes the responsibility of
 implementing details that are common to all command-line applications,
 making it possible for new applications adhering to well-defined
 conventions to be built without the need to repeatedly write the same
 command-line interface code.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpzpmTJf2Xc-6R-CVE7U4B7j=tfoFW5ON=tppagd368...@mail.gmail.com

Re: Standardizing the layout of git packaging repositories

[Marco d'Itri]

On Aug 15, Raphael Hertzog  wrote:

> - we can more easily share our git repositories with upstreams
>   and downstreams
Did they ask for this?

> - how do we tag the upstream releases?
>   - upstream/
Some of my packages just use the real upstream git tree as their 
upstream branch, so the upstream releases are already tagged using the 
upstream scheme.

> - how do we tag the package releases?
>   - pkg/
Other people already shot down this with good arguments.

> - shall we standardize the "pristine-tar" branch?
Shall we kill pristine-tar instead, since it is mostly a waste of space 
for everybody without an md5 fetish?

> - are there other important things to standardize?
Do not try to make other people change their workflows without evident 
benefits (pro tip: "standardization" in itself is not one) or they will 
be annoyed and just ignore your work.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Bálint Réczey]

Hi,

2014-08-15 14:20 GMT+02:00 Michael Niedermayer :
> On Fri, Aug 15, 2014 at 02:53:09PM +0800, Thomas Goirand wrote:
>> On 08/14/2014 11:59 PM, The Wanderer wrote:
>> > On 08/14/2014 11:27 AM, Thomas Goirand wrote:
>> >
>> >> On 08/13/2014 07:53 AM, Kieran Kunhya wrote:
>> >
>> >> On 08/13/2014 06:30 AM, Michael Niedermayer wrote:
>> >
>> >>> Also ive offered my resignation in the past. I do still offer to
>> >>> resign from the FFmpeg leader position, if it resolves this split
>> >>> between FFmpeg and Libav and make everyone work together again.
>> >
>> >> Why not just take the offer, and move on?
>> >
>> > Probably because of the condition he attached to it, which also dates
>> > back to the arguments preceding the original split:
>> >
>> >>> The part i insist on though is that everyone must be able to work
>> >>> on their code without people uninvolved in that specific parts
>> >>> maintaince or authorship being able to block their work.
>> >
>> > In other words, as I think I understand it from the discussion back
>> > then: people not involved with a particular area of the code can't NACK
>> > the work of someone who is working on it, and someone who works on a
>> > particular area of the code doesn't have to wait on review of people who
>> > aren't involved with that area of the code.
>> >
>> > Since one of the motivations of the people behind the libav side of the
>> > split seems, IIRC, to have been "no code gets in without having been
>> > reviewed by someone other than the author", this was apparently deemed
>> > an unacceptable condition.
>>
>> Hum... Well, to me, what's important is that the code gets
>> peer-reviewed.
>
> Yes, the tricky part in FFmpeg and Libav in relation to this is that
> theres quite a bit of code that is only well understood by a single
> person even if you would combine both projects together.
> So if that person posts a patch for review, theres noone who could
> do a real review
This situation is not totally unique to FFmpeg/Libav. IMO in this
real-life situation peers can do a best-effort review and people doing
so would sooner or later will get familiar with those parts of the
code as well.
In case of a widely used library like this the biggest issue is
breaking the ABI or modifying the ABI in a way which does not align
with the team's vision about the ABI roadmap. That type of change can
be pointed out by less experienced developers, too.
Internal regressions in the code can be easily fixed even if they are
not discovered during testing and enter the release.

>
>
>> Setting-up something like gerrit may help, as it can be
>> setup in a way that review becomes mandatory. Then discussing who's
>> core-reviewer and can approve this or that part of the code can be setup
>> within gerrit. This should be discussed, and setup based on technical merit.
>
> Not commenting about gerrit as i dont have experience with it, but
> FFmpeg currently uses a simple file in main ffmpeg git that lists
> which part is maintained by whom, and these developers would in the
> rare case of a dispute have the final say in each area.
Using Gerrit and "file ownersip" are not mutually exclusive. Gerrit
can be configured to automatically invite the right people for review
based on the changed path. We recently migrated to Gerrit at the
Wireshark project and it helps a lot in coordinating the reviews.

Cheers,
Balint

>
> OTOH, Libav early deleted their forked version of this file, and
> iam not aware of any replacement. But others should explain how it
> works in Libav ...
>
>
>>
>> Having a NACK review is often disappointing. It goes the wrong way if
>> there's only a NACK with no comments on how to improve things, so that
>> the code becomes acceptable.
>
>> Absolutely everyone should *always* be able
>> to leave comments, be it positive or negative.
>
> yes, i fully agree and this also was always so in FFmpeg. In that
> sense everyone is welcome to subscribe to ffmpeg-devel and review and
> comment patches. That of course includes Libav developers and everyone
> else. And more reviewers would also certainly help, so yeah anyone
> reading this and wanting to help review patches, you are welcome!
>
> Thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> it is not once nor twice but times without number that the same ideas make
> their appearance in the world. -- Aristotle


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpwaj1irea2ymdznjqwkw+hhep3yg-vvuy8mp8hje3d...@mail.gmail.com

Re: Standardizing the layout of git packaging repositories

[Scott Kitterman]

On August 15, 2014 10:16:01 AM EDT, Raphael Hertzog  wrote:
>Hello,
>
>while git is the most popular VCS for packaging, there's no clear rules
>on what you can expect in a random git packaging repository listed
>in Vcs-Git. I would like to fix this so that:
>- we can extract more useful data from the git repositories
>- we can more easily share our git repositories with upstreams
>  and downstreams
>- we start to converge on some conventions even though we might
>  continue to use different git helper tools
>
>I want to use the DEP process for this. But before I can write a first
>draft I would like to have your ideas of what we should include
>in such a document.
>
>Some initial questions and possible answers:
>
>- how do we name the various branches?
>
>- /master for the main development trunk (aka unstable in
>Debian)
>  - / for alternate versions
>
>The goal here is to be able to host in the same repository the branches
>for
>  multiple cooperating distributions (at least so that downstream can
>  clone the debian respository and inject their branches next to the
>  debian branches).
>
>- how do we tag the upstream releases?
>
>  - upstream/
> (note: we don't need an "upstream" branch, having the good tag for any
>  release that the distros are packaging is enough, it can point to a
>  synthetic commit built with tools like git-import-orig or to a real
>  upstream commit)
>
>- how do we tag the package releases?
>
>  - pkg/
>(note: git-buildpackage uses debian/ but I find this confusing
>as we then also have the "debian/" prefix for ubuntu or kali uploads,
>we
>  don't need the vendor prefix as the usual versioning rules embed the
>downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't
>be
> any conflict on the namespace, keeping a prefix is important to easily
>  differentiate tags created by upstream developers from tags created
>  by packagers)
>
>- where should the HEAD point to in the public repository?
>
>- shall we standardize the "pristine-tar" branch?
>
>- the above layout is for the traditional case of non-native packages,
> what would be the layout for native packages? how can be differentiate
>  between native/non-native layout?
>  
>-  encoding (due to git restrictions):
>":" -> "%"
>"~" -> "_"
>
>- are there other important things to standardize?

We don't even agree on if repositories should be full source or Debian 
directory only. Not sure how we can even start to discuss the rest if we don't 
agree on that. 

Scott K



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/dd4ca987-e3ca-4304-b8c4-e9afa0e5a...@email.android.com

Re: Python 3.4

[Scott Kitterman]

On August 15, 2014 1:42:04 PM EDT, Paul Tagliamonte  wrote:
>On Fri, Aug 15, 2014 at 07:28:06PM +0200, Diogene Laerce wrote:
>> Hi,
>> 
>> Does someone have any clue or hint on the upgrade of Debian to
>Python3
>> natively ?
>> 
>> Thank you,
>
>Hey Diogene,
>
>Python 3.4 is in Jessie, ready for action. I can confirm it works
>great,
>It's all I use for my personal projects (in fact, I actually complain a
>lot when I have to use Python 2 for some reason).
>
>the /usr/bin/python command is unlikely to change soon; more
>information
>on how this should be treated on UNIX like systems can be found at PEP
>0394.

s/soon/ever/

It's more likely /usr/bin/python will someday be removed than someday point to 
a python3 version. 

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cb3f3e44-09ec-4e0c-abbf-3c11025b3...@email.android.com

Re: Standardizing the layout of git packaging repositories

[Andrew Kelley]

On Fri, Aug 15, 2014 at 11:17 AM, Marco d'Itri  wrote:

> > - shall we standardize the "pristine-tar" branch?
> Shall we kill pristine-tar instead, since it is mostly a waste of space
> for everybody without an md5 fetish?


Can you explain what you mean by this, for someone who is relatively new to
packaging? What is the alternative to pristine-tar?

Re: Standardizing the layout of git packaging repositories

[Marco d'Itri]

On Aug 15, Andrew Kelley  wrote:

> > > - shall we standardize the "pristine-tar" branch?
> > Shall we kill pristine-tar instead, since it is mostly a waste of space
> > for everybody without an md5 fetish?
> Can you explain what you mean by this, for someone who is relatively new to
> packaging? What is the alternative to pristine-tar?
The first step is to determine which problem you are trying to solve.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Debian Installer Jessie Beta 1 release

[David Prévot]

Hi,

Le 15/08/2014 13:59, Stephen Allen a écrit :
> On Wed, Aug 13, 2014 at 06:15:05PM +0200, Cyril Brulebois wrote:
>> The Debian Installer team[1] is pleased to announce the first beta
>> release of the installer for Debian 8 "Jessie".
> 
> Thanks.

+1

> Any changes between alpha errata to beta?

http://anonscm.debian.org/viewvc/webwml/webwml/english/devel/debian-installer/errata.wml?r1=1.200&r2=1.201

Regards

David





signature.asc
Description: OpenPGP digital signature

Re: Standardizing the layout of git packaging repositories

[Steve Langasek]

On Fri, Aug 15, 2014 at 01:36:24PM -0700, Andrew Kelley wrote:
> On Fri, Aug 15, 2014 at 11:17 AM, Marco d'Itri  wrote:

> > > - shall we standardize the "pristine-tar" branch?
> > Shall we kill pristine-tar instead, since it is mostly a waste of space
> > for everybody without an md5 fetish?

> Can you explain what you mean by this, for someone who is relatively new to
> packaging? What is the alternative to pristine-tar?

The alternative is handwaving and ignoring the fact that your package
repository is not a complete representation of your package as it exists in
the archive.

-- 
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: Python 3.4

[Diogene Laerce]

On 08/15/2014 07:42 PM, Paul Tagliamonte wrote:
> On Fri, Aug 15, 2014 at 07:28:06PM +0200, Diogene Laerce wrote:
>> Does someone have any clue or hint on the upgrade of Debian to Python3
>> natively ?
> 
> Python 3.4 is in Jessie, ready for action. I can confirm it works great,
> It's all I use for my personal projects (in fact, I actually complain a
> lot when I have to use Python 2 for some reason).
> 
> the /usr/bin/python command is unlikely to change soon; more information
> on how this should be treated on UNIX like systems can be found at PEP 0394.
> 
> There's currently a big push to ensure we're all Python 3 compatable,
> but that's something distinct from changing /usr/bin/python to point at
> /usr/bin/python3.

I just downloaded Jessie, going to VM it.

Thanks for the link as well. :)
-- 
“One original thought is worth a thousand mindless quotings.”
“Le vrai n'est pas plus sûr que le probable.”

  Diogene Laerce



signature.asc
Description: OpenPGP digital signature

Re: Standardizing the layout of git packaging repositories

[Marco d'Itri]

On Aug 15, Steve Langasek  wrote:

> The alternative is handwaving and ignoring the fact that your package
> repository is not a complete representation of your package as it exists in
> the archive.
It is not obvious why this would be a problem.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Python 3.4

[Diogene Laerce]

On 08/15/2014 10:20 PM, Scott Kitterman wrote:
> On August 15, 2014 1:42:04 PM EDT, Paul Tagliamonte  
> wrote:
>> On Fri, Aug 15, 2014 at 07:28:06PM +0200, Diogene Laerce wrote:

[...]

>>
>> the /usr/bin/python command is unlikely to change soon; more
>> information
>> on how this should be treated on UNIX like systems can be found at PEP
>> 0394.
> 
> It's more likely /usr/bin/python will someday be removed than someday point 
> to a python3 version. 

No python on the OS ? Regard to the number of applications that rely on
python, that's kind of unlikely no ?

Cheers,
-- 
“One original thought is worth a thousand mindless quotings.”
“Le vrai n'est pas plus sûr que le probable.”

  Diogene Laerce



signature.asc
Description: OpenPGP digital signature

Re: Standardizing the layout of git packaging repositories

[Guido Günther]

On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote:
> Hello,
> 
> while git is the most popular VCS for packaging, there's no clear rules
> on what you can expect in a random git packaging repository listed
> in Vcs-Git. I would like to fix this so that:
> - we can extract more useful data from the git repositories
> - we can more easily share our git repositories with upstreams
>   and downstreams
> - we start to converge on some conventions even though we might
>   continue to use different git helper tools
> 
> I want to use the DEP process for this. But before I can write a first
> draft I would like to have your ideas of what we should include
> in such a document.
> 
> Some initial questions and possible answers:
> 
> - how do we name the various branches?
> 
>   - /master for the main development trunk (aka unstable in Debian)
>   - / for alternate versions

The gbp manual has a recommended branch layout:

  
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.BRANCH.NAMING

which could serve as a basis. There's plenty of room for improvement,
e.g. the case where one tracks upstream git isn't yet mentioned (I
started to follow the above layout also in this case).

>   The goal here is to be able to host in the same repository the branches for
>   multiple cooperating distributions (at least so that downstream can
>   clone the debian respository and inject their branches next to the
>   debian branches).
> 
> - how do we tag the upstream releases?
> 
>   - upstream/
>   (note: we don't need an "upstream" branch, having the good tag for any
>   release that the distros are packaging is enough, it can point to a
>   synthetic commit built with tools like git-import-orig or to a real
>   upstream commit)

Agreed, although having a branch (and recommended naming convention)
can be useful.

> - how do we tag the package releases?
> 
>   - pkg/
>   (note: git-buildpackage uses debian/ but I find this confusing
>   as we then also have the "debian/" prefix for ubuntu or kali uploads, we
>   don't need the vendor prefix as the usual versioning rules embed the
>   downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
>   any conflict on the namespace, keeping a prefix is important to easily
>   differentiate tags created by upstream developers from tags created
>   by packagers)

The tag format is configurable in gbp and I'd expect downstreams to
use a different name space (e.g. ubuntu/). This makes it
simpler to tab complete (or delete) certain groups of tags. A patch to
make the tag message configurable too is waiting to be applied. pkg/
is too generic since we'll have more of the RPM support upstreamed
soonish.

Cheers,
 -- Guido


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815191055.ga2...@bogon.m.sigxcpu.org

Re: Python 3.4

[Scott Kitterman]

On August 15, 2014 4:57:19 PM EDT, Diogene Laerce  wrote:
>
>
>On 08/15/2014 10:20 PM, Scott Kitterman wrote:
>> On August 15, 2014 1:42:04 PM EDT, Paul Tagliamonte
> wrote:
>>> On Fri, Aug 15, 2014 at 07:28:06PM +0200, Diogene Laerce wrote:
>
>[...]
>
>>>
>>> the /usr/bin/python command is unlikely to change soon; more
>>> information
>>> on how this should be treated on UNIX like systems can be found at
>PEP
>>> 0394.
>> 
>> It's more likely /usr/bin/python will someday be removed than someday
>point to a python3 version. 
>
>No python on the OS ? Regard to the number of applications that rely on
>python, that's kind of unlikely no ?
>
>Cheers,

Pointing /usr/bin/python at a python3 version is not providing python in that 
sense. If something uses python3, it should use /usr/bin/python3.  Someday, in 
the distant future, /usr/bin/python should become irrelevant. It should never 
point at a python3 version. 

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/831ef6a7-6f9d-4f45-954e-ea30a10ff...@email.android.com

Re: Standardizing the layout of git packaging repositories

[brian m. carlson]

On Fri, Aug 15, 2014 at 08:17:16PM +0200, Marco d'Itri wrote:
> On Aug 15, Raphael Hertzog  wrote:
> > - are there other important things to standardize?
> Do not try to make other people change their workflows without evident
> benefits (pro tip: "standardization" in itself is not one) or they will
> be annoyed and just ignore your work.

I send a lot of one-off patches to packages.  I like to file a bug and
follow it up with a patch.  Unfortunately, everybody doing things a
different way makes it unpleasant to do that.  (And yes, I know about
README.source.)

Right now, I just build the source package repeatedly until it works,
unless the package doesn't build twice in a row, in which case I swear
repeatedly and no patch is sent.  If there's a standard workflow, it
makes my life easier and results in a patch that works better for the
maintainer.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Standardizing the layout of git packaging repositories

[Don Armstrong]

On Fri, 15 Aug 2014, Marco d'Itri wrote:
> On Aug 15, Steve Langasek  wrote:
> > The alternative is handwaving and ignoring the fact that your package
> > repository is not a complete representation of your package as it exists in
> > the archive.
>
> It is not obvious why this would be a problem.

Because you're a Debian Developer and might want to upload a package to
the archive without downloading the uploaded tarball which substantially
duplicates what you have in your source tree? Or you're collaborating
with someone and need to use a repacked tarball?

-- 
Don Armstrong  http://www.donarmstrong.com

I'm wrong to criticize the valor of your brave men. It's important to
die for one's country when it means being the subject of a king who
wears a ruffled collar or a pleated one.
 -- Cyrano de Bergerac


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815230917.gl22...@teltox.donarmstrong.com

Bug#758178: screen resolution reverts to minimum when not selected by KVM

[Tomasz Nitecki]

tag 758178 + moreinfo
thanks


Hey,

Can you please provide us with some more details about your problem?

1. Are there any suspicious messages in dmesg or gnome log after the
screen resolution drops to 600x480? Can you please attach them both?

2. Can you ssh to an affected machine after it black outs (that is after
trying to reset the resolution)? If so, are there any error messages in
dmesg or gnome log? Please attach them if you can connect.

3. If you restart X server after the screen resolution drops, does it
get back to normal?

4. Did you (or can you) try if this problem also occurs while using any
other desktop environment?


Regards,
T.



signature.asc
Description: OpenPGP digital signature

Processed: screen resolution reverts to minimum when not selected by KVM

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tag 758178 + moreinfo
Bug #758178 [general] general: screen resolution reverts to minimum when not 
selected by KVM
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
758178: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758178
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.c.140814453026469.transcr...@bugs.debian.org

Re: Standardizing the layout of git packaging repositories

[Jeremy Stanley]

On 2014-08-16 01:15:45 +0800 (+0800), Thomas Goirand wrote:
[...]
> Yes. Producing orig.tar.xz out of upstream tag should be industrialized,
> and written in "some" tools, which we would all be using. I currently
> do: ./debian/rules gen-orig-xz, but that shouldn't be specific to my own
> packages.

However upstream may build tarballs through a (hopefully
repeatable/automated) process at release time, publish checksums and
signatures for them, et cetera, and prefer packagers use those as
the original tarballs for official release versions. I understand
needing to create "original" tarballs yourself in cases where there
are none (for example making development snapshot packages), but
when upstream provides them it seems like it would make sense to use
those tarballs in lieu of trying to recreate your own from tags in
their version control system.

I have become increasingly wary now that more and more slipshod
upstreams with no release process have created a need for package
maintainers to fabricate one on their behalf, the kludge can get
turned back around on upstreams with formal, traditional release
processes and used as a convenient excuse to discard their output in
the name of consistency. *Please* don't replace upstream's release
tarballs just because they have a VCS.
-- 
Jeremy Stanley


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815230550.gp1...@yuggoth.org

Re: Python 3.4

[Brian May]

On 16 August 2014 03:42, Paul Tagliamonte  wrote:

> There's currently a big push to ensure we're all Python 3 compatable,
>

Note that there is a huge number of Python packages in Debian. It is very
possible that your favourite packages aren't available as Python3 Debian
packages, either because upstream doesn't support Python 3, or because
nobody has done the work yet to make the Python 3 package.

For me, at least, the list of packages "in demand" is steadily going down,
especially if you consider the packages currently stuck in NEW.

On that note, is it ok for me to upload packages that depend on packages
stuck in NEW, or do I have to wait for the packages to clear NEW first? I
have at least one pending Python3 package in this situation.
-- 
Brian May 

Re: Standardizing the layout of git packaging repositories

[Scott Kitterman]

On Friday, August 15, 2014 23:04:54 brian m. carlson wrote:
> On Fri, Aug 15, 2014 at 08:17:16PM +0200, Marco d'Itri wrote:
> > On Aug 15, Raphael Hertzog  wrote:
> > > - are there other important things to standardize?
> > 
> > Do not try to make other people change their workflows without evident
> > benefits (pro tip: "standardization" in itself is not one) or they will
> > be annoyed and just ignore your work.
> 
> I send a lot of one-off patches to packages.  I like to file a bug and
> follow it up with a patch.  Unfortunately, everybody doing things a
> different way makes it unpleasant to do that.  (And yes, I know about
> README.source.)
> 
> Right now, I just build the source package repeatedly until it works,
> unless the package doesn't build twice in a row, in which case I swear
> repeatedly and no patch is sent.  If there's a standard workflow, it
> makes my life easier and results in a patch that works better for the
> maintainer.

This gets to why, for teams I work in where full source git branches are used, 
I really like git-dpm.  The output of the git-dpm workflow is a version 3.0 
(quilt) package with all the upstream changes in segregated patches per commit 
so they make logical sense.  That way, any third party that needs to address 
an issue in the package can do so with no reference at all to a VCS repo.  
They just work on the Debian source package that is available in the most 
common type that is used in the archive.

The packager's VCS is mostly useful for the people who normally work on the 
package.  For others, the source package is the most useful thing.  About the 
only thing I use the VCS of packages that aren't normally ones I work on for 
is to understand the history of something to try and figure out where it went 
wrong.

Whatever is "standardized" it really, really ought to produce a useful source 
package as that's the preferred form of modification in the project.

Scott K


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

Re: Standardizing the layout of git packaging repositories

[Russ Allbery]

m...@linux.it (Marco d'Itri) writes:
> On Aug 15, Andrew Kelley  wrote:

>> Can you explain what you mean by this, for someone who is relatively
>> new to packaging? What is the alternative to pristine-tar?

> The first step is to determine which problem you are trying to solve.

I want to be able to check out a git repository and do packaging work and
an upload, without having to pull any external artifacts from somewhere
else.

-- 
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: https://lists.debian.org/87ha1djj45@hope.eyrie.org

Re: Standardizing the layout of git packaging repositories

[Henrique de Moraes Holschuh]

On Fri, 15 Aug 2014, Steve Langasek wrote:
> The alternative is handwaving and ignoring the fact that your package
> repository is not a complete representation of your package as it exists in
> the archive.

What's wrong with storing the upstream tarballs themselves on a separate
branch, if you're that desperate to have them inside the same git repo as
the code?

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140816015310.ga22...@khazad-dum.debian.net

Re: Standardizing the layout of git packaging repositories

[Russ Allbery]

Henrique de Moraes Holschuh  writes:
> On Fri, 15 Aug 2014, Steve Langasek wrote:

>> The alternative is handwaving and ignoring the fact that your package
>> repository is not a complete representation of your package as it
>> exists in the archive.

> What's wrong with storing the upstream tarballs themselves on a separate
> branch, if you're that desperate to have them inside the same git repo
> as the code?

I like Git repositories that are about 10MB rather than 200MB or more.
(And yes, I have used exactly that approach in the past, and know exactly
how painful having all the tarballs in the revision control system is.
Never again.)

-- 
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: https://lists.debian.org/8738cxjhbm@hope.eyrie.org

Re: Standardizing the layout of git packaging repositories

[Charles Plessy]

Le Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog a écrit :
> 
> while git is the most popular VCS for packaging, there's no clear rules
> on what you can expect in a random git packaging repository listed
> in Vcs-Git. I would like to fix this so that:
> - we can extract more useful data from the git repositories
> - we can more easily share our git repositories with upstreams
>   and downstreams
> - we start to converge on some conventions even though we might
>   continue to use different git helper tools
> 
> I want to use the DEP process for this. But before I can write a first
> draft I would like to have your ideas of what we should include
> in such a document.

Bonjour Raphaël,

I think that it is a good idea to propose a standard that packaging team and
individual developers can follow optionally if they like it.  In the Debian Med
packaging team, I would be glad to be able to replace the guidelines in our
group with a pointer to the DEP that you propose to write.

Here are a few comments.

Regarding the name of the branches, I think that it would be preferable to
systematically use a prefix, ‘debian’, and I think that ‘debian/unstable’ is
more consistent than ‘debian/master’.  For the backports, I have been using
‘debian/wheezy-backports’, etc.  Altogether, the pattern is ‘debian/suite’. 

The ‘pristine-tar’ branch, while mostly used for Debian, is universal in
principle (who would knowingly release a tarball with the same name and a
different content from an alreadly circulating tarball ?), and therefore
probably does not need a ‘debian’ prefix.  Pristine-tar has been useful to
avoid preparing an upload with a tarball that has the same content but a
different MD5 sum than the one in the archive (because of time stamps, etc).
The interest for this is a bit reduced now that we have source-only uploads
(which are easier to prepare), but I think that it is still a good thing to
have for source packages based on upstream tarballs.

The ‘upstream’ branch generated and used by the tools from ‘git-buildpackage’
is usually different from the master branch of the upstream Git repository when
it exists.  While this branch name is well-established in Debian, I think that
it is misleading and for my new packages I try to avoid it.  When it is still
necessary to import upstream tarballs, I would rather use a name under the 
‘debian/’
prefix.  When the upstream master branch is enough, I prefer to leave it under
the name ‘master’.

Of course, the Debian clones of the repository should use a debian branch by
default, like ‘debian/unstable’.

For the Debian tags, I think that we definitely need a prefix, as I have seen
upstream releases like 1.0 being followed by 1.0-1…  The tag prefix 
can be seen as identifying the distribution or the format; I would not mind if
there were Ubuntu packages tagged with a  prefix.

The following is probably too rarely used to standardise, but maybe somebody
has an insightful comment to make ?  I have been storing build logs in the Git
repositories of some source packages I maintain.  At the beginning, I called
the branch ‘meta‘ and had all the logs in the same branch, and later I tried
things like debian/logs/unstable to separate suites, or build/amd64, etc, with
one log in each branch, so that ‘git diff’ can do the right thing.

Lastly, perhaps off-topic, would it make sense to give a recommendation on how
to manage upstream sources that use Git and ‘gnulib’ ?  I have met such a
situation, where the version number of the program was not availalbe in any
other way than through a Git tag, and could not find better than importing the
release tarball with ‘git-import-orig’ instead of following Upstream's master
branch.

Have a nice week-end,

Charles

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


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

Re: Python 3.4

[Lars Wirzenius]

On Sat, Aug 16, 2014 at 11:07:01AM +1000, Brian May wrote:
> On that note, is it ok for me to upload packages that depend on packages
> stuck in NEW, or do I have to wait for the packages to clear NEW first? I
> have at least one pending Python3 package in this situation.

If you upload things to unstable that depend on things in NEW, nobody
will be able to install or upgrade that package (until the dependency
gets through NEW). This includes, for example, automatic tools for QA.
Even though unstable is not meant for production, many people do run
it and we're better off when they do, quality-wise, It'd be nice to
avoid unnecessary breakage in unstable. Thus, uploading things only
after their depenencies get through NEW is what I would do and
recommend.

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140816061116.gd7...@exolobe1.liw.fi

Re: Python 3.4

[Brian May]

On 16 Aug 2014 16:19, "Lars Wirzenius"  wrote:
> If you upload things to unstable that depend on things in NEW, nobody
> will be able to install or upgrade that package (until the dependency
> gets through NEW).

In this case however the 2nd package will also get blocked in New (Python3
support requires adding at least one new package), so it really depends
which order the ftp-masters approve the requests.

I would hope they don't approve a package in New that depends on another
package in New, but not sure if they are setup to handle this case.

It really seriously limits the number of python3 packages we can get in for
Jessie if I have to wait 3+ weeks to get packages approved before I can
deal with the packages that depend on this one.