Re: Annonce d'un nouveau paquet guppy5.deb Ubuntu - Debian
On Wed, Nov 12, 2014 at 07:45:44AM +0100, Jean Millet wrote: Bonjour à tous, Bonjour. Nouveau sur cette liste et également dans le développement de paquet .deb, Mon gros problème est que je ne maîtrise pas l'anglais et je fais donc cette annonce sur les listes en français. Ce n'est probablement pas la meilleure solution et je sollicite donc votre aide. Il faut remplir un rapport de bug ITP (Intent To Package), qui sera automatiquement transmis à debian-devel. En anglais, impérativement :-). L’outil reportbug t’aidera à le faire dans les règles. Le document https://www.debian.org/doc/manuals/maint-guide/ répond à ces questions, et bien d’autres. J'ai commencé le développement sur une Ubuntu 14.04 LTS et je fais des tests en parallèle sur une Debian 7. La version finale du paquet doit être construite dans une debian unstable. Sauf erreur de ma part, il est possible d’utiliser un chroot Debian unstable dans une Ubuntu. Dois-je faire l'annonce de guppy5.deb sur la liste debian-devel-announce ou sur une autre liste ? Et puis-je utiliser le français sur cette liste ou sur d'autres qui sont en principe prévues pour l'anglais ?. Il est indispensable d’accomplir certaines démarches en anglais, ne serait-ce que remplir les fichiers debian/control ou debian/changelog. Le milieu est indulgent avec les anglophones non-natifs, et une demande de relecture passera très bien. Bon courage. -- Quidquid latine dictum sit, altum videtur. -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112082350.GA11920@pegase
Re: Annonce d'un nouveau paquet guppy5.deb Ubuntu - Debian
Le 12/11/2014 09:23, Nicolas Boulenguez a écrit : On Wed, Nov 12, 2014 at 07:45:44AM +0100, Jean Millet wrote: Bonjour à tous, Bonjour. Nouveau sur cette liste et également dans le développement de paquet .deb, Mon gros problème est que je ne maîtrise pas l'anglais et je fais donc cette annonce sur les listes en français. Ce n'est probablement pas la meilleure solution et je sollicite donc votre aide. Il faut remplir un rapport de bug ITP (Intent To Package), qui sera automatiquement transmis à debian-devel. En anglais, impérativement :-). L’outil reportbug t’aidera à le faire dans les règles. Le document https://www.debian.org/doc/manuals/maint-guide/ répond à ces questions, et bien d’autres. J'ai commencé le développement sur une Ubuntu 14.04 LTS et je fais des tests en parallèle sur une Debian 7. La version finale du paquet doit être construite dans une debian unstable. Sauf erreur de ma part, il est possible d’utiliser un chroot Debian unstable dans une Ubuntu. Dois-je faire l'annonce de guppy5.deb sur la liste debian-devel-announce ou sur une autre liste ? Et puis-je utiliser le français sur cette liste ou sur d'autres qui sont en principe prévues pour l'anglais ?. Il est indispensable d’accomplir certaines démarches en anglais, ne serait-ce que remplir les fichiers debian/control ou debian/changelog. Le milieu est indulgent avec les anglophones non-natifs, et une demande de relecture passera très bien. Bon courage. -- Quidquid latine dictum sit, altum videtur. Bonjour Nicolas, J'ai bien lu la doc en question et beaucoup d'autres. Merci pour la réponse très rapide. A bientôt sans doute. -- Cordialement, Jean Millet (JeandePeyrat) http://www.freeguppy.org http://asso.freeguppy.org --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5463671c.3030...@free.fr
Quelle structure et méthode adopter pour mon paquet guppy5.deb ?
Bonjour à tous, Ci-dessous les structures de mes deux premiers essais. Pour le premier paquet guppy_html.deb pas de problème de compilation, le paquet est bien créé et s'installe bien dans /usr/var/www/html/ et dossier guppy (c'est également OK dans var/www/ ou autre en modifiant l’arborescence. Alors tout est pour le mieux ? Ben non car Lintian n'est pas du tout content et me dit surtout qu'un paquet ne doit pas s'installer dans /var/www/ … sauf exception à décrire… mais là je n'ai pas tout compris. Quoi qu'il en soit ce ne serait pas compatible avec tous les hébergeurs qui ont le DocumentRoot tour à tour dans /www/, html, public_html, httpdocs ou autre sinon il faudrait autant de .deb que de serveurs :-(( guppy_html.deb . ├── DEBIAN │ ├── changelog │ ├── compat │ ├── control │ ├── copyright │ ├── docs │ └── rules ├ └── var └── www └── html └── guppy ├── admin │ ├── administrateur.php │ ├── admin.php │ ├── adminredac.php │ ├── admjqstyle.css │ ├── admstyle.css │ ├── editors et la suite des directories et fichiers du cms guppy. version /usr/share Donc pour faire plaisir à Lintian et sur « ses conseils », dans la mesure ou j'ai compris, ce qui est peu probable, je place « guppy » dans /usr/share/ et là Lintian est très content :-)) et guppy s'installe bien dans /usr/share/ sauf que placer un CMS sur le web dans /usr/share/ ce n'est pas terrible :-(( J'ai pensé à utiliser postinst pour lancer un script qui ferait un mv vers /var/www/ ou autre mais il faudrait un choix interactif avec l'utilisateur lors de l’installation du paquet. Çà ne me paraît pas très propre et comment faire ? L'idéal serait que le paquet s'installe dans le dossier courant ou il faudrait simplement se placer avant de lancer apt-get install guppy ! Désolé d'avoir été aussi long mais il me fallait planter le décor. Si vous avez des idées sur la méthode à utiliser et quelques explications qui vont avec ce sera avec plaisir. . ├── DEBIAN │ ├── changelog │ ├── compat │ ├── control │ ├── copyright │ ├── docs │ └── rules ├── etc ├── tree_usr_share.txt └── usr └── share ├── doc │ └── guppy-5.0.x │ ├── changelog.gz │ └── copyright └── guppy ├── admin │ ├── administrateur.php │ ├── admin.php │ ├── adminredac.php Et la suite des directories et fichiers du cms guppy Merci d'avance pour vos réponses. -- Cordialement, Jean Millet (JeandePeyrat) http://www.freeguppy.org http://asso.freeguppy.org --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com
Re: Quelle structure et méthode adopter pour mon paquet guppy5.deb ?
Vous l'installiez sur /usr/share , puis vous faites un shell script qui sera installer sur /usr/bin , qui fera le déplacement et la configuration selon le serveur de l'utilisateur On Thursday, November 13, 2014, Jean Millet jean.mil...@free.fr wrote: Bonjour à tous, Ci-dessous les structures de mes deux premiers essais. Pour le premier paquet guppy_html.deb pas de problème de compilation, le paquet est bien créé et s'installe bien dans /usr/var/www/html/ et dossier guppy (c'est également OK dans var/www/ ou autre en modifiant l’arborescence. Alors tout est pour le mieux ? Ben non car Lintian n'est pas du tout content et me dit surtout qu'un paquet ne doit pas s'installer dans /var/www/ … sauf exception à décrire… mais là je n'ai pas tout compris. Quoi qu'il en soit ce ne serait pas compatible avec tous les hébergeurs qui ont le DocumentRoot tour à tour dans /www/, html, public_html, httpdocs ou autre sinon il faudrait autant de .deb que de serveurs :-(( guppy_html.deb . ├── DEBIAN │ ├── changelog │ ├── compat │ ├── control │ ├── copyright │ ├── docs │ └── rules ├ └── var └── www └── html └── guppy ├── admin │ ├── administrateur.php │ ├── admin.php │ ├── adminredac.php │ ├── admjqstyle.css │ ├── admstyle.css │ ├── editors et la suite des directories et fichiers du cms guppy. version /usr/share Donc pour faire plaisir à Lintian et sur « ses conseils », dans la mesure ou j'ai compris, ce qui est peu probable, je place « guppy » dans /usr/share/ et là Lintian est très content :-)) et guppy s'installe bien dans /usr/share/ sauf que placer un CMS sur le web dans /usr/share/ ce n'est pas terrible :-(( J'ai pensé à utiliser postinst pour lancer un script qui ferait un mv vers /var/www/ ou autre mais il faudrait un choix interactif avec l'utilisateur lors de l’installation du paquet. Çà ne me paraît pas très propre et comment faire ? L'idéal serait que le paquet s'installe dans le dossier courant ou il faudrait simplement se placer avant de lancer apt-get install guppy ! Désolé d'avoir été aussi long mais il me fallait planter le décor. Si vous avez des idées sur la méthode à utiliser et quelques explications qui vont avec ce sera avec plaisir. . ├── DEBIAN │ ├── changelog │ ├── compat │ ├── control │ ├── copyright │ ├── docs │ └── rules ├── etc ├── tree_usr_share.txt └── usr └── share ├── doc │ └── guppy-5.0.x │ ├── changelog.gz │ └── copyright └── guppy ├── admin │ ├── administrateur.php │ ├── admin.php │ ├── adminredac.php Et la suite des directories et fichiers du cms guppy Merci d'avance pour vos réponses. -- Cordialement, Jean Millet (JeandePeyrat)http://www.freeguppy.orghttp://asso.freeguppy.org -- http://www.avast.com/ Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection Antivirus avast! http://www.avast.com/ est active.
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, Nov 12, 2014 at 01:13:39AM +0100, Matthias Urlichs wrote: Please discourage the use of pristine-tar. The format is fragile and can suffer from bit rot. I am not personally interested in pristine-tar, but I don't think this is the right place to take a stance on its use. -- 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/20141112080255.ga22...@chew.redmars.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, Nov 12, 2014 at 03:38:59PM +0800, Paul Wise wrote: Personally I wouldn't use anything other than debian-only repos, at least for those where I have a choice. I also actively avoid contributing to packages that don't use such repos. And I'm the exact opposite. -- 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/20141112080511.gb22...@chew.redmars.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Jonathan == Jonathan Dowland j...@debian.org writes: Jonathan On Wed, Nov 12, 2014 at 03:38:59PM +0800, Paul Wise wrote: Personally I wouldn't use anything other than debian-only repos, at least for those where I have a choice. I also actively avoid contributing to packages that don't use such repos. Jonathan And I'm the exact opposite. Which is fine - both layouts have their pros and cons and use cases. There are some cases where I prefer upstream+debian in the same repo, too. Hence, providing both as options, without a clear recommendation of one of them, in DEP-14 would benefit us all, in my opinion. -- |8] signature.asc Description: PGP signature
Re: so long and thanks for all the fish
On Friday 07 November 2014 17:04:10 Joey Hess wrote: It's become abundantly clear that this is no longer the project I originally joined in 1996. We've made some good things, and I wish everyone well, but I'm out. I'm very sorry to read this. We'll miss you. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.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/2367121.aOZJeVcjqt@ylum
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi, On Tue, 11 Nov 2014, Iustin Pop wrote: Packaging branches and tags === Packaging branches should be named according to the codename of the target distribution. In the case of Debian, that means for example `debian/sid`, `debian/jessie`, `debian/experimental`, `debian/wheezy`, `debian/wheezy-backports`, etc. We specifically avoid suite names because those tend to evolve over time (stable becomes oldstable and so on). The Git repository listed in debian/control's `Vcs-Git` field should usually have its HEAD point to the branch corresponding to the distribution where new upstream versions are usually sent. For Debian, it will usually be `debian/sid` (or sometimes `debian/experimental`). I find this paragraph confusing. With gbp, this is where new Debian developments are made, and new upstream versions are sent to upstream/xxx. Or do you mean something else here? Is it clearer if I rewrite it this way ? « The Git repository listed in debian/control's `Vcs-Git` field should usually have its HEAD point to the branch where new upstream versions are being packaged. For Debian, it will usually be `debian/sid` (or sometimes `debian/experimental`) » Interesting. Assuming a normal Debian package that has just a few backports (as opposed to every sid release being backported), and which imports only upstream tarballs/snapshots (not the whole history), I expect that a high proportion of the commits would happen on this branch. In which case, why not make it 'master', without debian/ ? Is it (only) in order to cleanly support multiple vendors? Henrique answered to that. The non-prefixed namespace is dedicated to upstream development. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112082156.ga27...@home.ouaza.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi, Jonathan Dowland: On Wed, Nov 12, 2014 at 01:13:39AM +0100, Matthias Urlichs wrote: Please discourage the use of pristine-tar. The format is fragile and can suffer from bit rot. I am not personally interested in pristine-tar, but I don't think this is the right place to take a stance on its use. Then we should either remove the paragraph entirely, or at least mention the danger of bit rot and that it's unwise to rely on being able to recover the tarfile (long term). Jonathan Dowland: On Wed, Nov 12, 2014 at 03:38:59PM +0800, Paul Wise wrote: Personally I wouldn't use anything other than debian-only repos, at least for those where I have a choice. I also actively avoid contributing to packages that don't use such repos. And I'm the exact opposite. FWIW: Me too. Debian-only is, to me, quite annoying, and a remnant of a workflow that was once a necessity (with CVS/SVN). Not so with git. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, 12 Nov 2014, Matthias Urlichs wrote: If the package maintainers use the pristine-tar tool to efficiently store a byte-for-byte copy of the upstream tarballs, this should be done in the `pristine-tar` branch. Please discourage the use of pristine-tar. The format is fragile and can suffer from bit rot. The DEP will neither encourage and discourage its use. It only mentions that if a maintainer is using it, it should store pristine-tar data in the pristine-tar branch. FWIW, I do use pristine-tar and I find it really useful even though I know that some day my old pristine-tar data will be unusable. It's not a big deal since we have snapshot.debian.org and archive.debian.org for those cases. The point of the pristine-tar data is to help contributors who are cooperating right now, it's not to make sure we can recreate the same old .orig.tar.gz in 10 years from now (even though it would have been nice if it achieved this). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112082833.gb27...@home.ouaza.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Paul Wise p...@debian.org writes: On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote: I'd like to note that there are very good reasons for a debian-only, overlay-style packaging repository too. This section should, in my opinion, at least acknowledge that, and briefly mention it as an option. I find it a bit sad that it was outright discouraged. Personally I wouldn't use anything other than debian-only repos, at least for those where I have a choice. I also actively avoid contributing to packages that don't use such repos. Agreed. The debian-packaging-in-separate-repo approach is fully supported by our build tools, and should be at least an equal citizen in this standard, IMO. -- \“The problem with television is that the people must sit and | `\keep their eyes glued on a screen: the average American family | _o__) hasn't time for it.” —_The New York Times_, 1939 | Ben Finney -- 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/85h9y46cgg@benfinney.id.au
Bug#769224: ITP: noggit -- Fast streaming JSON parser for Java
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg ebo...@apache.org * Package name: noggit Version : 0.6 Upstream Author : Yonik Seeley ysee...@gmail.com * URL : http://github.com/yonik/noggit * License : Apache-2.0 Programming Lang: Java Description : Fast streaming JSON parser for Java Noggit is the world's fastest streaming JSON parser for Java. Features: * Fast! Measured as the fastest JSON parser on char[], String input. * Streaming API (StAX/pull-parser like) for both easy and efficient parsing * Conforms to the JSON standard: http://www.ietf.org/rfc/rfc4627.txt * Memory efficiency * incremental parsing (Reader-based) in order to handle huge messages * a single byte of state needed per nested object or array * does not read large objects (including primitives) completely into memory unless asked * can eliminate most copying, allowing the user to provide the output buffer for values * can handle primitives of any size (does not attempt to parse numerics into a certain language primitives unless asked) * Simple serialization of objects (List, Map, etc) * Optional creation of objects (List, Map, etc) when parsing. This library is a dependency of Gerrit. -- 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/54631dca.10...@apache.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tue, 11 Nov 2014, Henrique de Moraes Holschuh wrote: In fact, I was quite non-amused by the initial versions of this idea, but reading this latest version, I must say I *like* it. Well done! I am especially happy about the way it respects the usual git usage conventions, this will ease its adoption a lot. Thank you! I'm pleased to see that I managed to draft something reasonable. It does fail to mention security, and stable-proposed branches. We can just leave those to maintainer's discretion, of course. I believe that those are not really needed in most cases. You rarely have conflicting updates for -security and -proposed-updates at the same time. But of course we can say something along this: --- a/web/deps/dep14.mdwn +++ b/web/deps/dep14.mdwn @@ -73,6 +73,14 @@ target distribution. In the case of Debian, that means for example suite names because those tend to evolve over time (stable becomes oldstable and so on). +Security updates and stable updates are expected to be handled on +the branch of the associated distribution. For example, in the case of +Debian, uploads to `wheezy-security` or `wheezy-proposed-updates` +are prepared on the `debian/wheezy` branch. Shall there be a need to +manage different versions of the packages in both repositories, then +the branches `debian/wheezy-security` and `debian/wheezy-updates` +can be used. + The Git repository listed in debian/control's `Vcs-Git` field should usually have its HEAD point to the branch corresponding to the distribution where new upstream versions are usually sent. For Debian, How does that sound ? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112084624.gc27...@home.ouaza.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tue, 11 Nov 2014, Barry Warsaw wrote: One question: when this gets adopted, will individual maintainers or teams have to know which of the git packaging helpers a particular repository is using? IOW, what happens if I were to use gbp-pq on a package that someone else had used git-dpm on? Do we need some kind of convention to detect which helper is being used? I wouldn't want to restrict choice by defining a standard Debian-wide (but it's okay within the context of a team). I just want someone who walks up to a git repo to at least easily know which tools to use. I don't know. My long term hope is that in this process we will get to a situation where: - either the tools are sufficiently interoperable that we don't have to care about this - or one of tools emerges as standard supporting all the important workflows that people are using Each vendor uses its own namespace for its packaging related Git branches and tags: `debian/*` for Debian, `ubuntu/*` for Ubuntu, and so on. My question is whether the vendor namespaces are overkill for the majority of packages, where there probably will be just one vendor (i.e. Debian). Should DEP 14 allow for a simplified layout such as master, pristine-tar, upstream when there is no other vendor involved? Allowing for master as an alternative to debian/sid or debian/master might simplify the common case. I am rather opposed to this because it because it doesn't separate clearly the namespaces for the upstream development and the namespace for the Debian packaging. Even when upstream doesn't use Git, you never know whether this won't change at some point and while it's perfectly possible to rename branches when needed, this operation is not something that is tracked in any way in the git clones that all users might have (it's really a branch deletion + a new branch) so local configuration about which branch is tracked is now broken and you have no safeguard against non-fast-forward change at the time you rename the branches, and so on. I really believe that always using the prefixed namespace is the correct course of action. for the current Ubuntu development series. If I needed to support older releases in either distro, then debian/wheezy or ubuntu/utopic would be good branches to use. (Or IOW, what's the equivalent of debian/sid for Ubuntu?) I was wondering that as well. For Ubuntu, it probably makes sense to use ubuntu/master because the latest development release regularly changes and it's not a good idea to alway update the branch. So that is one reason more to allow usage of `vendor/master` as a packaging branch. If the Git workflow in use imports the upstream sources from released tarballs, this should be done under the upstream namespace. By default, the latest upstream version should be imported in the `upstream/latest` branch and when packages for multiple upstream versions are maintained concurrently, one should create as many upstream branches as required. Similarly, is 'upstream' okay for the upstream branch? It's a little simpler than upstream/latest, especially if you don't anticipate importing an other upstream branches. And it's also compatible with the current gbp practice. I'm not set of upstream/latest but given what I said above about renaming branches, I still believe that it's best to have a default name that does not need to be renamed when you want to add more upstream branches. Or maybe we recommend upstream/latest by default but allow upstream alone in the case when there are no other upstream branches tracked ? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112090254.gd27...@home.ouaza.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
[ Ccing the maintainers of git packaging helper tools ] Hi Scott, using your mail as an opportunity to explicity notify the respective package maintainers of this ongoing DEP. Guido, Bernhard, Ron, if you are not reading debian-devel, I would like to bring your attention to a discussion that I recently started about trying to standardize the layout of Git packaging repositories: https://lists.debian.org/debian-devel/2014/11/msg00444.html https://lists.debian.org/debian-devel/2014/11/threads.html#00444 This mail is part of this discussion. On Tue, 11 Nov 2014, Scott Kitterman wrote: Who's going to do patches to existing tools (e.g. git-dpm is the one I use and care about) so they comply with this and similarly scripts to convert existing git repos to match this recommendation? It doesn't make much sense to have an standard unless there's also a plan to implement using it. My own idea was to involve the respective package maintainers in this discussion (now done with this mail) and once we have an agreed-upon DEP then to suggest a sprint (IRL or not) to update the respective tools. I would be willing to participate to such a sprint and do my share of the work (although I'm primarily using git-buildpackage and would likely start with this helper tool). Guido, Bernhard, Ron, would you be interested to attend such a sprint? Are there other persons who would be interested to help us implement the required changes? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112091527.ge27...@home.ouaza.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, 12 Nov 2014, Mathieu Parent wrote: A paragraph about repacked upstream is needed. A lot of packages are currently stripped for minified JS, non-free additions, included RFCs, ... What would the upstream/1.x branch be then? Maybe add an upstream/1.x+debian branch? Yeah, that was another open question I had. There's no clear conventions about how to handle the removal of files from upstream releases. It looks like some people are using uscan/mk-origtaz to drop non-DFSG files from the downloaded .tar.gz (via Files-Excluded in debian/copyright) and then the upstream branch is directly the DFSG clean version. But other persons are using dfsg branches where they handle the removal of the problematic files and they merge those branches. So their process is: - update the dfsg branch by merging the upstream release - merge the dfsg branch in the debian packaging branch There are probably other workflows. I'm not sure what's best. But given that the whole upstream namespaces is a packaging artifact, it would seem natural that those branches contain the upstream sources as we define them, i.e. with the non-free files already stripped. I would thus limit ourselves to stating that and not having any specific recommendations on how people should get rid of the files. Does that sound reasonable? Also, the vendor/* branches heads should be at a descendent commit of the corresponding upstream branch, diffing only by the debian dir. Does that need to be explicitly stated? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112092823.gf27...@home.ouaza.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi Gergely, On Wed, 12 Nov 2014, Gergely Nagy wrote: Raphael When releasing a Debian package, the packager should create and push Raphael a signed tag named `vendor/version`. For example, a Debian maintainer Raphael releasing a package with version 2:1.2~rc1-1 would create a tag named Raphael `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with Raphael version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should Raphael point to the exact commit that was used to build the corresponding upload. Mmm... I disagree here too. I think following upstream tagging conventions would be the way to go here. So if upstream uses `package-version` tags, then debian releases would be tagged like `debian/foo-2%1.2_rc1-1`, if upstream is `foo-1.2rc1`. And if upstream uses v1.2.3 we should use debian/v1.2.3-1? Do you know many upstreams using foo-1.2.3 as tags? I must say that I don't see the value that this brings. It might be aestethically more pleasant when browsing the list of tags but for everything else, it's just more painful. We lose the ability to easily identify the commit of a given Debian release (instead of a simple lookup operation, you have to scan all existing tags, and even then if you have no clear mapping with the Debian version, you can't be sure that you will find the correct tag). Thus I don't think that this is a good idea. Raphael It is also important so that contributors are able to use the tool of their Raphael choice to update the debian/patches quilt series: multiple helper tools Raphael need the upstream sources in Git to manage this patch series as a Git Raphael branch. I'd like to note that there are very good reasons for a debian-only, overlay-style packaging repository too. This section should, in my opinion, at least acknowledge that, and briefly mention it as an option. I find it a bit sad that it was outright discouraged. I'm open to that, but IMO the only case where there are very good reasons are the case where the upstream data is really huge and not easily patchable anyway (i.e. the case of openarena-data that Simon Mc Vittie described in https://lists.debian.org/debian-devel/2014/08/msg00582.html). Are there other reasons that you consider good enough to impose the above penalties on other possible contributors (i.e. making it impossible to use gbp pq or similar tools to update debian/patches)? For the record, I used to hate that style, and was an advocate for storing upstream sources in the repo too. Then I started maintaining ~6 packaging branches: three upstream versions, two packaging branch variants of each. The overlay style proved to be far superior in this case. Can you elaborate on how it was superior? In short, I'd suggest having the DEP document both layouts, and recommend using one of them, while also recommending to document it in debian/README.source. I have put this for now: @@ -195,6 +203,12 @@ choice to update the debian/patches quilt series: multiple helper tools need the upstream sources in Git to manage this patch series as a Git branch. +When you have good reasons to only store the `debian` packaging directory +(for example when the uptream sources are really huge and contains mostly +non-patchable data), you can do so but you should then document +this in `debian/README.source` along with some explanations of the tool +to use to build the package. + Managing debian/changelog - Does that sound better? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112094730.gg27...@home.ouaza.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, Nov 12, 2014 at 10:02 AM, Raphael Hertzog hert...@debian.org wrote: for the current Ubuntu development series. If I needed to support older releases in either distro, then debian/wheezy or ubuntu/utopic would be good branches to use. (Or IOW, what's the equivalent of debian/sid for Ubuntu?) I was wondering that as well. For Ubuntu, it probably makes sense to use ubuntu/master because the latest development release regularly changes and it's not a good idea to alway update the branch. Ubuntu has a fake devel suite (actually it's just a symlink to the current development release, iirc: http://archive.ubuntu.com/ubuntu/dists/devel/Release ) Maybe they can usa ubuntu/devel but also ubuntu/master sounds reasonable. -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo -- 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/CAHKYmetF8uUHJ5d5+PDecmUzW0XStiMx-C=ywfwsepnyr-p...@mail.gmail.com
veto?
It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? -- 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/54633095.9060...@pocock.pro
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
2014-11-12 10:28 GMT+01:00 Raphael Hertzog hert...@debian.org: On Wed, 12 Nov 2014, Mathieu Parent wrote: A paragraph about repacked upstream is needed. A lot of packages are currently stripped for minified JS, non-free additions, included RFCs, ... What would the upstream/1.x branch be then? Maybe add an upstream/1.x+debian branch? Yeah, that was another open question I had. There's no clear conventions about how to handle the removal of files from upstream releases. It looks like some people are using uscan/mk-origtaz to drop non-DFSG files from the downloaded .tar.gz (via Files-Excluded in debian/copyright) and then the upstream branch is directly the DFSG clean version. But other persons are using dfsg branches where they handle the removal of the problematic files and they merge those branches. So their process is: - update the dfsg branch by merging the upstream release - merge the dfsg branch in the debian packaging branch There are probably other workflows. I'm not sure what's best. But given that the whole upstream namespaces is a packaging artifact, it would seem natural that those branches contain the upstream sources as we define them, i.e. with the non-free files already stripped. OK. Makes sense. The unstripped upstream can then live in an non-namespaced branch if needed (this is not my usual workflow but should be possible). Maybe a short note would be good then? (but I don't know how to write it). I would thus limit ourselves to stating that and not having any specific recommendations on how people should get rid of the files. Does that sound reasonable? Yes. Also, the vendor/* branches heads should be at a descendent commit of the corresponding upstream branch, diffing only by the debian dir. Does that need to be explicitly stated? The What to store in the Git repository first paragraph is enough. Regards -- Mathieu -- 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/cafx5sbzqyj_73b9nufvxegvwnbz+xtn-dnevwyzb8fzapxg...@mail.gmail.com
Re: inconsistent versions of M-A: same packages
On Sat, 8 Nov 2014, Stuart Prescott wrote: UDD can help with this. A list of source packages that have M-A: same binary packages in jessie that have different versions in any two release architectures is at: Can we do this for the triplet (i386, amd64, x32) too, please? Yes, it’s not a release architecture, but still… I just scheduled a bunch of binNMUs for x32, anyway. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- 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.1411121131520.9...@tglase.lan.tarent.de
Re: Bad weather in testing?
On Fri, 7 Nov 2014, Ralf Treinen wrote: architecture-specific. The issue of architecture=all packages that are not installable on some architecture can IMHO not be solved with our current setup which makes architectures=all available on every architecture. This is a bug, I’ve seen this affect buildd dependency resolution, and anyway, if it’s not installable everywhere, why is it arch:all? bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die! -- 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.1411121134010.9...@tglase.lan.tarent.de
Re: veto?
On Wed, 12 Nov 2014 11:04:05 +0100 Daniel Pocock dan...@pocock.pro wrote: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? There are enough arguments already without that uncertainty. What does it mean if someone vetoes a GR? That just leads to anarchy. Decisions get made, some you agree with, some you don't. Some of the ones you disagree with can be accommodated and development moves on. If a binding decision is finally made, whether that be by a GR or a delegated team, there is no point allowing people to perpetuate the arguments long afterwards. There is enough scope for that already without making it formal. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp5WloE31Y0k.pgp Description: OpenPGP digital signature
Re: Bad weather in testing?
On Wed, Nov 12, 2014 at 6:34 PM, Thorsten Glaser wrote: This is a bug, I’ve seen this affect buildd dependency resolution, and anyway, if it’s not installable everywhere, why is it arch:all? I would guess that uninstallable arch:all things happens when they depend on non-portable things. For example pixbros/pixfrogger depend on fenix. -- 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/caktje6eue70ozrmhk9v5ohy84uuavdnw4ij9qrtfcyx279f...@mail.gmail.com
Re: veto?
* Daniel Pocock dan...@pocock.pro, 2014-11-12, 11:04: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? I hereby veto joeyh's decision to quit. -- Jakub Wilk -- 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/20141112105032.ga9...@jwilk.net
Re: veto?
On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock wrote: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? Can you elaborate which decisions and how many DDs could veto them? -- WBR, wRAR -- 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/20141112104327.ga16...@belkar.wrar.name
Re: veto?
On 12/11/14 11:43, Andrey Rahmatullin wrote: On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock wrote: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? Can you elaborate which decisions and how many DDs could veto them? I didn't want to be too specific, to give other people a chance to make suggestions However, one possibility is that anybody maintaining an essential package and anybody who is a DPL delegate would be able to veto. The implication is that somebody can still win a GR against the veto, but they do so knowing that they will have to find somebody else to maintain some essential packages. -- 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/54633fa7.1050...@pocock.pro
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi! On Wed, 2014-11-12 at 15:38:59 +0800, Paul Wise wrote: On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote: I'd like to note that there are very good reasons for a debian-only, overlay-style packaging repository too. This section should, in my opinion, at least acknowledge that, and briefly mention it as an option. I find it a bit sad that it was outright discouraged. Personally I wouldn't use anything other than debian-only repos, at least for those where I have a choice. I also actively avoid contributing to packages that don't use such repos. Exactly. In addition I also only tend to «git clone» native packages, for anything else I just simply «apt-get source» and can be pretty sure what I will get, because the alternatives are just annoying. As a maintainer and upstream, I also find crawling the packaging repos for many of the RPM based distros, Gentoo and BSDs port collections for example, actually way more pleasant and clear than many of the Debian packaging repos with packaging bits mixed with upstream code TBH, because they only have the build recipes and possibly patches, so I don't need to know their tools or path layouts to be able to find the packaging bits, because they are just obviously there, in front of you, alone. Not to mention the “unholy” practice of having to store autogenerated stuff shipped only in release tarballs in a git repo! :) I also fantasize sometimes of a day where the whole distribution would be stored on VCSs (per package) with a debian-only layout, so that I could have a local copy for the whole archive, taking only a couple of GiB at most, instead of the monstrosity of a complete exploded sources archive (according to http://sources.debian.net/stats/, that's currently 205 GiB, w/o including git history, which could easily double that size); and don't tell me space is cheap, because that does not take into account the downloading, nor the huge amount of wasted space if you only want the packaging bits. Even though it might be more convenient for the maintainer, in general I find the mixed up repos to be a disservice to the rest of the world. Regards, Guillem -- 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/2014111212.ga12...@gaara.hadrons.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Le 11/11/2014 22:26, Raphael Hertzog a écrit : Hello, following the initial discussion we had in August (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have written a first draft of the Debian Enhancement Proposal that I suggested. It's now online at http://dep.debian.net/deps/dep14 and also attached below so that you can easily reply and comment. I have left one question where I have had conflicting feedback and I'm not sure what's best. Thus I will welcome a larger set of opinions on this specific question (search for QUESTION in the text). Are there things that are missing? Hi, I see nothing about whether the debian branch should contained the unpacked or the unpacked *and* patched sources, and whether to ship the .pc directory. I personally ship the unpatched sources and don't ship the .pc directory. Kind regards, Thibaut. -- 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/5463418a.6060...@debian.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tue, 11 Nov 2014, Raphael Hertzog wrote: QUESTION: some people have argued to use debian/master as the latest packaging targets sometimes sid and sometimes experimental. Should we standardize on this? Or should we explicitly allow this as an alternative? Given the feedback received, and the case of derivatives that don't have a stable name for their development releases, I propose to update the Packaging branches and tags section with the content below. Does that sound like an improvement? Packaging branches and tags === In general, packaging branches should be named according to the codename of the target distribution. We differentiate however the case of development releases from other releases. For development releases Packages uploaded to the current development release should be prepared in a `vendor/master` branch. However, when multiple development releases are regularly used (for example `unstable` and `experimental` in Debian), it is also accepted to name the branches according to the codename or the suite name of the target distribution (aka `debian/sid` or `debian/unstable`, and `debian/experimental`). Those branches can be short-lived (i.e. they exist only until they are merged into `vendor/master` or until the version in the associated repository is replaced by the version in `vendor/master`) or they can be permanent (in which case `vendor/master` should not exist). NOTE: The Git repository listed in debian/control's `Vcs-Git` field should have its HEAD point to the branch where new upstream versions are being packaged (that is one of the branches associated to a development release). The helper tools that do create those repositories should use a command like `git symbolic-ref HEAD refs/heads/debian/master` to update HEAD to point to the desired branch. For stable releases --- When a package targets any release that is not one of the usual development releases (i.e. stable releases or a frozen development release), it should be prepared in a branch named with the codename of the target distribution. In the case of Debian, that means for example `debian/jessie`, `debian/wheezy`, `debian/wheezy-backports`, etc. We specifically avoid suite names because those tend to evolve over time (stable becomes oldstable and so on). Security updates and stable updates are expected to be handled on the branch of the associated distribution. For example, in the case of Debian, uploads to `wheezy-security` or `wheezy-proposed-updates` are prepared on the `debian/wheezy` branch. Shall there be a need to manage different versions of the packages in both repositories, then the branches `debian/wheezy-security` and `debian/wheezy-updates` can be used. Tagging package releases When releasing a Debian package, the packager should create and push a signed tag named `vendor/version`. For example, a Debian maintainer releasing a package with version 2:1.2~rc1-1 would create a tag named `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should point to the exact commit that was used to build the corresponding upload. -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112112021.gk27...@home.ouaza.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi, On Wed, 12 Nov 2014, Thibaut Paumard wrote: I see nothing about whether the debian branch should contained the unpacked or the unpacked *and* patched sources, and whether to ship the .pc directory. I personally ship the unpatched sources and don't ship the .pc directory. That's a volunteer choice at this stage. We have different workflows that are worth supporting and they differ at this level of details. The only thing that the DEP recommends is that the cloned tree be usable with `dpkg-buildpackage -b -us -uc`. I think it's enough at this point. But if we can come up with a consensus that we should say something about this, I'm happy to update the document. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112112537.gl27...@home.ouaza.com
Re: veto?
On 12/11/14 10:04, Daniel Pocock wrote: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? I'm not sure a veto would help matters when you get disagreement on topics that involve a lot of emotion. If a vote went through with a majority wanting option A and then a small group veto'd it, you might avoid the small group resigning, but what impact would that have on the majority who've had their views overturned? Short term, perhaps it would avoid resignations but longer term you may find it's those who had their votes veto'd that resign. Regards, Gary signature.asc Description: OpenPGP digital signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi Raphael, On Wed, Nov 12, 2014 at 10:15:27AM +0100, Raphael Hertzog wrote: Hi Scott, using your mail as an opportunity to explicity notify the respective package maintainers of this ongoing DEP. Guido, Bernhard, Ron, if you are not reading debian-devel, I would like to bring your attention to a discussion that I recently started about trying to standardize the layout of Git packaging repositories: https://lists.debian.org/debian-devel/2014/11/msg00444.html https://lists.debian.org/debian-devel/2014/11/threads.html#00444 This mail is part of this discussion. Thanks for the heads up on this, I wasn't aware of this before now. Please keep me in the CC for anything people would like me to see and/or reply to. On Tue, 11 Nov 2014, Scott Kitterman wrote: Who's going to do patches to existing tools (e.g. git-dpm is the one I use and care about) so they comply with this and similarly scripts to convert existing git repos to match this recommendation? It doesn't make much sense to have an standard unless there's also a plan to implement using it. My own idea was to involve the respective package maintainers in this discussion (now done with this mail) and once we have an agreed-upon DEP then to suggest a sprint (IRL or not) to update the respective tools. So I've got a bunch of reading to do to fully catch up on everything you've proposed here so far, but after a quick first pass, here's a few first impression comments: I think you probably need to be careful of overspecifying this. One of the beautiful things about git is that if you understand how the DAG works, it very easily lends itself to creating different ways of working that are particularly suited to the needs of a particular project. So while there are some rough guidelines as to some best practices for certain situations, it invariably works best when the workflow is shaped to suit the project and its developers, not when the project and the developers are rigidly jammed into a framework they need to contort themselves into. Likewise, in the same When in Rome vein as submitting patches upstream, exactly how a repository that is branched off the upstream one will look, depends at least in part on how upstream has chosen to work, and we definitely can't start telling them there are now rules for how they need to manage their repo. The design of gitpkg was based very much on this simple reality. Rather than duplicating how cvs-buildpackage worked, or how svn-bp evolved from it, gitpkg has a very simple rule: - It doesn't care what your repository looks like or how you choose to work in it, or what you name your tags and branches. It's designed to be able to work with essentially any repository that you find anywhere, without requiring you to first mash it into some particular form, or put tool specific files into it. Provided you can give it a treeish that contains the debian patched source you want to export, and (optionally) a treeish that contains the orig source, it can always make you a source package of that. The normal workflow is simply: work in git exactly how you normally would, whether you're making upstream changes or debian patches. Export a source package with `gitpkg $debtag $upstreamtag`. That in a nutshell is it. All of it. There aren't even any command line options for you to forget to type, or to screw up in a way that would make a different source package to the last time you called it. There are hooks you can use if you want p-t tarballs, or quilt patches, or to automatically build the package once it's exported (with cowpoke or dpkg-bp etc.), but they are all optional extras that each local user running gitpkg can choose for themselves, if they want them. The ability to export a valid source package does not depend on knowing some secret incantation or configuration the repo was made to depend on. All you need to know is the treeish you want to export. This means you can use it to export any version of a source package from a repo that existed long before you'd ever heard of gitpkg. Without needing to go back and rewrite or patch its history. You can use it to export packages from a repo where someone used some other tool previously. You can use it to branch your packaging off any upstream repo no matter how it has been used or arranged. You can use it to export packages that have been imported to git from snapshot.d.o to build a full history from the pre-git epoch (with git-debimport or any other tool you choose to do that with). The good news from all that though, is that it would seem unlikely that gitpkg itself would need any changes to be able to cope with any repo design you could come up with that wasn't completely insane :) The bad news perhaps, is I'm less convinced about how keen people already using gitpkg will be to arbitrarily restructure their entire existing repos to follow this. At least not without some much clearer rationale about what
Re: Beersigning in Zürich/SH/Winti? Meeting other local Debianistas? Bugfixing?
Thanks for all the nice info Paul! *t Am 12.11.2014 um 06:59 schrieb Paul Wise: On Wed, Nov 12, 2014 at 10:16 AM, Tomas Pospisek wrote: would any of you come and sign my key when in Zürich/SH/Winti? In case folks from these places aren't reading this list, some possibilities: https://db.debian.org/search.cgi?country=chdosearch=Search https://wiki.debian.org/Keysigning/Offers#CH https://wiki.debian.org/LocalGroups#Switzerland http://debian.ch/ This info brought to you by DebianLocations: https://wiki.debian.org/DebianLocations -- 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/54634e30.7030...@sourcepole.ch
Re: veto?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Please no. We need less and not more layers of governance/'political' complexity in project. Lets stop acting like government and more like community. Cheers, zlatan On 12 November 2014 11:04:05 CET, Daniel Pocock dan...@pocock.pro wrote: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? -- 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/54633095.9060...@pocock.pro - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- Version: APG v1.0.9 iQJSBAEBCAA8BQJUY06jNRxabGF0YW4gVG9kb3JpYyAoRGViaWFuZXIpIDx6bGF0 YW4udG9kb3JpY0BnbWFpbC5jb20+AAoJEC5cILs3kzv91W4P/ixE9NWYWVL6iw86 yvyUfngp8FHtOWUHFc/4LyhV2tyXbew6KYs+er1dpyFTr/5/8qBmuNTwJ26IIxov oyGR375mu1ocAV9gZyB8Ny4EnCAif5WQhhzgtufEG0jgLW0ds0htiH4ph5S+GKk6 q0trXhoyuirhzhk897qbeodW5Tb66+q591pO64fT0szWHE3XK8vScwsA6vdtG+yg 56Mn4KSSzWEivhgSZrYB76kc7bIcOK4uoFxg84UJ1GQ4SRZIcQGSQg98DkT1fWFH SQj/Qx7QuHjl3bkB3ZoNaZ/OUPqGU5kUp11XrXjZHFKvgIvUJjVWqRQh7GdVL/ap Emze2u+cELcXuQu3uJRbLyTImYM7jPrlGf7OXFWZeIbQU6HyNcfV6elAO3/3jSr7 Mo636sJsOsaKwpLcl9i/u/8WBGghwZWlWrcReoIr4aUULKds/SDaYP8npoAaSKv9 xpm8apkUuuOK9rfd6qx7KAnnkMwhApWWQE07qDau7s15DzG2wJyoZUNEapFXmtUf hdwRJq6n7eAmtVF53ENOQzB0UDpcBFEn7Fi9LxLhl0DuGqLo6GjPKAnQ/QcOcIlP IDyDVb95Mw5do2M4JLAe1dPbcB//m3WRwrtIhw0CZHkArgtty5wJ1Gf3fFkkhEd0 5vi4O6YOmZ+qGDw7JXtU8JfJ7kUb =PNj6 -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/43426b11-51ab-470d-9e18-c6d24d73d...@riseup.net
Re: veto?
On 12/11/14 13:12, zlatan wrote: Please no. We need less and not more layers of governance/'political' complexity in project. Lets stop acting like government and more like community. If a veto facility is created effectively, then it will deter people from complexity and force people back to looking for consensus If it is too easy to veto something though then I agree that would slow the project down -- 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/5463557d.2030...@pocock.pro
Re: veto?
Hi Daniel, aint the GR process exactly that, a way to say veto? Compare the current vote... cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#769283: ITP: python-oslo.middleware -- various WSGI middleware components for OpenStack
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-oslo.middleware Version : 0.1.0 Upstream Author : OpenStack Developers openstack-...@lists.openstack.org * URL : https://github.com/openstack/oslo.middleware * License : Apache-2.0 Programming Lang: Python Description : various WSGI middleware components for OpenStack The oslo.middleware library contains various functions and methods used by the OpenStack projects that are using the WSGI pipeline. -- 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/20141112124545.31176.90510.report...@buzig.gplhost.com
Re: veto?
On Wed, Nov 12, 2014 at 01:41:33PM +0100, Daniel Pocock wrote: Please no. We need less and not more layers of governance/'political' complexity in project. Lets stop acting like government and more like community. If a veto facility is created effectively, then it will deter people from complexity and force people back to looking for consensus Or we could fix the TC instead. -- WBR, wRAR -- 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/20141112124813.ga20...@belkar.wrar.name
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On 12/11/14 05:54, Mathieu Parent wrote: Also, the vendor/* branches heads should be at a descendent commit of the corresponding upstream branch, diffing only by the debian dir. This is only true for workflows similar to the one normally used with gbp-pq, in which desired patches are serialized into debian/patches/ by an out-of-band step (e.g. gbp-pq export, or quilt), and the upstream tree is unpatched. In particular, it is not true for git-dpm, dgit, or (as far as I can tell from Ron's description elsewhere in this thread) gitpkg; with those workflows, upstream files in the Debian branch *do* have their desired changes. Is it the intention of this DEP to mandate the gbp-pq-like repo structure, which basically forbids use of tools whose design does not match that? Or is the intention to set some conventions that can be true regardless of whether you are using a more gbp-pq-like or more git-dpm-like workflow, in the knowledge that that necessarily makes those conventions less strict? (I use gbp-pq for non-native packages myself, but trying out git-dpm is on my to-do list.) Concrete example: suppose you maintain an implementation of hello world, with a Debian patch changing hello.c to say puts (hello, Debian) instead of puts (hello, world). In the gbp-pq world, after git checkout debian/sid, hello.c would contain hello, world, but there would be a patch in debian/patches/ to change it from hello, world to hello, Debian. In git-dpm, after git checkout debian/sid, hello.c would contain hello, Debian, *and* there would be a patch in debian/patches/ to change it from hello, world to hello, Debian. AIUI, dgit also works best in this arrangement (or might even require it?) I'm not so sure about gitpkg - I *think* git checkout debian/sid in a gitpkg repository would result in hello.c containing hello, Debian, and no patches in debian/patches. But I could be wrong. (Ron?) S -- 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/54635b81.8020...@debian.org
Bug#769287: ITP: python-oslo.concurrency -- concurrency and locks for OpenStack projects
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-oslo.concurrency Version : 0.2.0 Upstream Author : OpenStack developers openstack-...@lists.openstack.org * URL : https://github.com/openstack/oslo.concurrency * License : Apache-2.0 Programming Lang: Python Description : concurrency and locks for OpenStack projects The oslo.concurrency library provides solutions for managing concurrency and locks within OpenStack projects. Note: I asked upstream to provide a better short and long description. In fact, I raised the topic upstream multiple times that these should be done better, and I hope to see improvements. When I get a better long desc upstream, I'll of course forward this to the Debian package. -- 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/20141112130851.32245.78228.report...@buzig.gplhost.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi Ron, On Wed, 12 Nov 2014, Ron wrote: I think you probably need to be careful of overspecifying this. Definitely. That's precisely why I don't want to dwelve (too much) into details of the various workflows and why I try to restrict the DEP at simple naming conventions for branches and tags that the various tools might need. The normal workflow is simply: work in git exactly how you normally would, whether you're making upstream changes or debian patches. Export a source package with `gitpkg $debtag $upstreamtag`. [...] The good news from all that though, is that it would seem unlikely that gitpkg itself would need any changes to be able to cope with any repo design you could come up with that wasn't completely insane :) Great, then it might be that gitpkg doesn't need any code update and that only its documentation should be updated to recommend using the default names when creating $debtag (and $upstreamtag in some cases). The bad news perhaps, is I'm less convinced about how keen people already using gitpkg will be to arbitrarily restructure their entire existing repos to follow this. At least not without some much clearer rationale about what compelling benefits they'd get in return for all that work and disruption and rewriting of history. I don't necessarily want everybody to update their current repositories (altought it would be nice). I want at least that when new contributors create a new git packaging repository, they have some good advice on how to structure their repository and the helper tools that they pick work nicely in that layout. Maybe I missed something somewhere (I should have been sound asleep a few hours ago, so that's quite possible), but I see lots of explanation of *what* you want to do, but not the killer reasoning about *why* you want to do it, or what concrete things you think will be gained from it. I think I explained my goals in the introduction of the DEP. Making it easier for Debian and its derivatives to build upon their respective Git repositories (possibly on a semi-automated basis). And making it easier to switch between various git packaging helper tools because they would share (by default) the same basic conventions. And making it easier to have the upstream git branches in the packaging repository too. More specifically, you have things like: Helper tools should usually rely on the output of dpkg-vendor --query vendor to find out the name of the current vendor. The retrieved string must be converted to lower case. This allows users to override the current vendor by setting DEB_VENDOR in their environment This seems like a git-bp specific hack to me, that has the assumption and trained habits of using that tool so deeply embedded in it that doesn't bother to explain why you would use this, when you would use this, or even what you would expect it to do. Given that the DEP recommends to create tags like vendor/version it seems like a good idea to explain how to retrieve vendor, no? It's not really related to git-bp (except for the fact that git-bp started this convention of prefixing the tags with debian/). gitpkg might not take the job of creating that tag, in which case that particular advice is obviously irrelevant and it's up the package maintainer to follow that naming convention when he manually creates the said tag. The section on Patch queue tags also seems to be written from the perspective of only knowing one tool and one workflow to use it. With the work that David Bremner did on git-debcherry, gitpkg can fully automatically extract a quilt patch series for a source package simply from completely normal commits to your repo, in a form that makes them trivial for upstream to cherry pick, and makes them automatically vanish when you merge the upstream release that includes them. Yes, the pach queue section is heavily inspired by gbp pq but again it's nothing mandatory. It says something like if the helper tools produces something that looks like a patch queue branch and if it wants to store it for later consumption, it should use that tag name. Fine if the other tools do not need anything like that. But who knows, maybe you will want to enhance git-debcherry to not only update debian/patches/ but also store the corresponding git branch for long-term storage. In which case, you will already have a recommended tag name for this purpose :-) I would be willing to participate to such a sprint and do my share of the work (although I'm primarily using git-buildpackage and would likely start with this helper tool). I am a bit curious about what patches you think you're going to need to make to make things comply with this plan? For gitpkg? I don't know. See above, maybe it's just documentation update. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To
Bug#769288: ITP: python-lda -- Topic modeling with latent Dirichlet allocation
Package: wnpp Severity: wishlist Owner: Allen Riddell abr+deb...@fastmail.fm * Package name: python-lda Version : 0.3.2 Upstream Author : lda developers lda-us...@googlegroups.com * URL : https://pypi.python.org/pypi/lda * License : MPL-2 Programming Lang: Python Description : Topic modeling with latent Dirichlet allocation lda implements latent Dirichlet allocation (LDA) using collapsed Gibbs sampling. LDA is the most familiar topic model. Topic models are unsupervised models useful for analyzing large collections of unlabeled text. lda has over 6,000 average monthly downloads on the Python package index. There are no other tested Python packages that implement LDA using Gibbs sampling (the algorithmic gold standard in this case). Mentor located, will maintain using gbp. Maintainer helps develop the software. -- 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/20141112130206.22242.59354.reportbug@cadlag
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, 12 Nov 2014, Mathieu Parent wrote: Maybe a short note would be good then? (but I don't know how to write it). I suggest this: --- a/web/deps/dep14.mdwn +++ b/web/deps/dep14.mdwn @@ -230,6 +230,17 @@ non-patchable data), you can do so but you should then document this in `debian/README.source` along with some explanations of the tool to use to build the package. +About repacked upstream sources +--- + +When the upstream sources needs to be repacked (for example to drop some +non-DFSG compliant files), then the branches and tags under the +`upstream/` prefix should actually contain the repacked sources. + +How the problematic files are pruned does not matter. What matters is that +what is stored in the `upstream/*` namespace are the sources that package +maintainers are effectively using. + Managing debian/changelog - Does this meet your expectation? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112132950.gn27...@home.ouaza.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi, Simon McVittie: Is it the intention of this DEP to mandate the gbp-pq-like repo structure, which basically forbids use of tools whose design does not match that? Or is the intention to set some conventions that can be true regardless of whether you are using a more gbp-pq-like or more git-dpm-like workflow, in the knowledge that that necessarily makes those conventions less strict? IMHO there are two basic approaches which are mostly at odds with each other. One: Treat Upstream's git repository as Source Code; if upstream doesn't have one, pretend that it does by importing their tarballs. Use git rm to remove nondistributable files and generated stuff (if Upstream even includes them, which if they use git they hopefully don't). Apply Debian changes, packaging or not, to a packaging branch. debian/patches is an auto-generated packaging artefact which I as a maintainer can basically ignore. Other distributions may share the common repository. Call this one integrated. Two: Treat Upstream tarballs as Source Code; if Upstream generates them from git-or-whatever, that's not our problem. Use a script to mangle the upstream tarball if it contains nondistributable files. Keep autogenerated Makefiles et al. around. Keep Debian packaging completely separate (in a different branch, or even in a diffferent archive) and use a quilt-ish workflow which treats the content of debian/patches as first-class citizens. There's not much point for other distros to share our packaging repository, so why plan for it? Let's call this one divided. This DEP describes an integrated workflow. This DEP does not say anything about any sort of divided workflow, other than to implicitly (un?intentionally?) discourage its use by omission. I personally happen to like an integrated workflow, to the point that the first thing I do when working on anything packaged in a divided way I'll run a script that unwraps debian/patches into my upstream archive clone's debian branch. Based on a couple of reactions here, some from people who dislike integrated workflow at least as intensely as I don't, IMHO there's not much common ground between the integrated- and the divided- workflow adherents. Thus, please don't try to shoehorn a divided workflow into this DEP. Write your own. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Removing duplication: Word lists of common words in languages
Ben Finney writes (Re: Removing duplication: Word lists of common words in
languages):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I had roughly this question in 2013, and found the answer. Here is
probably the best starting point:
http://www.chiark.greenend.org.uk/ucgi/~ijackson/git?p=evade-mail-usrlocal.git;a=blob;f=lemma.al-permission.mbox
Great! That asks for permission to redistribute the corpus under
free-software terms, and documents the response in the affirmative.
Vital for an eventual ‘debian/copyright’. Thank you.
In that exchange, you also mention you're planning to distribute the
data in a program. Is that online somewhere, and what's the URL?
Yes. (Depending on your definition of `distribute'.)
http://www.chiark.greenend.org.uk/ucgi/~ijackson/git?p=evade-mail-usrlocal.git
It's a userv-based tool for managing a domain containing
randomly-generated email aliases, on a shared shell account system. I
run it on chiark. I have cp the relevant section of chiark's
/info/mail.text below, along with the relevant bit of chiark's
/etc/exim4/exim4.conf.pl.
On chiark I run this directly out of a git working tree in /usr/local,
with symlinks from the relevant bits of /etc, /usr/local/bin, etc. If
anyone else thinks they might actually want this, I might consider
productising it a bit more.
Of course anyone else is welcome to do so, starting with the git tree
there. I see that I have forgotten to give it a copyright licence or
indeed any copyright notices.
Please treat it as AGPLv3+. (This is compatible with the GPLv2+
permission that I requested from Adam Kilgarriff. CCing Matthew
Vernon as the other copyrightholder.)
Ian.
3. Randomly-generated (weakly-psuedonymous) addresses
-
chiark users can have randomly-generated short email addresses
short-random-string@fyvzl.net, and randomly-generated readable
email addresses word.word.word@evade.org.uk.
This is managed using the slimy-rot13-mail and evade-mail
utilities. Run them without arguments for their usage messages.
The choose option generates ten random addresses and lets you say
which ones you would like to keep. Paste the ones you like back in,
to have them allocated to you. (Of course do NOT publish addresses
you have failed, or forgotten, to allocate!)
If you redirect an alias to yourself@chiark then your .forward file
will apply; your .forward file will see the address you redirect to,
not the @fyvzl or @evade address.
chiark's spamfilters treat fyvzl.net and evade.org.uk the same as
slimy.greenend.org.uk (see /info/spam.text). These addresses do not
go through SAUCE.
On privacy: these addresses are not trivial to map to a particular
user from outside chiark, although bounces (and any replies you send!)
are likely to reveal the linkage. It's not easy for another user to
get a complete list of your aliases, but chiark's mail logs are
available to everyone. And any chiark user can use exim -bt to
discover where a particular alias redirects.
These aliases are recorded in a database. It is not possible to ever
delete aliases because that would run the risk that another user would
subsequently be allocated an alias previously used by someone else.
The tools `evade-mail-pregen', `slimy-rot13-mail-pregen' and
`numbered-alias-sheet' can arrange to conveniently format pregenerated
aliases on sheets of paper for you to carry about and give to people
when offline. Run them without arguments to see the usage messages.
The usage message for numbered-alias-sheet has some examples.
evade_hard_dir:
.aliasdir(/etc/aliases-evade).
domains = @evade_domains
user = mail
evade_db_dir:
domains = @evade_domains
driver = redirect
allow_defer = true
data = .'${lookup sqlite {/var/lib/evade-mail/$domain.sqlite3 \
select redirect from addrs where \
localpart=\'${quote_sqlite:$local_part}\' \
and not redirect = \'\' \
and user not in disabled_users;}}'.
--
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/21603.25976.700221.615...@chiark.greenend.org.uk
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On 12/11/14 13:38, Matthias Urlichs wrote: IMHO there are two basic approaches which are mostly at odds with each other. I think there are at least three. Two: Treat Upstream tarballs as Source Code; if Upstream generates them from git-or-whatever, that's not our problem. Use a script to mangle the upstream tarball if it contains nondistributable files. Keep autogenerated Makefiles et al. around. Keep Debian packaging completely separate (in a different branch, or even in a diffferent archive) and use a quilt-ish workflow which treats the content of debian/patches as first-class citizens. There's not much point for other distros to share our packaging repository, so why plan for it? Let's call this one divided. Three: same as Two, but the Debian packaging branch is branched from the upstream branch, so it contains unpatched files *and* debian/ *and* debian/patches. (semi-integrated?) That's the gbp-pq workflow used in pkg-perl, pkg-systemd, pkg-utopia, pkg-telepathy, etc., and I think might also be the one Raphael advocates. S -- 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/54636731.3030...@debian.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Raphael Hertzog writes (RFC: DEP-14: Recommended layout for Git packaging repositories): following the initial discussion we had in August (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have written a first draft of the Debian Enhancement Proposal that I suggested. It's now online at http://dep.debian.net/deps/dep14 and also attached below so that you can easily reply and comment. Thanks. This is useful work. What to store in the Git repository --- This should be clearer that it applies only to the packaging branch: I would change the title to: What to store in the packaging branch in the Git repository --- It is recommended that the packaging branches contain both the upstream sources and the Debian packaging. Users who have cloned the repository should be able to run `dpkg-buildpackage -b -us -uc` without doing anything else (assuming they have the required build dependencies). It is also important so that contributors are able to use the tool of their choice to update the debian/patches quilt series: multiple helper tools need the upstream sources in Git to manage this patch series as a Git branch. I think you need to be more explicit about the implications for `3.0 (quilt)' format packages. Something like: If the git tree contains debian/format specifying `3.0 (quilt)', the git tree must also contain debian/patches/series and all the patch files contained within it. Furthermore, the tree should be in the `patches applied' state. (This means that every change to upstream files is represented twice: once in the contents of that very file in the git tree, and once as a hunk in one of the debian/patches. These two representations must be in step.) And you should add: The packaging branch should not contain a `.pc' directory. Managing debian/changelog - ... Helper tools should however configure the Git repository so that merges of the `debian/changelog` file are handled by `dpkg-mergechangelogs` as this will make it much easier to merge between different packaging branches. I didn't even know that git-mergechangelog existed, although I knew it was necessary... Ian. -- 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/21603.26522.748603.104...@chiark.greenend.org.uk
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Barry Warsaw writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): On Nov 11, 2014, at 10:26 PM, Raphael Hertzog wrote: Vendor namespaces - Each vendor uses its own namespace for its packaging related Git branches and tags: `debian/*` for Debian, `ubuntu/*` for Ubuntu, and so on. My question is whether the vendor namespaces are overkill for the majority of packages, where there probably will be just one vendor (i.e. Debian). Should DEP 14 allow for a simplified layout such as master, pristine-tar, upstream when there is no other vendor involved? Allowing for master as an alternative to debian/sid or debian/master might simplify the common case. I think this is a bad idea. Having a single standard arrangement is much more useful, than having a variety (which every tool will have to cope with). Of course anyone is free not to follow the recommendations in Raphael's document. Ian. -- 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/21603.26923.740807.786...@chiark.greenend.org.uk
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Raphael Hertzog writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): The DEP will neither encourage and discourage its use. It only mentions that if a maintainer is using it, it should store pristine-tar data in the pristine-tar branch. Would it be worth mentioning in the DEP that while some people swear by pristine-tar, some swear at it ? If you just mention it without comment there is an implication that using it is generally a good idea. Ian. -- 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/21603.27025.360397.511...@chiark.greenend.org.uk
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Scott Kitterman writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): Who's going to do patches to existing tools (e.g. git-dpm is the one I use and care about) so they comply with this and similarly scripts to convert existing git repos to match this recommendation? I'm obviously missing something here. I'm no expert on git-dpm but what Raphael wrote seems si9milar to whuat I have seen in existing repos. If there are differences between Raphael's document and existing practice, I think they should be 1. documented (in the DEP) 2. justified (here or in the DEP). It doesn't make much sense to have an standard unless there's also a plan to implement using it. I thought Raphael was trying to document existing practice. Ian. -- 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/21603.27182.788498.359...@chiark.greenend.org.uk
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi, Simon McVittie: Keep Debian packaging completely separate (in a different branch, or even in a diffferent archive) and use a quilt-ish workflow Let's call this one divided. Three: same as Two, but the Debian packaging branch is branched from the upstream branch, so it contains unpatched files *and* debian/ *and* debian/patches. (semi-integrated?) Well, if the two workflows I described are extremes, that'd be 1.95; the only difference seems to be the (non-)existence of a debian/.git directory. NB: .git will be a pseudo-symlink-ish file if/when somebody uses git's submodules for their personal code (dis)organization, so please only test whether it exists, not whether it's a directory. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Simon McVittie writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): On 12/11/14 05:54, Mathieu Parent wrote: Also, the vendor/* branches heads should be at a descendent commit of the corresponding upstream branch, diffing only by the debian dir. ... Concrete example: suppose you maintain an implementation of hello world, with a Debian patch changing hello.c to say puts (hello, Debian) instead of puts (hello, world). As I read Raphael's proposal, different branches may have different contents. Raphael defines a thing called a `packaging branch' (terminology is from git-dpm, I think). A packaging branch is like this: In git-dpm, after git checkout debian/sid, hello.c would contain hello, Debian, *and* there would be a patch in debian/patches/ to change it from hello, world to hello, Debian. AIUI, dgit also works best in this arrangement (or might even require it?) dgit requires it. In the gbp-pq world, after git checkout debian/sid, hello.c would contain hello, world, but there would be a patch in debian/patches/ to change it from hello, world to hello, Debian. If you check out such a git tree, and say dpkg-buildpackage, what happens ? I would much prefer it if branches with different layouts had different conventional branch names! Ian. -- 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/21603.27369.860753.854...@chiark.greenend.org.uk
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On November 12, 2014 7:38:25 AM CST, Matthias Urlichs matth...@urlichs.de wrote: Hi, Simon McVittie: Is it the intention of this DEP to mandate the gbp-pq-like repo structure, which basically forbids use of tools whose design does not match that? Or is the intention to set some conventions that can be true regardless of whether you are using a more gbp-pq-like or more git-dpm-like workflow, in the knowledge that that necessarily makes those conventions less strict? IMHO there are two basic approaches which are mostly at odds with each other. One: Treat Upstream's git repository as Source Code; if upstream doesn't have one, pretend that it does by importing their tarballs. Use git rm to remove nondistributable files and generated stuff (if Upstream even includes them, which if they use git they hopefully don't). Apply Debian changes, packaging or not, to a packaging branch. debian/patches is an auto-generated packaging artefact which I as a maintainer can basically ignore. Other distributions may share the common repository. Call this one integrated. Two: Treat Upstream tarballs as Source Code; if Upstream generates them from git-or-whatever, that's not our problem. Use a script to mangle the upstream tarball if it contains nondistributable files. Keep autogenerated Makefiles et al. around. Keep Debian packaging completely separate (in a different branch, or even in a diffferent archive) and use a quilt-ish workflow which treats the content of debian/patches as first-class citizens. There's not much point for other distros to share our packaging repository, so why plan for it? Let's call this one divided. This DEP describes an integrated workflow. This DEP does not say anything about any sort of divided workflow, other than to implicitly (un?intentionally?) discourage its use by omission. I personally happen to like an integrated workflow, to the point that the first thing I do when working on anything packaged in a divided way I'll run a script that unwraps debian/patches into my upstream archive clone's debian branch. Based on a couple of reactions here, some from people who dislike integrated workflow at least as intensely as I don't, IMHO there's not much common ground between the integrated- and the divided- workflow adherents. Thus, please don't try to shoehorn a divided workflow into this DEP. Write your own. I don't think so. This is about what Debian as a whole -- 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/87d2ca04-cfc2-4929-8f2b-73083b93c...@kitterman.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Raphael Hertzog writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): +When you have good reasons to only store the `debian` packaging directory +(for example when the uptream sources are really huge and contains mostly +non-patchable data), you can do so but you should then document +this in `debian/README.source` along with some explanations of the tool +to use to build the package. I think your document should be neutral on the choice between packaging-only and all-inclusive workflows. Personally I am a 100% all-inclusive partisan but it is clear that not everyone agrees :-). Your DEP will be most useful if it documents best practices for each of the commonly found layouts. Ian. -- 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/21603.27551.172689.938...@chiark.greenend.org.uk
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Raphael Hertzog writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): For development releases Packages uploaded to the current development release should be prepared in a `vendor/master` branch. I preferred the previous text for this section. I think that: * We should specify debian/sid et al * We should avoid specifying things for non-Debian distros other than to use conventional terms (like distro and suite) which leave the appropriate extensibility iAN. -- 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/21603.27690.628464.110...@chiark.greenend.org.uk
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On November 12, 2014 8:15:02 AM CST, Scott Kitterman deb...@kitterman.com wrote: On November 12, 2014 7:38:25 AM CST, Matthias Urlichs matth...@urlichs.de wrote: Hi, Simon McVittie: Is it the intention of this DEP to mandate the gbp-pq-like repo structure, which basically forbids use of tools whose design does not match that? Or is the intention to set some conventions that can be true regardless of whether you are using a more gbp-pq-like or more git-dpm-like workflow, in the knowledge that that necessarily makes those conventions less strict? IMHO there are two basic approaches which are mostly at odds with each other. One: Treat Upstream's git repository as Source Code; if upstream doesn't have one, pretend that it does by importing their tarballs. Use git rm to remove nondistributable files and generated stuff (if Upstream even includes them, which if they use git they hopefully don't). Apply Debian changes, packaging or not, to a packaging branch. debian/patches is an auto-generated packaging artefact which I as a maintainer can basically ignore. Other distributions may share the common repository. Call this one integrated. Two: Treat Upstream tarballs as Source Code; if Upstream generates them from git-or-whatever, that's not our problem. Use a script to mangle the upstream tarball if it contains nondistributable files. Keep autogenerated Makefiles et al. around. Keep Debian packaging completely separate (in a different branch, or even in a diffferent archive) and use a quilt-ish workflow which treats the content of debian/patches as first-class citizens. There's not much point for other distros to share our packaging repository, so why plan for it? Let's call this one divided. This DEP describes an integrated workflow. This DEP does not say anything about any sort of divided workflow, other than to implicitly (un?intentionally?) discourage its use by omission. I personally happen to like an integrated workflow, to the point that the first thing I do when working on anything packaged in a divided way I'll run a script that unwraps debian/patches into my upstream archive clone's debian branch. Based on a couple of reactions here, some from people who dislike integrated workflow at least as intensely as I don't, IMHO there's not much common ground between the integrated- and the divided- workflow adherents. Thus, please don't try to shoehorn a divided workflow into this DEP. Write your own. I don't think so. This is about what Debian as a whole Oops. ... as a whole is doing. The DEP should be broad enough to capture at least rough consensus. Let's not make this in another poisonous us versus them issue. We have enough of those already. 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/e2a648b3-b9b0-4d45-b165-3b0d77cd5...@kitterman.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Matthias Urlichs writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): This DEP describes an integrated workflow. That's true right now. But I think a document called `Recommended layout for Git packaging repositories' ought to cover the reasonable possibilties which are currently in use. This DEP does not say anything about any sort of divided workflow, other than to implicitly (un?intentionally?) discourage its use by omission. I think that implicit discouragement is a problem. It /could/ be solved by Raphael retitling his document and changing the intro, so that the restricted scope is clear. But I think it would be better to have a single document which contains the different alternatives. Thus, please don't try to shoehorn a divided workflow into this DEP. Write your own. I disagree with half of this but agree with the other half. I think that the divided workflow should be documented in this DEP. But I agree that those who like the divided workflow should be the ones to write it up. I see that Simon (for example) is actively engaging in the discussion. Simon, would you care to write up a concrete text documenting the conventional divided layouts ? Raphael, I guess you have the DEP in git. Where's the repo ? Wait, what, it's in the webtree in ... is that still CVS ? Ian. -- 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/21603.28389.467398.780...@chiark.greenend.org.uk
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Ian Jackson writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): I think you need to be more explicit about the implications for `3.0 (quilt)' format packages. Something like: If the git tree contains debian/format specifying `3.0 (quilt)', the git tree must also contain debian/patches/series and all the patch files contained within it. Furthermore, the tree should be in the `patches applied' state. (This means that every change to upstream files is represented twice: once in the contents of that very file in the git tree, and once as a hunk in one of the debian/patches. These two representations must be in step.) It now seems like people are saying that patches-unapplied git trees work with dpkg-buildpackage. In which case the text above needs to explicitly deal with that possibility. What a complicated variety of different kinds of mess we have all made. (And I'm definitely including myself here. dgit's .pcs, I'm looking at you.) Ian. -- 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/21603.28647.404446.992...@chiark.greenend.org.uk
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On 12/11/14 14:12, Ian Jackson wrote: Simon McVittie writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): In the gbp-pq world, after git checkout debian/sid, hello.c would contain hello, world, but there would be a patch in debian/patches/ to change it from hello, world to hello, Debian. If you check out such a git tree, and say dpkg-buildpackage, what happens ? It works, assuming you don't have a leftover .pc directory with inaccurate contents: dpkg-buildpackage: source package ioquake3 dpkg-buildpackage: source version 1.36+u20140929+g918eed9+dfsg1-1 ... dpkg-source --before-build ioquake3 dpkg-source: info: using options from ioquake3/debian/source/local-options: --unapply-patches dpkg-source: info: applying Add-a-special-vmMagic-that-causes-equivalent-native-.patch dpkg-source: info: applying Add-sv_dorestart-which-can-be-set-by-game-code-to-re.patch dpkg-source: info: applying Let-servers-set-sv_fps-too.patch dpkg-source: info: applying Run-in-a-window-by-default-on-new-installations.patch dpkg-source: info: applying Add-support-for-the-GNU-Hurd-architecture.patch dpkg-source: info: applying Don-t-crash-if-more-than-128-modes-are-available.patch fakeroot debian/rules clean ... dpkg-source --after-build ioquake3 dpkg-source: info: using options from ioquake3/debian/source/local-options: --unapply-patches dpkg-source: info: unapplying Don-t-crash-if-more-than-128-modes-are-available.patch dpkg-source: info: unapplying Add-support-for-the-GNU-Hurd-architecture.patch dpkg-source: info: unapplying Run-in-a-window-by-default-on-new-installations.patch dpkg-source: info: unapplying Let-servers-set-sv_fps-too.patch dpkg-source: info: unapplying Add-sv_dorestart-which-can-be-set-by-game-code-to-re.patch dpkg-source: info: unapplying Add-a-special-vmMagic-that-causes-equivalent-native-.patch dpkg-buildpackage: full upload (original source is included) The debian/source/local-options used to be useful for this workflow, but should be unnecessary these days, because dpkg-buildpackage has been changed to leave the tree the way it found it, whatever that happens to be: patches are unapplied at the end iff they needed to be applied at the beginning. I should probably remove it from git. S -- 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/54637041.3020...@debian.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, 12 Nov 2014, Ian Jackson wrote: Raphael Hertzog writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): The DEP will neither encourage and discourage its use. It only mentions that if a maintainer is using it, it should store pristine-tar data in the pristine-tar branch. Would it be worth mentioning in the DEP that while some people swear by pristine-tar, some swear at it ? Why would that be needed? pristine-tar data sits quietly in its branch and should not annoy anyone. Obviously if a team mandates the usage of pristine-tar, then as a member of that team you might be annoyed to have to update this data, but it's another discussion. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112143844.gc9...@home.ouaza.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi Ian, On Wed, 12 Nov 2014, Ian Jackson wrote: Raphael Hertzog writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): +When you have good reasons to only store the `debian` packaging directory +(for example when the uptream sources are really huge and contains mostly +non-patchable data), you can do so but you should then document +this in `debian/README.source` along with some explanations of the tool +to use to build the package. I think your document should be neutral on the choice between packaging-only and all-inclusive workflows. While I'm all for embracing as many workflows as possible, I don't agree that all of them should be on an equal footprint. When new contributors that do not have any specific preference wonders what layout they should use, we should provide them a clear answer. Then if they have reasons to prefer something, else, fine. But just submitting raw data and letting them pick one of them based on his judgment is not the best option when we aim for more standardization in the long term. Much like we have a default desktop environment we should have a default layout for a git packaging repository. Your DEP will be most useful if it documents best practices for each of the commonly found layouts. I'm certainly ready to integrate other best-practices that are specific to the packaging-only way of doing things. Since I don't use that model, those people should submit them in this discussion! Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112144624.gd9...@home.ouaza.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
2014-11-12 14:29 GMT+01:00 Raphael Hertzog hert...@debian.org: On Wed, 12 Nov 2014, Mathieu Parent wrote: Maybe a short note would be good then? (but I don't know how to write it). I suggest this: --- a/web/deps/dep14.mdwn +++ b/web/deps/dep14.mdwn @@ -230,6 +230,17 @@ non-patchable data), you can do so but you should then document this in `debian/README.source` along with some explanations of the tool to use to build the package. +About repacked upstream sources +--- + +When the upstream sources needs to be repacked (for example to drop some +non-DFSG compliant files), then the branches and tags under the +`upstream/` prefix should actually contain the repacked sources. + +How the problematic files are pruned does not matter. What matters is that +what is stored in the `upstream/*` namespace are the sources that package +maintainers are effectively using. + Managing debian/changelog - Does this meet your expectation? Yes. thanks for taking care. Regards -- Mathieu -- 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/CAFX5sbxP_mFeUt5JSBcAzxLGC+SXNKWF1=hS29TCEFYxJ=y...@mail.gmail.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Raphael Hertzog writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): Much like we have a default desktop environment we should have a default layout for a git packaging repository. There's an argument for that. Of course (donning my partisan colours) I think the answer should be dgit-compatible. I've resisted asking you to document in your DEP the requirements that dgit impose, but to summarise: dgit branches are patches-applied packaging branches without[1] .pc directories. They must contain everything in the source package (including any autogenerated files which are in the sources). The source package must contain everything that's in git (including .gitignore, for example). [1] Current dgit still wants the .pc directory. This is going to change, in a backwards- but not forwards- compatible way. -- 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/21603.30207.176849.914...@chiark.greenend.org.uk
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, 12 Nov 2014, Ian Jackson wrote: It doesn't make much sense to have an standard unless there's also a plan to implement using it. I thought Raphael was trying to document existing practice. The problem is that existing practices are not uniform and vary between helper tools (often without good reasons, just because they started independently). So I'm certainly basing my work on some common existing conventions and I'm not changing things where it doesn't bring any value, but there is definitely some work to do to make the various tools use the recommended layout by default. For instance, git-buildpackage uses by default the branches master and upstream and do not use the recommended debian/ prefix (while it does add the debian/ prefix for the tags it generates). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112150810.gf9...@home.ouaza.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi, On Wed, 12 Nov 2014, Ian Jackson wrote: Simon, would you care to write up a concrete text documenting the conventional divided layouts ? Raphael, I guess you have the DEP in git. Where's the repo ? Wait, what, it's in the webtree in ... is that still CVS ? It's in the dep SVN repository as documented in the DEP header which points to: http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn And the main webpage of dep.debian.net points to http://dep.debian.net/depdn-howto/ I do have git-svn clone of that SVN repository with some local commits corresponding to changes discussed today in that list. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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/20141112151455.gg9...@home.ouaza.com
Bug#769304: ITP: graypy -- Python logging handler that sends messages in GELF
Package: wnpp Severity: wishlist Owner: Benjamin Drung benjamin.dr...@profitbricks.com * Package name: graypy Version : 0.2.11 Upstream Author : Sever Băneşiu banesiu.se...@gmail.com * URL : https://github.com/severb/graypy * License : BSD Programming Lang: Python Description : Python logging handler that sends messages in GELF This package can be used to sent messages to Graylog2 using a custom handler for the builtin logging library in the Graylog Extended Log Format (GELF). . Alternately, GELFRabbitHandler can be used to send messages to RabbitMQ. Your Graylog2 server needs to be configured to consume messages via AMQP then. This prevents log messages from being lost due to dropped UDP packets (GELFHandler sends messages to Graylog2 using UDP). You will need to configure RabbitMQ with a 'gelf_log' queue and bind it to the 'logging.gelf' exchange so messages are properly routed to a queue that can be consumed by Graylog2 (the queue and exchange names may be customized to your liking). . graypy can be easily integrated into Django's logging settings. -- 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/20141112161522.10738.45463.report...@konstrukt.pb.local
Re: Should fast-evolving packages be backports-only?
On Tue, Nov 11, 2014 at 2:35 PM, Rogério Brito rogerbr...@uol.com.br wrote: On 2014-11-11 15:30, Henrique de Moraes Holschuh wrote: However, candidate packages due to reason (c) above really are a problem, IMHO they shouldn't be in stable in the first place. Does this mean that I should ask for the removal of youtube-dl from testing? It will certainly bitrot in a stable release, as it supports downloading from many sites, the target sites are moving too fast (that's the nature of the web) and there's no chance that I will be hunting minimal patches to fix breakage of multiple sites, as upstream generally refactors the whole thing constantly and as multiple sites may get broken, the pile of patches would sometimes be larger than the code to extract data from some simpler sites. Maybe a decent release goal for Jessie+1: what to do with these packages that require changes that aren't fit for stable-updates to remain useful. CUT [1,2] I believe, was the most recent stab that this idea, but as Daniel Pocock pointed out there are an increasing number of cloud/web/networking/communications packages that require larger changes than stable-updates would reasonably accept. Such packages, if released in stable, would be unusable, or at worst dangerous, to users. As such, some are blocked from testing for now. The problem is that those packages can't be in backports because they can't be in testing because they can't be in stable because they can't be updated by stable-updates and need to be updated in backports which they can't be in because then they would have to be in testing. There's a chicken-and-egg game that prevents supporting those packages in Debian, users can't even say I'll just run testing since those packages aren't allowed in testing. I don't think backports being enabled by default, on its own, is the right answer (stable systems should be stable) - but some other mechanism might be appropriate for users to choose which packages they want continuously updatable. Rebecca's suggestion might be a clever way of obtaining such a feature: (1) blocking migration to testing, (2) maintaining in backports, and (3) incorporating some easy way for users to choose to pin the backports version or install from backports if not available via stable. [1] http://cut.debian.net/ [2] http://lwn.net/Articles/406301/ -- 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/CANg8-dBv1vs-L1Zt+nUM�d-ks4btjz397_jxzbz0dc_j1...@mail.gmail.com
Re: r-base-core upload to unstable does not respect freeze policy
On Wed, Nov 12, 2014 at 07:17:59AM +0100, Andreas Tille wrote: Hi Santiago, On Tue, Nov 11, 2014 at 10:24:11PM +0100, Santiago Vila wrote: So, would this patch to the current r-base package improve things if applied to the version in unstable? [...] While this would create a versioned dependency relation which would allow to migrate r-cran-epi to testing I'm personally lacking the technical knowledge whether this is the correct solution. From my point of view the correct approach would be to create an r-base-core package which declares a stable ABI and packages should depend from the ABI version. However, its way to late for implementing this in Jessie and the R maintainer is not willing to do this anyway (at least he was not when we discussed this in Wheezy freeze time[1]). I was proposing this patch not as a fix for Bug #704805, but as a way to avoid the big mess created by the upload of R 3.1.2 for unstable. -- 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/20141112163406.ga5...@cantor.unex.es
Re: veto?
On 11/12/2014 07:08 PM, Daniel Pocock wrote: On 12/11/14 11:43, Andrey Rahmatullin wrote: On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock wrote: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? Can you elaborate which decisions and how many DDs could veto them? I didn't want to be too specific, to give other people a chance to make suggestions However, one possibility is that anybody maintaining an essential package and anybody who is a DPL delegate would be able to veto. The implication is that somebody can still win a GR against the veto, but they do so knowing that they will have to find somebody else to maintain some essential packages. I don't agree with filtering the people on what kind of package they maintain, or if they have a role delegated by the DPL. This makes absolutely no sense to me: in what way are they more competent, and why should they have more power than others? Like many, I'm sad to see Joey going. But the way to have him come back isn't by adding more complexity to our constitution. In fact, it'd be quite the opposite: he wishes for technical sanity, and not administrative decision making (and I have to admit that I can only agree on his view...). 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/54638f3b.1020...@debian.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Nov 12, 2014, at 10:02 AM, Raphael Hertzog wrote: I don't know. My long term hope is that in this process we will get to a situation where: - either the tools are sufficiently interoperable that we don't have to care about this - or one of tools emerges as standard supporting all the important workflows that people are using I think we should strive for #1 for now and see if #2 emerges. I am rather opposed to this because it because it doesn't separate clearly the namespaces for the upstream development and the namespace for the Debian packaging. I still think you could get away with simpler names for most cases, but it also seems fine to establish these namespaces. I mention it because over in Debian Python we've been experimenting with the migration to git, and if we're going to continue then I think it's useful to align with this DEP. It'll mean renaming some branches in the experimentally converted repos, but that's should be okay. for the current Ubuntu development series. If I needed to support older releases in either distro, then debian/wheezy or ubuntu/utopic would be good branches to use. (Or IOW, what's the equivalent of debian/sid for Ubuntu?) I was wondering that as well. For Ubuntu, it probably makes sense to use ubuntu/master because the latest development release regularly changes and it's not a good idea to alway update the branch. Actually, Ubuntu does have a 'devel' channel for rolling releases, and I believe it's guaranteed that this will always point to the current, in-development version. E.g. right now it points to vivid. So I guess ubuntu/devel makes the most sense here. Or maybe we recommend upstream/latest by default but allow upstream alone in the case when there are no other upstream branches tracked ? +1 Cheers, -Barry signature.asc Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, Nov 12, 2014 at 12:11:12PM +0100, Guillem Jover wrote: Hi! On Wed, 2014-11-12 at 15:38:59 +0800, Paul Wise wrote: On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote: I'd like to note that there are very good reasons for a debian-only, overlay-style packaging repository too. This section should, in my opinion, at least acknowledge that, and briefly mention it as an option. I find it a bit sad that it was outright discouraged. Personally I wouldn't use anything other than debian-only repos, at least for those where I have a choice. I also actively avoid contributing to packages that don't use such repos. Exactly. In addition I also only tend to «git clone» native packages, for anything else I just simply «apt-get source» and can be pretty sure what I will get, because the alternatives are just annoying. As a maintainer and upstream, I also find crawling the packaging repos for many of the RPM based distros, Gentoo and BSDs port collections for example, actually way more pleasant and clear than many of the Debian packaging repos with packaging bits mixed with upstream code TBH, because they only have the build recipes and possibly patches, so I don't need to know their tools or path layouts to be able to find the packaging bits, because they are just obviously there, in front of you, alone. Not to mention the “unholy” practice of having to store autogenerated stuff shipped only in release tarballs in a git repo! :) I also fantasize sometimes of a day where the whole distribution would be stored on VCSs (per package) with a debian-only layout, so that I could have a local copy for the whole archive, taking only a couple of GiB at most, instead of the monstrosity of a complete exploded sources archive (according to http://sources.debian.net/stats/, that's currently 205 GiB, w/o including git history, which could easily double that size); and don't tell me space is cheap, because that does not take into account the downloading, nor the huge amount of wasted space if you only want the packaging bits. Even though it might be more convenient for the maintainer, in general I find the mixed up repos to be a disservice to the rest of the world. I share your point of view so much. Having upstream history into a packaging repo is probably too much for most of the debian packages. Not to mention pristine-tar, Debian servers already contain .orig.tar.gz tarballs... Making buildd be able to work directly from VCS can be a plus also. No more sync problem between NMU, and/or contributor that forgot (or ignore) to push onto the repository. Where the VCS *is* the .debian.tar.gz. From this, it's easy to formalize helper tools. Ok, I know that is too much changes. But maybe there is some ideas here. Greetings, -- Maxime Chatelle (xakz) gpg: 5111 3F15 362E 13C6 CCDE 03BE BFBA B6E3 24AE 0C5B -- 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/20141112164619.ga10...@hermes.rxsoft.eu
Re: Should fast-evolving packages be backports-only?
On 12/11/14 17:42, Scott Howard wrote: On Tue, Nov 11, 2014 at 2:35 PM, Rogério Brito rogerbr...@uol.com.br wrote: On 2014-11-11 15:30, Henrique de Moraes Holschuh wrote: However, candidate packages due to reason (c) above really are a problem, IMHO they shouldn't be in stable in the first place. Does this mean that I should ask for the removal of youtube-dl from testing? It will certainly bitrot in a stable release, as it supports downloading from many sites, the target sites are moving too fast (that's the nature of the web) and there's no chance that I will be hunting minimal patches to fix breakage of multiple sites, as upstream generally refactors the whole thing constantly and as multiple sites may get broken, the pile of patches would sometimes be larger than the code to extract data from some simpler sites. Maybe a decent release goal for Jessie+1: what to do with these packages that require changes that aren't fit for stable-updates to remain useful. CUT [1,2] I believe, was the most recent stab that this idea, but as Daniel Pocock pointed out there are an increasing number of cloud/web/networking/communications packages that require larger changes than stable-updates would reasonably accept. Such packages, if released in stable, would be unusable, or at worst dangerous, to users. As such, some are blocked from testing for now. The problem is that those packages can't be in backports because they can't be in testing because they can't be in stable because they can't be updated by stable-updates and need to be updated in backports which they can't be in because then they would have to be in testing. There's a chicken-and-egg game that prevents supporting those packages in Debian, users can't even say I'll just run testing since those packages aren't allowed in testing. I don't think backports being enabled by default, on its own, is the right answer (stable systems should be stable) - but some other mechanism might be appropriate for users to choose which packages they want continuously updatable. Rebecca's suggestion might be a clever way of obtaining such a feature: (1) blocking migration to testing, (2) maintaining in backports, and (3) incorporating some easy way for users to choose to pin the backports version or install from backports if not available via stable. [1] http://cut.debian.net/ [2] http://lwn.net/Articles/406301/ Looking at it from the user perspective: users expect Debian packages to be stable So if we have some packages that will never be stable, as long as we have a way to signal that to users when they choose the package, I think we should make it as easy as possible to make them available in a stable release. backports already does some of that. Security team is using security updates to do it with browsers. The only question is whether to have packages that are always essentially like a backport. -- 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/5463956b.5090...@pocock.pro
Re: veto?
On 12/11/14 17:47, Thomas Goirand wrote: On 11/12/2014 07:08 PM, Daniel Pocock wrote: On 12/11/14 11:43, Andrey Rahmatullin wrote: On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock wrote: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? Can you elaborate which decisions and how many DDs could veto them? I didn't want to be too specific, to give other people a chance to make suggestions However, one possibility is that anybody maintaining an essential package and anybody who is a DPL delegate would be able to veto. The implication is that somebody can still win a GR against the veto, but they do so knowing that they will have to find somebody else to maintain some essential packages. I don't agree with filtering the people on what kind of package they maintain, or if they have a role delegated by the DPL. This makes absolutely no sense to me: in what way are they more competent, and why should they have more power than others? It is not a suggestion that such people are more or less competent than anybody else. Rather, it is a recognition of the fact that if these people are going to leave anyway (or are not going to lift a finger to support a particular decision, as everybody is a volunteer after all) then people proposing the decision need to actively demonstrate that they can take on the extra workload that will result from getting a decision in their favor. -- 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/54639613.1010...@pocock.pro
Re: veto?
Daniel Pocock dan...@pocock.pro writes: On 12/11/14 17:47, Thomas Goirand wrote: On 11/12/2014 07:08 PM, Daniel Pocock wrote: On 12/11/14 11:43, Andrey Rahmatullin wrote: On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock wrote: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? Can you elaborate which decisions and how many DDs could veto them? I didn't want to be too specific, to give other people a chance to make suggestions However, one possibility is that anybody maintaining an essential package and anybody who is a DPL delegate would be able to veto. The implication is that somebody can still win a GR against the veto, but they do so knowing that they will have to find somebody else to maintain some essential packages. I don't agree with filtering the people on what kind of package they maintain, or if they have a role delegated by the DPL. This makes absolutely no sense to me: in what way are they more competent, and why should they have more power than others? It is not a suggestion that such people are more or less competent than anybody else. Rather, it is a recognition of the fact that if these people are going to leave anyway (or are not going to lift a finger to support a particular decision, as everybody is a volunteer after all) then people proposing the decision need to actively demonstrate that they can take on the extra workload that will result from getting a decision in their favor. Oh, I see. You're expecting people proposing GRs to be receptive to rational argument. I fear you've not been paying close attention recently. Well done. I congratulate you on your wisdom. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgp8GLErTraVz.pgp Description: PGP signature
Re: veto?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/11/14 18:36, Philip Hands wrote: Daniel Pocock dan...@pocock.pro writes: On 12/11/14 17:47, Thomas Goirand wrote: On 11/12/2014 07:08 PM, Daniel Pocock wrote: On 12/11/14 11:43, Andrey Rahmatullin wrote: On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock wrote: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? Can you elaborate which decisions and how many DDs could veto them? I didn't want to be too specific, to give other people a chance to make suggestions However, one possibility is that anybody maintaining an essential package and anybody who is a DPL delegate would be able to veto. The implication is that somebody can still win a GR against the veto, but they do so knowing that they will have to find somebody else to maintain some essential packages. I don't agree with filtering the people on what kind of package they maintain, or if they have a role delegated by the DPL. This makes absolutely no sense to me: in what way are they more competent, and why should they have more power than others? It is not a suggestion that such people are more or less competent than anybody else. Rather, it is a recognition of the fact that if these people are going to leave anyway (or are not going to lift a finger to support a particular decision, as everybody is a volunteer after all) then people proposing the decision need to actively demonstrate that they can take on the extra workload that will result from getting a decision in their favor. Oh, I see. You're expecting people proposing GRs to be receptive to rational argument. I fear you've not been paying close attention recently. Well done. I congratulate you on your wisdom. If rational argument is not necessary, then I'll propose a GR myself: Debian will give every DD a present of 1 million BTC for Christmas. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJUY5ySAAoJEGxlgOd711bEoykP/2ibacRc+firPLXHsYv+BYzJ ahN6RL7GqW0abHXEgqbvQkg6sUOHcU5R0hxRGm0kCYg43hybmPQaLvEkteh3r9Qd 580p5hsQdtuTBHu9mFTeHBHeWKxI7dfqi+Zt5TEfvi/1brFn2rCEkdZXXX6KJkv4 diA4lKJ5MPPBW5ZiEMKLZMM6uF1I0fdkW6jbd3yI6wsxXbzHiH3OBSKFl3mrX6fV 61ByJX+lcsDfCzTOguVGUanbXMQvuA6W4NVGOTqXOSjoXAYxLdgEmjqeCLJYcOx8 8ysEnMH1/SL1jsYOvBq7MX75I7PqCPrMka23I9MsD9AKfJcHqz8tud/YYL6V8E8/ C7ZcthPxJWRVxrW8cNAQVnjp/dYwKSyyKj+iv7KHm1smnv6qS9okJ5t0FO90kJj5 2oVlowNG9UaVDUIeu5MhKIjMb3YAF3S9dK++T9vkMGZfQgextFzrsSoHBbGxasic iwlkK0A0ldo+x/RWoQ4vMcbQvwKuNPJhxrwPcE6JAn/i8fzloXxfeAP6OkBHqbOm GsCjKZyuSWEZGBm0dvb3D+o+ril+Mvsw03jHxqkmfCMmUa/y2uxqj57/km29Osyw nZj4xT5bDEEu9gFaNDBdTVc9IzznfXbIL7h9H3Z+U03wo/IaNIb/0/PMKUW+w7Ny e7ux+oFkalhzB1uua4zt =n+Cj -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/54639c92.7010...@pocock.pro
Re: veto?
On Wed, Nov 12, 2014 at 06:44:50PM +0100, Daniel Pocock wrote: You're expecting people proposing GRs to be receptive to rational argument. I fear you've not been paying close attention recently. Well done. I congratulate you on your wisdom. If rational argument is not necessary, then I'll propose a GR myself: Debian will give every DD a present of 1 million BTC for Christmas. There is a difference between not necessary and won't help in the case we are discussing. -- WBR, wRAR signature.asc Description: Digital signature
Re: veto?
On 11/12/2014 02:04 AM, Daniel Pocock wrote: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? I would prefer a solution with less politics. Not more. -- 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/5463aa4d.8040...@alvarezp.ods.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On 11/11/14 22:26, Raphael Hertzog wrote: Hello, following the initial discussion we had in August (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have written a first draft of the Debian Enhancement Proposal that I suggested. It's now online at http://dep.debian.net/deps/dep14 and also attached below so that you can easily reply and comment. I have left one question where I have had conflicting feedback and I'm not sure what's best. Thus I will welcome a larger set of opinions on this specific question (search for QUESTION in the text). Are there things that are missing? Here's the draft: Title: Recommended layout for Git packaging repositories DEP: 14 State: DRAFT Date: 2014-11-04 Drivers: Raphael Hertzog hert...@debian.org URL: http://dep.debian.net/deps/dep14 Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn Abstract: Recommended naming conventions in Git repositories used to maintain Debian packages Introduction This is a proposal to harmonize the layout of Git repositories used to maintain Debian packages. The goals are multiple: * making it easier for Debian and its derivatives to build upon their respective Git repositories (with the possibility to share a common one in some cases) * make it easier to switch between various git packaging helper tools. Even if all the tools don't implement the same worflow, they could at least use the same naming conventions for the same things (Debian/upstream release tags, default packaging branch, etc.). Scope = This proposal defines naming conventions for various Git branches and Git tags that can be useful when doing Debian packaging work. The hope is that maintainers of git packaging helper tools will adopt those naming conventions (in the default configuration of their tools). Generic principles == Vendor namespaces - Each vendor uses its own namespace for its packaging related Git branches and tags: `debian/*` for Debian, `ubuntu/*` for Ubuntu, and so on. Helper tools should usually rely on the output of `dpkg-vendor --query vendor` to find out the name of the current vendor. The retrieved string must be converted to lower case. This allows users to override the current vendor by setting `DEB_VENDOR` in their environment (provided that the vendor information does exist in `/etc/dpkg/origins/`). If `dpkg-vendor` is not available, then they should assume debian is the current vendor. Helper tools can also offer a command-line option to override the current vendor if they desire. What about an extra prefix, e.g. dist/debian/* ? This would be useful for those cases where the upstream official repository is willing to keep Debian and Ubuntu branches. Version mangling When a Git tag needs to refer to a specific version of a Debian package, the Debian version needs to be mangled to cope with Git's restrictions. The colon (`:`) needs to be replaced with a percent (`%`), and the tilde (`~`) needs to be replaced with an underscore (`_`). Packaging branches and tags === Packaging branches should be named according to the codename of the target distribution. In the case of Debian, that means for example `debian/sid`, `debian/jessie`, `debian/experimental`, `debian/wheezy`, `debian/wheezy-backports`, etc. We specifically avoid suite names because those tend to evolve over time (stable becomes oldstable and so on). The Git repository listed in debian/control's `Vcs-Git` field should usually have its HEAD point to the branch corresponding to the distribution where new upstream versions are usually sent. For Debian, it will usually be `debian/sid` (or sometimes `debian/experimental`). QUESTION: some people have argued to use debian/master as the latest packaging targets sometimes sid and sometimes experimental. Should we standardize on this? Or should we explicitly allow this as an alternative? The helper tools that do create those repositories should use a command like `git symbolic-ref HEAD refs/heads/debian/sid` to update HEAD to point to the desired branch. When releasing a Debian package, the packager should create and push a signed tag named `vendor/version`. For example, a Debian maintainer releasing a package with version 2:1.2~rc1-1 would create a tag named `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should point to the exact commit that was used to build the corresponding upload. Managing upstream sources = Importing upstream release tarballs in Git -- If the Git workflow in use imports the upstream sources from released tarballs, this should be done under the upstream
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Nov 12, 2014, at 09:27 AM, Matthias Urlichs wrote: Then we should either remove the paragraph entirely, or at least mention the danger of bit rot and that it's unwise to rely on being able to recover the tarfile (long term). Because the vast majority of upstream Python packages are released as tarballs on PyPI, I have recommended that we continue to use pristine-tar for debian-python packages maintained in git, even with the oft-mentioned problems with pristine-tar. (Which FWIW, I have never seen *in practice*, though I know others have.) Other team members don't want to use pristine-tar for various reasons, and I think it makes less sense if upstream doesn't release on PyPI. Jonathan Dowland: On Wed, Nov 12, 2014 at 03:38:59PM +0800, Paul Wise wrote: Personally I wouldn't use anything other than debian-only repos, at least for those where I have a choice. I also actively avoid contributing to packages that don't use such repos. And I'm the exact opposite. FWIW: Me too. Debian-only is, to me, quite annoying, and a remnant of a workflow that was once a necessity (with CVS/SVN). Not so with git. +1. On Ubuntu, we had sourceful branches with UDD (bzr-based Ubuntu Distributed Development). It always seemed more awkward to use debian-only branches in debian-python svn branches. Playing with sourceful e.g. git-dpm is a joy. Cheers, -Barry signature.asc Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, Nov 12, 2014 at 09:21:56AM +0100, Raphael Hertzog wrote: Hi, On Tue, 11 Nov 2014, Iustin Pop wrote: Packaging branches and tags === Packaging branches should be named according to the codename of the target distribution. In the case of Debian, that means for example `debian/sid`, `debian/jessie`, `debian/experimental`, `debian/wheezy`, `debian/wheezy-backports`, etc. We specifically avoid suite names because those tend to evolve over time (stable becomes oldstable and so on). The Git repository listed in debian/control's `Vcs-Git` field should usually have its HEAD point to the branch corresponding to the distribution where new upstream versions are usually sent. For Debian, it will usually be `debian/sid` (or sometimes `debian/experimental`). I find this paragraph confusing. With gbp, this is where new Debian developments are made, and new upstream versions are sent to upstream/xxx. Or do you mean something else here? Is it clearer if I rewrite it this way ? « The Git repository listed in debian/control's `Vcs-Git` field should usually have its HEAD point to the branch where new upstream versions are being packaged. For Debian, it will usually be `debian/sid` (or sometimes `debian/experimental`) » Yes, (to me) that is much more clear. Interesting. Assuming a normal Debian package that has just a few backports (as opposed to every sid release being backported), and which imports only upstream tarballs/snapshots (not the whole history), I expect that a high proportion of the commits would happen on this branch. In which case, why not make it 'master', without debian/ ? Is it (only) in order to cleanly support multiple vendors? Henrique answered to that. The non-prefixed namespace is dedicated to upstream development. Ack. Thank you, iustin signature.asc Description: Digital signature
Re: Bug#769317: ITP: lightmdeditor -- An editor for markdown files
Control: reassign -1 wnpp Control: severity -1 wishlist Control: owner -1 Bhavyanshu Parasher a...@bhavyanshu.me Your mailer messed up the line breaks, trying to fix. * Package name : lightmdeditor Version : 1.0-2 Upstream Author : Bhavyanshu Parasher a...@bhavyanshu.me * URL : https://github.com/bhavyanshu/lightmd_editor * License : GPL-3 Programming Lang: C, C++ Description : An editor for markdown files A markdown editor application which supports syntax highlighting, multiple themes, focus mode and other features for distraction free editing. On Jo, 13 nov 14, 01:13:05, Bhavyanshu Parasher wrote: Package: wnpp Severity: wishlist Owner: Bhavyanshu Parasher lt;a...@bhavyanshu.megt; * Package name : lightmdeditor Version : 1.0-2 Upstream Author : Bhavyanshu Parasher lt;a...@bhavyanshu.megt; * URL : https://github.com/bhavyanshu/lightmd_editor * License : GPL-3 Programming Lang: C, C++ Description : An editor for markdown files A markdown editor application which supports syntax highlighting, multiple themes, focus mode and other features for distraction free editing. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, 12 Nov 2014, Raphael Hertzog wrote: On Tue, 11 Nov 2014, Henrique de Moraes Holschuh wrote: In fact, I was quite non-amused by the initial versions of this idea, but reading this latest version, I must say I *like* it. Well done! I am especially happy about the way it respects the usual git usage conventions, this will ease its adoption a lot. Thank you! I'm pleased to see that I managed to draft something reasonable. It does fail to mention security, and stable-proposed branches. We can just leave those to maintainer's discretion, of course. I believe that those are not really needed in most cases. You rarely have conflicting updates for -security and -proposed-updates at the same time. But of course we can say something along this: --- a/web/deps/dep14.mdwn +++ b/web/deps/dep14.mdwn @@ -73,6 +73,14 @@ target distribution. In the case of Debian, that means for example suite names because those tend to evolve over time (stable becomes oldstable and so on). +Security updates and stable updates are expected to be handled on +the branch of the associated distribution. For example, in the case of +Debian, uploads to `wheezy-security` or `wheezy-proposed-updates` +are prepared on the `debian/wheezy` branch. Shall there be a need to +manage different versions of the packages in both repositories, then +the branches `debian/wheezy-security` and `debian/wheezy-updates` +can be used. + The Git repository listed in debian/control's `Vcs-Git` field should usually have its HEAD point to the branch corresponding to the distribution where new upstream versions are usually sent. For Debian, How does that sound ? Well, I use a stable-proposed branch because it might well happen that the stable update is rejected. As for -security updates, they can be superseded by -stable updates. So, it all depends on how well you are going to deal with the need to rebase or revert. I'd be very wary to push for a specific workflow that forces anyone to rebase or revert, even if it is not something that will happen often. So, I sugest we either leave this to maintainer's discretion, or go with the use of separate vendor/release-* branches for s-p-u and security. -- 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/20141112213532.ga20...@khazad-dum.debian.net
Re: Should fast-evolving packages be backports-only?
On Tue, 11 Nov 2014, Rogério Brito wrote: On 2014-11-11 15:30, Henrique de Moraes Holschuh wrote: However, candidate packages due to reason (c) above really are a problem, IMHO they shouldn't be in stable in the first place. Does this mean that I should ask for the removal of youtube-dl from testing? I don't think youtube-dl is in reason (c), if anything it would be in (b). from many sites, the target sites are moving too fast (that's the nature of the web) and there's no chance that I will be hunting minimal patches to fix breakage of multiple sites, as upstream generally refactors the whole thing constantly and as multiple sites may get broken, the pile of patches would sometimes be larger than the code to extract data from some simpler sites. Well, yeah, that could be a problem, as that much change can easily introduce regressions. I'd ask the release managers if they're OK with the heavy use of stable-updates for this. -- 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/20141112215130.gb20...@khazad-dum.debian.net
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Raphael == Raphael Hertzog hert...@debian.org writes: Raphael Hi Gergely, Raphael On Wed, 12 Nov 2014, Gergely Nagy wrote: Raphael When releasing a Debian package, the packager should create and push Raphael a signed tag named `vendor/version`. For example, a Debian maintainer Raphael releasing a package with version 2:1.2~rc1-1 would create a tag named Raphael `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with Raphael version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should Raphael point to the exact commit that was used to build the corresponding upload. Mmm... I disagree here too. I think following upstream tagging conventions would be the way to go here. So if upstream uses `package-version` tags, then debian releases would be tagged like `debian/foo-2%1.2_rc1-1`, if upstream is `foo-1.2rc1`. Raphael And if upstream uses v1.2.3 we should use debian/v1.2.3-1? Yes. Raphael Do you know many upstreams using foo-1.2.3 as tags? syslog-ng and syslog-ng-incubator uses foo-1.2.3, so does a few of my own (libmongo-client, riemann-c-client), and I came across a few others, but I haven't been keeping track. Raphael I must say that I don't see the value that this brings. It might be Raphael aestethically more pleasant when browsing the list of tags but for Raphael everything else, it's just more painful. We lose the ability to Raphael easily identify the commit of a given Debian release (instead Raphael of a simple lookup operation, you have to scan all existing tags, and even Raphael then if you have no clear mapping with the Debian version, you can't be Raphael sure that you will find the correct tag). It's just two lookups, but I see your point. Sticking to the more common v$VERSION as a recommendation is good enough. I'd like to note that there are very good reasons for a debian-only, overlay-style packaging repository too. This section should, in my opinion, at least acknowledge that, and briefly mention it as an option. I find it a bit sad that it was outright discouraged. Raphael I'm open to that, but IMO the only case where there are very good reasons Raphael are the case where the upstream data is really huge and not easily Raphael patchable anyway (i.e. the case of openarena-data that Simon Mc Vittie Raphael described in https://lists.debian.org/debian-devel/2014/08/msg00582.html). Raphael Are there other reasons that you consider good enough to impose the above Raphael penalties on other possible contributors (i.e. making it impossible to use Raphael gbp pq or similar tools to update debian/patches)? My reason for going debian-only is that I'm doing far more packaging work, than upstream. I hardly ever touch upstream, to be honest. But I actively maintain half a dozen packaging branches, and do merges between them. This would be a big headache if upstream sources were there, because some of these branches belong to different upstream versions. For the record, I used to hate that style, and was an advocate for storing upstream sources in the repo too. Then I started maintaining ~6 packaging branches: three upstream versions, two packaging branch variants of each. The overlay style proved to be far superior in this case. Raphael Can you elaborate on how it was superior? See the use-case above. It was superior because I could do merges much easier, my history looks nicer, and upstream can use my debian-only repo as an overlay too, to build their own unofficial packages. It's very useful not only for the case when you have numerous active packaging branches, but in the case when you work with upstream on unofficial packages, too. With an overlay, they can just include it as a submodule, or use git-buildpackage with its overlay support, on top of pretty much any codebase they want, with minimal modifications. Raphael I have put this for now: Raphael @@ -195,6 +203,12 @@ choice to update the debian/patches quilt series: multiple helper tools Raphael need the upstream sources in Git to manage this patch series as a Git Raphael branch. Raphael +When you have good reasons to only store the `debian` packaging directory Raphael +(for example when the uptream sources are really huge and contains mostly Raphael +non-patchable data), you can do so but you should then document Raphael +this in `debian/README.source` along with some explanations of the tool Raphael +to use to build the package. Raphael + Raphael Managing debian/changelog Raphael - Raphael Does that sound better? Better, but this still leaves it as a second-class citizen, with which I'm not entirely happy with. -- |8] signature.asc Description: PGP signature
Re: veto?
On Wed, 12 Nov 2014 13:20:01 +0100, zlatan wrote: We need less and not more layers of governance/'political' complexity in project. Lets stop acting like government and more like community. When you have a small number of people involved in a 'community' then you can get by with little governance. This requires that each member have a reliable mental model of identities and interactions within the group, so as to track the member's own responsibilities to and expectations of other members. In communities up to Dunbar's number[1] plus-or-minus some unknown error bar probably smaller than Dunbar's number, this works fine. As community size increases beyond that point it starts to break down. Debian has more than 1000 developers, thousands of other contributors, and hundreds of thousands or even millions of users. All of these have some stake in decisions that the project makes. Debian is long past the point where everyone in the project can know everyone else. Politics is just another tool. Talk about politics (as opposed to political talk) is also technical discussion. More or less governance is never the answer to political problems. The answer is _better_ governance. [1] Not a specific number. Thought by anthropologists to be about 250 https://en.wikipedia.org/wiki/Dunbar's_number -- 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/m40jho$9bs$1...@speranza.aioe.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi Simon, (Please CC me on these, I'm not currently subscribed to -devel, and I'm catching up from the list archives. At the very least it will make it easier to avoid accidentally breaking the threading :) On 12/11/14 05:54, Mathieu Parent wrote: Also, the vendor/* branches heads should be at a descendent commit of the corresponding upstream branch, diffing only by the debian dir. Simon said: This is only true for workflows similar to the one normally used with gbp-pq, in which desired patches are serialized into debian/patches/ by an out-of-band step (e.g. gbp-pq export, or quilt), and the upstream tree is unpatched. In particular, it is not true for git-dpm, dgit, or (as far as I can tell from Ron's description elsewhere in this thread) gitpkg; with those workflows, upstream files in the Debian branch *do* have their desired changes. Is it the intention of this DEP to mandate the gbp-pq-like repo structure, which basically forbids use of tools whose design does not match that? Or is the intention to set some conventions that can be true regardless of whether you are using a more gbp-pq-like or more git-dpm-like workflow, in the knowledge that that necessarily makes those conventions less strict? (I use gbp-pq for non-native packages myself, but trying out git-dpm is on my to-do list.) Concrete example: suppose you maintain an implementation of hello world, with a Debian patch changing hello.c to say puts (hello, Debian) instead of puts (hello, world). In the gbp-pq world, after git checkout debian/sid, hello.c would contain hello, world, but there would be a patch in debian/patches/ to change it from hello, world to hello, Debian. In git-dpm, after git checkout debian/sid, hello.c would contain hello, Debian, *and* there would be a patch in debian/patches/ to change it from hello, world to hello, Debian. AIUI, dgit also works best in this arrangement (or might even require it?) I'm not so sure about gitpkg - I *think* git checkout debian/sid in a gitpkg repository would result in hello.c containing hello, Debian, and no patches in debian/patches. But I could be wrong. (Ron?) So in gitpkg, the repo itself is, for want of a better term, quite simply WYSIWYG. I believe it's actually the simplest of all the schemas here, since the idea is the repo simply contains the source in the preferred form for modification. If you happen to also be upstream, you check out the upstream branch and modify it as per normal. When you're ready to release, you merge the new upstream changes into the debian branch, and then make any modification to it as per normal. You don't need to build any tool-specific structure into what you put into the repo for this to work. The diff between the debian branch (or tags) and the upstream branch (or tags) at any relevant points should be exactly equal to what you'd get in a format 1 diff.gz or its equivalent for format 3 packages. If you want to build a format 3 package with your upstream changes broken out into debian/patches, then you simply enable the hook for that, which automatically extracts the changes that are still outstanding from upstream (just like the normal git-cherry function would for feature branches forked from an upstream branch) and creates the relevant debian/patches for you in the exported package. The idea is, you *already* have those patches in the repo, in a form which your upstream could trivially cherry pick when asked, or that you could cherry pick into a for-upstream feature branch for them to merge etc. (again just using the normal non-debian git workflow for people submitting patches to an upstream reviewer for merging). Duplicating them in the repo in some way just makes busy-work for you to maintain that, bloats your repo unnecessarily, and adds an extra point of failure if you make a mistake in keeping those copies correctly synchronised. So gitpkg recognises that this is something that is part of what some people want in the exported package, and automates the task of turning what is in the source repo into a Debian package in the form that they want. Exporting a debian/patches that exactly corresponds to the unmerged patches you still have is one of the tools that it provides for making packages in the form that you want them, without needing a repo that was specially prepared for this purpose in advance, and locked into the idiosyncrasies of some specific tool to be able to do it. Does that make sense? Cheers, Ron [On a slightly separate note I am also interested to hear more about whatever the confusion was you had with this was when you started working with Tollef's systemd repo that you mentioned in the previous thread. AIUI at the time, it was just that mbiebl was out of his comfort zone when typing git-buildpackage on that repo didn't do what he expected (which seems more like gbp's failing to me ;) If it was something more than that, I'm curious to know about it though to
Re: veto?
On Wed, 12 Nov 2014, Daniel Pocock wrote: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? You got it backwards. This would people LEAVE outright. -- 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/20141112221512.gc20...@khazad-dum.debian.net
Re: veto?
* Daniel Pocock (dan...@pocock.pro) [141112 13:42]: On 12/11/14 13:12, zlatan wrote: Please no. We need less and not more layers of governance/'political' complexity in project. Lets stop acting like government and more like community. If a veto facility is created effectively, then it will deter people from complexity and force people back to looking for consensus We already have that, at least for any decision done by dpl or delegates. Check the GR process for details. Andi -- 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/20141112224709.gg...@mails.so.argh.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, Nov 12, 2014 at 02:14:55PM +0100, Raphael Hertzog wrote:
Hi Ron,
On Wed, 12 Nov 2014, Ron wrote:
I think you probably need to be careful of overspecifying this.
Definitely. That's precisely why I don't want to dwelve (too much)
into details of the various workflows and why I try to restrict
the DEP at simple naming conventions for branches and tags that
the various tools might need.
Well, that's part of what I'm wary of overspecifying :)
We can't control how upstream names their branches and tags, and to
me (who as often as not either also is upstream or working closely
with them, sometimes with direct commit access to their repo too)
it's more important that the names of things reflect on their purpose
and their association with the upstream treeish they are related to
than that they follow some arbitrary one-size-fits-all naming
convention.
Obviously that doesn't mean naming them completely random things,
there are some rough patterns I follow, but that's shaped to fit
with the When in Rome principle of fitting what I do around the
upstream conventions, not forcing mine on them if they chose some
different thing for their own reasons.
Part of the rationale I was asking you for are things like:
Exactly what tools break and how that would make these conventions
necessary?
Because maybe that's a bug we ought to fix in the tools that break.
The normal workflow is simply: work in git exactly how you normally
would, whether you're making upstream changes or debian patches.
Export a source package with `gitpkg $debtag $upstreamtag`.
[...]
The good news from all that though, is that it would seem unlikely
that gitpkg itself would need any changes to be able to cope with
any repo design you could come up with that wasn't completely insane :)
Great, then it might be that gitpkg doesn't need any code update
and that only its documentation should be updated to recommend
using the default names when creating $debtag (and $upstreamtag in
some cases).
gitpkg fairly deliberately stayed away from making recommendations
like this, partly for the reasons above, partly because it is designed
to be able to be used with already existing repos (where you should
follow the existing conventions unless you have really good reasons
to make some discontinuous change), and partly because it simply isn't
limited by this in any way at all so you're free to do whatever you
are most comfortable with.
For me personally, I dislike tags of the form: unecessaryverbiage/x.y.z
in much the same way as I dislike debian changelogs that say nothing
more than '* New upstream version'.
It adds nothing of value beyond wasted time typing it and visual clutter
when reading it.
I already know you uploaded a new upstream version, the version number
in the changelog tells me that.
If I was going to recommend a tagging convention, it would probably be
the vX.Y.Z one that is in widespread use in the majority of repos, and
which seems to have clearly won the race for common convention, rather
than pushing something oddball just because gbp did it that way.
If I see a repo with tags:
v1.2.3
v1.2.3-1
v1.2.3-2
v1.2.4
v1.2.4-1
I'm not likely to have much trouble figuring out which tag debian
releases and which tag upstream releases.
As more general advice I'd probably recommend using:
${upstream_tag_name}-${debian_version}
Since I definitely have some upstreams that use $packagename-$version
or similar for their own tags (and When in Rome).
I don't think I've ever seen a repo with namespace/blah tags in
it outside one that was gbp influenced.
Maybe I missed something somewhere (I should have been sound asleep
a few hours ago, so that's quite possible), but I see lots of
explanation of *what* you want to do, but not the killer reasoning
about *why* you want to do it, or what concrete things you think
will be gained from it.
I think I explained my goals in the introduction of the DEP. Making
it easier for Debian and its derivatives to build upon their respective
Git repositories (possibly on a semi-automated basis). And making it
easier to switch between various git packaging helper tools because they
would share (by default) the same basic conventions. And making it easier
to have the upstream git branches in the packaging repository too.
Sure, I understood those were your goals.
What I haven't seen, and what I'm asking for, is an actual detailed
rationale describing the actual detailed problem(s) that you think
these goals will be a remedy for.
It's already quite possible for derivatives to use any of my git
repos as an upstream base for their own packaging work, and is
something that already happens, despite the fact that I'm not
following any of the new conventions you are proposing here.
So what tools break if you don't follow them, and how?
Every repo I have that is in git upstream has my work based directly
on their repository. Even the ones where I had the
Re: veto?
Andrey Rahmatullin w...@debian.org writes: On Wed, Nov 12, 2014 at 01:41:33PM +0100, Daniel Pocock wrote: If a veto facility is created effectively, then it will deter people from complexity and force people back to looking for consensus Or we could fix the TC instead. It would be lovely if that were the fix. If I could fix this by, say, resigning from the TC, or if we could make different TC rules that would make the problem go away, that would be AWESOME. That would be a clear path forward for this whole mess. I think it's worth mentioning here that the reason why I argued for making a TC decision on systemd was because I hoped some sort of official decision-making process would provide some closure. As Michael correctly points out, he was dubious that would happen, and history has proven that he was right and I was wrong. But remember, the reason why multiple people in the project asked the TC to get involved was because, prior to that decision, we had a different problem: an ongoing flamewar that had been recurring for two years, and which was also horribly demoralizing. The sad and difficult problem here, I believe, is not that the TC is off on some tangent. Rather, I suspect the TC is remarkably representative of the project here. The project is deeply, strongly, and even ideologically divided on this complex of questions... and so is the TC. The project is struggling to reach any sort of shared consensus or even agreement on what we're trying to get consensus *on*, and so is the TC. The project contains fundamental disagreements about even the facts of the situation, and so does the TC. You can't solve those sorts of problems with process. If there really is a disagreement over fundamental principles, which is what Ian has been arguing that there is, and which I have also been arguing there is along a different axis of fundamental principle, then it doesn't matter what framework or mechanism you use to try to structure the conversation. You'll still end up at loggerheads over a matter of fundamental principle. We have a lot of procedural and legalistic mechanisms that can be, and are currently being, invoked for such disputes, which means that we end up in deep process arguments that are highly demoralizing and off-putting to people who (rightfully) want our community to act like a community and not a legal system or a legislature with a hostile and adversarial process. Stripping away that sort of system at least gets rid of that problem, but it's still not going to somehow magically resolve an actual fundamental conflict over principles. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87389nncn5@hope.eyrie.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi. I've read the original proposal and believe it is generally going in the right direction. things I liked: * didn't pick between dgit/git-dpm/git-pq; documented the common parts * Seemed to really focus on one clear scope. * Discouraged overlay packaging. I've tried to read the arguments, and I'm unconvinced that should be a recommended practice. I'd prefer to simply rule it out of scope: this proposal describes how to package debian and upstream sources together. It does not apply to other cases and does not forbid or recommend them. It doesn't apply to svn. It doesn't apply to overlay packaging. --Sam -- 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/0149a6c75f57-85b0ccf2-2e0c-42cd-9299-f17f889aa95e-000...@email.amazonses.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wednesday 12 November 2014 10:47:30 Raphael Hertzog wrote: [snip] I'd like to note that there are very good reasons for a debian-only, overlay-style packaging repository too. This section should, in my opinion, at least acknowledge that, and briefly mention it as an option. I find it a bit sad that it was outright discouraged. I'm open to that, but IMO the only case where there are very good reasons are the case where the upstream data is really huge and not easily patchable anyway (i.e. the case of openarena-data that Simon Mc Vittie described in https://lists.debian.org/debian-devel/2014/08/msg00582.html). Bandwith and disk space. The upstream data not being easily patchable is just and addition here (IMPOV). And yes, bandwith and disk space is not so cheap everywhere. Are there other reasons that you consider good enough to impose the above penalties on other possible contributors (i.e. making it impossible to use gbp pq or similar tools to update debian/patches)? Yes: when using tools like gbp sometimes (which becomes more valid with newcomers) don't really know what's really happening. We in the Qt/KDE team have found that it's much simple and straightforward to just keep debian/ and teach people the workflow basics, specially when trying to debug a workflow over IRC :) Of course, this is experience and YMMV. It works for us at least ;) If someone wants to use a local branch for keeping the source and use tools like gpb they are free to do so, locally. IIRC Maxy has achieved this for KDE stuff. -- 7: Hay diferencia entre cortar un archivo y borrarlo o eliminarlo * Depende cuando se cuelgue Windows Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: veto?
Daniel Pocock dijo [Wed, Nov 12, 2014 at 12:08:23PM +0100]: I didn't want to be too specific, to give other people a chance to make suggestions However, one possibility is that anybody maintaining an essential package and anybody who is a DPL delegate would be able to veto. The implication is that somebody can still win a GR against the veto, but they do so knowing that they will have to find somebody else to maintain some essential packages. As a DPL delegate, I'd strongly veto that idea. That clearly creates first- and second-class citizens. signature.asc Description: Digital signature
Bug#769373: ITP: ruby-notifier -- send system notifications on several platforms
Package: wnpp Severity: wishlist Owner: Balasankar C balasank...@autistici.org * Package name: ruby-notifier Version : 0.5.0 Upstream Author : Nando Vieira fnando.vie...@gmail.com * URL : https://github.com/fnando/notifier * License : Expat Programming Lang: Ruby Description : send system notifications on several platforms Notifier gem can be used to send system notifications on several platforms with a simple and unified API. Currently supports Growl, Libnotify, OSD, KDE (Knotify and Kdialog) and Snarl. -- 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/20141113055131.7607.10070.reportbug@sasalam
Re: Second call for votes: GR - Init system coupling
* Neil McGovern (ne...@debian.org) wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 57dd4d7c-3e92-428f-8ab7-10de5172589e [ 5 ] Choice 1: Packages may not (in general) require a specific init system [ 3 ] Choice 2: Support for other init systems is recommended, but not mandatory [ 4 ] Choice 3: Packages may require specific init systems if maintainers decide [ 1 ] Choice 4: General Resolution is not required [ 2 ] Choice 5: Further Discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- signature.asc Description: Digital signature
Re: veto?
On 13/11/14 06:29, Gunnar Wolf wrote: Daniel Pocock dijo [Wed, Nov 12, 2014 at 12:08:23PM +0100]: I didn't want to be too specific, to give other people a chance to make suggestions However, one possibility is that anybody maintaining an essential package and anybody who is a DPL delegate would be able to veto. The implication is that somebody can still win a GR against the veto, but they do so knowing that they will have to find somebody else to maintain some essential packages. As a DPL delegate, I'd strongly veto that idea. That clearly creates first- and second-class citizens. Not quite: if people are choosing not to remain a citizen at all, then they are neither first or second class. If there was such a scheme in place, then I don't think people could use it frivolously, at least not for too long. E.g. maintainer of essential package foo vetoes 5 GRs in a row. At some point, other people will start stepping forward to maintain that package or propose an alternative. -- 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/54646273.7070...@pocock.pro
Accepted libcatalyst-perl 5.90075-2 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 12 Nov 2014 08:00:40 + Source: libcatalyst-perl Binary: libcatalyst-perl Architecture: source all Version: 5.90075-2 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: Damyan Ivanov d...@debian.org Description: libcatalyst-perl - elegant Model-View-Controller Web Application Framework Closes: 769093 Changes: libcatalyst-perl (5.90075-2) unstable; urgency=medium . * Team upload * Remove obsolete build-dependency on libcatalyst-engine-psgi-perl This allows for libcatalyst-engine-psgi-perl to be removed from the archive. (Closes: #769093) Thanks to Simon McVittie Checksums-Sha1: 7cee9cce2ad99496ad7ccd186dde3a5a53320cd3 3885 libcatalyst-perl_5.90075-2.dsc 1ff1ab47e9f896e49311420acf09fed0f69a4da0 10924 libcatalyst-perl_5.90075-2.debian.tar.xz 63fdf6dea2fab4042428b00a84864b94c0c42b20 342160 libcatalyst-perl_5.90075-2_all.deb Checksums-Sha256: 5a9fa77dd4ee2737ee2b72bef59accf5cfa61d879e2a4ffde8662cae53799791 3885 libcatalyst-perl_5.90075-2.dsc 92ef56215dfb937fb2be333e24bd5866be256b254b5631475ee69bfec52b87fd 10924 libcatalyst-perl_5.90075-2.debian.tar.xz d4430f350756f545ef7057608795a3e4309447f7236c9bef5b73c6fa207eb3f3 342160 libcatalyst-perl_5.90075-2_all.deb Files: bbd3c591d3585a5746142ba5231d3bf8 3885 perl optional libcatalyst-perl_5.90075-2.dsc 874924ee86e72ce18d9fefd0b96a1679 10924 perl optional libcatalyst-perl_5.90075-2.debian.tar.xz 9a41e49775ecfd45206fd09e07b741ff 342160 perl optional libcatalyst-perl_5.90075-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUYxSQAAoJENu+nU2Z0qAEA9AP/2qQGfEK+R2NdbdtWUZVBi/t lyqLmy/b+LgSuz/uRHfkxW1tEKzxcgG19KvzdagchnYYZozM50Z4uuyeUVv6SRDV FGcx0EgNyE+o1v0b9Vhi3jnwhfjQk5DwLKhnl7szGGsbfW98mQ07QKkpbvcMsCf5 wgECGho6xwMz/GUCwUH/fw6L0r8h2yD3GQuJ5k9Y543AGfZWxSeG5Lx0bpIKCApo MirmppKUXClfZ9ktHPWs5HuBkAewO68C6yn65YH/qHtqShCYjjBPd9IatqjOepl3 5mq90DVuShi7TgacsIHTyqLSdunjelDBixA4ZGtWln4Uq8H2/nnFU+bJZa6CR4Dg PE0ka4PGBmlCrT1W5klbzUzI/b7pj22Cww/jiHfiqIjVytY5hJ6oLJIgAuTgXMJO W7/ie/pPC8yfc6WFv3avW7yGcIBbDezg23mSF83e+dUU01pHVggGKoRfwuc2pliQ HMOMDNDVsoU2oN0fci1qZaikY0qN61QeKRKwvVydqXtpJxgTwb8ftfPXVjczP/JG S10lMU+2XlhAj6tmGkop4RzDiIjMXKI541VPagQm/mM68vQlRX2s3pgF041AGxbb HUL39ty1ZdThSnWXl87vW9jDEkZ8x1aOaE02+RGehZ/4OkJbSVYnNPd2i26vL7rC aXEi6JwqI+5Wz2whAedP =LuV/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xou5p-0002xu...@franck.debian.org
Accepted ironic 2014.1-10 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 05 Oct 2014 14:35:21 +0800 Source: ironic Binary: python-ironic ironic-common ironic-api ironic-conductor ironic-doc Architecture: source all Version: 2014.1-10 Distribution: unstable Urgency: medium Maintainer: PKG OpenStack openstack-de...@lists.alioth.debian.org Changed-By: Thomas Goirand z...@debian.org Description: ironic-api - bare metal hypervisor API for OpenStack - API server ironic-common - bare metal hypervisor API for OpenStack - common files ironic-conductor - bare metal hypervisor API for OpenStack - conductor ironic-doc - bare metal hypervisor API for OpenStack - doc python-ironic - bare metal hypervisor API for OpenStack - Python lib Closes: 767479 Changes: ironic (2014.1-10) unstable; urgency=medium . * Mangling upstream rc and beta versions in watch file. * Added nl.po debconf translation (Closes: #767479). * Removed BSD license of nature.css of docs (file is gone upstream). * Added dh-systemd and dh-python as build-depends. * Added --with systemd in debian/rules. Checksums-Sha1: 597575943052a8a423b891d8d7e436e6296c202f 3353 ironic_2014.1-10.dsc a04f86b6773f1dc4976a9867993ef6168dd96a8b 12432 ironic_2014.1-10.debian.tar.xz a2cfd127700b4b41cc6c83473558af3391e4e58c 243334 python-ironic_2014.1-10_all.deb 9c12bdfff2fcf2aa1b8dc95d2aa7c3e19465fe33 23818 ironic-common_2014.1-10_all.deb d9068d452898712a7133fef05138f9c95d5bc62f 5436 ironic-api_2014.1-10_all.deb 4eac5171c5d443f0a2b83753cffdd9d5b613dd06 5412 ironic-conductor_2014.1-10_all.deb cdec3560b86183c91a34de08e10885093784d0cb 47834 ironic-doc_2014.1-10_all.deb Checksums-Sha256: 2b69be8564f550791d897fb13b451177b1d17e4ab870a264f7c680192d7ca3dc 3353 ironic_2014.1-10.dsc 0c9875cf781447887dcfdad69aefe061ad354c9cbeadabec0c6c75899039564d 12432 ironic_2014.1-10.debian.tar.xz 4622b55eb684accb1991968f6032935283a34135a84473be7754ba321f98e1c8 243334 python-ironic_2014.1-10_all.deb b178947e4ebdaee48ddf5c2a8dee09dad7787cebed7dc1481e4eb5906970849b 23818 ironic-common_2014.1-10_all.deb 7be187d22def133ddf3d1489ea58eef140048aa176c1e047cbd48665bdb5f423 5436 ironic-api_2014.1-10_all.deb 62e61d514064136462aa1d970f549e9ee75078d3307caeda3775cbb2f5452c8c 5412 ironic-conductor_2014.1-10_all.deb b09220480d1a8ea240d5b50e672d7423176fba5a33c56d6d73a85c3da4faccf0 47834 ironic-doc_2014.1-10_all.deb Files: 62429f9157e83f51c3a2b081f8ef1563 3353 net extra ironic_2014.1-10.dsc b8a92cfd00af8b416b87a1354bcef753 12432 net extra ironic_2014.1-10.debian.tar.xz c671a084b5a5b0fadbd0305535bffcfe 243334 python extra python-ironic_2014.1-10_all.deb 398d7dab1ad69f8cec6886aab498f7d1 23818 net extra ironic-common_2014.1-10_all.deb 688feb7f985801e64b1594a1adb72737 5436 net extra ironic-api_2014.1-10_all.deb f4d04141b96e729e8b487d5b95c39628 5412 net extra ironic-conductor_2014.1-10_all.deb c1512324d62c6b6f053a01dff1288551 47834 doc extra ironic-doc_2014.1-10_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUYyLfAAoJENQWrRWsa0P+tPQP/RjzScyVTRMFWvWwcV7bxllk vtbFgwM2i9aXL/dh/O69MSGsJyMQKKX8xxq5plF0LXYG2gEnwyiy68/p2/pGI45e QDpl+pVo+TFSLb25jOmXjkXnWgMmXmwtfzqBh7ef2JJwndlJJixr22RKhAin9bEP BXrczJ1Q1ci7cEPVKl44Q8U9+3D8ZzswAcFK/GnW50SgyrO7zvfUYvwB0d5O75jc r6lAvHCWof1KeSZy+0wF5gUwzO+fLUJBxKiAUKzFaohWONwf7VBwCiN8OF3VBPpP wpkYht/pGFgkosRS8Xk5nOx3W7QXMXBmXtsxQwT9WBa4FjKN1/amWn+fc2jB9yGs 5HPlAF/NeTW4sSyvETFIWtPrqy914jo7UBVkVUNKddASIBt60Z0BZ2bVvsKcGPYb tCRfzb+sZqhaUIFucNrLDIuLN6pKuYUOYNQi8vFUhgC8fACgDazIG3i6EYYgaED/ rOlIdzgb5Vb6dYeC0AGwOWv3yRnOuREqDuau50OOyueqeGBN+0IhG7XAQnNg+/YS tNkcQUsgnjx9CVUAMFjW+deuZisbvtFt5Psqp0SNwkzq4fncgf9kPs++Ap0K7cVQ rNc8ydyRnamQMZcT3dJamjYjkn2ae+S2D9OZ1xHu+g50YjM5zilTdrq4B2yMZyWK AJrVTkmY95UfLtCH3Cv0 =1bUo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xou5i-0002w9...@franck.debian.org
