[00:00] Right. [00:00] Which is still a problem. [00:00] That's clearly a use restriction. [00:00] need to run [00:00] bbl [00:00] ScottK-laptop: that is akin to saying that the GPL restricts distribution [00:00] It does! [00:01] then the GPL shouldn't comply with the DFSG [00:01] * cody-somerville doesn't think we need to be having a "yes, it does" "no, it doesn't" pissing match in -motu. [00:01] use restriction != distribution restriction. [00:01] cody-somerville: I agree. [00:01] cody-somerville: There is no #ubuntu-legal, so where then? [00:01] Gotta run. [00:01] ScottK-laptop: Ubuntu has a technical council for this reason. [00:03] There's little point invoking the TB without having a discussion first. [00:07] I guess I've gotten as much about MOTU's processes that I'm going to [00:07] thanks for the link guys [00:13] REVU seems not to consider reviews by contributors, packages are still in "new", not in "needs work" [00:14] mok0: yep, that's a feature [00:14] RainCT: why? [00:15] RainCT: seems like a misfeature to me :-) [00:16] So we should go through and post a comment so they move to the needs-work category? [00:18] mok0: rationale: contributors may be wrong, and having their comments move the package down to "needs work" may a) discourage them from commenting if they are not sure and b) annoy the uploader if someone posts a wrong comment (point c) would be that evil guys could move all uploads down, but I think/hope this wouldn't happen anyway :)) [00:18] mok0: the real reason though is that it isn't possible with the current design (as it's either advocate or move down) [00:20] mok0: I'm not sure if the rationale is really good and there are plans to change the design so that MOTUs can post non-advocating positive comments so you even have a chance to get this changed :) [00:22] RainCT: It just seems there are a whole bunch of packages that actually need work, and contributors comments seem pretty sensible. [00:23] RainCT: I think uploaders may not have discovered that there is work to do [00:23] RainCT: In any case, there is an incredible amount of packages in REVU. Seems there has not been much turnaround in REVU this cycle. [00:24] mok0: feel free to raise this on ubuntu-motu@ / create a blueprint for it on launchpad.net/revu / whatever [00:24] (^ means the "packages don't get down to 'needs work'" point) [00:24] RainCT: Probably should be discussed at a MOTU meet [00:25] RainCT: I feel there may be quite differing opinions on this [00:25] mok0: about uploaders not noticing the changes, that's being worked one (there's the atom feed now and e-mail subscriptions mail follow somewhen soon) [00:26] RainCT: I've posted a few "please address comments above" comments which move them to the needs-work section --- hopefully uploaders will discover that [00:26] mok0: and on your last point, there were no REVU days this cycle :) [00:26] RainCT: yeah I noticed... any particular reason? [00:27] mok0: The current REVU Coordinator hasn't much time and there were no volunteers to help him [00:28] well, actually persia said there was a non-MOTU one [00:28] RainCT: What a shame. It is quite discouraging to the uploaders [00:28] * cody-somerville whats the question? [00:29] mok0: indeed [00:29] cody-somerville: we're talking about REVU [00:29] * cody-somerville nods. === Kmos_ is now known as Kmos === Kopfgeldjaeger is now known as Kopfi|offline [00:45] RainCT: have a minute? [00:46] RainCT: never mind [00:47] mok0: yes? [00:48] * RainCT is about to leave, so if you want something say it fast ;P [00:55] 'night everyone === EagleSn is now known as EagleScreen [01:51] when packaging something for REVU, is it possible to get it through with a lintian warning of W: mythnettv source: patch-system-but-direct-changes-in-diff bin/mythnettv [01:51] the mentioned file isn't part of the orig.tar.gz, it was added by me [01:51] tgm4883_laptop: why not use the patch system? [01:51] hrm? [01:52] azeem, I have the same errors for setup.py and the man pages I created [01:52] If the patch system is the correct way to do it, then i'll do it that way, just seems wrong though [01:52] tgm4883_laptop: ok, do you know what a patch system is? [01:52] why wrong? [01:52] azeem, yea I'm using it for other things [01:53] azeem, seems wrong because I thought you only use a patch system when you want to fix a file from the orig.tar.gz [01:53] not when adding files necessary for packaging [01:53] in general, the .diff.gz should only have files under debian/ when you use a patch system [01:54] if you have to add files to the source tree, those should either be shipped under debian/ (if somewhat ubuntu-specific), or as a patch in the patch system when upstream specific [01:55] azeem, what about setup.py? I believe that has to be in the root dir doesn't it? [01:55] yes [01:55] so I would need to make that a patch? [01:55] looks like it's supposed to be in upstream in the first place, no? [01:56] I guess. I'm not that familiar with python packages, but my understanding would be that all python packages need that in the root? [01:56] and that isn't debian specific correct? [01:56] well [01:57] it's certainly not debian specific, right [01:57] and it's the usual way to package upstream python stuff [01:57] but still, other ways to distribute python stuff upstream can be thought off [01:57] of* [01:58] well the way it is released is a tarball that when extracted you can run from the directory it's in [01:58] not really an installation [01:58] euh [01:58] ok [01:58] so adding setup.py is improving on upstream [01:58] thats what i'm a fixing [01:58] yes [01:58] so, if there's a patch system already, it's reasonable to add setup.py as a patch [01:59] well I added the patch system, but as long as adding setup.py as a patch seems reasonable then i'll do it [01:59] I was just confused a little on what should and should not be a patch [02:00] Any change outside debian/, when you're using a patch system :). [02:01] So that you can send a patch upstream. It doesn't really matter that you're adding a whole file; upstream is likely to want to see that change as a patch anyway. [02:01] RAOF, ok will do. [02:01] One more question, slightly related [02:02] this program is a command line program. I'm adding a gui to it. Would it be better to have the gui as a separate package? [02:02] hrm [02:02] depends on how involved "adding a gui to it" is, I guess [02:02] Are you adding this GUI as an Ubuntu patch? [02:03] i've let upsteam know about the gui, and they are interested in it. But i'm not sure that they will want to bundle the two together [02:03] RAOF, at the moment, it's a separate app [02:03] I guess the real question is [02:03] With a separate source tree? [02:03] that sounds like something you should figure out upstream [02:03] if they do decide to bundle them together for future releases, how hard is it to kill the -gui package in the repos? [02:04] the -gui app lifts out of the command line app really easy [02:04] Splitting a source package is a tradeoff between annoying the archive admins and annoying the users ;) [02:04] it just parses output from the command line app [02:04] currently it's a separate branch and everything [02:05] That sounds like it wants to be an entirely separate source package, really. [02:06] IMO, they should be offered seperatly to offer less bloat. [02:06] although we're not talking very big packages [02:07] azeem, RAOF thanks for the clarifications on those issues [02:11] RAOF, azeem, I just ran into a small problem on the patch that we were just talking about regarding setup.py [02:12] In order to build, i have to apply the patch. But if the patch is applied, I get the lintian warning when building [02:12] so i'm not really sure what to do with this catch 22 [02:13] tgm4883_laptop: You need to remove the file in clean:, then. Because patches won't remove files, IIUC. [02:16] there is no clean using cdbs? [02:16] i'm probably confused here [02:16] Of course there is; it's just implemented by cdbs. [02:16] You can write a clean:: target, though. [02:16] The double-: means "Append this on the end of the existing clean: target" [02:17] ah, and that goes in rules [02:17] * tgm4883_laptop is slowly getting all this packaging down [02:18] thanks RAOF, i'll look into doing that [02:19] tgm4883_laptop: just remove it locally [02:19] and let the patch system handle it [02:20] azeem: Will unpatch: remove the file? [02:20] azeem, I can't remove it locally, otherwise I get an error about setup.py not being there [02:20] hrm [03:07] ScottK, what exactly to backport testers do? [03:09] soren: Ooh, you evil triblodyte bricordion nickerbook, you. [03:10] what has soren done this time? === orly_owl is now known as Davo_Dinkum === Davo_Dinkum is now known as orly_owl [05:33] good morning [05:38] NCommander: Look at the bugs in the various backports projects and then build and test that them. For backports, the standard is builds, intalls, and runs. [05:38] Ah [05:38] That's easy enough ;-) [05:38] NCommander: Then you mark the bug confirmed and an ubuntu-backporter will review it for approval. [05:38] Yes. [05:39] The trick is that if any modifications to the package are needed, then you need to have a core-dev do the upload, even for a universe package. [05:40] O_o? [05:40] Why's that [05:40] Because source backports are discouraged. The archive admins have a script they use for semi-automated backporting. [05:40] oh I see [05:41] I think they want to keep potentially disruptive backports to a minimum. [05:41] Decision was made before my time, but at least there's finally one core-dev with some interest in backports. [05:42] That would be you, right? [05:42] yeah. [05:43] what's your usual workflow for handling testing? (I think you told me once you run intrepid or hardy, so I assume you have chroot fun) [05:43] steven@liquified:~% schroot -l -a | wc -l [05:43] 21 [05:44] * StevenK should clean some of them up [05:44] NCommander: For backports I generally just test the ones I could run. That means Dapper or Hardy. [05:45] Bah [05:45] That means downgrading for me, unless I want to run in a VM [05:45] For other releases I do installability testing and such in a chroot. [05:45] (I could use a chroot, but that isn't perfect) [05:45] Yep. [05:45] There is also a limit of what you can test in a chroot. [05:45] StevenK: How much cleanup is possible? I have 19 and that's only for the current and development releases. [05:46] That and generally I've got decent judgement about who to believe when it comes to backports test report. [05:46] BTw [05:46] Any objections if I go close all the hoary bugs ;-) [05:46] They seem a little out of date [05:46] I did manage to break a bunch of people with a bad Flash backport a month or two ago. [05:46] NCommander: ubuntu-vm-builder is your friend [05:46] ubuntu-vm-builder? [05:46] persia: There is 3 that need to be cleaned, and gutsy* is still in that list. [05:46] NCommander: yep [05:47] NCommander: it create an ubuntu VM with just one command [05:47] no isos needed [05:47] or configuration [05:47] LVM, or what? [05:47] i use kvm [05:47] ScottK-laptop, I remember that, I thought that was an SRU, not a backport [05:47] but it supports qemu, vmware and some other [05:47] i think [05:47] how hard is it to get going with kvm? [05:47] * nxvl checks [05:47] (I've never used it before) [05:47] not at all [05:47] you just need the hardware [05:47] If you mean VTx [05:47] I got it [05:48] Just need to enable the chip [05:48] then you can tun ubuntu-vm-builder and it even creates a sh script to run the vm [05:48] (Sony's BIOS updates like to disable it every update) [05:48] NCommander: Nope. That was a backport. Lots of people run with backports on. [05:48] It's kind of scary given how lightly they are tested. [05:48] Oh fun. [05:48] NCommander: https://wiki.ubuntu.com/kvm [05:48] NCommander: That's what you get for buying a Sony. [05:48] (you didn't answer if I could kill the horay backport bugs) [05:48] NCommander: kvm is really easy as long as you're supported. [05:48] Yeah well, the laptop was 600 dollars off [05:48] NCommander: Sure. [05:48] You may be interested in virt-manager, too. I rather like it. [05:49] NCommander: My first laptop was a Sony. Never, ever again. [05:49] My previous laptop was a macbook pro [05:49] Never, ever again [05:49] This sony been a massive improvement [05:49] * StevenK hugs his X40 [05:49] I almost went with an Ubuntu Dell, but they were backordered for four weeks [05:50] * ScottK-laptop has a very nice Dell that couldn't be gotten with Ubuntu (not that I'd want it), but worked out of the box with no issues. [05:50] Everything works out of the box on my sony [05:50] So I'm not complaining [05:50] Right, except the stuff that doesn't. [05:51] * StevenK sighs at his sisters laptop [05:51] What were Compaq thinking, selling a laptop with XP with 224MB of RAM. It's ... dumb [05:51] O_O; [05:51] OW [05:51] That's even low for xubuntu [05:52] That's under Evolution's resident size, here :) [05:52] It's 2% cheaper, and there's a chart somewhere that shows that sales go up when prices go down. [05:52] I've got an ancient Dell with 256MB of RAM that runs Hardy Kubuntu OK as long as you only do one thing at a time. [05:53] Death has come to the horay Ubuntu bugs :-) [05:53] This is my sister, I think she wants MSN, Microsoft Word and 17 IE windows open all at once [05:54] * nxvl wants a X61 [05:54] but still love my T61 [05:54] https://bugs.edge.launchpad.net/ubp-hoary - Bugs be dead [05:55] I didn't see anything compelling about the X6* over my X4 [05:55] Er, X40 [05:55] Unfortunately (if you care about such things) it doesn't help Ubuntu bug counts any. [05:56] edgy is dead also, right? [05:56] NCommander: Indeed. [05:56] (I just want to clean up this bug tracker given the chance) [05:56] with motu membership i get ubuntu-bug-control one too, don't i? [05:56] * ScottK-laptop hands NCommander a flamethrower. [05:56] nxvl: Yes. [05:56] nxvl: yes. [05:56] :D [05:56] I got bug-control without motu [05:56] By having packages in Debian [05:57] then i don't need to worry for my ubuntu-bug-control membership which is about to expire [05:57] :D [05:57] (I was told that I was the first to ever use that method to get bug-control group membership O_O!) [05:57] nxvl: Nope. [05:58] You can get bugcontrol for having packages in Debian? That's interesting, but I suppose it's non-trivial to Maintain a package in Debian. [05:58] Yeah [05:58] They were kinda confused when I pointed to the wiki page about it [05:58] It seems since bug control was established, no one ever used that [05:58] Do they still enforce the signing of the CoC? I know a couple people with CoC reservations who are active in Debian, actually maintain their packages for Ubuntu, and might find it helpful. [05:59] Oh yeah [05:59] YOu do [05:59] Your only waived from the five ubuntu bug requirement with it [05:59] OK. That was never the problem for the specific people I'm thinking about :) [05:59] Heh [05:59] Yeah [05:59] (five bugs is *easy*) [06:00] Of course [06:00] I think your also waived something else [06:00] The test the bugcontrol guy gives you on prioritys/statusus [06:01] LP seriously needs a mass bug killer [06:01] Or a bug shotgun [06:02] Very much no, just more people fixing the bugs. [06:02] I don't think keeping bugs open on backports that have left support is useful ;-) [06:02] I guess thats a specialized case [06:03] Right, but that doesn't need a mass bug killer. Closing them all is a single email after a few minutes of looking them over. [06:03] You can close bugs via email? [06:03] (like in Debian?) [06:03] Yes, you can do almost anything with bugs via email. You have to sign the mail to authenticate. [06:04] so control@bugs.launchpad.net [06:04] and then closes 1 2 3 [06:04] (etc.) [06:04] Not precisely. [06:04] I knew you could reply to bugs via email but I didn't know you could close [06:04] Not control, no [06:04] yeah i get ubuntu-bug-control membership before uuc and long before motuship [06:04] that's why it's about to expire [06:05] NCommander: https://help.launchpad.net/Bugs/EmailInterface [06:05] Oh [06:05] sexy [06:06] nxvl: so did mok0 happen to mention to you what package this is that he was concerned about the wrong version number on? [06:06] persia, er, how would you do this enmass? [06:06] A lot of CCs? [06:06] slangasek: not at all [06:06] NCommander: That's how I do it. [06:06] slangasek: just that it was a package [06:06] slangasek: and the version [06:06] nxvl: ohwell :) [06:06] :D [06:07] WHere's that GUI program for handling Launchpad bugs? [06:07] NCommander: Leonov? [06:07] yeah [06:07] Oh, I can do bug XXX status invalid [06:08] nxvl: looks like it was the torque upload to hardy-proposed [06:08] You can also just write an email saying ' status invalid', and Cc it to as many bugs as your SMTP server allows. [06:08] slangasek: :D [06:08] I wonder how many google allows ... [06:08] Hm. I think Launchpad should accept 'kthxbye' like control@bugs.d.o does [06:09] control@bugs.d.o accepts kthxbye O_O? [06:09] slangasek: you have quite an odd schedule, where are you based? [06:09] Yes :-) [06:09] nxvl: Oregon [06:10] yeah, i was thinking in the US, so it is an odd work schedule [06:10] :D [06:10] StevenK: I'm not sure if it still does, Don has made a couple passes over the mail interface since he took over maintainership [06:10] nxvl: I'm not at work right now :) [06:10] slangasek: yeah sure :D [06:11] if i finally got a FOSS related job i will work with an odd schedule too [06:11] it's just fun [06:11] Death has come to the edgy backport bugs [06:12] it's like being paid for testing games [06:12] * NCommander downloads a freedos CD so I can fix VT on my laptop [06:12] NCommander: :( [06:12] poor bugs [06:12] \o/ [06:14] nxvl: no, really, I'm not at work right now... :) If I were at work, I should be doing things according to work priorities. :) [06:14] nxvl: Congratulations. What can you tell us about the job? [06:14] :D [06:14] ScottK-laptop: what job? [06:15] Right. [06:15] :D [06:18] lol [06:18] Meh, bugs-by-email seems to lag ;.; [06:18] NCommander: Bug design. [06:18] Bug/By [06:18] It reminds me of Debian's BTS [06:19] dammit i still can't upload to flickr from f-spot at home [06:19] i hate my ISP provider [06:19] Yes. It's the only place their speed is ~equivalent. [06:19] You hate your Internet Service Provider Provider? [06:19] It's the only thing I know of that isn't faster on BTS. [06:19] Is that like an ATM Machine? [06:20] * NCommander has a love/hate relationship with BTS [06:20] Yes. I can understand that. My relationship with Launchpad is rather more consistent than that. [06:20] StevenK: heh, it's 12:20 here :D [06:20] And rather more one-sided [06:21] ScottK-laptop has a deep, abiding hatred for launchpad & all that goes with it [06:21] and loves to share that [06:21] I actually prefer bugzilla. [06:21] Ewww! [06:21] * ajmitch remembers the fun of the 1MB js that was loaded on every ubuntu bugzilla page load [06:21] i felt that provider shouldn't be there [06:23] well, time to sleep now [06:23] read you tomorrow [06:23] good night nxvl [06:23] dholbach: have a nice day! [06:23] thanks :) [06:23] Yeah. The original Malone was *much* preferable to Ubuntu bugzilla. That said, I haven't used bugzilla since the mass import into Malone, so things may be different now. [06:23] why is there 1MB of JS on the old Ubuntu bugzilla? [06:23] package list [06:24] persia: I agree (about the original malone). [06:27] Good morning. [06:36] Sigh. I'm going to work. See you guys later. [06:38] how can I kill every schroot on my system? [06:40] brb [06:48] woo [06:48] now my laptop has VTx [06:53] VTx? [06:53] a laptop with a Honda motorcycle? [06:58] kirkland, your ubuntu-vm javascript page is amazing [07:16] ajmitch: I made the mistake of engaging in this discussion: http://bobbo.me.uk/?p=179 [08:33] what's the url of that ubuntu-vm page ? [08:37] tacone: Which ubuntu-vm page? [08:38] persia: I found it, nevermind. btw it was this: http://people.ubuntu.com/~kirkland/ubuntu-vm-builder.html [08:41] tacone: You know that there is a command-line client as well, right? [08:42] persia: that page is a webform to generate a shell line to be used with the command line client. try to press the generate command. [08:43] Oh. I thought it actually generated the image. I remembered that being talked about at some point, to support use cases where the host machine was not Ubuntu. [08:45] that could easily done with a little server-side scripting, just extending kirkland's work. not sure it's worth the work yet :-) [08:49] morning fellows [08:49] Morning [08:59] Is there any MOTU who want to advocate CDEmu? The packages have been thoroughly fixed now. [09:04] Besides the ubuntu brainstorm thingie listed a CD emulator as the #9 most wanted feature of all time. [09:04] isn't loopback good enough? [09:08] not really. linux can't mount CUE/BIN files and the likes. [09:12] there's a tool to convert cue/bin to .iso [09:13] also, couldn't this be done through fuse? (or is it fuse-based) [09:21] cdemu doesn't really concern itself with filesystems but leaves that part to linux. it interpretes disc images and serves it as a virtual disc. the kernel driver is quite thin and it does most of the work in userspace. while there are a couple of interresting fuse plugins, none of them offer the quite the same functionality. [09:29] a nice example would be that you could mount a protected MDS (alcohol 120%) image and use fuseiso to access the contents for example. [09:45] Though in most cases HAL would catch it and mount it automagically. :) === Czessi_ is now known as Czessi [10:17] dpkg-buildpackage is in devscripts right? [10:17] dpkg-buildpackage is in dpkg-dev [10:17] StevenK: thanks [10:33] maybe i had to reboot after removeing gnupg-agent [10:34] gnomefreak: gpg signing works for you again? [10:35] persia: i think so [10:35] im testing another package [10:36] persia: seems removing gnupg-agent didnt help and i shut down for the day yesterday and now it works [10:37] gnomefreak: So just some leftovers in your session then. [10:56] where did /etc/dput.cf go? [10:57] Are you running Intrepid? [10:57] cody-somerville: yep [10:57] * cody-somerville is on a hardy box right now so can't look. [10:58] I have it on Untrepid [10:58] Intrepid* [10:58] i dont see anything related to dput in etc [10:59] i have ~/dput.conf but that ws handmade for PPA [10:59] s/ws/was [11:01] i guess i could add it to $HOME/,dput.cf [11:01] gnomefreak: I also have an /etc/dput.cf on intrepid. Is the dput package installed? [11:02] http://pastebin.com/f546a285d is the output of dpkg -L dput [11:02] yeah i guess since i can upload to PPA [11:02] hmmmmm [11:02] /etc/dput.cf [11:02] it says i have it too [11:03] seems i overlooked it :( [11:04] moin [11:07] moin emgent [11:08] hi there :) [11:08] jelmer: I have merged your changes to ubuntu-dev-tools. Thanks. === dholbach_ is now known as dholbach [11:28] can someone please review http://revu.ubuntuwire.com/details.py?package=smartirc4net and http://revu.ubuntuwire.com/details.py?package=smuxi the lintian warnings are most likely caused by me adding a clean option to fix FTBFS but i didnt make a patch i just changed it since it was our file not upstreams [11:29] s/most likely/most for sure [11:31] gnomefreak: why not use the Debian packages? [11:31] gnomefreak: the first lintian warning is caused by diff refusing to add empty files. [11:33] gnomefreak: see also bug 259833 [11:33] Launchpad bug 259833 in ubuntu "Please sync smuxi 0.6.1-2 from Debian(Unstable)" [Undecided,Incomplete] https://launchpad.net/bugs/259833 [11:34] geser: thats where i got it from [11:35] look at changelog it has debians 1 and ours [11:36] henrik-kabelkaos: ah ok good nothing i did [11:36] asac: there? [11:37] devfil_: more or less :) [11:37] gnomefreak: you don't need to go through REVU in that case, just file a sponsoring bug with the needed debdiff to get it build [11:38] devfil_: how are you doing? [11:38] geser: i thought revu was for ne packages? [11:38] asac: can you take a look at the xulrunner update? [11:38] s/ne/new [11:38] gnomefreak: yes, for completely new packages [11:38] devfil_: yes. i have to [11:39] thanks [11:39] devfil_: 254618 ? [11:39] geser: ok so a debian package built for Ubuntu isnt new [11:39] 205325 [11:39] asac: --^ [11:39] gnomefreak: we could sync the packages from debian, see that it FTBFS and upload -1ubuntu1 (no revu involved at all). So we can also skip the sync and upload -1ubuntu1 directly. [11:39]