| jayvee | zul: ping | 01:00 |
|---|---|---|
| zul | jayvee: pong | 01:00 |
| jayvee | zul: I was told to ping you with regards to a bug report of mine | 01:02 |
| jayvee | actually, looks like I got a response from somebody else, but this is it: https://bugs.launchpad.net/libvirt/+bug/528934 | 01:02 |
| zul | jayvee: ok whats the bug report? | 01:02 |
| ubottu | Launchpad bug 528934 in libvirt "IPv6 shouldn’t be disabled by default in libvirt" [Wishlist,Triaged] | 01:02 |
| zul | can you attach the upstream bug report to it? | 01:03 |
| jayvee | zul: just done | 01:05 |
| jayvee | I was sure that I’d done it before, but I guess I mustn’t have. | 01:05 |
| zul | thanks | 01:06 |
| jayvee | I presume you’re ~zulcss on Launchpad? :) | 01:06 |
| zul | yep | 01:07 |
| getxsick | anyone around? | 01:47 |
| persia | !ask | 01:48 |
| ubottu | Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) | 01:48 |
| getxsick | i'm reading that Ubuntu Policy and it's written about different package versioning schemes (Ubuntu uses ubuntuX). well, i just downloaded the source via apt-get source and what i see in debian/changelog, there is no that ubuntuX | 01:49 |
| funkyHat | getxsick: use dch -i to update the changelog, it will add an entry with the correct version number | 01:50 |
| persia | Which version do you have, for which package? | 01:50 |
| getxsick | persia: i'm updating scripts for pypy* packages, because we are releasing 1.2 version | 01:52 |
| getxsick | the last time we did it for long time ago and it was for Debian | 01:52 |
| persia | getxsick: Seems like Ubuntu is using the Debian source of that unmodified. | 01:52 |
| getxsick | persia: possible | 01:52 |
| persia | That's why you find that versioning. | 01:53 |
| getxsick | persia: at least, we are not really interested in supporting Debian, we would like to use launchpad PPA... | 01:53 |
| persia | It also looks like pypy was removed from Debian and that removal was synced to Ubuntu. | 01:53 |
| persia | Oh, then the version doesn't matter at all. | 01:53 |
| getxsick | ah | 01:54 |
| persia | In fact, I recommend using -0ppaN where N is incremented for each rebuild as the revision. | 01:54 |
| persia | But this really isn't the best place to ask about PPA stuff: we don't support PPAs. | 01:54 |
| getxsick | what if we would like to include pypy to next ubuntu release? | 01:54 |
| persia | If you'd like it in Ubuntu, I'll recommend putting it back in Debian: that's the easiest way. | 01:54 |
| getxsick | persia: why? | 01:56 |
| funkyHat | getxsick: because Ubuntu syncs from debian automatically | 01:58 |
| funkyHat | getxsick: also if you submit a package to Ubuntu and later a newer version gets uploaded to Debian that creates more work because someone has to check the the Ubuntu version doesn't have any changes that need to be kept. | 01:59 |
| funkyHat | woo long sentence | 01:59 |
| persia | getxsick: Because of what funkyHat said, and because there are no dedicated maintainers in Ubuntu, so unless something is particularly popular, it usually gets deleted after a while if it's not in Debian. | 02:00 |
| getxsick | we can maintain it, that's not a problem | 02:00 |
| persia | well, except you can't, unless you can continuously convince some developer to upload any changes. | 02:01 |
| persia | Based on past history it usually takes 18-36 months for someone pushing changes to only one package and not otherwise acting as an Ubuntu Developer to be granted upload rights to that package. | 02:02 |
| funkyHat | Also why do you want to leave Debian out? | 02:02 |
| persia | If you can maintain it, why not sign up as the Debian Maintainer. | 02:03 |
| getxsick | persia: actually i don't know, have to check in maling list ;) i just knew that there were some different opinions between us and them ;) | 02:05 |
| persia | Hrm. Depends on the difference of opinion. If it was mainly personal, we may be able to help work around that. If it was technical, we tend to share their opinions. | 02:07 |
| getxsick | persia: it was 2-3 years ago | 02:07 |
| getxsick | anyway, our buildbots run under Ubuntu | 02:07 |
| persia | Things may well have changed. | 02:07 |
| getxsick | persia: sure | 02:07 |
| getxsick | well, i will talk with others what they think about | 02:08 |
| persia | Yeah. I understand the goal is to get it in Ubuntu, and I support that goal, I just happen to think getting it into Debian is the easiest way to get it into Ubuntu and make sure it stays in Ubuntu. | 02:08 |
| getxsick | persia: ok. i understand this point | 02:08 |
| persia | But I'd be happy to help you try to get it into the Ubuntu 10.10 release if you really want, I just have a sense that without sorting the issue with Debian, it would be dropped for 12.04 if not sooner. | 02:09 |
| getxsick | persia: 12.04? :) | 02:09 |
| persia | Yes. | 02:09 |
| getxsick | isn't 2012? | 02:09 |
| persia | We plan things out a fair bit in advance. | 02:09 |
| persia | Yes. | 02:09 |
| getxsick | michael hudson (who is one of the pypy developer) said that it should be included in 10.10 AFAIR | 02:10 |
| getxsick | well, when do you freeze debian unstable for 10.10 ? | 02:11 |
| persia | Based on https://wiki.ubuntu.com/MReleaseSchedule it looks like 24th June. | 02:12 |
| persia | But we can pull new packages until 26th August, if we need, it's just not automatic. | 02:14 |
| getxsick | persia: cool | 02:14 |
| persia | I'd suggest targeting mid-late June, and leaving the rest as a gap for coverage if anything goes wrong. | 02:14 |
| getxsick | we are releasing final 1.2 by the end of March | 02:15 |
| getxsick | so it shouldn't be any problem | 02:15 |
| persia | Cool. | 02:16 |
| funkyHat | I'm looking at the merge report for sensors-applet https://merges.ubuntu.com/s/sensors-applet/REPORT - everything looks great, I'm just running a test build now. But I've found this bug https://bugs.edge.launchpad.net/ubuntu/+source/sensors-applet/+bug/380669 which wants to upgrade to 2.2.5-3 | 02:24 |
| ubottu | Launchpad bug 380669 in sensors-applet "Please merge sensors-applet 2.2.5-3 (universe) from Debian (unstable)" [Unknown,Fix released] | 02:24 |
| funkyHat | Should we upgrade to 2.2.5-3, or only to 2.2.4-2. ...5-3 is only in unstable | 02:24 |
| persia | funkyHat: Which one works better with lucid? | 02:27 |
| funkyHat | persia: I don't know. How do I grab the debian source packages for 2.2.5-3? | 02:28 |
| persia | pull-debian-source works, or visit packages.qa.debian.org and use dget or visit qa.ubuntuwire.com/multidistrotools and use dget or ... | 02:29 |
| * persia tends to open a sid schroot and apt-get source stuff | 02:30 | |
| funkyHat | Ok, building 2.2.5-3 now | 02:31 |
| funkyHat | persia: well I've hit a limitation of using a VM which is I don't have any sensors, so I can't really test properly | 02:37 |
| funkyHat | Other than that I can't see any problems with 2.5.5-3 | 02:39 |
| persia | Then you either need to find some testers, or upgrade :) | 02:39 |
| persia | Given that we're past FeatureFreeze, I'd recommend doing both. | 02:39 |
| funkyHat | I'm going to be buying a wacom tablet soon, and I heard that Lucid didn't support them a while ago... I'll have to investigate whether that's been resolved | 02:40 |
| AnAnt | Hello, could someone grant FFe to LP 530204 ? | 06:53 |
| ubottu | Launchpad bug 530204 in libbasicplayer-java "FFe: Sync libbasicplayer-java 3.0-5 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/530204 | 06:53 |
| AnAnt | especially it also closes LP 491784 | 06:53 |
| ubottu | Launchpad bug 491784 in openjdk-6 "Sound does not work with openjdk" [Undecided,New] https://launchpad.net/bugs/491784 | 06:53 |
| dholbach | good morning | 07:54 |
| jayvee | hmm, no feedback from zooko or his team about the tahoe-lafs package | 08:22 |
| GheRivero | morning | 08:45 |
| wrapster | i have a control file like so.. http://pastie.org/855217 .. which in turn builds a lot of other pakcages.. and i wanted to say that in a particular pkg 'spjadbx' it conflicts with ss12.. So i enter that that pkg declaration and built that pkg..But when i tried installing it.. it fails saying that there is a file present in this pkg as well as another pkg(the very reason why i added conflicts)... and when i open the control file again.. the conflicts | 08:46 |
| siretart | bjsnider: exactly! | 08:59 |
| siretart | debfx: i've just filed a debian bugreport to not forget it! thanks for notifying me | 09:00 |
| === noodles785 is now known as noodles775 | ||
| debfx | siretart: okay, packaging branch should be ready for upload | 10:08 |
| hakaishi | Hi, I’d like to remove qt-shutdown-p from revu, since there is a newer package of it with a new name and is already uploaded to debian. What can I do, who can I ask (to remove it)? | 10:30 |
| hakaishi | Does nobody know? | 10:40 |
| hakaishi | X-P | 10:45 |
| === hannesw_ is now known as hannesw | ||
| falktx | hi there | 11:52 |
| falktx | I've sucessfully send a package to revu and it was accepted | 11:53 |
| falktx | now I need to fix a bug in the package | 11:54 |
| falktx | I've made the needed changes and it's ready for upload | 11:54 |
| falktx | how should I do it? | 11:54 |
| falktx | using 'dput ubuntu *.changes' doesn't work | 11:54 |
| falktx | ideas? | 11:54 |
| geser | let me guess, it complains that's it's already uploaded? | 11:55 |
| geser | dput -f ... | 11:55 |
| falktx | nope | 11:55 |
| falktx | it uploads | 11:55 |
| falktx | then I receive an email saying it was been rejected | 11:56 |
| falktx | message says: "The signer of this package has no upload rights to this distribution's primary archive. Did you mean to upload to a PPA?" | 11:56 |
| falktx | I am the maintainer of the package | 11:56 |
| falktx | I did try now just 'dput *.changes', no mail answer so far | 11:57 |
| falktx | the wiki revu page says I should manage the package through launchpad | 12:00 |
| falktx | but I guess it doesn't allow new uploads (?) | 12:00 |
| falktx | (just got the rejection mail again) | 12:01 |
| falktx | should I upload to REVU again ?? | 12:01 |
| geser | ah, then you are not uploading to REVU but to the official archive | 12:02 |
| geser | "dput revu yourpackage_source.changes" | 12:02 |
| falktx | but I though I could just upload to universe and not going for the revu stuff all over again... | 12:03 |
| falktx | if the package is assigned to me, isn't there a faster way to do this? | 12:04 |
| geser | your package is already part of official archive? | 12:04 |
| falktx | yes | 12:05 |
| falktx | https://launchpad.net/ubuntu/+source/zyn | 12:05 |
| falktx | (this is the first time I do this, please be patient) | 12:06 |
| geser | then you don't need to go through REVU again | 12:06 |
| falktx | - thanks - | 12:07 |
| falktx | so how? | 12:07 |
| geser | create a debdiff with your changes (or alternatively prepare a bzr branch for merging (if you like)) | 12:07 |
| geser | open a bug and attach your debdiff (or link merge proposal) to the bug and subscribe ubuntu-universe-sponsors for sponsoring | 12:08 |
| geser | see also https://wiki.ubuntu.com/SponsorshipProcess | 12:08 |
| falktx | i'll look into that, thanks again | 12:09 |
| porthose | it may need a FFe https://wiki.ubuntu.com/FreezeExceptionProcess | 12:10 |
| geser | not for a fix of a bug | 12:11 |
| porthose | key word *may* :) | 12:11 |
| falktx | thanks guys, you rock! | 12:15 |
| falktx | I created a debdiff, now into sponsorship... | 12:15 |
| === Tonio__ is now known as Tonio_ | ||
| falktx | I'm unsure about what to do next... | 12:28 |
| falktx | https://bugs.launchpad.net/ubuntu/+source/zyn/+bug/532590 | 12:28 |
| ubottu | Launchpad bug 532590 in zyn "Install path is wrong" [Undecided,Confirmed] | 12:28 |
| falktx | should I just wait ? or is it something missing ? | 12:34 |
| === Tonio__ is now known as Tonio_ | ||
| randomaction | falktx: I mean, subscribe the team to your bug | 12:46 |
| randomaction | there's a "Subscribe someone else" link on the right-hand side | 12:47 |
| === Tonio__ is now known as Tonio_ | ||
| falktx | done | 12:51 |
| falktx | thanks | 12:51 |
| === popey_ is now known as popey | ||
| JamieBennett | I'm trying to push a revision of a package up to REVU: http://revu.ubuntuwire.com/p/webservice-office-zoho but its not appearing even though I get a successful upload message. I pushed around an hour ago and still nothing. Any idea's (I signed the package with a different key this time, would that cause problems?) | 13:12 |
| mok0 | JamieBennett: If it's a revision, better do through a bug in LP. | 13:16 |
| mok0 | JamieBennett: because it needs to clear through as an SRU anyway | 13:16 |
| JamieBennett | mok0: sorry, its me not being clear, this is a new package but I made changes to it today and tried to upload | 13:17 |
| mok0 | JamieBennett: ah | 13:17 |
| JamieBennett | Its currently not in the archive | 13:17 |
| === txwikinger2 is now known as txwikinger | ||
| mok0 | JamieBennett: the signing key must be the same as the one you have in LP | 13:18 |
| JamieBennett | mok0: Oh, maybe thats it, I'm not sure if LP has this new key | 13:18 |
| * JamieBennett goes to check | 13:18 | |
| c_korn | hello. the scilab package in lucid is currently broken because the build for amd64 timed out. I added a watchdog process which prints a message every ten minutes (because the compilation just needs some time but it is still going on). do I need a FFe for this change ? | 13:23 |
| c_korn | (would be a new revision to sync from Debian) | 13:23 |
| mok0 | c_korn: yes you would | 13:24 |
| geser | mok0: why a FFe? | 13:24 |
| mok0 | c_korn: because there are new features in a new version | 13:25 |
| geser | mok0: is only a revision bump, no upstream version bump if I understood c_korn correctly | 13:25 |
| mok0 | ah | 13:25 |
| c_korn | new features ? I already got a FFe granted for scilab 5.2.1-3 the new one is 5.2.1-4 which adds the watchdog | 13:25 |
| c_korn | yes, geser is right | 13:26 |
| mok0 | But you need to file a sync request then | 13:26 |
| c_korn | yeah, I just talked to the Debian maintainer. he is currently building it. so I have to wait for the package to be in Debian. | 13:27 |
| c_korn | I thank you | 13:27 |
| mok0 | c_korn: I remember scilab 5.1 had lots of problems compiling etc. Is that better now? | 13:28 |
| mok0 | c_korn: I helped push a bunch of dependencies through AFAIR | 13:28 |
| c_korn | yeah, we required a lot of packages synced from Debian last time. and because we were a bit late we also required a FFe for them. should be easier this time. it already compiled fine in a PPA. just times out on amd64 when building for the archive. | 13:30 |
| mok0 | c_korn: what do you mean "times out"? | 13:30 |
| geser | mok0: if there is no output for 150min the build gets killed | 13:31 |
| mok0 | Weird | 13:31 |
| mok0 | What is it waiting for? | 13:31 |
| c_korn | yeah, and the compilation of the docs is "slow like hell" :) | 13:31 |
| c_korn | mok0: it is not waiting. it is compiling. it is java :) | 13:32 |
| geser | either the build is bugged or a very long running process (which is it in this case) | 13:32 |
| c_korn | it just takes some time. 4h in a PPA: https://launchpad.net/~getdeb-package-managers/+archive/ppa/+build/1527822 | 13:33 |
| c_korn | the build for the archive times out after 3h: https://launchpad.net/ubuntu/+source/scilab/5.2.1-3/+build/1525155 | 13:33 |
| StevenK | The PPA builds are slightly faster, I think | 13:38 |
| geser | btw: does somebody know if ghc6 on armel is still building (for over a week now) or stuck? | 13:39 |
| lan3y | probably stuck :( | 13:41 |
| lan3y | wait what is this nick | 13:41 |
| === lan3y is now known as Laney | ||
| ogra | its unlikely that you have packages that build a week ... even on armel | 13:41 |
| Laney | it took 6 days on debian | 13:42 |
| Laney | but yeah i would expect it to have done by now | 13:43 |
| ogra | Laney, what kind of armel builders does debian use ? we have 800MHz/512MB machines | 13:47 |
| ogra | ubuntu builds should be generally a bit faster than debian ones | 13:47 |
| Laney | ogra: http://db.debian.org/machines.cgi?host=ancina http://db.debian.org/machines.cgi?host=arcadelt http://db.debian.org/machines.cgi?host=argento | 13:49 |
| Laney | there must be some other difference that makes the build hang on Ubuntu but not Debian :( | 13:50 |
| ogra | debian doesnt optimize for ARMv7 | 13:50 |
| ogra | we use v7 and thumb2 optimizations | 13:51 |
| ogra | sad there is no cpuspeed info on the pages | 13:51 |
| Laney | you could check in #debian-arm | 13:53 |
| bjsnider | siretart, you're the ffmpeg expert, not me, but isn't the 0.5.1 code actually older than what is in karmic? | 13:58 |
| JamieBennett | still no luck with REVU. I've added my key to launchpad, is there a delay before it works with REVU? | 14:02 |
| JamieBennett | are there any admins around to poke REVU and see whats happening for me? | 14:10 |
| mok0 | JamieBennett: All I can see is that you have a rejected upload at 15:01 | 14:11 |
| JamieBennett | mok0: does it say why it was rejected? | 14:12 |
| mok0 | No | 14:12 |
| mok0 | JamieBennett: Nothing I know about, anyway | 14:13 |
| mok0 | But it very likely has to do with your gpg key changes | 14:13 |
| JamieBennett | mok0: Shame, I'm getting a 'Successfully uploaded packages.' message. Maybe its a key propogation problem, my key is in launchpad, maybe there is some delay? | 14:14 |
| mok0 | JamieBennett: Indeed there is | 14:14 |
| JamieBennett | mok0: OK, I'll leave it for a while, thanks for the help so far. | 14:15 |
| mok0 | JamieBennett: NP | 14:15 |
| JamieBennett | and as that is said, the package magically appears this time :) | 14:15 |
| ogra | :) | 14:16 |
| mok0 | Ah, patience is a virtue | 14:17 |
| JamieBennett | mok0: bah | 14:17 |
| JamieBennett | ;) | 14:17 |
| mok0 | That said, can anyone tell me why I'm getting two different popup notification every time? | 14:17 |
| mok0 | Because it annoys the hell out of me... | 14:17 |
| JamieBennett | ls | 14:18 |
| * JamieBennett is having one of them days | 14:18 | |
| mok0 | No files found | 14:18 |
| hakaishi | Hi everyone! Could someone tell me how a package from Debian gets into the Ubuntu sources? | 15:15 |
| hggdh | usually it is via a sync request | 15:17 |
| hakaishi | hggdh: and where could I do that? | 15:23 |
| hggdh | hakaishi: please see https://wiki.ubuntu.com/SyncRequestProcess | 15:25 |
| hakaishi | cool, thank you | 15:25 |
| mok0 | hakaishi: bear in mind that we are now in FF, and syncs will only happen if they fix bugs | 15:26 |
| nigelb | hakaishi: if its something for lucid, please see https://wiki.ubuntu.com/FreezeExceptionProcess too | 15:26 |
| hakaishi | Since my packages only got uploaded to debian, it'll take some time till I can do a sync request... | 15:28 |
| donkyhotay | can someone help me figure out why my package isn't showing up in revu? I followed the instructions at https://wiki.ubuntu.com/MOTU/Packages/REVU including logging in, uploading GPG key and using dput. Didn't get any errors or messages but it hasn't shown up yet. | 15:32 |
| hakaishi | donkyhotay: did you get an e-mail for successfully uploading? - If not it would be something wrong with your dput.cf | 15:37 |
| donkyhotay | I didn't get a confirmation Email, I didn't change my dput.cf since it sounded like the default file on a standard karmic would work so long as I used "dput revu filename_source.changes" which I did | 15:39 |
| hakaishi | donkyhotay: please look at https://wiki.ubuntu.com/MOTU/Packages/REVU | 15:41 |
| === Tonio__ is now known as Tonio_ | ||
| donkyhotay | As I mentioned before, I followed the instructions on that page. I even checked my dput.cf file and confirmed it has the revu entry the wiki says is preconfigured from 6.06 and on | 15:43 |
| hakaishi | donkyhotay: and dput did the upload without any warnings/errors? - That's strange... Then I don't know how to help you, sorry -.-' | 15:46 |
| donkyhotay | Yeah, thats the part that confuses me. I did everything exactly, dput gave me no warnings or errors. Confirmed my key was uploaded, even redid the package to confirm dpkg-buildpackage wasn't giving my warnings of this being unsigned (which I did get earlier but have since resolved) | 15:47 |
| hakaishi | mok0: From which Debian version will the packages be included into the new Ubuntu version? (I'll have to do the sync request till the next DebianImportFreeze, right?) - Will it be sid, or squeeze? | 15:49 |
| mok0 | hakaishi: for lucid, it is testing | 15:50 |
| mok0 | hakaishi: normally, it's unstable | 15:50 |
| mok0 | (Lucid is a LTS release) | 15:50 |
| mok0 | hakaishi: So for lucid+1, the sync will be from unstable. It will get synced automatically when the cycle starts | 15:51 |
| mok0 | hakaishi: therefore, if the sync you request is for lucid+1, there's no need to do anything | 15:51 |
| hakaishi | mok0: okay, thank you for your help^^ | 15:52 |
| mok0 | hakaishi: my pleasure .-) | 15:52 |
| donkyhotay | Oh wait... my old key is the one currently registered? I thought I checked that... Well I feel a little silly now. I think I found the problem. | 15:52 |
| hakaishi | donkyhotay: then I'll wish you goog luck ;) | 15:53 |
| hakaishi | *good | 15:53 |
| donkyhotay | I'm updating my keys, should work this time around. | 15:54 |
| hakaishi | mok0: There is still one more thing I'm wondering about. If my packages from sid get into lucid+1, will I have to upload them into sid+1 to get the packages into lucid+2 again? | 15:56 |
| mok0 | hakaishi: once the package is in Debian, it will be synced for every Ubuntu release | 15:57 |
| mok0 | hakaishi: so if you maintain your package in Debian (sid) all is dandy | 15:57 |
| hakaishi | mok0: cool XD, thanks again^^ | 15:57 |
| hakaishi | bye bye ;) | 15:59 |
| hyperair | any archive admin around? | 16:09 |
| hyperair | bug #529340 could use some love | 16:09 |
| ubottu | Launchpad bug 529340 in taglib-sharp "FFe: Sync taglib-sharp 2.0.3.6+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/529340 | 16:09 |
| lightnin | Is there a debhelper script that installs / registers .desktop files? | 16:14 |
| lightnin | or do I just use dh_install desktop_file /usr/share/applications? | 16:15 |
| === plopplop is now known as Tonio_ | ||
| hyperair | lightnin: the latter. | 16:20 |
| hyperair | lightnin: a dpkg trigger from one of the packages will register it. | 16:21 |
| sebner | lightnin: you might want to use a .install file though | 16:21 |
| lightnin | hyperair:Thanks! How do I go about making a "dpkg trigger" happen? | 16:22 |
| hyperair | lightnin: just put the file in /usr/share/applications, it'll trigger automatically. | 16:28 |
| donkyhotay | Yep, outdated GPG key was definitely my problem as my package is now on revu. Now I just need to wait for some MOTU's to check out my game and either advocate it or tell me whats wrong with. (c: | 16:29 |
| vincs | Hi. | 16:29 |
| lightnin | cool. Do I need to run "gtk-update-icon-cache"? It's in my postinst script, but it seems like it's not needed if I've installed the desktop file (and it breaks in KDE) | 16:30 |
| hyperair | i'm not sure | 16:30 |
| vincs | When debian/watch file is used, do a get-orig-source rule is needed in debian/rules file ? | 16:31 |
| sebner | hyperair: will you wait for banshee 1.5.5 until updating? | 16:35 |
| hyperair | sebner: i'm waiting for taglib-sharp. our archive-admins are asleep, i think? | 16:36 |
| hyperair | sebner: at the rate we're going, it's better to wait for 1.5.5, yeah. | 16:36 |
| hyperair | sebner: assuming taglib-sharp gets in before 1.5.5 appears. | 16:36 |
| sebner | hyperair: I guess, it's nearly weekend after all. Wondering if some update will fiXX0r my crashes/halt whatever | 16:37 |
| hyperair | sebner: taglib-sharp's been like that all week. | 16:37 |
| hyperair | hmm maybe it's because i forgot to remove the FFe tag | 16:37 |
| hyperair | sebner: http://www.facebook.com/video/video.php?v=101470883219048 | 16:38 |
| hyperair | er shit | 16:38 |
| hyperair | https://bugs.launchpad.net/ubuntu/+source/taglib-sharp/+bug/529340 | 16:38 |
| ubottu | Launchpad bug 529340 in taglib-sharp "FFe: Sync taglib-sharp 2.0.3.6+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] | 16:38 |
| hyperair | stale clipboards ftl. | 16:38 |
| sebner | heh | 16:38 |
| sebner | hyperair: nah, we just have to wait. Or you bug the archive admin which is on duty today | 16:39 |
| hyperair | sebner: who? | 16:39 |
| hyperair | sebner: (and the facebook video is pretty funny all the same, if you feel like viewing it) | 16:39 |
| sebner | hyperair: jdstrand | 16:39 |
| hyperair | sebner: how do you tell? | 16:39 |
| sebner | hyperair: nvm, I'm not at facebook | 16:39 |
| hyperair | heheh | 16:40 |
| sebner | hyperair: https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days | 16:40 |
| hyperair | ah cool | 16:40 |
| lightnin | Should I use dh_installmime to install xml files describing new mimetypes? Seems like it must be in /debian directory for this to work, but mimetype .xml file is in upstream tarball... | 16:48 |
| vincs | When debian/watch file is used, do a get-orig-source rule is needed in debian/rules file ? | 16:50 |
| randomaction | vincs: it's a good idea if there's no tarball that corresponds to the current state of the package (e.g. it's a snapshot or it was repackaged) | 16:56 |
| vincs | It is a new package (not in debian or ubuntu). | 16:57 |
| vincs | But the tarball is in upstream. | 16:58 |
| randomaction | if the tarball for the version you're packaging can be obtained from upstream, there's no need for get-orig-source rule | 16:58 |
| vincs | Ok. Thanks for your reply. | 17:00 |
| hyperair | lightnin: the stuff in /usr/share/mime is debian-specific | 17:04 |
| lightnin | hyperair: Oh, ok, so it doesn't really need to be in upstream tarball. I guess it doesn't hurt to be there though. (Btw- I am upstream and packager...) | 17:05 |
| mok0 | hyperair: can you help me out? | 17:07 |
| hyperair | mok0: what's up? | 17:08 |
| mok0 | hyperair: bug 489845 | 17:08 |
| ubottu | Launchpad bug 489845 in karmic-backports "Please backport codelite" [Undecided,Incomplete] https://launchpad.net/bugs/489845 | 17:08 |
| mok0 | hyperair: What version is in lucid? | 17:09 |
| hyperair | codelite | 1.0.2893+dfsg-0ubuntu2 | karmic/universe | source, amd64, i386 | 17:10 |
| hyperair | codelite | 2.2.0.3681+dfsg-0ubuntu1 | lucid/universe | source, amd64, i386 | 17:10 |
| mok0 | yes just got that | 17:10 |
| mok0 | hyperair: is it relevant to backport it? | 17:11 |
| hyperair | mok0: i suppose so. there weren't many packaging changes. i think it can be ported directly. | 17:11 |
| hyperair | mok0: i haven't testbuilt it though | 17:11 |
| mok0 | hyperair: I can do that | 17:11 |
| mok0 | hyperair: don't think it will be a problem, there aren't many toolchain changes | 17:12 |
| hyperair | mok0: please do, then. i have to drag my ass out the door (and walk back to my hostel) pretty soon =) | 17:12 |
| mok0 | hyperair: right, thnx | 17:12 |
| mok0 | See you | 17:12 |
| hyperair | mok0: not yet, but soon enough that i can't finish a testbuild ;-) | 17:13 |
| hyperair | mok0: i own a pretty modest dual core machine, see | 17:13 |
| mok0 | hyperair: don't I know it? It takes forever... | 17:13 |
| mok0 | :) | 17:13 |
| jdong | lol I just found out to my dismay that this new cluster I have access to is a lie. | 17:14 |
| hyperair | mok0: yep. it was the first compilation that managed to overheat and shutdown my notebook =p | 17:14 |
| jdong | it claims to be octo 3.06 xeon with 24G of RAM | 17:14 |
| jdong | but apparently is all running virtualized. | 17:14 |
| mok0 | hyperair: great package to choose for maintenance, then ;-) | 17:14 |
| jdong | was kinda surprised when python took longer to ./configure there than build locally. | 17:14 |
| mok0 | jdong: hehe | 17:15 |
| hyperair | mok0: hehehe. i learnt my ^Z trick then ;-) | 17:15 |
| jdong | hyperair: haha I have a script called heatlimit.py here | 17:15 |
| jdong | that monitors ACPI thermal zones and throttles tasks based on temp. | 17:15 |
| hyperair | jdong: that's made of win. =p | 17:15 |
| jdong | stupid laptops. | 17:16 |
| jdong | :) | 17:16 |
| hyperair | jdong: i went the phc way. | 17:16 |
| hyperair | jdong: undervolted my CPU, and cut the temperature by 20 degrees celcius =p | 17:16 |
| jdong | I should just open up the stupid thing and blow it out with some compressed air | 17:16 |
| jdong | it's just dust clogging up the fan. | 17:16 |
| jdong | too lazy. | 17:16 |
| hyperair | oh that's your case eh? | 17:16 |
| hyperair | my fan is clean. | 17:16 |
| hyperair | it overheats anyway | 17:17 |
| jdong | ah ,ouch | 17:17 |
| hyperair | overheated* | 17:17 |
| hyperair | and the stupid thing is that it never generates enough heat when i want it to. | 17:17 |
| hyperair | i was feeling particularly cold in this air-conditioned room earlier, and started a kernel compilation, turned off phc, and it didn't go past 60 degrees. | 17:17 |
| jdong | hahaha | 17:18 |
| * hyperair sighs | 17:18 | |
| jdong | one of my friends keeps a quad-core P4 Xeon in his room for that purpose. | 17:18 |
| hyperair | heheheh | 17:18 |
| jdong | he's told me that he tripped a circuit breaker with folding@home once. | 17:18 |
| jdong | whoops bet that didn't help with heating :) | 17:18 |
| hyperair | heheheh | 17:18 |
| hyperair | yeah, i can imagine | 17:18 |
| lightnin | Hmm... I don't seem to be able to make my binary package register it's new mime filetype on the target system. dh_installmime doesn't seem to do it... | 17:20 |
| sebner | hyperair: syncs are processed in some hours so we might be lucky ones just before weekend ;D | 17:28 |
| hyperair | sebner: cool | 17:29 |
| vincs | I have reupload my fisrt package in REVU. REVU shows now no warning or common error. Do new packages are processed in a certain order or do I need to ask for an first person to advocate ? | 17:39 |
| ScottK | vincs: We are past feature freeze for Lucid, so reviewing new packages is a low priority at the moment. | 17:41 |
| vincs | ScottK: I know but as I am new at packaging and I would like to upload 4 packages for lucid+1. I start early. | 17:44 |
| ScottK | OK, as long as your expectations aren't high .... | 17:48 |
| vincs | No. If someone comments my package early I will make the necessary changes. If not, I will wait. | 17:51 |
| === yofel_ is now known as yofel | ||
| === andreas__ is now known as ahasenack | ||
| lightnin | If I need to run update-mime-database after registering a new filetype for my application, should I declare it as a dependency? It doesn't seem to come with kubuntu... | 18:39 |
| randomaction | yes | 18:48 |
| randomaction | you can use dh_installmime, which adds necessary fragments to maintainer scripts and adds necessary packages to ${misc:Depends} | 18:49 |
| === jono_ is now known as jono | ||
| funkyHat | I've attached a compiled .deb for sensors-applet 2.2.5-3 to https://bugs.edge.launchpad.net/ubuntu/+source/sensors-applet/+bug/380669 | 19:29 |
| ubottu | Launchpad bug 380669 in sensors-applet "Please merge sensors-applet 2.2.5-3 (universe) from Debian (unstable)" [Unknown,Fix released] | 19:29 |
| funkyHat | Don't know if that is a normal thing to do but it was suggest I find testers for the new version. | 19:29 |
| funkyHat | I suppose a 32bit version would probably be helpful too | 19:30 |
| siretart | bjsnider: no, but how do you come to this opinion? | 19:54 |
| bjsnider | siretart, i tried building the 0.5.1 release in pbuilder using the build scripts for the karmic ffmpeg. the result failed because the vhook stuff was still there. but the build scripts do not contain the --disable-vhook flag, and the reason is that the vhook code isn't in the karmic version. i then explicitly asked the ffmpeg devs in that channel when vhook was removed from the code and they gave me an exact date: march 3 2009. i then asked if the | 20:06 |
| bjsnider | rest of the 5.1 release is at least that old and the answer was: yes. | 20:06 |
| superm1 | siretart, are you aware that mplayer FTBFS right now? | 20:08 |
| siretart | superm1: no, but I'm aware that I really should revisit and finally upload the local changes to the package I have on my laptop | 20:08 |
| superm1 | siretart, indeed :) I was considering looking into the FTBFS but figured its better to check with you first and not trump what you might have going on | 20:09 |
| siretart | superm1: anyways, why does it ftbfs? | 20:10 |
| bjsnider | it pulls in nvidia-current because of the build-depends on nvidia-xxx-libvdpau | 20:10 |
| siretart | bjsnider: the version between the version in karmic and 0.5.1 should be pretty close. the difference is mainly that many patches that were in karmic got committed upstream for 0.5.1 | 20:10 |
| superm1 | siretart, libmp4codec/ve_264.c or something like that (i dont have the log handy) | 20:10 |
| bjsnider | easy to fix | 20:10 |
| mok0 | jdong: ping | 20:11 |
| bjsnider | siretart, i just downloaded the tarball. maybe i got older code | 20:11 |
| siretart | bjsnider: check the diffstat: http://wiki.tauware.de/~siretart/ffmpeg/diffstat.txt | 20:13 |
| bjsnider | siretart, but your version doesn't have the two soname changes int he recent code | 20:16 |
| bjsnider | and also, they told me there's a .6 release coming this month | 20:16 |
| bjsnider | i guess that isn't enough time to get it into lucid | 20:16 |
| sistpoty | no | 20:17 |
| siretart | bjsnider: or you can check the diff here: http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=shortlog;h=refs/heads/upstream-0.5 | 20:17 |
| * sebner waves as sistpoty :D | 20:18 | |
| siretart | bjsnider: no, 0.5.1 does not introduce any soname change. We need versioned symbols deployed before we can do that | 20:18 |
| sistpoty | huhu sebner | 20:18 |
| siretart | hey sistpoty! | 20:18 |
| sistpoty | hi siretart | 20:18 |
| sebner | sistpoty: In 4 Tagen hab ich Grunzüge der Informatik Wiederholungsprüfung. Wäre recht mal anfang zu lernen xD | 20:18 |
| sistpoty | sebner: better do that than ;) | 20:19 |
| sistpoty | then even | 20:19 |
| sebner | sistpoty: b000000000000ring :P | 20:19 |
| sistpoty | heh | 20:20 |
| siretart | sebner: 2nd or 3rd try? | 20:22 |
| bjsnider | siretart, did you have to explicitly disable vhook in the 5.1 build? | 20:22 |
| sebner | siretart: 2nd or course :P well, if I'm that lazy again it might turn out in a 3rd one xD | 20:23 |
| siretart | bjsnider: vhook is disabled since ffmpeg-debian_0.svn20080925-1 | 20:25 |
| siretart | bjsnider: so that's no change since karmic AFAIUI | 20:25 |
| bjsnider | i couldn't find that build flag in the confflags file or the rues file | 20:25 |
| sebner | siretart: unless you wanna give me a hand :P | 20:27 |
| siretart | bjsnider: debian/confflags, line 75 | 20:27 |
| bjsnider | strange | 20:29 |
| siretart | don't horrify me like that | 20:29 |
| siretart | ;-) | 20:29 |
| bjsnider | it's not in these build scripts i'm using | 20:30 |
| bjsnider | where did i get them | 20:30 |
| * siretart points bjsnider to http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=summary | 20:34 | |
| blueyed | "bzr branch lp:ubuntu/apport" does not result in the current sources. By design? | 21:02 |
| geser | probably an error during package import into bzr | 21:07 |
| geser | yep, see http://package-import.ubuntu.com/status/apport.html#2010-02-22%2011:47:45.304032 | 21:09 |
| jpds | lolsiretart . | 21:10 |
| siretart | jpds? | 21:25 |
| jpds | siretart: See log above. ;) | 21:25 |
| siretart | oh, seems I'm holding some lock :-) | 21:26 |
| * siretart passes a lock to jpds | 21:26 | |
| * jpds hugs siretart. | 21:26 | |
| siretart | :-) | 21:27 |
| blueyed | oh.. is there no more reasonable automatic timeout? | 21:36 |
| james_w | blueyed: you want lp:apport for the moment | 21:39 |
| blueyed | james_w: thanks, I've used the line from "apt-get source apport" already. | 21:39 |
| sebner | christoph_debian: persia: I'm going too FFe sync supertux, are you ok with that? (Uhm, I already filed the bug though ^^) | 21:41 |
| persia | sebner: Always. Except where freezes get in the way, the Games Team likes to be in sync. | 21:42 |
| sebner | persia: Great :) | 21:42 |
| === sistpoty changed the topic of #ubuntu-motu to: Feature Freeze in effect | Lucid Alpha 3 Released! | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://is.gd/2y76G | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS/ | http://qa.ubuntuwire.com/debcheck | latest rebuild failures: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi | Outstanding merges: merges. | ||
| sebner | persia: haha, new record for me. 16 minutes until FFe granted and archive admins subscribed :D | 21:58 |
| persia | sebner: Clearly you have some work to do. | 21:59 |
| sebner | persia: hmm? rationale, changelog, buildlog, installing + screenshot all done | 21:59 |
| persia | sebner: You might want to start digging into RCbugs. At this point none of them need FFes, but once the freeze gets firmer, we end up needing release approval for every upload. Building a background in RCBug work should get your turnaround time down to a minute or two once we get there. | 22:00 |
| persia | sebner: The work is on reducing the 16 minutes, not on that bug :) | 22:00 |
| sebner | persia: ah sure, but I might wait until next week (some important exam on tuesday and still a lot to learn) | 22:01 |
| persia | Of course. $study (like $life and $work) must necessarily take priority over Ubuntu, else you'll burn out and be unable to help. | 22:01 |
| sebner | persia: heh, I have to defend myself. Building supertux took surely ~5-10 minutes :P | 22:03 |
| sebner | persia: http://qa.ubuntuwire.com/bugs/rcbugs/ is still the place to start right? | 22:05 |
| persia | sebner: If that's not the place to start, complain loudly. | 22:06 |
| persia | sebner: If something is wrong, the most likely thing would be that it's still targeting karmic, but that usually changes around DIF time | 22:07 |
| christoph_debian | sebner: was going to ask for it myself | 22:07 |
| sebner | christoph_debian: heh, done already :) | 22:08 |
| sebner | persia: aye :) | 22:08 |
| sistpoty | thanks christoph_debian for packaging it in the first place :) | 22:08 |
| christoph_debian | :) | 22:08 |
| * sebner ^5 christoph_debian | 22:08 | |
| sistpoty | superm1: I'm inclined to accept the FFe for bug #532933, any objections from your side? | 22:18 |
| ubottu | Launchpad bug 532933 in imdbpy "Sync imdbpy 4.5.1-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/532933 | 22:18 |
| micahg | how do I force a build with a non-ubuntu maintainer address to build? | 22:22 |
| persia | Easiest way is to use an unmangled dpkg-buildpackage | 22:23 |
| micahg | persia: for upload... | 22:23 |
| persia | You can also fiddle with dpkg-source | 22:23 |
| micahg | sorry, I meant source build for upload | 22:23 |
| persia | Yes. | 22:23 |
| jdong | micahg: unset DEBMAIL? | 22:23 |
| jdong | DEBEMAIL? | 22:23 |
| persia | micahg: So, what's the top line of the changelog, and what's the maintainer? | 22:24 |
| micahg | persia: it's for a no source change rebuild of openJDK | 22:24 |
| micahg | to PPA | 22:24 |
| persia | micahg: So, what's the top line of the changelog, and what's the maintainer? | 22:24 |
| micahg | persia: not what they should be... | 22:25 |
| persia | There is no "should" | 22:25 |
| superm1 | sistpoty, not that i can think of | 22:25 |
| persia | So, I'll help you with the tools. | 22:25 |
| persia | I won't help you get it into a PPA. | 22:25 |
| micahg | ubuntux and not an ubuntu.com address | 22:25 |
| sistpoty | superm1: thanks! | 22:25 |
| persia | With luck, the former will result in the latter. | 22:25 |
| micahg | I normally do debuild -S -sd, but that obviously doesn't work | 22:26 |
| micahg | let me ask him if there's a reason that he doesn't update the maintainter for Ubuntu | 22:26 |
| micahg | not around... | 22:27 |
| persia | micahg: The easiest way is to use an unmangled dpkg-buildpackge. You can also fiddle with dpkg-source if you won't want to backport. If you give me the top line of the changelog and the Maintainer entry, I may be able to suggest something else. | 22:27 |
| sistpoty | superm1: another question: would you volunteer as delegate for mythbuntu packages in universe for ubuntu-release again? or would you suggest someone else= | 22:27 |
| jdong | micahg: as mentioned, if the DEBMAIL environment variable is blank, the maintainer check isn't done. | 22:27 |
| sistpoty | s/=/? | 22:27 |
| micahg | jdong: k, I'll just do taht | 22:27 |
| persia | jdong: That's not actually the case, depending on the changelog entries. | 22:27 |
| jdong | micahg: DEBEMAIL rather | 22:27 |
| jdong | with the E. | 22:27 |
| jdong | persia: oh? | 22:27 |
| micahg | this is still unofficial and I don't want to fiddle too much | 22:27 |
| superm1 | siretart`, i'm still the one that sponsors for all of ~mythbuntu (none of them have gotten motu or ~mythbuntu-dev yet, so yes, i'm fine) | 22:28 |
| persia | jdong: At least I almost never set DEBEMAIL, and I get the check. | 22:28 |
| micahg | persia: openjdk-6 (6b18~pre1-1ubuntu1.0ffox36.1) lucid; urgency=low | 22:28 |
| sistpoty | superm1: thanks! | 22:28 |
| micahg | jdong: no go | 22:28 |
| persia | micahg: OK. The issue you're encountering is that you have "ubuntu" in the version. Don't do that. | 22:28 |
| micahg | persia: that's what the current revision has. | 22:29 |
| jdong | " - scripts/dpkg-source.pl: Check that debian/control complies with | 22:29 |
| jdong | https://wiki.ubuntu.com/DebianMaintainerField: If $DEBEMAIL contains | 22:29 |
| jdong | '@ubuntu.com', refuse to build a source package if we have an Ubuntu | 22:29 |
| jdong | version number, but Maintainer: is not an Ubuntu address. Output a | 22:29 |
| jdong | warning if $DEBEMAIL contains 'ubuntu' but not '@ubuntu.com', or if | 22:29 |
| jdong | there is no XSBC-Original-Maintainer: field for packages with an | 22:29 |
| jdong | gah | 22:29 |
| micahg | it is currently ubuntu1 and it built for him | 22:29 |
| jdong | that was a nastty paste | 22:29 |
| micahg | so I'm just wondering what switch I need to override | 22:29 |
| jdong | it doesn't appear to have a switch to bypass the check. | 22:30 |
| geser | unset $DEBEMAIL temporarily | 22:31 |
| persia | This whole "let's support third-party repositories" thing probably needs some tools work. | 22:32 |
| jdong | geser: that's what I said initially, and it seems like it didn't work | 22:33 |
| sistpoty | asac: would you be willing to act as ubuntu-release delegate again for universe packages related to mozilla packages? | 22:36 |
| * micahg gives up and updates maintainer | 22:36 | |
| vincs | I have upload my first package to REVU. I am looking for someone to comment it. I have already amend all common errors. I understand that it is not the right time for packaging so I won't be upset if no one answers the call. | 22:37 |
| sistpoty | cody-somerville: would you volunteer as ubuntu-release delegate for universe packages of xubuntu again? | 22:39 |
| persia | micahg: Aren't you the primary mozillateam maintainer these days? | 22:39 |
| micahg | persia: I wouldn't exactly say that...but I am one of the maintainers | 22:40 |
| cody-somerville | sistpoty, Provided mr_pouit is permitted to also volunteer, yes :) | 22:40 |
| sistpoty | cody-somerville: sure, if you can convince him ;) | 22:40 |
| micahg | persia: but I don't have upload rights | 22:40 |
| micahg | yet | 22:40 |
| * persia thinks we should have a single release delegate for each delegation to preserve a small well-knit release team | 22:40 | |
| persia | micahg: Ah. Nevermind then :) | 22:40 |
| sistpoty | micahg, persia: yes, I'm trying to be a little bit conservative, but I guess a fallback might come in handy though | 22:41 |
| * micahg will probably be pushing through most of the changes to mozilla universe packages in any case | 22:41 | |
| sistpoty | persia: redundancy eliminates a single point of ... blocking ;) | 22:42 |
| sistpoty | micahg: would you want to volunteer for the position? | 22:42 |
| micahg | sistpoty: do I need upload rights? | 22:43 |
| sistpoty | micahg: you'll mainly need to know if a proposed FFe is good, so not necessarily | 22:43 |
| persia | sistpoty: Well, yes, but I'd hope the redundancy could be found elsewhere within the release team. Maybe I'm optimistic. | 22:44 |
| sistpoty | persia: we've used more than one delegate for a package set in the past, the results were usually good | 22:45 |
| micahg | sistpoty: I just don't know if I have the time...in fact this cycle it's probably not a good idea, but maybe next cycle | 22:46 |
| sistpoty | micahg: ok, fair call. I'll treat you as fallback, if that's ok, and just ask you (either on irc, or via bug-report subscription) for input in case of mozilla-related package updates, ok? | 22:48 |
| micahg | sistpoty: sure, that's fine | 22:49 |
| sistpoty | :) | 22:49 |
| micahg | thanks | 22:49 |
| sistpoty | persia: I've no clue about netbook and edubuntu atm, do you have some suggestions? should we drop one of these for delegation? | 22:50 |
| sistpoty | (or anyone else of course) | 22:50 |
| persia | For edubuntu I'd probably target highvoltage or stgraber | 22:51 |
| persia | Netbook and Desktop seem to be merging: I'd suggest seb128 or didrocks for netbook. | 22:51 |
| sistpoty | highvoltage, stgraber: would you volunteer for edubuntu as ubuntu-release delegate for universe packages?= | 22:51 |
| sistpoty | persia: thanks! | 22:52 |
| persia | sistpoty: Out of curiosity, why just for universe packages? | 22:52 |
| persia | sistpoty: More pointedly, I don't think Netbook has anything left in universe, and edubuntu has precious little (plus the edubuntu team is before the TB requesting a packageset currently) | 22:53 |
| sistpoty | persia: basically based on slangasek's mail. | 22:53 |
| sistpoty | persia: I guess main packages have a high overlap so ubuntu-release should take care | 22:54 |
| * persia hopes that ArchiveReorg/components can follow closely now that ArchiveReorg/permissions is essentially complete | 22:54 | |
| persia | sistpoty: My issue is that the set of people caring for a package doesn't typically differ just because a package happens to be in one component or another, given the new permissions structure. | 22:55 |
| persia | For example, the CLI/Mono team handles stuff in both main and universe. | 22:55 |
| persia | as does MozillaTeam | 22:55 |
| persia | For some stuff, it matters. For example, some Xubuntu stuff is part of the core set, so shouldn't be delegated. But I don't understand the point for stuff in main that isn't in core. | 22:56 |
| sistpoty | persia: CLI/Mono does have lots of rdepends in other seeds, at least I believe so. Hence there needs to be a central point of syncrhonisation | 22:57 |
| persia | sistpoty: Sure, but that's completely separate from main/universe | 22:57 |
| persia | http://people.canonical.com/~cjwatson/packagesets is a handy resource | 22:58 |
| sistpoty | persia: I guess delegations might be better thought of as packages seeded only by one team | 22:58 |
| persia | Yes :) | 22:58 |
| persia | Or rather, within one packageset | 22:58 |
| sistpoty | whatever it's called := | 22:59 |
| sistpoty | :) | 22:59 |
| persia | (some packagesets, like CLI/Mono are not generated from a seed currently) | 22:59 |
| persia | This probably matters most to the edubuntu folk, as they have lots of stuff that is only in their packageset yet happens to be in main. | 22:59 |
| sistpoty | persia: I guess the main rationale is that a package (atm) is currently easily visibe to fall under main or universe | 23:00 |
| persia | That's why I pointed you at the packagesets output list. | 23:00 |
| persia | That makes it more easy to figure out which packageset(s) apply. | 23:00 |
| sistpoty | persia: yes, but everyone involved must know this by hart, so I'd rather suggest to go step by step | 23:00 |
| persia | Well, OK. | 23:01 |
| stgraber | sistpoty: it'd make sense for both of us to do that yes | 23:01 |
| persia | But for next release, can we please use packagesets, even if components still exist? | 23:01 |
| sistpoty | stgraber: thanks! | 23:01 |
| sistpoty | persia: I don't object to this. | 23:02 |
| sistpoty | persia: at least in the hope that the main<->universe merge of release-teams will have settled during lucid (still biting a little bit at it) | 23:03 |
| persia | sistpoty: If you happen to move from there to "I support this" in the next 5 months, I'll be happy, but I'll also take it to others. | 23:03 |
| persia | sistpoty: Oh! Yeah, if that's still not smooth, then I agree it doesn't make sense to add more complexity now. | 23:03 |
| sistpoty | persia: well, give it some time, everyone is still adjusting to it ;) | 23:04 |
| sistpoty | (it's neither rough, nor smooth, it just takes some time so that everyone is aware of it) | 23:04 |
| persia | Understood. | 23:06 |
| asac | sistpoty: yeah. | 23:21 |
| sistpoty | thanks asac! | 23:21 |
| asac | welcome | 23:21 |
| LLStarks | hi. what are the chances of a tiny bugfixing debdiff being accepted for gstreamer -bad a day or two after tonight's release? | 23:22 |
| sistpoty | LLStarks: bugfix only debdiffs aren't subject to feature freez | 23:27 |
| sistpoty | +e | 23:27 |
| LLStarks | what would be subject to freeze rules? | 23:28 |
| sistpoty | LLStarks: anything that introduces new features | 23:28 |
| LLStarks | define "features" | 23:28 |
| slangasek | persia: the set of people caring about the packages doesn't differ, but my willingness to wholesale delegate the freeze decisions does | 23:29 |
| LLStarks | nvm. | 23:29 |
| sistpoty | LLStarks: that's difficult. anything that fixes a bug isn't a feature ;) | 23:29 |
| persia | slangasek: OK. What would it take to change that willingness? That feels like something leftover for resolution to make components go away. | 23:29 |
| sistpoty | LLStarks: if in doubt, just file a FFe, it'll get sorted | 23:29 |
| slangasek | persia: it's really about components as a proxy for seeds, for me | 23:30 |
| slangasek | persia: I would still not want to delegate decisions about packages seeded on the Ubuntu CDs | 23:30 |
| LLStarks | so, if blah 0.0.1 comes out tonight but bugfix just misses the upstream deadline but is accepted to the git, 0.0.1-ubuntu1 or 0.0.1-1 would be allowed to fix it ahead of an upstream release? | 23:30 |
| sistpoty | slangasek: actually I would, if the team is responsible for the image in question (and the package doesn't influence any other CD) | 23:31 |
| persia | slangasek: OK, so your issue is mostly that we only have the one report about packagesets, and you need better tools? | 23:31 |
| sistpoty | is *solely* probably | 23:31 |
| LLStarks | also, is an ffe more likely to be attended to faster than a simple a bug report that contains a patch/debdiff? | 23:33 |
| slangasek | persia: which report are you referring to? I'm not concerned about reporting for my own sake, I just don't know that there's a very clear way to communicate to delegates what's being delegated to them at present if we describe it in terms of seeds | 23:33 |
| sistpoty | persia: btw.: ok with my interpretation: http://paste.ubuntu.com/389257/ | 23:33 |
| sistpoty | *nod* slangasek | 23:34 |
| slangasek | LLStarks: if a bug requires a feature freeze exception, it needs to be touched by *both* the release team and a sponsor, which are normally separate roles, so... no | 23:35 |
| persia | slangasek: http://people.canonical.com/~cjwatson/packagesets | 23:36 |
| persia | sistpoty: Yes. I'm seeking someone for studio, but probably not until the next release cycle. I strongly recommend didrocks also for Netbook. The final paragraph seems sane to me. | 23:37 |
| sistpoty | persia: you could volunteer for -studio though ;) | 23:38 |
| sistpoty | persia: thanks for proofreading though :) | 23:39 |
| persia | sistpoty: I'm not convinced I'd be a good delegate. There are reasons I haven't volunteered for the release team previously. | 23:39 |
| sistpoty | heh | 23:39 |
| slangasek | persia: so by packageset, the ones I would not want to delegate are: core, desktop-core, langpack (well - delegate it to pitti, same thing), mobile, ubuntu-desktop, ubuntu-server, unr | 23:39 |
| persia | slangasek: Why only those? Why not to arbitrary packagesets? | 23:40 |
| persia | slangasek: nvm misread. | 23:40 |
| persia | slangasek: So I think you shouldn't delegate core or desktop-core, or langpack: those are clearly central. I don't know why you shouldn't delegate to ubuntu-desktop, ubuntu-server, and unr for non-central packages. If mobile is still there, that's a bug, and I'll try to fix it. | 23:41 |
| persia | slangasek: That said, I'd hope you'd pick your delegates carefully. | 23:41 |
| slangasek | persia: and the fact that packages that are in the intersection of sets are listed as being in both package sets makes this report suboptimal, yah | 23:42 |
| persia | slangasek: So would you be amenable to delegation of anything not in core or desktop-core that wasn't part of an intersection between packagesets? (note that this is requirements gathering for lucid+1 policy, not for immediate implementation) | 23:43 |
| slangasek | persia: I think the field of people those decisions could be delegated to for server, unr, desktop is so small that there would inevitably be conflicts of interest and they would properly be referred back to the release team; so I think it's simpler to not delegate in the first place | 23:47 |
| slangasek | anyone I would see delegating those to is someone who should be on the release team anyway :) | 23:47 |
| persia | slangasek: given that, would it make sense to expect each packageset maintaining group to contribute a member to the release team if they sought to be involved in release discussions? | 23:48 |
| persia | (pitti and Riddell being current good examples of such) | 23:48 |
| slangasek | I'm not sure the requirement holds for arbitrary packagesets | 23:49 |
| persia | Why not? | 23:49 |
| slangasek | hmm, trying to think through it | 23:50 |
| persia | slangasek: Mind you, my only objection is the implication "some packagesets are better than others" for stuff not core or core-desktop. | 23:50 |
| persia | slangasek: So it makes sense to me to either delegate for everything (else) or not delegate at all, and tell people to get involved in the release team. | 23:51 |
| slangasek | if a team such as mythbuntu wants to be autonomous in making decisions about their particular packages, but doesn't have anyone who can commit to helping with the release team generally, what do you think is the correct course of action? | 23:51 |
| slangasek | well, I don't see it as "better than" | 23:52 |
| persia | I don't either, but believe it to be potentially misconstrued. | 23:52 |
| persia | Well, how much extra burden is it to participate in the release team generally? | 23:53 |
| persia | Is it not just reading one more mailing list and one more IRC channel, and attending one more meeting? | 23:53 |
| Riddell | there's a mailing list? | 23:54 |
| persia | https://lists.ubuntu.com/mailman/listinfo/Ubuntu-release | 23:55 |
| slangasek | persia: hum; abstractly, if we're going to expect each member of the release team to be able to represent the whole release team, then there needs to be some shared model for how this works; that model doesn't come from the mailing list and the meetings, and we haven't really made an attempt yet to scale it | 23:56 |
| slangasek | Riddell: yes, there is :-) | 23:56 |
| slangasek | (not heavily used) | 23:56 |
| slangasek | persia: so I think in practice there has to be some committment to actively engage | 23:56 |
| persia | slangasek: That makes lots of sense. Would you be willing to think about this for the next few months, and see if you can come up with a model that doesn't depend on components? | 23:57 |
| slangasek | sure | 23:57 |
| persia | Because I agree with most of your criticisms, although I also suspect most of the identified delegates will have the same conflict-of-interest issues that you cite for the ones that concern you more. | 23:58 |
| slangasek | yep | 23:58 |
| persia | Thanks for digging into this. Please let me know if I can be of any help. | 23:59 |
| sistpoty | slangasek: btw, can you whitelist stefan.potyra@informatik.uni-erlangen.de for ubuntu-release? (work address), thanks! | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!