Re: Ubuntu's docker-compose packages are outdated
Hi there! On Wed, Jul 5, 2017 at 10:35 PM, Drew DeVault wrote: > Would you consider updating them to 0.13 at least, if not 0.14? I have > sent a similar email to the maintainer of the original Debian package, > though the Debian package is more up-to-date than the Ubuntu package. > Not sure whether you heard about this, but Docker is now also available as a snap and directly updated by Docker Inc. This allows for latest CE releases to make their way to Ubuntu 14.04 (and later) users – and of course users of other distros, but that's less relevant :-) Docker-compose is included and up-to-date in the latest CE snaps :-) Best, - Loïc Minier -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Buildd's and pbuilder provide differing results
On Mon, Oct 12, 2009, Charlie Smotherman wrote: > The package however FTBFS on the official ubuntu buildd's. > https://launchpad.net/ubuntu/+source/rlpr/2.05-4/+build/1288660/+files/buildlog_ubuntu-karmic-i386.rlpr_2.05-4_FAILEDTOBUILD.txt.gz It fails with: dh_md5sums dh_builddeb pkgstriptranslations: processing control file: ./debian/rlpr/DEBIAN/control, package rlpr, directory ./debian/rlpr pkgstriptranslations: rlpr does not contain translations, skipping pkgstriptranslations: The following PO/POT files are empty. This is known to cause trouble in the translation importer and generally indicates a package bug: ./po/rlpr.pot dh_builddeb: dpkg-deb returned exit code 1 > How is one to know if a package will build successfully if the ubuntu > buildd's, ppa builders, and pbuilder provide differing results? The pkgstriptranslations system is only needed on Ubuntu buildds; you can install the package in your development environment if you want to reproduce the failure. You might have to enable stripping in an /etc config file. Look at the files of the pkgbinarymangler package to get started. > How is one to setup a local build system that mimics the ubuntu > buildd's? And yes I used --debootstrapopts --variant=buildd when > setting up my pbuilder. --extrapackages pkgbinarymangler You might also want to check the pkg-create-dbgsym package which is also only on the Ubuntu buildds. -- Loïc Minier -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: what compat level for debhelper in jaunty?
On Tue, Dec 16, 2008, Robert Collins wrote: > man debhelper recommends compat 7; is there some reason not to follow th > recommendation? I can see two reasons: - if applicable, avoid diverging from Debian and maintaining a diff for this - ease backports and building on older releases which don't have debhelper 7 by default -- Loïc Minier -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release will revert libgems-ruby to the old state.
MS): install some machinery which allows one to create a .deb installing binaries below /usr/bin in a special deb namespace (packages would be named gemdeb- to distinguish them easily). > In the mean time, what can be done in the Intrepid time frame ? I think it's too late for intrusive changes, and we shouldn't push anything which can not be easily reverted or upgraded from. We could sacrifice the availability of gems in the default PATH of all programs while trying to implement a facility to set this up (to support B). For now, perhaps you could only consider inserting gems in /etc/environment's PATH (supporting A). > It seems that leveraging /usr/local/bin/ is one of the best option. > You've raised a valid point above. I'd like to put in the balance the > end user experience: the usage of /usr/local/bin would remove one step > to the configuration process of rubygems in Ubuntu and get rid of the > "Where did my gem go?" question. I think Debian/Ubuntu systems are known for the stability of their packaging system and high quality packages before being known for the ease of administration. Do we prefer offering a quick and dirty solution which will be hard to move away from but works right now, or do we want to engineer a rock solid solution while only offering now what we can safely offer? > IMO what goes into /usr/local/ is the administrator responsibility. It's > disappointing if they install software in /usr/local that breaks other > things they've installed in /usr/local/, but it's up to them in the end. I'm not sure I buy into this argument. By this logic, people could provide downloadable .debs which install files below /usr/local but that would be ok because the admin pushes the "dpkg -i" button. I would rather prefer we keep the /usr/local hierarchy as "unknown territory" for the tools we provide. Data in there could well have been installed by matters of gems, we don't know nor do we want to interfere or maintain that hierarchy. I wouldn't mind that we provided tools which default to pushing data into /usr/local if we dont provide any warranty on upgrades, removals, management of that data. The proposed alternatives system for gems seems to promise a tool to manage installed gems like dpkg maintains packaged files, and that crosses the line of the usage of this hierarchy for me. -- Loïc Minier -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release will revert libgems-ruby to the old state.
On Thu, Sep 04, 2008, Mathias Gug wrote: > > * it's not against policy to setup a system to try to expand its PATH > >to use additional data, as long as using the default PATH wouldn't > >break the system and its packages > What do you mean by "as long as using the default PATH wouldn't break > the system and its packages" ? I mean that even if the gems aren't in the PATH, the packages continue to work. > Do you mean that only the gem system should be setup to use gem > installed binaries ? No, I mean that it's not a policy violation to try to add the gem binary path to PATH on a best effort basis because packages will continue to work whether PATH has the gem binary patch or not. I wish manually installed gems benefit the users of the system (including the admin) and services as much as possible since someone went through the hassle of installing the gems: it means they either additional software or newer software available as gems. > A.The end user wants to use a binary provided by a gem from the command >line (shell environment). >Example: the rails command to start a rails project. Let's stop mentionning this one which is well understood and covered by all proposals so far. > B. A daemon that runs gem installed binaries. >Example: cgi scripts under apache2. That one I'm afraid I thought would be covered by /etc/environment, but I now realized it's not. I thought /etc/environment was also sourced by central sysvinit scripts to affect all child processes, but this is wrong, it is only sourced by some scripts and used by pam_env for some services. I should dig up the rationale for implementing support of /etc/environment in the way; the OneTruePath spec doesn't hint at this. I'm certainly again overly naive, but it would seem to me that a central definition of the default environment should cover more than pam sessions and a handful of init scripts. Shall we revisit OneTruePath to cover non user-session use cases? I certainly understand that pam_env made it easy to implement OneTruePath for cases where the environment needs to be cleared/sanitized (sshd comes to mind), but it seems to fall short on covering the use case you describe as B. Perhaps we can simply enforce this support in init/upstart? However, if there are reasons that we didn't want to support setting the PATH for *everything* which drove the current implementation of OneTruePath to only use pam_env and selectively read /etc/environment from some key places (e.g. gdm, cron) then these reasons probably apply equally to gems. In this case, we should pursue with the current style and add support for /etc/environment in apache2. > It seems to me that symlinking gems binaries to /usr/local/bin/ is the > simplest solution to cover both use case A. and B. While it might be simple to build on the current level of support for the /usr/local/bin path in various places, it seems to be a dangerous solution, even more when using the alternatives system. I think some admins run things like ./configure (the default usually installs in /usr/local) && make & sudo make install to install random software. This would clash with the current symlinks. Ubuntu systems also need to allow similar situations to other parallel distribution/packaging systems (as provided by python tools, perl tools etc.). -- Loïc Minier -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release will revert libgems-ruby to the old state.
On Wed, Sep 03, 2008, Steve Langasek wrote: > > For example, libnssmdns mangles /etc/nsswitch.conf to add its entries: > > this sounds equally intrusive to me. > I for one don't consider that high praise, I'm not happy with packages > taking it upon themselves to edit /etc/nsswitch.conf. :) By my reading, > that's a violation of Debian Policy ¶ 10.7.4, but one that's been quite low > on my list of bugs to file so long as PAM remained in disarray. For the record, I agree the nsswitch.conf mangling is intrusive and I would also like to move to wrapper scripts to manage its contents. -- Loïc Minier -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release will revert libgems-ruby to the old state.
On Mon, Sep 01, 2008, Mathias Gug wrote: > This was indeed suggested at the very beginning of the bug thread [1] by > using /etc/profile.d/. However it was rejected on the following grounds > [2] I'm not quite sure I agree with the rationale; I agree it's a good policy that programs /installed by packages/ must not depend on environment variables to get reasonable /defaults/. However: * it's not against policy that programs installed via gems (not installed by packages) rely on a specific PATH or LD_LIBRARY_PATH to work * it's not against policy to setup a system to try to expand its PATH to use additional data, as long as using the default PATH wouldn't break the system and its packages * the rubygems package doesn't require a custom PATH setting to do its work (installing gems) -- however you do need special settings to use the installed data (gems) * Ubuntu went through the hassle of promising that PATH is set in exactly one place across the whole system <https://wiki.ubuntu.com/OneTruePath>; especially in light of "Ubuntu wants to remove /usr/games from the default $PATH" in the above spec, it seems that it's a long term desired distro feature to define the PATH in a central place for various use cases and this sounds like a good use case An issue I see with relying on the PATH env var is that its old value is in a bunch of running processes; probably not worse than upgrading a lib such as libssl and having to restart services to pick it up. So I don't know whether it would be hard to implement a /etc/environment.d which would be guaranteed to be used in all cases where /etc/environment is used, or whether it would be too dangerous to update PATH in /etc/environment -- there are certainly implementation questions -- but I don't think this should go against policy. > This is related to section 9.9 of the Debian Policy [3], Environment > variables: > A program must not depend on environment variables to get reasonable > defaults. (That's because these environment variables would have to be > set in a system-wide configuration file like /etc/profile, which is not > supported by all shells.) Is there any shell which doesn't honor the PATH in /etc/environment? If yes, I think it's a bug; if not, we can build on the PATH set in this file IMO. And even if there were such shells, these shells would simply miss gems; the programs installed by packages would still work correctly, even commands to add / remove gems. What might not work are gems themselves. -- Loïc Minier -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release will revert libgems-ruby to the old state.
On Mon, Sep 01, 2008, Mathias Gug wrote: > 1. sudo apt-get install rubygems > 2. sudo gem install rails > 3. Modify the default PATH in the environment to include > /var/lib/gems/1.X/bin/ so that the rails command can be invoked from the > command line. > The upload aims at removing step number 3 from the process by symlinking > the gem binary from /var/lib/gems/1.X/bin/ into /usr/local/bin/. -You certainly considered the following option, but I'm curious about the rationale for excluding it from the implementation.) Why don't you do 3 in place of the admin instead of using /usr/local? If touching /etc/environment is too fragile, could we add some new mechanism to handle default PATH changes (e.g. /etc/environment.d)? For example, libnssmdns mangles /etc/nsswitch.conf to add its entries: this sounds equally intrusive to me. -- Loïc Minier -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Hosting and Vcs-* fields in packages modified from Debian
On Thu, Aug 21, 2008, Robert Collins wrote: > > I personally try to use the same type of VCS that upstream is using for > > the packaging bits I maintain [1]: I can merge from upstream and keep a > > common history. > > Given that there is only one VCS really supporting cherry picking today > (darcs), and many upstream releases are not accurately represented in > tarballs (due to e.g. configure, Makefile.in etc), I'm not sure how much > of a common history you really get. Certainly with svn/cvs/other > centralised system you won't get any common history. Its true that the > closer the connection the easier things get. I would get LP to import > and svn/cvs upstream though, and bzr-git is coming along quite well at > the moment. Hmm importing remains an additional step which I could bear, but I wouldn't be able to offer my work back as a git tree to e.g. upstream or Debian. Or: were I to develop a feature in a branch or prepare a new upstream ahead of Debian in an Ubuntu bzr-git imported repo, how would they pull back in their git tree? > >* I could push to Alioth [2], but it's disturbing for many > > reasons: > > - not all Ubuntu people have accounts, and we would miss the > >groups anyway > > - use of Debian resources for Ubuntu; I feel I need permission > >of the packaging project I'm forking from; not really > >possible for packages in Ubuntu alone > > - causes a dependency between Ubuntu data and Debian > >infrastructure: e.g. Alioth is down and you can't commit :-/ > The primary problem here is introducing skew between the packaging > branch and the uploaded-to-Ubuntu packaging - that would occur if Alioth > were down and you needed to get stuff built. Exactly; even more disturbing if we consider a future where we push to a DVCS branch to upload a new revision of a source. If we imagine that I could point LP at a remote DVCS where I push new versions of the package to push into Ubuntu (with GPG signing and all), then an Alioth downtime might prevent uploading new packages to Ubuntu. (Granted, this is very hypothetical.) > > b) we seem to lack clear/strict guidelines for dealing with Debian > > versus Ubuntu versus upstream Vcs information; I think we need more > > tools, more policies, and more documentation for this issue: > > - we should clear Vcs-* fields when forking a package for Ubuntu > > which was kept in a Vcs when we don't intend to keep it in a Vcs > > (examples of packages getting this wrong: pbuilder, xorg-server) > > -- or rename them to X(S)-Original-Vcs-* -- or mention the Ubuntu > > Vcs instead > > - we should update tools such as "update-maintainer" to do the right > > thing > > - we could enhance the Vcs-* policies/specs to cover upstream > > information and perhaps improve the "X*-Original*" policies/specs > > to handle multiple levels of forking (package forked from maemo > > into Debian, and then forked from Debian into Ubuntu for instance > > :-) > You should probably read the Ubuntu Distributed Development pages :). These pages cover some interesting processes for future technologies which would probably make my questions obsolete, but I feel like we could improve the present situation with some not too complex extensions of the meta-information we have in source packages -- such as the above proposals, or simply providing things like the branch to checkout from a Vcs-Git repo for example. I do look forward to distributed development though :) -- Loïc Minier -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Hosting and Vcs-* fields in packages modified from Debian
On Wed, Aug 20, 2008, Steve Langasek wrote: > Ideally if the maintainer is already using > feature branches in a distributed VCS, Ubuntu could hook into that with its > own feature branches, and that would entirely satisfy my concerns about > maintainability of the patches. But the highest percentage of Vcs-* fields > in Debian packages still point at subversion, which is not at all useful for > this purpose. Ah it's been a while I'm tempted to ask how other people deal with a couple of issues I have on these topics... I personally try to use the same type of VCS that upstream is using for the packaging bits I maintain [1]: I can merge from upstream and keep a common history. I wonder about a couple of things: a) I don't have access to centralized hosting for e.g. git trees with Launchpad's access control / unix permissions; ideally, we would have the major services provided by Alioth on Launchpad to share with various Ubuntu teams, but since we only have Bzr, it's not easy to use other distributed VCSes for Ubuntu branches; it's not always possible to import into Bzr, and it adds a conversion step (also it makes it harder to pull the other way around) So where do you people host your branches? * I could push to say people.ubuntu.com/~lool, but then if I were to declare this to be the location for the Ubuntu packaging bits, I would have to act as a middleman before any update to this tree. * I could push to Alioth [2], but it's disturbing for many reasons: - not all Ubuntu people have accounts, and we would miss the groups anyway - use of Debian resources for Ubuntu; I feel I need permission of the packaging project I'm forking from; not really possible for packages in Ubuntu alone - causes a dependency between Ubuntu data and Debian infrastructure: e.g. Alioth is down and you can't commit :-/ * I could ship the DVCS files in the source package itself, but I understand it's still "future technology" b) we seem to lack clear/strict guidelines for dealing with Debian versus Ubuntu versus upstream Vcs information; I think we need more tools, more policies, and more documentation for this issue: - we should clear Vcs-* fields when forking a package for Ubuntu which was kept in a Vcs when we don't intend to keep it in a Vcs (examples of packages getting this wrong: pbuilder, xorg-server) -- or rename them to X(S)-Original-Vcs-* -- or mention the Ubuntu Vcs instead - we should update tools such as "update-maintainer" to do the right thing - we could enhance the Vcs-* policies/specs to cover upstream information and perhaps improve the "X*-Original*" policies/specs to handle multiple levels of forking (package forked from maemo into Debian, and then forked from Debian into Ubuntu for instance :-) So I'd love to read what you people are doing around these issues; perhaps I'm too conservative and should make more use of Alioth; perhaps we shouldn't tweak Vcs fields manually but use a central Launchpad override (the information might be in Launchpad already!) or perhaps Launchpad should import the information and help us fork the packages? I'm sure other people have very cool ideas to deal with these! [1] it's a tighter constraint than what you mention, or perhaps it's what you meant, not sure [2] In the past I (as an Alioth project maintainer) personally offered to other distros to host their packaging in the same repo (e.g. SVN) -- Loïc Minier -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
