Re: Patch systems in packages
On Wed, Aug 20, 2008 at 07:23:27AM +0200, Reinhard Tartler wrote: Phillip Susi [EMAIL PROTECTED] writes: If you run into a package that does not already have some kind of patch system there are 2 possibilities: 1) The package has never needed to be patched before 2) The package has been patched by directly modifying the original upstream files, which is a big no-no In the second case, the package should be fixed and the upstream debian maintainer notified and asked to repair their broken package as well. In that case, I kindly ask you to not touch any of the package I maintain in debian. I very much prefer managing patches to sources using a VCS, and adding patch system adds unnecessary noise in the debdiff. I really wonder who brought up the (wrong) claim that *not* using a patch system was deprecated in the first place. I think the problem is, that many people don't know, that debian source packages do have this diff.gz handling, which is also a patch system. Not the best one, but actually it works. A debianized source tree (with debian/ already applied) can be changed outside debian/ dir and those changes are going in the resulting diff.gz. No orig.tar.gz source is being touched. I do the same...a source package which doesn't have a patch system (like dpatch, cdbs-simple-patchsys, quilt, or even dokos python patch system ,-)) applied, will go with diff.gz. Or, if it's possible and I have the time, I'll get a VCS branch and do what the debian maintainer did. As Lars said, we have everything in place... Only packages I introduced in Ubuntu will have explicit patch system in future (like I did now e.g. for zend-framework). So others and especially I can track the patches I applied from upstream. Regards, \sh -- Stephan '\sh' Hermann | OSS Developer Systemadministrator JID: [EMAIL PROTECTED] | http://www.sourcecode.de/ GPG ID: 0xC098EFA8 | http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Considering component-specific work when reviewing applications
On Tue, Aug 19, 2008 at 05:21:21PM -0400, Scott Kitterman wrote: [...] Well then I guess I'm left feeling like this is the unwritten Server Team need not apply rule. When I've brought this up about people who were active in #ubuntu-desktop, but not #ubuntu-motu my concerns were dismissed. I feel like it's a clear double standard. I think we have some social problems here... In the past, we didn't have those teams in the first place, so the very first step was to do work in Universe...and it didn't matter what packages we were interested in. We were doing anything... Now we have different, specific teams, like server team, desktop team, mozilla team, mobile team, what have you team, and many people are not interested anymore in doing general universe package work, but are interested in specific packages. Nowadays we see that happening, and yes, the distinction of universe and main is questionable. But, people are just being pushed to MOTU team to get their upload rights, but are not working with people from MOTU or do some other work then their work they are interested in. So, we have problems. 1. Most MOTUs won't know people coming from the specialised teams. 2. Those people are not interested to work for anything else then their pet packages 3. Universe work will lose menpower, and the whole workflow becomes questionable. I agree, that working on particular packages is more fun, because it can help you in your daily real life work or whereever. But having still the universe/multiverse component, it's important that we recrute people who are interested in doing general work too. Therefore, I can understand the two viewpoints: a) Who is this guy, I never saw him doing any work on Universe in general, only on those packages which are somehow split up in main and universe. b) We need this guy, because he's da rockstar for desktop/server/mobile etc. I wonder if it's time to review the whole universe/multiverse main/restricted system...but I do see already one problem with it: more packages won't be in the view of anyone. We will get more people working on their favorite area (the specialised teams), and less people are working on the more general side of ubuntu life. Furthermore, it will be more and more difficult to judge for people we don't know, because we never worked with them. I don't think it's a personal problem but more a general problem between the people not being inside the motu team, but doing great work in their specialised teams. We need to fix it...we should review our policies. Regards, \sh -- Stephan '\sh' Hermann | OSS Developer Systemadministrator JID: [EMAIL PROTECTED] | http://www.sourcecode.de/ GPG ID: 0xC098EFA8 | http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Tue, Aug 19, 2008 at 02:01:26PM -0700, Mathias Gug wrote: What are you referring to by package ? The make a parallel with python, the gem command is similar to easy_intall. And ezinstall is broken by design for a binary distro and for endusers. ezinstall doesn't check if there is the correct version somehow installed, but downloads from questionable sources (!) .egg files. Most likely we (as packagers) are patching this away. Neil's proposal is to improve the gem command (from the libgems-ruby package) so that binaries are installed in /usr/local/bin (thus they're on the default path). If you'd use install gems from the upstream source, binaries would be installed in /usr/bin/. The goal is that gems installed by the gem command don't interfere with ruby libraries and binaries installed by debian packages. Don't Use Another Package System Then The One From The Distro ! Gem is just another broken package management system for ruby. Pear is just another broken package management system for php. ez_install is just another broken design fullfill dependency management system for python. I think there are others I forgot to mention. Gem packages are even more dangerous because they are delivering sometimes also binaries...which can break your current installation of the stable distro you use. Everytime I have developers in my real life work who are trying to convince me to use this system, I rather try to let them stay in front of a wall and do the chinese way of getting rid of those devs. Mostly I'll go and try to package it in a sane way, the way of my used distro. It will be more difficult but it helps the user and in this case mostly the user is the sysadmin. Developer, who are in need of the newest crack for their development can use gem or pear or ez-install without being unhappy when they destroy their system, they are developer, and they should know what they are doing. (Today this is difficult to say, because most developers don't have a clue what they are doing anyways, only when they are involved in distro specific workflows they know about the problems). I think we don't need another way of handling gem, we just need the time to package all this broken gem crack.. \sh -- Stephan '\sh' Hermann | OSS Developer Systemadministrator JID: [EMAIL PROTECTED] | http://www.sourcecode.de/ GPG ID: 0xC098EFA8 | http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Considering component-specific work when reviewing applications
On Tue, Aug 19, 2008 at 05:21:21PM -0400, Scott Kitterman wrote: Well then I guess I'm left feeling like this is the unwritten Server Team need not apply rule. When I've brought this up about people who were active in #ubuntu-desktop, but not #ubuntu-motu my concerns were dismissed. I feel like it's a clear double standard. I agree[1]. To Emmet: I think it's interesting that this thread started when you retracted your +1 on Dustin's application referencing that it would set a new precedent. Well, by doing so, you've helped establish a different, new precedent, namely that if you're a server team person, you get to be dragged through the mud for weeks for no apparant, good reason, and you don't get to play until you're core-dev. [1]: Yes, you heard it here first. ScottK and I agree. -- Soren Hansen | Virtualisation specialist | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/ signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Considering component-specific work when reviewing applications
On Tue, Aug 19, 2008 at 02:44:47PM -0700, Jordan Mantha wrote: One one level I might say Server Team need not apply, just the same as I'd say Desktop Team need not apply because I want MOTUs, not Server/Desktop Team members with Universe upload rights. But maybe that's just me. Would you rather have these people apply for core-dev instead or not apply at all? If you want them to apply for core-dev instead, why is it more appropriate to work on only desktop packages or only server packages if you're core-dev than if you're MOTU? If you don't want them to apply at all.. Err... That's just silly :) -- Soren Hansen | Virtualisation specialist | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/ signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Considering component-specific work when reviewing applications
Michael Bienia [EMAIL PROTECTED] writes: Or to put it an other way: what makes a person a MOTU? - is it the membership in the ~motu team (and it's a coincidence that the team has upload rights) - or is it the upload rights to universe/multiverse (which are granted by being a member of ~motu) Perhaps I see a difference where no exists, but it depends on how one defines being a MOTU. I think the difference is only important if you also consider the effects that arise because of that. One possible effect if we choose the 2nd alternative is that we would effectivly require for all uploads to become 'full' MOTUs. That means if we have an applicant from a specialised team (think kernel, server, desktop team), do we require them to be active in the MOTU community first? In general we didn't in the past. Thinking more about it, it seems that we more or less already accepted that there are Ubuntu Developers that are not strictly MOTUs. Most commongly they can be found in the more specialised teams that I mentioned above. Interesting implication that come up with the plans about the UbuntuArchiveReoganisation is if e.g. a prospective kubuntu developer becomes kubuntu member, he will be granted upload permission for packages in the kubuntu seed. Which is of course part of why we want UbuntuArchiveReoganisation in the first place. I expect that after UbuntuArchiveReoganisation the majority of prospective ubuntu developers will no longer apply for MOTU, but for these specialised teams. What impact will that have for unseeded packages? And most interstingly for MOTU: what can WE do about those 'abandoned' packages? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
Scott, I'm trying to avoid the wheres and wherefores of what gem is about. Suffice to say that Rails depends upon effective gem support, such that the configuration of Rails can specify gem dependencies directly. So if Ubuntu wants Rails, it has to have Gem that works. Therefore I saw my task as trying to get gem to work as a user would expect it to work without gem destroying the operating system, leaving cruft lying around the filesystem in the wrong place and try and prevent it running into itself too much It's an exercise in containment. What are you referring to exactly ? Which use case do you have in mind ? It's my understanding that gems produces one complete package (gem) with all Ruby libs needed to run the application and that there is no internal notion of versioning. Think of gem as a source package that generates binary packages on the fly. It has notions of build dependencies with other gems (including versioning) and run dependencies. One thing it can do is manage several versions of the same gem on the machine at the same time. For example the Rails gem depends upon the rake, activesupport, activerecord, actionpack, actionmailer and actionresource gems. You can install multiple different versions (usually one of each minor revision - 1.2.6, 2.0.2 and 2.1.0) and gem will ensure that the correct versions of the dependent gems are brought in at run time. So it's not all downside. This sounds very like Windows DLL hell. It can be, but in reality you don't generally have a problem. For the most part the system works - until you start uninstalling, upgrading the operating system or changing interpreter versions. It does sound like progress. As long as we aren't actually packaing the gems themselves it seems like a reasonable way to go until Ruby Gems grows enough features to support proper integration of gems into the distro package space. Debian has attempted to package some gems, and the results are really not very useful from a Rails point of view. The packages don't tell the gem database that apt has installed something. So gem just reinstalls it. The classic example is the Rake package which is always overridden if somebody does 'gem install rails'. Making apt and gem work better together is something for the future though. -- Neil Wilson -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Wed, Aug 20, 2008 at 02:07:46PM +0100, Neil Wilson wrote: Scott, I'm trying to avoid the wheres and wherefores of what gem is about. Suffice to say that Rails depends upon effective gem support, such that the configuration of Rails can specify gem dependencies directly. So if Ubuntu wants Rails, it has to have Gem that works. Therefore I saw my task as trying to get gem to work as a user would expect it to work without gem destroying the operating system, leaving cruft lying around the filesystem in the wrong place and try and prevent it running into itself too much It's an exercise in containment. What about teaching ROR to use an overlay, especially for the webapp you code for? I mean, the problem with gem is known...it's nasty... afaik gem can do something like a destdir install somehow (when I'm not mistaken and my mind is working in normal parameters, and my knowledge from old ROR times is still valid). If you have such a structure: /var/www/ROR_App1/... std ror dirs ... /var/www/ROR_App1/gems/gem1 ... this gems dir will be used as overlay, so somehow it needs to be possible to LD_PRELOAD/LD_LIBRARY_PATH this directory (via config in apache2/lighty/whereever) What are you referring to exactly ? Which use case do you have in mind ? It's my understanding that gems produces one complete package (gem) with all Ruby libs needed to run the application and that there is no internal notion of versioning. Think of gem as a source package that generates binary packages on the fly. It has notions of build dependencies with other gems (including versioning) and run dependencies. One thing it can do is manage several versions of the same gem on the machine at the same time. For example the Rails gem depends upon the rake, activesupport, activerecord, actionpack, actionmailer and actionresource gems. You can install multiple different versions (usually one of each minor revision - 1.2.6, 2.0.2 and 2.1.0) and gem will ensure that the correct versions of the dependent gems are brought in at run time. As long as gems are only delivering their own binaries... But gems are much more, you can include complete (one or more) upstream packages (I had this at one ocasion, there was this imagemagick gem and this module was only working with a special imagemagick version, so it shipped it together with the other cruft, but instead of installing it somewhere where this imagemagick lib didn't hurt, it was just a smartass and installed it in /usr/lib, overwriting the distro imagemagick). This gem package didn't respect: DESTDIR, neither it respected the ./configure --prefix=... commands...so it destroyed other apps...but this wasn't documented anywhere, btw. so, having an overlay dir, where those gems can be installed without disturbing the other software, fine...but not as it is now, and not installing their stuff into /usr/local/lib or into /opt/foo Regards, \sh -- Stephan '\sh' Hermann | OSS Developer Systemadministrator JID: [EMAIL PROTECTED] | http://www.sourcecode.de/ GPG ID: 0xC098EFA8 | http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Considering component-specific work when reviewing applications
Soren Hansen wrote: To Emmet: I think it's interesting that this thread started when you retracted your +1 on Dustin's application referencing that it would set a new precedent. Well, by doing so, you've helped establish a different, new precedent, namely that if you're a server team person, you get to be dragged through the mud for weeks for no apparant, good reason, and you don't get to play until you're core-dev. Again, I retracted my vote in large part because I understood there to be a desire of discussion, and from the results, I believe that this was the correct choice, as there appears to be a lot of discussion. As I originally stated, I believe that Dustin being a MOTU would be useful for Dustin's work, and that Dustin has the necessary technical skills. On the other hand, I believe that discussion within the team is useful. I specifically did not vote against Dustin in my retraction, but do not feel comfortable again changing my vote: I believe I have lost the right to do so as a result of my retraction, and again will only vote again on this application if it is required to break a tie. That said, there are two members of MOTU Council who have yet to vote, and at least one is participating in the ensuing discussion. Either of them might vote positively. This is very much not about treatment of members of the Server team, but rather about having discussions within MOTU: these discussions seem to have moved from being about a specific candidate to being about general issues with MOTU identity, which should be resolved. I'm not sure that there are outstanding questions for the specific candidate, but leave the decision to approve or reject that candidate to the remainder of MOTU Council. Regardless of the application process for the specific candidate that stated the discussion, the wider discussion defining What is MOTU is likely useful: whatever the result of any consensus, we are likely to have a better shared understanding of how we work as a result. -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Trying to deploy a grails application in Ubuntu/Debian tomcat 5.5
Hi, The motu team is named as the maintainer of the tomcat5.5 package, so I hope I'm right here for this question(and I'm positing it here first, before going to the Debian packager): I'm trying to deploy a Grails application in the tomcat5.5 server included in Ubuntu Linux 8.04. If I got it right, web applications are to be deployed to /var/lib/tomcat5.5/webapps. When doing so, the application doesn't start, and the log puts the error below. It seems to be a problem of very restrictive security settings, while reading afile that doesn't even exists in my application (and isn't needed when I run it in a tomcat 6 binary fropm upstream) - so, what do I need to do to get my webapp running in tomcat? SEVERE: Error registering Catalina:type=Valve,name=StandardContextValve,path=/TimeTracker-0.1,host=localhost javax.management.MBeanException: Cannot instantiate ModelMBean of class org.apache.commons.modeler.BaseModelMBean at org.apache.commons.modeler.ManagedBean.createMBean(ManagedBean.java:385) at org.apache.commons.modeler.Registry.registerComponent(Registry.java:835) at org.apache.catalina.core.StandardPipeline.registerValve(StandardPipeline.java:302) at org.apache.catalina.core.StandardPipeline.start(StandardPipeline.java:234) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4140) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760) at org.apache.catalina.core.ContainerBase.access$0(ContainerBase.java:744) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:144) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:738) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022) at org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:448) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177) Caused by: java.security.AccessControlException: access denied (java.io.FilePermission /var/lib/tomcat5.5/webapps/TimeTracker -0.1/WEB-INF/classes/logging.properties read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.exists(File.java:731) at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:828) at org.apache.naming.resources.FileDirContext.lookup(FileDirContext.java:211) at org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:294) at org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1924) at org.apache.catalina.loader.WebappClassLoader.findResource(WebappClassLoader.java:936) at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:299) at org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:273) at
REVU: ircp-tray 0.7.3~bzr40-0ubuntu1 (source)
NEW: ircp-tray_0.7.3~bzr40.orig.tar.gz NEW: ircp-tray_0.7.3~bzr40-0ubuntu1.diff.gz NEW: ircp-tray_0.7.3~bzr40-0ubuntu1.dsc Format: 1.7 Date: Mon, 11 Aug 2008 17:46:28 +0200 Source: ircp-tray Binary: ircp-tray Architecture: source Version: 0.7.3~bzr40-0ubuntu1 Distribution: intrepid Urgency: low Maintainer: Ubuntu MOTU Developers ubuntu-motu@lists.ubuntu.com Changed-By: Devid Antonio Filoni [EMAIL PROTECTED] Description: ircp-tray - IrDA and OBEX wireless file transfer Launchpad-Bugs-Fixed: 252217 Changes: ircp-tray (0.7.3~bzr40-0ubuntu1) intrepid; urgency=low . * Initial release (LP: #252217). Files: 84180708c4f660cbc3853e845d4826f3 795 misc optional ircp-tray_0.7.3~bzr40-0ubuntu1.dsc c0d5e459aa54ca7d67d46042bc5ad105 99593 misc optional ircp-tray_0.7.3~bzr40.orig.tar.gz 2f7233d7eebd12d4b0a32d4afbea71a1 2338 misc optional ircp-tray_0.7.3~bzr40-0ubuntu1.diff.gz Original-Maintainer: Devid Antonio Filoni [EMAIL PROTECTED] Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the overrides about once a week. pgpDIn7SNgKvu.pgp Description: PGP signature -- 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
Re: Hosting and Vcs-* fields in packages modified from Debian
On Wed, 2008-08-20 at 22:51 +0200, Loïc Minier wrote: 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. 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. 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) It also lets us build toolchains on a single base, rather than on N bases. So we can build to the strengths of bzr, rather than to the smallest common subset of features different VCS systems have. So where do you people host your branches? Launchpad. * 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. You would also effectively be creating a maintainer lock, which is one of the key differences between Debian and Ubuntu. * 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. * I could ship the DVCS files in the source package itself, but I understand it's still future technology It also conflates build-this-software instructions and manage-the-patches-for-upstream, which is quite a bit icky. 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 :). -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Patch systems in packages
On Wed, 2008-08-20 at 12:29 -0700, Steve Langasek wrote: Why? Why should the Debian Maintainer care about the monolithic patch as applied in Ubuntu (perhaps also cluttered by several changelog entries about merges that have happened, or rebuilds). Is it not best practice to send those patches relevant to Debian to bugs in the BTS, as separated patches? If this is done, to whom is it useful to track the patches independently, so long as the patches remain easy to maintain? I think this is a misleading question: it is /not/ easy to maintain patches that are jumbled together in a monolithic diff, because even if it's easy for the person who created the patches (which is likely to change over time), it's not necessarily easy for $random_other_ubuntu_developer who comes along afterwards. Even the most innocuous-seeming of patches can become head-scratchers over time if they aren't accompanied by appropriate metadata (description, + some sort of bounding box saying which bits belong). And yet, upstream development proceeds by editing a single huge monolithic diff (NULL-BRANCH_TIP) :). The key difference IMO is that when you have a bunch of patches that have not yet been reviewed, its likely that some will be accepted, and some not - and its harder to detangle those two sets after the fact. But making incremental changes is no harder with a monolithic patch than a set of itemised patches - and in some respects a monolithic patch is easier. So for *Ubuntu's* benefit, I believe our best practices should be to use some sort of patch management whenever patching upstream sources, not just a monolithic diff. (Again, I think this can be either VCS feature branches or an in-package patch system, whichever is easier for the people doing the work.) Agreed. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Patch systems in packages
On Wed, Aug 20, 2008 at 11:31:41AM +0900, Emmet Hikory wrote: Steve Langasek wrote: If you have more than one change to the upstream source of a Debian package, then you need some system to manage the changes to indicate which parts of the patch belong to which functional change -- i.e., a patch management system. This can be a set of VCS feature branches, if you prefer (in which case it's important to use the Vcs-* headers in debian/control in the Ubuntu upload), or it can be an in-package patch system; but it is important to have /some/ mechanism for labelling your changes so that you aren't left with a single massive diff. Why? Why should the Debian Maintainer care about the monolithic patch as applied in Ubuntu (perhaps also cluttered by several changelog entries about merges that have happened, or rebuilds). Is it not best practice to send those patches relevant to Debian to bugs in the BTS, as separated patches? If this is done, to whom is it useful to track the patches independently, so long as the patches remain easy to maintain? I think this is a misleading question: it is /not/ easy to maintain patches that are jumbled together in a monolithic diff, because even if it's easy for the person who created the patches (which is likely to change over time), it's not necessarily easy for $random_other_ubuntu_developer who comes along afterwards. Even the most innocuous-seeming of patches can become head-scratchers over time if they aren't accompanied by appropriate metadata (description, + some sort of bounding box saying which bits belong). So for *Ubuntu's* benefit, I believe our best practices should be to use some sort of patch management whenever patching upstream sources, not just a monolithic diff. (Again, I think this can be either VCS feature branches or an in-package patch system, whichever is easier for the people doing the work.) If the Debian maintainer already has a patch system in place, it's far better to continue using that one (no matter how bad it is, sometimes); otherwise, adding a patch system *should* be done when needed. I generally argue against the introduction of patch systems, as 1) I am very much opposed to working with a package that has both changes in diff.gz (from the original packaging), and 2) a patch system. If we're talking about packages where the Debian maintainer has already patched upstream and done so without a patch system, then I agree that this is ugly; in that case I think the best outcome is if the Debian maintainer can be persuaded to /use/ some form of patch management. These are painfully ugly, and the monolithic diff frequently becomes completely unreadable (was this a change to a previous Debian change, to an upstream change, or to a combination?); and 2) I have heard a number of Debian maintainers complain about the useless introduction of a patch system when they maintain the package in a VCS with no patch system. Can you give examples of these? 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. That said, in the case where there are no previous diff.gz changes external to debian/, I think it is best practice to review other packages with the same Debian Maintainer to attempt to determine the preferred patch system of that maintainer (which may be monolithic diff.gz), and follow that practice. In the rare case where there are no patches external to debian/ in any of the packages maintained by that Maintainer, the introduction of a patch system seems the least bad way to do things, but this is very much an exceptional case, and for most packages we would do well to instead follow the existing practice (even where that is a monolithic diff.gz). I agree; I was assuming the common case was that the Debian package did not include patches to the upstream source, or that if there were any such patches, they were managed with a patch system. Perhaps this is not such a common case as I believed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
libaws2.2 on ubuntu
hi :-) do you agree to take my bug report by email, please ? :-) or must i create an acount and put it on the web site ? i don't succeed in install libaws2.2 with synaptic, i get the error libaws2.2: DÈpend: libldap2 (=2.1.17-1) but it is not installable -- j'agis contre l'assistanat, je travaille dans une SCOP ! (les SCOP, c'est les sociétés dans lesquelles les employés peuvent virer les patrons qui se remplissent les poches) -- 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 Wed, Aug 20, 2008 at 10:51:58PM +0200, Loïc Minier wrote: So where do you people host your branches? * 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 :-/ For X, we're maintaining a git repos for xorg and xorg-server at Alioth. The Debian X folk have been helpful at sorting it out, and I gather are reasonably happy to have us on board using their VCS. They've even stepped in to help when there's been problems (and there's been a few, mostly due to my own lack of advanced git-fu). The only significant infrastructure interruption so far with Alioth that impacted my own work was back with that ssh key issue, but that was a pretty exceptional situation. Also note with git you can commit locally, and just hold off pushing if Alioth happened to be down. Bryce -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Trying to deploy a grails application in Ubuntu/Debian tomcat 5.5
Hi Henning, On Wed, Aug 20, 2008 at 06:38:00PM +0200, Henning Sprang wrote: Hi, The motu team is named as the maintainer of the tomcat5.5 package, so I hope I'm right here for this question(and I'm positing it here first, before going to the Debian packager): I'm trying to deploy a Grails application in the tomcat5.5 server included in Ubuntu Linux 8.04. You should try on the ubuntu-server mailing list [1] - you may have a better chance there. [1]: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server -- Mathias Gug Ubuntu Developer http://www.ubuntu.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
