Derivatives, MongoDB and freezes
I came across this on Planet Debian http://rb.doesntexist.org/blog//posts/lack_of_cooperation_from_ubuntu/ I'm guessing that Ubuntu may not have pushed the changes to sid because of the freeze, that may well be the answer to Rogério's questions. Nonetheless, with derivatives and Debian itself having different release cycles, and wearing my upstream developer hat, I can't help wondering: how can upstreams ensure that the freshest versions of their package propagate to the derivatives without duplicating effort? For example, to respect the Debian release process, I've avoided uploading the latest versions of my packages to sid, so it appears that newer versions of those packages missed the boat when Ubuntu started their freeze. This means that both Debian and Ubuntu will release with versions of the packages that are old and don't have the latest bug fixes and/or any manual effort to work around that takes away time that could be spent on more bug fixes or features. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51727df2.8040...@pocock.com.au
Re: Derivatives, MongoDB and freezes
On Sat, Apr 20, 2013 at 7:37 PM, Daniel Pocock wrote: > Nonetheless, with derivatives and Debian itself having different release > cycles, and wearing my upstream developer hat, I can't help wondering: > how can upstreams ensure that the freshest versions of their package > propagate to the derivatives without duplicating effort? You can push those versions to experimental and ask Ubuntu to sync from there (they do that during freeze but not automatically) using requestsync from ubuntu-dev-tools (available in Debian). For other derivatives there aren't any specific sync procedures, you'll need to contact their development fora, some are listed in the census pages. http://wiki.ubuntu.com/SyncRequestProcess http://wiki.ubuntu.com/UbuntuDevelopment/Merging http://wiki.debian.org/Derivatives/Census -- bye, pabs http://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: http://lists.debian.org/CAKTje6FG=sluznjrwqdwxymtmlnphujjn7ryx-lbr7ez9-0...@mail.gmail.com
Re: multiarch and interpreters/runtimes
On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote: > It seems correct at first glance, but not enough to solve all the issues > mentioned. Currently existing package relationships lack information > that is necessary to do the right thing in all cases. Consider different > kinds of dependencies a package P can have on package Q: Let me attempt to draw these. > 1) P contains code for that links with code from Q. >Q needs to work for . P (any) -> Q (any) > 2) P executes a binary provided by Q. >Any arch for Q is OK. P (any) -> Q (any) Most likely Q is M-A:foreign here. Alternatively M-A:allowed with a different dependency: P (any) -> Q:any (any) Another variation comes if P is Arch:all, but those cases work similarly to the first one. > 3) P runs a script using system interpreter X, and depends on the >interpreter environment supporting functionality provided by Q. >Q needs to work for the arch matching installed version of X. P (all) +--> X (any) `--> Q (any) The interpreter will most likely be M-A:allowed. So all P has to do here is not add ":any" to its dependencies. Then everything should work out here. X and Q would usually have singleton sets for their virtual architectures. (Only Arch:all and M-A:something packages can have non-singleton sets here.) The dependencies of P are considered satisfied only if those singleton sets are equal. > 4) P runs a script in an embedded interpreter in its code, and >depends on the interpreter environment supporting functionality >provided by Q. >Q needs to work for . Since P uses an interpreter X, it has to depend on it as well. So the resulting dependency graph should look exactly like the one above, except that P is arch:any now. > In the most common case dependencies on a package Q are either all of > type 1 or all of type 2, as long as Q only exposes one kind of > interface; in the current multiarch spec Q indicates this by > "Multi-Arch: same" for 1 and "foreign" for 2. However, dependency types > 3 and 4 require adding more information in the depending package to > allow determining what arch needs to be supported for Q. The new dependency resolution is designed to catch precisely the cases for 3 and 4 with no further annotations, because those annotations are not necessary. We just assume that a package needs all of its dependencies in the same architecture unless there are declarations that lift this requirement. Currently there are two declarations that can do this. 1. M-A:foreign tells the resolver that the rdep should not care about this particular package's architecture. 2. A package:any annotation (for M-A:allowed dependencies) says that the architecture of this particular dependency should be ignored. In the light of the above I do not quite understand what is missing to support your use cases yet (besides an implementation). Can you explain them in more detail? Examples would be helpful. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420122744.ga17...@alf.mars
Re: multiarch and interpreters/runtimes
Helmut Grohne wrote: > On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote: > > 3) P runs a script using system interpreter X, and depends on the > >interpreter environment supporting functionality provided by Q. > >Q needs to work for the arch matching installed version of X. > > P (all) +--> X (any) > `--> Q (any) > > The interpreter will most likely be M-A:allowed. So all P has to do here > is not add ":any" to its dependencies. Then everything should work out > here. But that 'not add ":any"' is completely impractical. The default system interpreter can only have one architecture - what "#!/usr/bin/python3" executes. Multiple versions of that can not be coinstallable, and so it's completely unreasonable for a foreign package containing Python scripts to demand that you change your _default_ Python interpreter to another architecture. It would immediately lead to conflicts. In a sane system scripts written in pure Python must work with the default system interpreter, whatever architecture that is. > In the light of the above I do not quite understand what is missing to > support your use cases yet (besides an implementation). Can you explain > them in more detail? Examples would be helpful. Consider a package that contains a Python script (#!/usr/bin/python) doing image manipulation using python-imaging (Depends: python, python-imaging) and an i686 binary using embedded Python (Depends: libpython2.7, python-levenshtein). As above, installing this package must not require changing your default system python to i686. So the effective dependencies are: python:any, python-imaging:, libpython2.7:i686, python-levenshtein:i686. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1366468972.1964.44.camel@glyph.nonexistent.invalid
Bug#705821: ITP: ocaml-opus -- OCaml bindings to libopus
Package: wnpp Severity: wishlist Owner: Romain Beauxis * Package name: ocaml-opus Version : 0.1.0 Upstream Author : The Savonet Team * URL : https://github.com/savonet/ocaml-opus * License : GPL2 Programming Lang: OCaml Description : OCaml bindings to libopus The Opus codec is designed for interactive speech and audio transmission over the Internet. It is designed by the IETF Codec Working Group and incorporates technology from Skype's SILK codec and Xiph.Org's CELT codec. . This package contains all the development stuff you need to use Opus codec in your OCaml programs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420154127.3462.30435.reportbug@iroy
Bug#705822: ITP: ocaml-frei0r -- OCaml bindings to the frei0r API for video effects
Package: wnpp Severity: wishlist Owner: Romain Beauxis * Package name: ocaml-frei0r Version : 0.1.0 Upstream Author : The Savonet Team * URL : https://github.com/savonet/ocaml-frei0r * License : LGPL 2.1 Programming Lang: OCaml Description : OCaml bindings to the frei0r API for video effects frei0r is a minimalistic plugin API for video sources and filters. The behavior of the effects can be controlled from the host by simple parameters. The intent is to solve the recurring reimplementation or adaptation issue of standard effects. It is not meant as a generic API for all kinds of video applications. . This package contains all the development stuff you need to use frei0r plugins in your OCaml programs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420154555.3507.5509.reportbug@iroy
Vous concernant
Honorable Pour tout commencer je m'excuse de vous avoir adressé ce message sans votre consentement, je vous adresse ce message pour discuter d'affaire avec vous, mais je ne sais pas quelle sera votre réaction à ma proposition. Je travaille actuellement comme un auditeur externe avec une banque. J'ai découvert un compte dormant qui appartient à un homme d'affaire syrien décédé du nom Mohammed Husni Hashmi résident d'une ville appelé Alep en Syrie. Ce compte est resté dormant pendant 9 ans. Quand j'ai élevé la question concernant le compte, un cadre supérieur de la banque m'a confié qu'il n'y a eu personne qui a pu mener une investigation de système à propos des fonds dans la question de savoir si Monsieur Mohammed Husni Hashmi a une famille pour la réclamation, mais personne n'a signalé depuis son décès. De chaque indication, le besoin du directeur est de se débarrasser de l'argent. J'aimerais savoir si vous êtes intéressé par cette affaire ? Nous avons besoin d'un compte vide n'importe où, mais hors des Etats Unies d'Amérique où nous pourrons transférer ses fonds. La proportion pour le partager de l'argent sera discutée sur votre acceptation.Le montant des fonds est estimé $4,3 millions de dollars Américain. Sincères salutations. PREU PATRICK -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ccvtxeen-limn-38o-pmtm-bs3pgfhlv...@gmail.com
Re: Derivatives, MongoDB and freezes
On 2013-04-20 04:37, Daniel Pocock wrote: I came across this on Planet Debian http://rb.doesntexist.org/blog//posts/lack_of_cooperation_from_ubuntu/ I'm guessing that Ubuntu may not have pushed the changes to sid because of the freeze, that may well be the answer to Rogério's questions. Those changes are extremely recent. For instance, MongoDB 2.2 was only uploaded to Ubuntu on March 21. The ARM changes are also just from this recent raring cycle which only began in October. MongoDB is getting a lot of attention because it is at the core of Juju. Normally this much delta would be avoided, but some new features from 2.2 are needed and ARM is an important platform for Ubuntu server. Typically Ubuntu takes a pattern of re-converging with Debian as much as possible early in each 6 month cycle. So I would expect that we will get quite a few patches pushed toward Debian unstable right about the time wheezy releases. Nonetheless, with derivatives and Debian itself having different release cycles, and wearing my upstream developer hat, I can't help wondering: how can upstreams ensure that the freshest versions of their package propagate to the derivatives without duplicating effort? These patches, by and large should not require duplication. If you look, some of the arm support patches happened in Fedora, not Ubuntu. Now, I think I might scold my colleagues in Ubuntu for not annotating their patches with bug reports so we can make sure they get forwarded to upstream and closed. But as long as these issues are being forwarded upstream, they should not be "duplicated" at all. For example, to respect the Debian release process, I've avoided uploading the latest versions of my packages to sid, so it appears that newer versions of those packages missed the boat when Ubuntu started their freeze. This means that both Debian and Ubuntu will release with versions of the packages that are old and don't have the latest bug fixes and/or any manual effort to work around that takes away time that could be spent on more bug fixes or features Debian is focused on stable releases. There's nothing "wrong" with this model, but it does mean you don't get the latest upstreams without diverging. IMO this is why upstream packaging should be embraced and enhanced rather than focusing on dpkg. I once worked on the 'pkgme' project for Ubuntu and there have been others, but never followed through. The idea was just to build debian source packages from upstream sources. Upstreams should be able to release a package which serves their needs, and Debian should be able to consume these almost directly. Where Debian's efforts should be focused is on things like license verification and helping bug reports and fixes get to upstream. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/da27206329b6ad09d56602e8d78b4...@secure.spamaps.org
Re: Derivatives, MongoDB and freezes
On 20 April 2013 12:37, Daniel Pocock wrote: > > > I came across this on Planet Debian > > http://rb.doesntexist.org/blog//posts/lack_of_cooperation_from_ubuntu/ > > I'm guessing that Ubuntu may not have pushed the changes to sid because > of the freeze, that may well be the answer to Rogério's questions. > That is mostly correct. The other part is that packages & fixes not suitable for sid/wheezy were not applied & uploaded to experimental as aggressively as Ubuntu pace would want. I also posted on Debian Planet, how to find patches applied in Ubuntu via Debian PTS together with categories of useful fixes that are relevant to Jessie and may be already solved/patched in Ubuntu. [1] I perceived that blog post as a partial personal stab at me, by the way. Which I found unjust. > Nonetheless, with derivatives and Debian itself having different release > cycles, and wearing my upstream developer hat, I can't help wondering: > how can upstreams ensure that the freshest versions of their package > propagate to the derivatives without duplicating effort? > > For example, to respect the Debian release process, I've avoided > uploading the latest versions of my packages to sid, so it appears that > newer versions of those packages missed the boat when Ubuntu started > their freeze. This means that both Debian and Ubuntu will release with > versions of the packages that are old and don't have the latest bug > fixes and/or any manual effort to work around that takes away time that > could be spent on more bug fixes or features. You can look at glibc, gcc, python which all got packages in Debian VCS and/or uploaded into Ubuntu from Debian VCS or sycned/merged from Debian Experimental uploads. These workflows can be done, but require cooperation and are not automatic (e.g. sync-from-experimental is always manual and not automatic as e.g. syncing from sid or testing). Ideally, i'd like to see debian to branch or use t-p-u, such that sid can continue accepting new uploads and not freeze. E.g. something similar to how fedora operates. I vaguely recall that something like that has been proposed to debian in the past, and didn't get much traction, since developers can get distracted by continious uploads instead of working on releasing the frozen part of the archive. Regards, Dmitrijs. [1] http://blog.surgut.co.uk/2013/04/ftbfs-fixes-and-other-patches-available.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujh1-g77ffrhruganszhmx06gjzuexn5zc6hmoh7np...@mail.gmail.com
Re: multiarch and interpreters/runtimes
On Sat, Apr 20, 2013 at 05:42:52PM +0300, Uoti Urpala wrote: > Helmut Grohne wrote: > > On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote: > > > 3) P runs a script using system interpreter X, and depends on the > > >interpreter environment supporting functionality provided by Q. > > >Q needs to work for the arch matching installed version of X. > > > > P (all) +--> X (any) > > `--> Q (any) > > > > The interpreter will most likely be M-A:allowed. So all P has to do here > > is not add ":any" to its dependencies. Then everything should work out > > here. > > But that 'not add ":any"' is completely impractical. The default system > interpreter can only have one architecture - what "#!/usr/bin/python3" > executes. Multiple versions of that can not be coinstallable, and so > it's completely unreasonable for a foreign package containing Python > scripts to demand that you change your _default_ Python interpreter to > another architecture. It would immediately lead to conflicts. In a sane > system scripts written in pure Python must work with the default system > interpreter, whatever architecture that is. You point out a limitation that I'd consider to be a feature. My proposal requires that every package has a single set of running architectures that has to apply to all code contained. I did think about lifting this requirement, but let me first point out how to work around it. The workaround is not pretty, but doable in all cases. What you have here is that your script should run in a different architecture than the rest of the package. You need two sets of running architectures and that means two packages. You move the script to a separate Arch:all package with M-A:foreign and depend on it from P. P (any) ---> P-script (all, M-A:foreign) +--> X (any) `--> Q (any) That way P-script will have the same running architecture as the interpreter, but P can have a different running architecture. (Note that I am using "running architecture" to refer to the single element of the running architecture). > Consider a package that contains a Python script (#!/usr/bin/python) > doing image manipulation using python-imaging (Depends: python, > python-imaging) and an i686 binary using embedded Python (Depends: > libpython2.7, python-levenshtein). As above, installing this package > must not require changing your default system python to i686. So the > effective dependencies are: python:any, python-imaging: is>, libpython2.7:i686, python-levenshtein:i686. After splitting your package, you have the following graph. ,--> P-script (all, M-A:foreign) +--> python P (i686) +--> python-2.7:i686 `--> python-imaging `--> python-levenshtein:i386 So why am I proposing this limitation of a single set of running architectures per package? Not to do so would mean to annotate the dependencies with "". In my opinion this would clutter the dependency syntax and the field itself. We already have/had problems to find a syntax for the bootstrap stage annotations. A syntax change is very hard to implement as it has to touch a large number of tools. In addition I believe the solution outlined to be expressive enough to cover all cases albeit introducing intermediate packages. Indeed the cases that have popped up requiring these additional capabilities are a minority. Having to split a small number of packages to achieve true multiarch seems like a good trade off to complicating the dependency syntax to me. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420193753.ga13...@alf.mars
Bug#705844: ITP: zuul -- zuul - a project gating system
Package: wnpp Severity: wishlist Owner: Antoine Musso * Package name: zuul Version : 1.2.0 Upstream Author : OpenStack * URL : http://ci.openstack.org/zuul/ * License : Apache Programming Lang: Python Description : zuul - a project gating system Zuul is a program that is used to gate the source code repository of a project so that changes are only merged if they pass tests. The main component of Zuul is the scheduler. It receives events related to proposed changes (currently from Gerrit), triggers tests based on those events (currently on Jenkins), and reports back. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420191831.14984.97886.reportbug@integration-jobbuilder.pmtpa.wmflabs
Bug#705850: ITP: gti -- Animates a car and launches git if you type gti by mistake
Package: wnpp Severity: wishlist Owner: Felix Crux * Package name: gti Version : 1.0.4+1 Upstream Author : Richard Wossal * URL : http://r-wos.org/hacks/gti * License : Old-Style MIT Programming Lang: C Description : Animates a car and launches git if you type gti by mistake The gti package would provide a fun little launcher application similar to the existing sl package, except aimed at git instead of ls. When the user accidentally types gti instead of git, an ASCII animation of a car driving by appears, and then git is run. signature.asc Description: Digital signature
Re: multiarch and interpreters/runtimes
Helmut Grohne wrote: > You point out a limitation that I'd consider to be a feature. My > proposal requires that every package has a single set of running > architectures that has to apply to all code contained. Should that "set of running architectures" be just "architecture"? I think that after adding such splitting of packages the system could represent the required constraints, but I'm not sure if such splitting is a practical way. > Having to split a small number of packages to achieve true multiarch > seems like a good trade off to complicating the dependency syntax to me. Have you tried to somehow count the affected packages? Where did you get the "small number" from? There are over 2500 packages with a dependency relationship on "python" alone that are not named "python-*" (to exclude python module packages). Is the proportion of those with Python scripts in addition to other code really that low? Would something like apt-file be split into 3 - apt-file, apt-file-perl-scripts, apt-file-python-scripts? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1366501352.1964.55.camel@glyph.nonexistent.invalid
Re: Derivatives, MongoDB and freezes
Le Sat, Apr 20, 2013 at 11:05:29AM -0700, Clint Byrum a écrit : > > These patches, by and large should not require duplication. If you > look, some of the arm support patches happened in Fedora, not > Ubuntu. Now, I think I might scold my colleagues in Ubuntu for not > annotating their patches with bug reports so we can make sure they > get forwarded to upstream and closed. But as long as these issues > are being forwarded upstream, they should not be "duplicated" at > all. Hi Clint, this is a key point: the one who makes the patch should forward it upstream directly. This way it benefits everybody. For a large number of bug reports forwarded to Debian from Ubuntu, I wonder why one is asking me to forward Upstream, intead of doing it himself, especially in some race-conditions situations (new compilers, new linkers, etc.) where Upstreams would have adapted their software themselves if we had given them a bit more time. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130421012815.gb5...@falafel.plessy.net
