Re: Potential Server Seed impact for 14.04: removal of OpenJDK/Tomcat7 from Ubuntu main
Hi James (2014.01.21_20:16:24_+0200) > What do people think to this plan? Are OpenJDK and Tomcat7 important > packages for Ubuntu users? Will not having a well supported OpenJDK > implementation in Ubuntu main discourage people from using Ubuntu to > host their Java based applications? Or do users still just use the > Oracle Java downloads instead and ignore what Ubuntu provides? As much as I'd prefer not to run Java, we (my employer) have a reasonable amount of it, some of which is user-facing and in Tomcat7. We migrated from Oracle Java to OpenJDK to make our lives easier (APT has its uses). A less supported Java probably wouldn't affect us too much, unless there were serious security issues that weren't dealt with. It likely wouldn't cause us to stop using Ubuntu, or to run back to Oracle Java. Java is a very popular language. And I would consider it surprising if it wasn't supported in Ubuntu server. gcj isn't really an option for Java webapps, it's too different to the traditional Java stack. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
Hi Daniel (2013.07.23_08:13:47_+0200) > For the other 99% of users, where practicality is more important than > immediate access to source, we end up wasting ~10% of Canonical and > our mirror's bandwidth on the source updates. Can you back that up with evidence? As I (and a few other people) have repeatedly said in this thread: The release pocket lists aren't changed after release. Only -updates, -security, -backports and -proposed change, and they are all small because they are an overlay on the release pocket. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on "rolling releases"
Hi Scott (2013.03.07_16:27:02_+0200) > > These are users who otherwise would use the LTS, but need some > > particular feature or version of some program that is newer than the > > LTS. > > This is exactly the case that backports are for. I don't think users who > want > a generally stable experience, but need a thing or two newer are at all > candidates for running the development release. Except for more complex HWE situations. (e.g. something that needs an entirely new network-manager modem-manager stack) Getting an official backport is still quite hard, though. * You have to know exactly what it is that you need backported (sometimes it's non-trivial to determine) * Then build the backport, which could be easy (no-change backport of one package) or really hard * Then file the backport bug, to request it for other people. At this point, your own needs are satisfied, so you are doing this for altruism and reproducibility. * Finally, someone has to review and sponsor the backport. That can take ages. We've gone a long way to making backports easier, but I don't think there's much low-hanging fruit left. We can provide more help, and spread the word that backports can be easy. That's about it? SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Let's Discuss Interim Releases (and a Rolling Release)
> As an application developer I want a stable environment that isn't too > far behind upstream. I don't want to deal with changing APIs when I'm > working on a project. I don't think you can expect that from a rolling release. Things will be changing regularly. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Let's Discuss Interim Releases (and a Rolling Release)
Hi Colin (2013.03.01_19:10:04_+0200) > I wonder whether we could petition for the Canonical-only restrictions > on devirtualised PPAs to be lifted for people in ~ubuntu-dev as a > consequence of this release plan, and what other changes that would > take. Presumably devirt PPAs would have to not throw away uploads? And we'd need a list of all the devirt PPAs. Of course, having separate PPAs for staging unrelated changes would be fantastic. But if we are dependent on full upload history as a buildd audit trail, then these PPAs need to be considered part of the Ubuntu archive. If we want end-users on our rolling release, then we don't really have anywhere to put things that we'd like to dogfood on our developers, but not the users. I was thinking of that too, when I proposed a new pocket. I feel that if we are trying to totally change our release process, we should consider restructuring pockets, rather than shoe-horning everything into the existing structure. Or maybe it's going to take us a while to figure out what we want and we shouldn't be making any hasty changes... And yes, of course, adding new pockets would be non-trivial. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Let's Discuss Interim Releases (and a Rolling Release)
Hi Jonathan (2013.03.01_16:48:21_+0200) > What bothers me more than user loss is developer loss. It's a fact > that Ubuntu as a community project is currently completely > unsustainable. ... > >If we are finding that our non-LTS releases aren't stable enough, and > >people are using the LTSs, what makes us think we can get a significant > >userbase onto a rolling release that's less polished than our existing > >releases? > > Would it be a goal to have users use the rolling releases? I can't > remember seeing that mentioned before in my catching up of the list. Hrm, that is another good argument in favour of a rolling release. Having more users on our development release will make contributing to Ubuntu significantly easier, and take the round-trip time between submitting a patch and seeing the benefit from 6 months to 1 month / 1 day. When the development release isn't something that only Ubuntu developers run, then the barrier to new contributions goes down. > I can see a benefit in having normal users on lts releases only. It > will make packaging of 3rd party apps that go into repositories such > as 'extras' a lot easier and faster. Right, agreed. As long as 2 years isn't too old for those users. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Let's Discuss Interim Releases (and a Rolling Release)
Hi Florian (2013.03.01_14:06:37_+0200) > > That means users could choose: > > * The LTS release > > * The rolling release updated daily or as frequently as desired > > * The rolling release updated at least monthly > > Neither of those choices fits my needs. I want new versions more > often than every 2 years, but I can't affort the time of monthly > upgrades. And we have to ask the question of what advantage Ubuntu is providing over Debian, without 6-monthly releases. Ubuntu has a few packages Debian doesn't. Including a desktop environment that people seem to complain about a lot. Of course, it would also be nice to see most of those in Debian eventually. Ubuntu would benefit from that too. After that, you're left with commercial support and certified hardware. Commercial support is of course available for other distros too, and the hardware certification work will benefit other distros eventually, as the changes go upstream. Most developers want to be developing on the latest libraries. Essentially, developing on their target. For open source developers, that could mean the latest Gnome/KDE, but for everyone else probably wants a rock-solid desktop environment. If we are finding that our non-LTS releases aren't stable enough, and people are using the LTSs, what makes us think we can get a significant userbase onto a rolling release that's less polished than our existing releases? Dare I ask what happens when we approach the next LTS? Does the rolling release freeze? From our current plans, I'd guess so. Isn't that exactly what people who like rolling releases want to avoid? The "debian-testing is frozen" problem? I have a hard time seeing huge benefits for our users, from a rolling release. I only see the benefits for developers like us, and a reduction in stable-support manpower. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Let's Discuss Interim Releases (and a Rolling Release)
Hi Scott (2013.03.01_06:55:18_+0200) > > I fully agree, and this is not even limited to the kernel. There are > > other kinds of "major transitions" like switching to a new X.org > > server, preparing a new major Qt or GNOME release, new eglibc, etc. Or > > we want to do a complex transition such as moving from ConsoleKit to > > logind. > > > > For those we'll need temporary staging areas which are not put into > > the RR yet until they get a sufficient amount of testing; these could > > be "topic PPAs" which interested people would enable and develop in, > > which get landed into the RR when everything is ready? > > For people or teams that are largely or entirely !canonical, this only works > if all you care about is x86 (i386/amd64). Anything for armhf (or powerpc) > would have to land untested since the PPAs that are available for !canonical > don't build these architectures. It feels like an -experimental pocket would be the best solution here. Which we would try to keep small, but could stage major transitions in. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Developer Summits Now Online and Every Three Months
> and for community members who have been caught off-guard and aren't > able to participate this time, they'll still be able to get the videos > of the discussions online, and three months from now be in a position > to participate on an even footing just like they would have otherwise. I don't know about you, but I have a huge backlog of conference talk videos on my laptop that keep waiting for me to find time to watch them. Most end up being deleted first. But I guess things that I *really* want to see, I'll find time for. And then be really irritated that I can't join the discussion because it's already over... > This isn't going to be a perfect, drop-in replacement for our previous > approach to UDS; there are certainly some trade-offs. But I'm not convinced > that participation from Asia is actually one of them. > Setting aside the fact that in this case there's very short notice, > why would it be any easier to take off a week, hop on a plane, deal > with jet lag and attend UDS in person, than to take off two days, have > a couple of late nights, and attend sessions remotely? The latter > option scales a lot better, takes /less/ time out of people's lives, > and I'm sure it gets a lot fewer people sick with the UbuFlu. I don't need to take time off from work for technical conferences (I guess I'm lucky there), but it also means for those two days, my concentration isn't on Ubuntu. It's on normal work stuff, because UDS won't really interfere with my work day (other than sleep deprivation). In my past experience of remote participation, it's far too easy to get distracted (other people around you don't really understand "I'm at a conference" when you aren't physically there). Having any reasonable discussion on IRC sucks, and you don't get the out-of-band discussion at the bar later that night. Sometimes that bar discussion results in another session being scheduled for the next day. We don't get to meet the new community members in person. It's amazing how much it changes one's relationship with someone, when you meet them in person. I suspect this will have a big affect on the community over time (but not so much in the short term). I'm going to miss UDS. And it'll undoubtedly affect my contributions to Ubuntu, although what the affects are will remain to be seen... Hope to see some of you at DebConf, and I guess I'd better get myself to EuroPython (IIRC the talk submission deadline is soon). > I know that Google Hangouts include various "low bandwidth" tweaks. Do you > happen to have any experience with these, to know how well they work / what > the real minimum bandwidth requirements are for participating? I suspect > that, in practice, it's not so different from what's required in order to be > able to participate effectively in other aspects of Ubuntu development, but > possibly it would be worth testing this before next week. I have days where YouTube is unusable, but I have a full Debian+Ubuntu mirror at home. The mirror can even be a week or two out of date without significantly affecting my ability to contribute. So no, decent bandwidth has less effect on ability to participate than you'd imagine. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Developer Summits Now Online and Every Three Months
Hi Scott (2013.02.28_01:30:12_+0200) > Since Launchpad was open sourced there's been no requirement to use > proprietary web services to be involved in Ubuntu development Worse than that, proprietary local client. I guess I'll discover how good/bad G+ is next week... SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Minutes from Developer Membership Board Meeting 2013-01-07
Hi Sebastien (2013.01.21_20:27:29_+0200) > >Upload rights at the moment conflate membership and upload rights. > >Therefore, the board has to evaluate the qualifications for both. > > Right, Bjoern is applying for upload right so it seems logical he > gets reviewed in context of upload rights... Upload rights currently go with membership, so applicants have to be reviewed in the context of both. We'll tell the applicant, if we think granting membership would be hard, or if we think upload rights aren't suitable yet and they should be applying for membership only. > >We will be sending Bjoern an E-Mail explaining our concerns and ways > >that he can address them. > When is that planned? He still didn't get those, we still have no > clue what to change, As soon as we can. And I think the idea of looking for things to change is short-sighted. If we don't think someone is ready, it usually means they need to do some more good distro work, and show that they are ready. > and meanwhile he has a SRU and a raring update blocked waiting... Nobody is blocked from working on Ubuntu, without upload rights. That's what sponsorship is for - if you don't have upload rights, you prepare an upload and find someone who has the upload rights to sponsor your upload. In this case, besides his usual sponsors, bdrung has offered to review and sponsor libreoffice uploads, which is he has already been working on. Stéphane also provided some feedback yesterday. > I appreciate that the job is not easy, your reply doesn't address > the concerns I raised in my initial email though. We still have a > community member who has been working full time on maintaining a > difficult package for 1.5+ years, got endorsement from 3 members, > and he got rejected mostly for "lack of devel releases" and an wrong > assumption (no review) ... isn't the project just making the bar too > high to join there? I was absent from the meeting that declined his application, but I wouldn't agree with your synopsis of the reasoning behind it. I think the reasons are wider, and we'll do our best to explain them in a private e-mail to him. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: raring uploads redirected to raring-proposed by default
Hi Scott (2012.10.26_06:38:24_+0200) > Since the package doesn't exist in raring-proposed, the current syncpackage > thinks it's new and includes the entire debian/changelog. Already fixed in bzr. Of course, that doesn't affect -changes, only the changelog displayed to the user, and used in closing bugs. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Patch pilot report 2012-10-15
Hi Dmitrijs (2012.10.16_12:16:26_+0200) > I don't know if per-package uploaders are in ~ubuntu-dev or not. They are. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenCL / CUDA in Ubuntu
Hi Dmitrijs (2012.10.01_10:47:52_+0200) > Earlier in the cycle I have synced pyopencl and discussed bug 763457 > [1] with graphics drivers maintainer/uploader. > > Later I realised that potentially that bug is a duplicate of a wider > in scope bug 950963 [2] > > Currently pyopencl is not installable in quantal. [3] Quite possibly those should be demoted to Recommends, so that users who have installed OpenCL from outside our package world can use it. (As icky as that is, what choice are we giving them? The CUDA tools aren't packaged) > Should I do s/opencl-icd/fglrx | nvidia-current/ in the pyopencl package > or > will we modify the graphics packages to provide the virtual packages > requested in the bugs mentioned? The provides is what we want long term, as long as there aren't going to be any versioned depends. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Minutes of the Developer Membership Board Meeting - 2012-09-24
Chair: Stefano Rivera Present: Stefano Rivera, Iain Lane, Micah Gersten, Benjamin Drung, Stéphane Graber === Review of previous action items === micahg to document the zentyal packageset Blocked on https://code.launchpad.net/~stefanor/launchpad/edit-packagesets/+merge/124555 Action carried. laney to delete network-manager packageset Likewise, action carried. laney to contact menesis about schooltool packageset Action carried. We also need to follow up on the netbook/unr/mobile packagesets. === Upcoming meetings === We decided to have a meeting at UDS. Hopefully, there'll be some candidates present. Because 8 October is a public holiday in the US, we'll skip it, and have a meeting on the 15th, which is, conveniently, two weeks before UDS. After which we'll return to the regular schedule (probably skipping a week in the process). === Other Business === Micah proposes creating a docs packageset, he'll ask the potential uploaders. === Next chair === Stéphane Graber Full logs: http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-09-24-14.05.log.html SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [ubuntu/quantal] python-swiftclient 1:1.2.0-0ubuntu1 (Accepted)
Hi Chuck (2012.09.19_02:10:14_+0200)
> python-swiftclient (1:1.2.0-0ubuntu1) quantal; urgency=low
...
> * debian/control: Add X-Python version and ${python:Provides}
> -Depends: ${python:Depends}, ${misc:Depends},
> - python-eventlet,
> - python-httplib2
> +Depends: python-eventlet,
> + python-httplib2,
> + python-keystoneclient,
> + ${misc:Depends},
> + ${python:Depends},
> + ${python:Provides}
Somehow, that reminds me of:
https://lists.ubuntu.com/archives/ubuntu-devel/2012-August/035692.html
The generated dependencies are totally nuts. It's worth eyeballing the
dependencies from a test-build before uploading.
> Depends: python-eventlet, python-httplib2, python-keystoneclient,
> python2.7, python (>= 2.7.1-0ubuntu2), python (<< 2.8),
> python-simplejson, python2.7-swiftclient
SR
--
Stefano Rivera
http://tumbleweed.org.za/
H: +27 21 461 1230 C: +27 72 419 8559
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Simple but worthwhile to fix bugs?
Hi a.grandi (2012.09.09_15:44:08_+0200) > I've followed the instructions and now I've two .deb generated in > /home/andrea/pbuilder/quantal_result/ > but why their name begins with "happycoders" ?! The source package libdbg builds two binary packages: happycoders-libdbg and happycoders-libdbg-dev http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Simple but worthwhile to fix bugs?
Hi a.grandi (2012.09.09_11:51:16_+0200) > but when I execute this: bzr bd --builder=pdebuild > I get the following errors: http://pastebin.com/ytYZxThh > > Please note that I built both "quantal" and "precise" pbuilder targets with: > > pbuilder-dist quantal create > pbuilder-dist precise create > > Am I missing something else? Yes. pdebuild doesn't know how to find pbuilder-dist's tarballs. https://bugs.launchpad.net/bugs/377179 You need to build a source package: bzr bd -S And then build it: pbuilder-dist quantal ../libdbg_1.2-2ubuntu4.dsc SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Hi Loïc (2012.09.07_15:48:53_+0200) > e.g. can an application rely on libgtk-x11-2.0.so.0 to be there or > should it bundle it? It wouldn't make any sense to bundle anything like that. The library's ABI isn't going to change over the life of the stable release. However, (although this is the wrong thread for this, sorry) apps *are* going to need to bundle new third party libraries that aren't in Ubuntu. And then we run into the problem of the third party libraries not being authored by the app author. Even if there isn't a bundled library, there is quite likely to be bundled artwork not authored by the app author. It seems that we have to allow apps to incorporate works with copyright held by third parties, assuming it's released under an appropriate license. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Hi ubuntu-devel (2012.09.06_15:31:14_+0200) > The hooks just run a script provided by another package (in the > archive). It makes the decisions on how to collate things. A (hopefully) clearer attempt to articulate this: We make the extras packages entirely self-contained and namespaced. Then, we provide some machinery outside them that handles collates things across extras packages. If there's some kind of conflict here, (although it should be avoidable), it's not an issue. It just results in a broken extras package. Not broken in a way that stops apt from working. And it doesn't break anything in the Ubuntu archive, only the conflicting extras packages. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Hi Michael (2012.09.06_15:12:40_+0200) > No, but if you have two packages with post-install hooks trying to put a > symlink in the same place, one of them is going to lose. The hooks just run a script provided by another package (in the archive). It makes the decisions on how to collate things. This is a standard practice amongst groups of packages that need similar postinst actions. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Hi Michael (2012.09.05_23:56:04_+0200) > Yes, or we could just allow the direct installation into > /opt/extras.ubuntu.com/share/applications/. But in doing so, we bring > back the possibility for file conflicts because we're not isolating > Extras apps from each other. They aren't conceptually the same. If the file isn't in the package, dpkg isn't going to see it as a conflict, and our collation tool can be smart about it. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
> It's important to remember that when we say "support /opt/ properly"
> what we really mean is "support /opt/extras.ubuntu.com/* properly". We
> aren't just using /opt/ as an install prefix, we making a different
> install prefix for every single application, and that means that every
> tool is going to need to consider every install prefix for every
> application that might be installed.
Can this not be solved with a post-install-hooked script (added by
dh_extras) that collates symlinks to everything in
/opt/extras.ubuntu.com/{appname}/share/applications/{appname}.desktop
in /opt/extras.ubuntu.com/share/applications?
Suddenly we only have one new path to look at. Not n paths.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
H: +27 21 461 1230 C: +27 72 419 8559
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [ubuntu/quantal] python-quantumclient 1:2.0-0ubuntu2 (Accepted)
Hi Adam (2012.08.28_01:35:16_+0200)
> python-quantumclient (1:2.0-0ubuntu2) quantal; urgency=low
>
> * debian/control: Set Provides: ${python:Provides}. (LP: #1042468)
The solution there isn't adding ${python:Provides}. ${python:Provides}
is very rarely needed, and hard to use correctly. It's only useful in
arch-dependant packages that are reverse-dependencies of packages that
don't support all supported python versions. i.e. never :)
The problem (LP: #1042468) was:
Depends: ${python:Provides}
Depending on ${python:Provides} is totally insane. You did notice that
and fix that in the upload, but it wasn't mentioned in the changelog.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
H: +27 21 461 1230 C: +27 72 419 8559
signature.asc
Description: Digital signature
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Automatic import from debian package not found in Ubuntu
Hi Emmanuel (2012.07.11_15:00:38_+0200) > Is it because the package sits in the non-free section of the Debian > Archive ? Is to possible to ask for the package to be imported ? Am > I missing something ? No, it is because it has been sync blacklisted: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt # cjwatson, 2012-06-01 # Temporary blacklist entries for quantal, requiring manual resolution due # to conflicts with existing Ubuntu-versioned binaries. mess If it is correct, and it should be overriding the binary packages from mame, then please raise a bug with the Archive Admins. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Minutes from the Developer Membership Board meeting, 2012-06-04
== Developer Membership Board meeting, 2012-06-04 == Chair: tumbleweed (with help from stgraber) Present: barry Laney micahg stgraber tumbleweed === Review of previous Minutes === * cfalco got his upload rights * zentyl packageset and it's membership team was created * micahg to document the packageset: todo * stgraber to review the freeze process with bencer: in-progress * the membership monitoring script is working again. * cody-somerville and bdrung to vote in early meeting poll: cody still needs to vote === Contributing Developer Juan Negron === Not present, postponed. === MOTU application Jeremy Bicha === Application: https://wiki.ubuntu.com/JeremyBicha/DeveloperApplication Voting: +1 stgraber Laney barry tumbleweed +0 micahg The application is accepted. Action: stgraber to add jbicha to MOTU (done) === AOB === Chair for next meeting: stgraber rodrigo-moya appears expired from ubuntu-dev, tumbleweed pinged him in late April. Received no reply, so we agreed to remove his PPU rights for couchdb-glib and evolution-couchdb Action: stgraber to remove rodrigo-moya's PPU rights (done) SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: dh_python2 and /usr/share/pyshared in quantal
Hi Micah (2012.05.23_04:02:36_+0200) > > Do we really need to break the archive version to figure those out, > > can't we do an archive rebuild of some way using a custom or ppa build? > > An i386 rebuild should be sufficient for this. I'd have thought a grep through the lintian lab would be sufficient? SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Quantal open for development
Hi Colin (2012.05.22_14:30:57_+0200) > MoM is back up and running now, thanks to a variety of folks in IS. Thanks. Now that that's back, here's a list of the packages that haven't been merged in a long time: http://qa.ubuntuwire.org/oldmerges/ Now that it's the beginning of a new LTS cycle, it's a great time to go and do those scary merges that nobody else dares to. :) You probably want to sort by the superseded column. You can see who last touched a package by hovering over the Uploaded column. Note that a couple of the packages near the top of that list (like configure-debian) have odd version numbers, and don't actually have anything to be done. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
A useful tool: seeded-in-ubuntu
Two weeks from release, now that we're pretty much at final freeze, it's worth mentioning a tool we added to ubuntu-dev-tools, last cylcle: seeded-in-ubuntu. If you haven't come across it, yet, here's a brief description: It can be hard to tell whether it's safe to touch a package, when the archive is frozen. The Tasks on binary packages don't corrospond directly to the presence of a package on a CD image. And during freezes, it's the stability of the CD builds that matters. So, we have a job that scrapes the CD build manifests hourly, and creates a database of seeded packages. It also knows about the supported seed, which is unrelated to images. The client for this database is 'seeded-in-ubuntu', in ubuntu-dev-tools. I hope you find this useful during freezes. For anyone who is interested, the database is generated by lp:~stefanor/+junk/ubuntu-seeded-packages SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: XULRunner in 12.04
Hi Chris (2012.04.04_15:01:54_+0200) > Is there a reason the package is not longer there or is this just an > oversight? Intentional. With Firefox's rapid release cycle, we couldn't provide a stable xulrunner for the life of the release. The removal bug [0] hints at this, although it assumes you already knew the background :) [0]: https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9.2/+bug/816377 SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: How to tell a arch-all package to build on specific architecture?
Hi Andreas (2012.02.26_14:05:59_+0200) > by default, arch: all packages are built on the i386 buildds. That is > fine for most packages, but I found one where it isn't, openbios-ppc. > > This needs a powerpc to build on, see https://pad.lv/935018. > > How can one do that in Ubuntu? One can't. That package has never built in Ubuntu. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: syncpackage
Hi Bhavani (2012.02.11_19:16:33_+0200) > (CC'ing the devel list too for any inputs on the standard way of using > syncpackage for sponsoring) Use a newer syncpackage that supports native syncing: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-January/000923.html If you want a suggestion on using it for sponsoring, look at sponsor-patch (again, the latest version in precise). SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Renaming the Packaging Guide
Hi Daniel (2011.11.30_15:37:20_+0200) > http://mdzlog.alcor.net/2010/11/15/ubuntu-project-platform-products/ > > To re-use Matt's words we all are "on the inside" and when we reached > out to new areas to explain what we are doing the confusion about app > development and platform/os/distro development is real. > > In addition to that I think it's worth making use of this as a selling > point: not only can you write applications for Ubuntu, but you can > change the platform/os/distro as well if you need. This will be less > clear to new groups of people we might interest in Ubuntu and we should > try to do our best to invite them in. In that context (and I don't disagree with Matt), yes, this is a Guide for the Ubuntu platform development. So, part of the aim here is to give the guide an unambiguous name for newcomers to Ubuntu Development. It's unambiguous if you've read Matt's 3 Ps, but probably not if you haven't. Maybe the rest of developer.ubuntu.com could benefit from an explanation of the terminology? And (not quite so) subtle hints towards changing Ubuntu ould be spread around? SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Renaming the Packaging Guide
Hi Daniel (2011.11.25_12:23:48_+0200) > I think it might be helpful to rename the Packaging Guide to something a > bit more clear, like Ubuntu Platform Development Guide or Ubuntu > Platform Guide or something along those lines. My get response to this is that I don't like the word "Platform". It makes it sound really big and dull, and says nothing about what to expect in it. An Ubuntu Platform guide could be about Administering Ubuntu. Or it could be a big diagram showing how userspace sits on top of the kernel (oh, we have one of those :) ). But that's not what it is. This is a guide about how to package things, work on packaging, work with our packaging branches, and understand some of our processes. Those are all necessary components for fixing bugs and making changes in Ubuntu. So, to me it's an Ubuntu Development Guide. If I understand correctly, one of the concerns here is that new developers, wanting to ship their apps with/on Ubuntu aren't realising that they can help improve Ubuntu itself. I think the solution there is to have a smaller gap between the "Ubuntu Development" documentation and whatever "stuff on top of Ubuntu" docs we are preparing for them. On the developer.u.c website right now, the packaging guide is hiding under Tools, which is the last place I'd expect to find it. From the 6 categories on the left, I'd probably most expect to find it under the Platform section. But I still don't consider a Platform Guide to be a particularly good name for it. I think it exudes boredom and says little. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: lintian.ubuntuwire.org
Hi Philipp (2011.11.13_14:29:34_+0200) > speaking about LTS→LTS upgrades: do tools like apt-listchanges work with such > stripped changelogs? Shouldn't all changelog entries since the last LTS be > included? I've seen apt-listchanges download changelogs from changelogs.ubuntu.com (apt-get changelog), so I assume it's doing the right thing. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Patch Pilot Report 2011-10-25
Hi Scott (2011.10.26_16:01:15_+0200) > >One tool to rule them all. ;) > It's probably a somewhat archaic view, but that's not a very Unix > like approach to the problem. If I was going to work on syncing a > package, I'd expect the tool for syncing packages to be the one I > wanted to use ... But there's a big overlap in functionality. Reviewing a merge and a sync both require test building, and a having a quick look at the diff and new changelog entries. Also, native syncs can't indicate sponsorship, yet (LP: #827555), so syncpackage isn't much help. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: data.tar.xz support added to Launchpad
Hi Barry (2011.10.25_22:45:23_+0200) > But this makes me think of another question: why didn't the Debian package > have that same Pre-Depends. Extrapolating from Steve's explanation, my guess > is that they don't have the same distro-version restriction setup that we do > (i.e. outside the chroot). > > So what would happen if I just sync'd m2crypto instead of merging it? Would > it still fail without the Pre-Depends? (my guess: yes). This would probably > force me to add the Pre-Depends and upload a 1ubuntu1 version, since we'd be > carrying a delta. Unless i could convince the Debian maintainer to add that > line for us. It wouldn't have any negative consequences for Debian, would it? Yes to all of the above. There were a bunch of missing Pre-Depends in the initial syncs this cycle. They were all caught pretty quickly. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UDS Final Preparation and scheduling
Hi Jorge (2011.10.19_17:18:07_+0200) > - The schedule is starting to populate If, like me, you find the "5 recently added specs" list on Launchpad too short, I whipped up a quick script to monitor spec additions and let you sort them by date added. (It also has an Atom feed) http://corelli.tumbleweed.org.za/ubuntu-qa/specs-by-date/ It saves me having to read the entire list of blueprints every couple of days, when looking for sessions I may want to subscribe to. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Getting new packages into Ubuntu
Hi Micah (2011.10.10_21:52:58_+0200) > I thought ARB was supposed to be lightweight apps, why would these > require (or even be allowed) to include library dependencies? It's not uncommon when packaging new apps to need to package a library or two too. And most upstreams (that don't have distributions in mind) seem to target specific versions of their dependency libraries, and just bundle them with their app, Windows-style (and Java-style). I prepared one app for ARB, and it required a bundled library. That's a single data point, but from my experience elsewhere, not an outlier. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Getting new packages into Ubuntu
Hi Sebastien (2011.10.10_20:34:48_+0200) > What if we made packaging easy enough that upstream code get their > software themself in extras? I think that's a pretty vital requirement for ARB to succeed long term. And sandboxing. Otherwise the review load is monstrous. And yes, ARB has the potential to give a really low submission-to-publication turnaround time, which is a great motivator. > > * Every package needs to be explicitly uploaded to every release. > We might want to target mainly lts versions then for arb? I guess we'll know, once ARB gets up to speed... > > * No obvious approaches to handling security issues or bug reports yet. > How does android or app stores deal with those? I have no idea :) But they haven't necessarily found all the right answers, yet, either. > Do we need to deal with those or can we just treat those as any > software you download from the internet and let users deal with > software writes? When you download something from the software centre, the origin isn't obvious. Currently, I think about the only obvious feedback mechanism is the reviews in Software Center (are those visible on the web anywhere?). By doing this, we are also aligning Ubuntu with these apps, to some degree. People find the quality of the apps in smartphones application stores to be a discriminator between smartphone platforms. I think that'll easily carry over to Ubuntu, and people will measure Ubuntu by the quality of the app store. We don't want as little responsibility as possible. We want to create the best experience for our users and ourselves. > We shouldn't aim at getting libraries in extras, the libraries should be > part of the platform an in the archive itself then. I'm talking about bundled libraries, not library packages. There'll be ARB apps that need libraries that aren't in Ubuntu. (And probably ARB apps that want different library versions to what we ship in Ubuntu). > Well, do you think that letting the universe unfrozen under feature > freeze rules would improve its stability or lower it? I think it would > improve it since we could keep fixing bugs. The only FFes we've turned down have been NEW applications. There haven't been many requests. And yes, I think universe needs time to stabilise like everything else. > Well you would perhaps have run into some issues where you need upgrades > or fixes to the "platform" side and looked at the "main" archive to get > those solved? Or you would have just contributed to extras and reach > users which is a valid contributions as well... In fact I did (python-configobj), and now maintain that library in Debian. But I'm expecting that the ARB solution to that problem would be to bundle the newer library version. Otherwise, would we be expecting ARB to sort out the dependencies as SRUs? SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Getting new packages into Ubuntu
Hi Sebastien (2011.10.10_18:08:16_+0200) > - there are lot of people out there who writer softwares and have no > interest to learn enough about Ubuntu to become a MOTU, they just want > to reach users, they should be welcome to join as well and in a way > which is not to difficult for them I'm still sitting on the fence about ARB in general. I think lowering the barrier to entry for new apps is probably a good idea. It does come with downsides: * We need to divert manpower to packaging these apps. On the other hand, that's volunteer time, and volunteers can work on whatever they want to. * Every package needs to be explicitly uploaded to every release. I imagine that it means that we'll start every release with a relatively empty ARB store, and have a rush to get new apps in. Some will then spend a month or two stabilising. Ubuntu's 6 month release cycle may be too short for this to be an efficient process. * No obvious approaches to handling security issues or bug reports yet. I got a single report for my ARB app, by a user who found the source and hunted me down. (And I haven't dealt with it yet, eep) * It doesn't deal very well with libraries that aren't in Ubuntu. (And with the vague proposal of having a tiny Ubuntu core, main, without universe, this becomes a much larger problem). They need to be bundled with every app. This poses security problems, even if it does make the app author's lives easier. > - you were recently complaining as well about the number of packages > that see one upload and stop being maintained that we have to fix then, > do we want those in the main archive because they attract people or > would they be better suited in extras? Yes, this would help with that. I seem to remember an earlier proposal, where, if an app was still popular after a release or two, it would be strongly encouraged to be included in Universe / Debian. > - locking upstream softwares to our release cycle just don't fit, it's a > best un-natural and create extra work, it often means that users get > outdated softwares or versions that upstreams want to replace That is another reasonable advantage. > One other way would be perhaps to stop freezing universe at release and > to let softwares elvolve in a least strict way... I'm sure there'd be people who'd appreciate that (it sounds rather ports-ish), but I'm already concerned about the stability of Universe as it is (MOTU is rather understaffed right now). Yes, I also got involved in Ubuntu because I wanted to get a (particularly minor) app, and all its dependencies in. I had also been a Debian user for a decade or so, and had always intended to get more involved in the development side of the distributions, so I might have been more naturally drawn in than others. But I'm pretty sure that if ARB had been available then, I would have used it, rather than sticking my nose into #ubuntu-motu and asking where I could help out. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
Hi Barry (2011.10.05_20:35:43_+0200) > Maybe we need to find ways to flag such potentially troublesome syncs early in > the process, so that it's more clear to the developer and/or sponsor. I feel that it should be obvious, if we are actually making any effort to review the sync, beyond "does it build". The changelog normally mentions new packages, and other ABI breakage. And when something is coming from experimental, it should be easy to see if it'll require a transition. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
Hi Scott (2011.10.05_18:23:38_+0200) > When I started a library transition I've always felt it was my job to drive it > to closure. That's certainly what I've always seen people say when asked how transitions were managed in Ubuntu. > If it's not clear that developers are responsible for this, then we ought to > communicate this better (and I include if you sponsor such an upload/sync > then > I think you are on the hook for this, it's not just up to the non-developer > you are sponsoring - hopefully they'll do this, but you (the developer) are > the one responsible). The sponsors not requesting testing and a transition effort commitment is something I've noticed too. I see transition sync requests that I don't look at immediately because they'll need a fair amount of review, and 10 mins later someone has gleefully sponsored them because they build successfully. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Syncing via LP and syncpackage
Hi Andrew (2011.09.24_22:18:32_+0200) > I've noticed that the long awaited Launchpad sync button has shown up > on the +localpackagediffs page. [0] I've also noted that as of 0.129 > the syncpackage script in ubuntu-dev-tools now uses the LP API: ... > Can I start using this? Yes, it hasn't been announced yet, but is mostly safe to use. Please use syncpackage, rather than the web interface, because syncpackage can do more checks (blacklisting, tarball mismatch, overriding Ubuntu delta). There are still issues with this process, which you should be aware of, if using it: https://launchpad.net/bugs/827608 - You aren't credited with the upload, and won't receive build failure e-mail. https://launchpad.net/bugs/827555 - Sponsorees can't be credited for syncs either. https://launchpad.net/bugs/851562 - No diffs of the +queue page for the archive admins to review. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Anyone use massfile? (ubuntu-dev-tools)
We have a script for mass bug filing in Ubuntu Dev Tools, but the interface is ugly and could use improvement. https://bugs.launchpad.net/bugs/145598 Does anyone actually use it? Most automated bug filing I know about is done with custom scripts for the job. I'd rather remove it than let it rot in a corner. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
FFe for build-system changes
Hi, The release team would like to see build-system changes (e.g. dh_python2 transitions) go through the Freeze Exception process. They are are changes that can easily introduce bugs without causing an obvious build failure, and it's a good idea to have them looked over by a second set of eyes. [0] In the case of dh_python2 transitions, a motivation for the transition isn't necessary (it's a release goal), but we'd like to get a chance to preview the changes. As usual, please attach: a debdiff, a buildlog, and debc output. Thanks, SR [0]: https://lists.ubuntu.com/archives/ubuntu-release/2011-August/000328.html -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reminder to update timestamps before sponsoring (or maybe not :))
Hi Micah (2011.07.07_07:44:57_+0200) > >> it in the last 24 hours. One should try to update the timestamp > >> before sponsoring/uploading a package. This can be accomplished with > >> either 'dch -m -r' for sponsoring or just 'dch -r' for one's own upload. > > Why should one do this? > Apparently I thought it was a good idea and was under the impression > that it was widely done With DEBCHANGE_RELEASE_HEURISTIC=changelog, dch won't touch a timestamp while an entry is still UNRELEASED. When it's released (dch -r), often by a sponsor, the timestamp is updated. In debdiff / merge proposal reviews, if there are a few rounds of review, the timestamp can get very out of date. Sometimes by months. It's also quite common for sponsorees to edit the changelog without dch, and thus not bump the timestamp. sponsor-patch touches timestamps before uploading. I do it in my sponsorship in Debian (team and single-maintainer) too. > This seems counterintuitive to see something uploaded on a certain > date, but dated much before then. Yeah, I thank that's a pretty good reason to bump it. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Toolchain-related FTBFS Jam today
We have a fairly high number of FTBFS packages in the archive at the moment, a good chunk of them due to toolchain changes (the linker in particular). As Nigel announced on the Planet [0], we're having a jam to try and fix a bunch of them. Come and join us in #ubuntu-motu today (or for the rest of the week), and get a few more packages building. We've picked a bunch of no-add-needed and as-needed issues to work on [1] [0]: http://nigelb.me/ubuntu/2011/07/27/fix-ftbfs-jam.html [1]: http://corelli.tumbleweed.org.za/ubuntu-qa/bugjam/ I see someone already started last night \o/ In total, it looks like around 200 packages failing to build [2], although there has been some decent progress since I started keeping an eye on it [3] [2]: http://qa.ubuntuwire.com/ftbfs/ [3]: http://corelli.tumbleweed.org.za/ubuntu-qa/qa-ftbfs/oneiric-historical.html For more details on these issues, see [4] and [5]. [4]: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition [5]: http://wiki.debian.org/ToolChain/DSOLinking SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: "Ubuntu Packaging Guide"
Hi Scott (2011.06.03_15:51:00_+0200) > you'll find no mention of the 'normal' tools and processes that I (and > I believe most) Ubuntu developers use. I think it's useful to develop documentation aimed at where we want to be, a little more than where we are, as the documentation takes a while to mature. However, I agree that the documenting the "normal" tools is entirely necessary. You can't understand Debian packaging well, without understanding the processes it was designed for. In the beginning, when you don't have a clue what you are doing, having simple abstractions can help a lot. But soon enough, the packager will need to understand the concept of source packages and all the tools for dealing with them. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Missing panel items (was Re: Default Desktop Experience for 11.04 - User testing results)
Hi Alin-Andrei (2011.04.18_15:11:29_+0200) > For the CPU and memory usage you can use System Monitor Indicator [1] Thanks, I'll look at that. I'd considered writing something similar, but appindicators are supposed to be simple mono-colour icons rather than graphs, so I waited to see what else would appear :) In reply to Dustin: > Shameless plug here, but Byobu supports monitoring everything > system-monitor does Yeah I spend a fair amount of my time in terminals, but mostly connected over ssh to remote screens. screen-in-screen gets a bit much :P SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Missing panel items (was Re: Default Desktop Experience for 11.04 - User testing results)
Hi Barry (2011.04.18_15:02:06_+0200) > * The weather notifier is missing. I really like this little notifier so I > know when to throw open the windows and get some fresh air! Having a configurable date format would also be really nice. > * System monitor. I like this little applet because it gives me a quick way > to take the pulse of my system. How hard it's running, is there a lot of > network activity going on, etc. Really really miss that. My laptop's fan volume is a poor substitute for system-monitor. I feel blind without it. > * Force quit. Some times you just need it and a kill -9 just isn't easy to > get to. The force quit dialog that pops up a few seconds after you've tried to close a non-responsive window usually does the trick for me. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Analysis of Python 2.7 support in Natty
Hi Stephan (2011.02.04_10:51:04_+0200) > I don't think we are dropping Python 2.6 from the archives, I hope it > will just be demoted from Main to Universe, so packages (!main) which > are still depending on 2.6 will build in universe without problems. Unfortunately, it's not that simple. The python-defaults package needs to know which pythons are supported. python-support and -central also need to (IIRC). Packages don't depend on 2.6, they just build with all available versions, and that means if they have C extensions, they'll depend on libpython2.6. It wouldn't be *impossible* to implement what you suggest, but I can't see it being easy. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Analysis of Python 2.7 support in Natty
Hi Soren (2011.02.04_01:58:26_+0200) > I understand it, any such package will prevent installation of the > python2.7 package (since it will fail to bytecompile for 2.7)? I thought that was a soft failure. You get an error, and you can't really use that library with 2.7, but everything else is ok. More to the point, C extensions specifically Depend on python << 2.7 if they were built for 2.6 and not 2.7. dh_python2, with its in-package symlink farm, has the same issue. These would all have to be rebuilt. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: continuing conversation from UDS-N - Application Review Board
Hi Barry (2010.11.15_17:17:01_+0200) > A good way to think about it is that an "application" (i.e. the command you > execute) is just the tip of the iceberg on top of a rich library that could be > useful to others. I'm thinking about examples like 'bzr' and 'bzrlib' which > were explicitly designed to work that way, to great benefit. I agree with applications that have an API that's designed to be consumed by others. Of course that requires a little more generalisation in the design. Not *all* applications should have private modules, and you shouldn't have to hack sys.path to get access to a library you need, but most apps have no need to put themselves in the public namespace. Especially the kind of apps that ARB is intending to distribute. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: continuing conversation from UDS-N - Application Review Board
Hi Allison (2010.11.11_04:25:40_+0200) > Let us know of any changes (anything I missed, or that doesn't seem to > accurately reflect the discussions). We'll try to finalize it next week. Hi, some Python-related questions: > * There is no support in Quickly, python-distutils-extra, > python-distutils, and python-support for installing Python binaries > and libraries in /opt. Why not just use python-support/dh_python2's private-module mode? This is what most applications should be using, anyway, rather than polluting the public Python module namespace. I mean --install-lib=/opt/extras/$packagename, and then tell pysupport/dh_python2 to look for modules there. This does mean that the package will automatically install a /usr/share/python-support/$packagename.private, or /usr/share/python/runtime.d/$packagename.rtupdate for dh_python2. While this is outside /opt, it shouldn't result in clashes, as package names have to be unique, anyway. Doing this will result in byte-compiling on install, and re-byte-compiling when the system default Python version changes. It only supports .pyc files for one python version at a time, but for applications (as opposed to libraries) this is all that is required. > To increase the separation of extras from regular applications, files > installed outside /opt will be required to either prepend "extras" to > their name (e.g. "extras-.desktop"), or to add "extras" to > their path (e.g. "/usr/lib/python2.6/extras/..."). I don't see why ARB packages should be installing modules into the public python namespace, even withinin an "extras" module. ARB is supposed to be for applications, not libraries, right? > Quickly will include a python_path to work with Python libraries > installed in /opt/extras/lib. Why is that necessary, shouldn't ARB packages be self-contained? > Quickly will automatically perform name-mangling on .desktop and panel > files after Natty, until system packages support these files living in > /opt. Can we go one step further and automatically generate the software-centre metadata for the binary control file, from the installed .desktop file (assuming only one). This looks like something that could be done by pkgbinarymangler. I packaged up a pyweek game for ARB [1] and noticed a couple of other things installed outside /opt that don't seem to be covered by exceptions: /usr/share/doc/$packagename /usr/share/lintian/overrides/$packagename [1]: https://launchpad.net/bugs/675033 Not a serious issue, but what about icons? With an absolute filename for the icon, the application either can only install a 48x48 icon or an svg, rather than taking advantage of the hicolor theme. I noticed a couple of issues with the ARB documentation. It's unclear about whether the application is filed on a wiki page with an-email to the ARB list or as a bug. Can this be cleared up? Other minor bits I'll fix / improve myself: * Lack of dh7 examples, * The deprecated XB-Ppython-Version appearing in examples SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
