=== lutin is now known as Lutin [00:15] !paste [00:15] pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the channel topic) [00:52] james_w: I would like to get my patch into Hardy, but I figure that if it gets accepted upstream it'll make its way down, won't it? [00:53] marnanel: yes, but probably not for hardy [00:53] marnanel: and it seems that there is no upstream any more [00:53] * marnanel nods, makes sense. well, okay, how should I do that? [00:53] Oh, I have to read a bedtime story. bbiab. [00:54] :-) [00:54] can you read me one after? [00:54] * marnanel laughs. I think my kid is almost ready to learn to triage bugs anyway [00:54] yeah we should start a nightly bedtime story ritual here [00:55] yay [01:16] Hi, I'm currently testing 8.04 beta and it seems to take a long while to boot. Looking at the relevant part of the dmesg, suggests that this is the issue: http://pastebin.ca/961632 [01:20] nabcore: I don't quite know what to make of that [01:20] is it the probing for the floppy that is slow? [01:21] That's the conclusion I've come to [01:21] it's weird [01:21] okay, back... how would I get the patch into Hardy? [01:21] I've tested it, and it does work [01:24] marnanel: ok, you need to create what is called a "debdiff", which turns your application in to a patch for the package, are you familiar with doing that? [01:24] nabcore: I have seen a couple of reports about slow booting [01:24] I don't have numbers though I'm afraid [01:26] james_w I may need to test again since I had my USB disk plugged in and I want to reduce the noise in the bug report [01:29] james_w: No, but I suspect I am about to discover how [01:29] * marnanel makes a cup of tea and settles down to find out [01:30] james_w also, the beta does not seem to pick up correctly my Nokia 447v monitor, hence the resolution is quite low [01:30] Setting it using "Screens and Graphics" and then logging out and in resolves this [01:34] marnanel: are you sitting comfortably? [01:42] sure. (well, I'm still arranging things, but I'm listening) [01:43] also I am apparently not the only one to be old enough that I listened to Listen With Mother in the seventies [01:44] so, the process is that you create a new version of the package that includes your changes, and then use the debdiff script to generate the changes between the old and new versions [01:44] you can then upload this diff to the bug and get it sponsored in to the archive. [01:44] Okay, like a patch really, only across a whole package [01:44] right. [01:44] yeah, exactly [01:45] That makes sense. Cool. [01:45] so you need 2 things, your patch, and the existing package [01:45] to get the latter use "apt-get source gnome-alsamixer" [01:46] which will create a directory with the unpacked source, so cd gnome-alsamixer-0.9.7~cvs.20060916.ds.1 [01:46] okay... [01:46] you may also need to install some things, so run [01:47] sudo aptitude install dpkg-dev devscripts dpatch [01:48] aptitude doing its thing... [01:49] cool [01:50] are you familiar with the source package format at all? [01:50] or rather what goes in a debian/ directory? [01:51] debian/rules and things? Yes, but I haven't looked at it in a few years. [01:51] Okay, aptitude is done at last [01:53] Is there a good place to read up on the package format? (Or you can tell me things, of course.) [01:53] ok, this package uses dpatch, are you familiar with it? [01:53] No. [01:53] https://wiki.ubuntu.com/PackagingGuide [01:53] * marnanel goes to look [01:53] that's the most specific I can be off the top of my head [01:54] so, dpatch is a way of keeping separate upstream patches in debian/patches/ and then applying them at build time. [01:54] so we can just drop your patch in there and let it do its thing [01:54] That makes sense. [01:54] however dpatch is a little strange, and so you have to run a highly cryptic command for the next bit [01:55] one that I am going to have to look up, one moment please [01:58] dpatch patch-template -p "04_" "" < > debian/patches/04_.dpatch [01:59] there are two redirections there, as well as the variables for you to fill in [01:59] right [01:59] what does the 04_ mean? [01:59] I mean, obviously a filename prefix [01:59] so dpatch has a special format to the files, that includes a header, the patch-template command tells it to generate that header [01:59] but why 04_ ? [01:59] oh, because there are already three others [02:00] by convention they are numbered [02:00] exactly [02:00] the -p tells it to prepend that header to standard input [02:00] awesome. [02:00] you should then check that the file created looks sane, you can pastebin it if you would like me to check [02:00] right... [02:01] * marnanel tries to fix all this up to this point [02:05] Does it make any difference what "name of patch" is? [02:06] nope, but it's helpful to make it slightly descriptive [02:06] Makes sense. [02:06] fix_bugnumber is quite common [02:06] fix_whatever_it_fixes as well [02:06] All my patches in GNOME are saved as "a.patch", "b.patch" and things because they never stay on my hard disk after they're uploaded [02:09] fair enough, this one will be around until it is fixed and relased upstream, so other people may well have to work with it. [02:09] * marnanel nods, makes perfect sense. [02:10] also, you may want to put it in a file ending with .diff for consistency with the others, but it won't make a difference otherwise [02:10] oh, thanks-- I had started to wonder [02:11] yeah, dpatch works with both, but requires one as I remember [02:13] how's it looking? [02:13] oops, I used 04-, it should be 04_ [02:13] * marnanel does it again [02:14] I don't think it matters much [02:15] Okay, so I have this new file, and it has a header and then the contents of my patch which look just the same. [02:17] cool, so the next step is to check that it applies [02:18] this means that it must also apply with the other three patches applied first. [02:18] Okay... [02:18] I don't think there will be conflicts but it is good to check at this stage [02:18] to do that run dpatch apply-ll [02:18] apply-all sorry [02:19] ah, no, first we have to add it to the series file so that dpatch knows about it [02:19] so edit debian/patches/series and add the filename to the end [02:21] Okay, sure [02:22] Okay, and I ran dpatch apply-all, and it returned without printing anything. [02:23] hmm, that's not right [02:24] ah, crazy, it's not dpatch at all, it's quilt, but with dpatch headers in the files [02:24] It also appears not to have applied the patched :/ [02:24] Oh, weirdness. [02:24] Okay, so I run quilt? [02:25] yes, but quilt is not debian specific, so there's an environment variable to set [02:25] the easiest way to do this though is use debian/rules [02:25] so run ./debian/rules patch [02:25] ah, but I bet you'll have to "sudo aptitude install quilt" [02:25] first [02:26] oh, in fact "sudo aptitude install quilt cdbs" [02:26] this package uses cdbs, which is a set of makefiles try and simplify debian/rules in common situations [02:26] It is thinking about it... [02:26] right.. [02:29] Okay, installed. (This is not the fastest computer in the world.) [02:30] okay, so does ./debian rules patch work now? [02:31] make: *** No rule to make target `patch'. Stop. [02:31] Hm. [02:32] ah, sorry my fault the target is apply-patches [02:36] oh, sorry! [02:36] *tries* [02:38] Hm, that patched everything but 04_ and that said: make: *** [debian/stamp-patched] Error 1 [02:38] Which wasn't very informative [02:38] :( [02:39] there was no error above? [02:39] it may conflict then [02:39] Oh, good point. It doesn't conflict upstream but perhaps it does with the patched version. [02:39] Would the output of patch have been saved somewhere? [02:40] I can just reapply the patch to the patched version and see [02:40] I'm not sure, you can see it with [02:40] QUILT_PATCHES=debian/patches quilt push [02:43] oh, silly me, I named the file foo.diff.dpatch for some reason [02:50] yay, and found the other problem [02:51] if you create a patch using svn diff and you're in trunk, which is the way we do it upstream [02:51] then the filenames in the patch look like src/foo.c [02:51] but it turns out debian-rules wants them like gnome-alsamixer/src/foo.c [02:51] ah, so you want to edit debian/patches/series and add -p0 to the end of the line [02:51] I think that's right [02:52] it's okay, I just edited the patch and put gnome-alsamixer in before src on each line [02:53] * marnanel tries to make my patch conform to the style of the others [02:54] that works too [02:55] Okay, so I appear to have a working patch. I should compile and link and test next? [02:56] well, it's better to test the final package, so we'll carry on with that [02:56] the clean target or debian/rules will take care of de-applying the patches, so we'll just do the next bit [02:56] that is to edit the changelog [02:57] there is a tools called "dch" (it's actually debchangelog I think) [02:57] if you run "dch -i" then you will be given a new changelog stanza to fill in your changes. [02:58] you should check that your name and email at the bottom is how you would like it, if not we can fix that up [02:58] (or you can just edit it) [03:00] Okay [03:01] * marnanel laughs. I am apparently marnanel@localhost.localdomain [03:01] * marnanel fixes it up [03:01] well, it's kind of accurate [03:01] true... [03:02] you can set DEBEMAIL in your environment to choose what you want to be known as for packages [03:02] man dch explains it all if you care [03:02] so you should explain what you are fixing and how. [03:02] also here you would put any notes to the release team as we are close to release [03:03] and also any notes to possible future people who work on the package [03:03] I don't think they apply here [03:03] for instance you might say, this change can be dropped in hardy+1 when we no longer need to support an upgrade path from dapper [03:04] right. What goes next to the * I can see? [03:04] that's where you put the change [03:04] you use a * for each separate change [03:04] * Fix a [03:04] - including this [03:04] * Fix b [03:05] so you only need one [03:05] Oh, okay. But my name goes at the bottom with the -- next to it? [03:05] yep [03:05] the other trick is that we want the archive software to take care of closing the bug for us so we can upload and forget about it, for that you use special markup for the bug number [03:06] so at the end of the change put (LP: #) [03:06] Oh, awesome. I've seen that in trac too; I'm trying to lobby for gnome to have it but there are political problems as well as technical ones [03:07] okay... [03:07] Do I need to do wordwrap or does it do that for me? [03:07] yeah, it's fantastic, I would recommend that every project adopt it [03:07] you need to wrap [03:08] use four spaces for any continuation lines [03:08] (only two are required by the format, but four is convention) [03:09] Okay, sure [03:09] This is fun. I wonder whether my wife would be upset with me if even more of my time disappeared because I tried adopting any ubuntu packages. :) [03:10] there's only one way to find out :-) [03:11] * marnanel grins [03:17] whoah, writing LP: #nnnnnn in Vim lights up in yellow [03:18] yep, useful to know you've got the right syntax. [03:18] so, once you've saved it you can try building the package [03:19] And that's debian/rules something? [03:19] there's a wrapper, well, actually a wrapper of a wrapper, called debuild [03:19] so you wan't "debuild -uc -us" [03:20] those options tell it not to bother signing anything, as signatures don't matter for a test-build [03:20] okay, great [03:21] * marnanel installs patchutils [03:21] ah, you'll need gnome-pkg-tools libgnomeui-dev libasound2-dev autotools-dev intltool as well [03:22] I guess you'll have at least some of them if you've been building the package already. [03:24] apparently I have all of them, so here goes :) [03:24] This is pretty awesome. I wish we were this organised with tools and things [03:25] some would call it a mess [03:25] if you were to move on to another package now you would probably have to deal with a whole different set of things [03:25] bug dch debuild etc. are good [03:26] crunch. link error. clearly my problem. *pours more tea* [03:38] * marnanel idles for a few minutes-- called away [03:38] james_w: thank you for your help, in case you leave before I come back. I appreciate it very much. [03:39] marnanel: yeah, it's late here, I'll be leaving shortly [03:39] I'll probably be around tomorrow if you are [03:39] also there is #ubuntu-motu where someone will probably be able to walk you through the last part [03:40] once you get the package built you should install and test it. [03:40] then make the debdiff [03:40] this is done by building a source package "debuild -S -uc -us" [03:40] and then calling debdiff old.dsc new.dsc [03:41] then attach that to the bug and subscribe ubuntu-universe-sponsors [03:41] but as I said, someone on #ubuntu-motu can help you out if I'm not around [03:41] also there is https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff === asac_ is now known as asac === doko_ is now known as doko [10:05] <\sh> guys, could you take care, that people are not just passing by to bugreports and change status etc. just because of karma hunting? [10:30] hello [10:36] G'morning [10:37] hello [10:37] Hi qense === qense is now known as qense-lunch [11:43] hi. I'm getting this error in apt-get. is something wrong with the repositories? "Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hardy/Release Unable to find expected entry web/binary-amd64/Packages in Meta-index file (malformed Release file?)" [11:48] <\sh> salty-horse: works here... [11:49] I tried this command: "sudo apt-get update". when trying "sudo apt-get build-dep I get this error: "E: Could not open file /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hardy_main_source_Sources - open (2 No such file or directory)" [11:57] \sh, my /etc/apt/sources.list has "web" as a repository. I have no idea how it got there. ("deb http://archive.ubuntu.com/ubuntu/ hardy main restricted universe multiverse web") [11:58] <\sh> salty-horse: whoops.-.-.remove the web part :) [11:58] could it have gotten there in the gusty->hardy upgrade process? [11:59] <\sh> salty-horse: I don't think so... [11:59] <\sh> never saw it happen :) === \sh is now known as \sh_away [13:07] hi guys, where do i report bugs for ubiquity? [13:10] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+filebug [13:12] james_w: thanks [13:12] no problem === \sh_away is now known as \sh [14:00] someone knows a place where I can get tarballs ob xulrunner snapshots? [14:01] seems like mozilla only offers tarballs for releases [14:06] elmargol, asac will presumably know [14:07] elmargol: -> #ubuntu-mozillateam [14:07] ask fta [14:31] hi there, I have a debdiff for LP#188178 [14:31] how to I submit it? attach it to the bug report? [14:41] yes [14:41] secretlondon: thks for confirming [14:49] hello [14:50] hi [14:59] bug 188178 [14:59] Launchpad bug 188178 in xserver-xorg-video-intel "[Hardy] [regression] xorg with Intel driver crashes if Virtual > 2048" [Undecided,Confirmed] https://launchpad.net/bugs/188178 === tjaalton is now known as tjaalton_ [15:28] james_w was explaining to me here how to set up a debdiff earlier, which involved learning how to use debuild. Can someone help me with a problem I'm having with that, or do you know where I should go to find that? [15:28] marnanel, the hands on section of the packaging guide is good [15:29] I'm a packaging n00b and I always have problems with key signing etc [15:29] #motu is where you may find people with more packaging exerience too [15:29] experience [15:29] awesome. okay *gets more coffee, settles in* [15:30] thanks [15:30] np [15:35] morning [15:36] * afflux found a gold source :) [15:36] hello [15:37] screenlets has lots of bugs, with many of them being duplicates of others and some are really easy to fix [15:37] afflux, loads of packages are like that, unloved, especially if they've been synced untouched from debian [15:37] yep [15:38] btw., we are in feature freeze, so what should I do with bug 204894? [15:38] Launchpad bug 204894 in screenlets "Screenlets .14 released--please add to repository" [Undecided,Confirmed] https://launchpad.net/bugs/204894 [15:38] leave it confirmed, tell him that we'll put it in intrepid? [15:38] there is the exception process [15:38] does it fix loads of bugs? [15:38] right, refer the reporter to the FFe process wiki page [15:38] don't think so, checking [15:39] okay [15:55] I have made a freature freeze request but was unsure on what package to mark as affected..can someone please take a look? bug 208836 [15:55] Launchpad bug 208836 in ubuntu "Feature Freeze Exception request for Transmission 1.10" [Undecided,New] https://launchpad.net/bugs/208836 [15:58] uh, add-5-a-day ist extremly slow today : [15:59] askand: src:transmission [15:59] took me ~5 minutes to push (no pulling) a single linge change [15:59] askand: (i.e., the source package transmission) [16:01] crimsun: please take a look again, I have changed [16:16] askand: ok [16:16] askand: keep in mind that transmission is a main source package; MOTU does not have jurisdiction over its FFe approval [16:17] askand: as a result, please make sure you adhere to [the main component's] https://wiki.ubuntu.com/FreezeExceptionProcess [16:29] afflux: launchpad bzr is really slow at the moment [16:29] i need some help [16:30] my package manager will not work what do i need to do? [16:31] Nismo69: what is the error you are getting? [16:33] that i need to reload the list of packages [16:33] so it trys to do that and then it still doesn't work [16:35] hello? [16:38] i need help [16:39] Nismo69: try to open a terminal and type: sudo apt-get update [16:39] tried that too [16:40] and does that give you an error? [16:40] no [16:42] i cant load anything that is preloaded i can only load packages i download manually [16:45] Nismo69, #ubuntu is better for support queries, or you could try launchpad answers === charle1 is now known as mrooney [16:56] I've subscribed for bugmail of "ubuntu/+source/screenlets/", do I get [NEW] notifications for private bugs then? (I'm in bugcontrol) [16:57] don't think so [16:57] and don't know how to get them (if it's possible at all) [16:58] okay, I'll try asking in #lp [16:58] let me know if you got a reply :) [16:58] yep [16:59] I think there's a team which gets private crashes (as apport subscribes that team), but I'm not sure and I don't want to receive crashes for every ubuntu package [16:59] only for those packages I'm a bug contact [17:00] yes, the team is ubuntu-crashes-{universe,main} [17:00] but I'm not sure how the general bugmail subscriptions are handled [17:02] afflux, yes you do if you are the bug contact [17:03] secretlondon: the bug contact is ~ubuntu-bugs [17:03] afflux, and I think for edits to bugs on packages you've subscribed to [17:03] I am subscribed to bugs on tuxpaint and get all new and I think all changes [17:03] right [17:03] I think only 'direct' subscribers get notifications for private bugs [17:03] do you get private ones, too? [17:04] (Adri2000 is saying the opposite: he subscribed to some package and is a member of motu, but doesn't get the private notifications) [17:04] I haven't had any, but then I'm in bugcontrol so I can see crashes anyway [17:04] when you subscribe to a package in ubuntu you are 'also notified', so no direct subscriber [17:06] thekorn: that may be the point, yes [17:06] and this makes perfect sense [17:07] everybody can subscribe to bugs, and the private option is the only one to control the access to a bug [17:07] e.g. if there is private data [17:07] right [17:09] * afflux wants to have a check whether the "also notified" subscribers are also "indirect" "direct" subscribers. :P [17:37] Hi folks. PCMCIA ethernet doesn't work for me in Hardy Beta. Are others experiencing this? [17:40] vanilla Beta? [17:40] you should dist-upgrade to current [17:41] I can't without ethernet. It's the beta available from the ubuntu.com main page. [17:41] I dont mean any of the alphas. [17:42] I know, and to effectively troubleshoot, you need to reproduce it on a daily-live image [17:42] Ah, now I understand what you mean. [17:43] Are the daily images avaiable as ISOs ? [17:44] Found it. [17:44] Thank you crimsun. [17:50] marnanel, I don't know if we need to do anything so that your patch is noticed by people with commit access [17:50] secretlondon: we can just wait? [17:51] that's good, I have just started reading a novel. :) [17:51] I don't know, I hope it's a long one ;) [17:51] * marnanel laughs [17:51] (and yes: "The Mists of Avalon") [17:51] did you tick the patch box? [17:51] I did [17:52] There's also a couple of reported segfaults in metacity I really ought to be seeing to [17:52] the wiki prob has some details (as ever!), it's probably a tag or subscribing a group [17:52] I'll go look [17:52] Oh well, coffee was made to be drunk [17:52] Oh [17:53] Someone on motu said that I should subscribe the ubuntu-sponsors thing [17:53] so I duid [17:53] did [17:53] ubuntu-universe-sponsors <-- that [17:53] marnanel, there may be more segfaults that you won't have access to as they haven't been checjed for personal data [17:53] marnanel, then it's sorted :) [17:53] ah. makes sense [17:53] and: awesome [17:53] is there a way that I can have access to segfaults which people can't see? [17:54] I mean, I understand why people don't get access generally [17:54] but I'm the maintainer, and I'm pretty trustworthy generally [17:54] at least the upstream maintainer [17:54] I don't think there is a setting that can give the bug contact from upstream access [17:54] but I don't know [17:54] I get it through being a bug control [17:54] Maybe if I became a sort of honorary downstream maintainer [17:55] in the bug control team [17:55] * marnanel nods [17:55] marnanel: you can join ~ubuntu-bugcontrol and you will have access to them [17:55] marnanel: but in the meantime I can check them for you and make them public [17:56] marnanel: 6 private crashes [17:57] * secretlondon can confirm that marn is from metacity [18:15] marnanel: you will normally get a response from u-u-sponsors in a day or two [18:16] there was a discussion in here yesterday(?) about blessing certain accounts as upstream for a particular package so that they can come down and have the power to do bugcontrol things, but only on bugs in their packages. [18:16] it sounds like that would be perfect for you. [18:17] if you like I can mention your name in any more discussions about it as someone that would be interested in helping to test that. [18:17] it's easier than joining bugcontrol :-) [18:18] james_w: that'd be awesome [18:18] james_w yep, we need that for upstreams [18:18] I think the idea was to discuss it with bdmurray when he is back, and then take it to the lp folks [18:19] we should get upstream more involved into LP, and this would be a good way to do this [18:19] someone remind me to poke jcastro and bdmurray about it next week. [18:20] btw, is Mark Pitt responsible for the wiki page DebuggingProcedures? I'd like to ask him a few things [18:20] does anyone know any other upstream that would be suitable [18:20] qense: I think you mean Martin Pitt [18:21] yeah :) [18:21] qense: no, it's a wiki page [18:21] ? [18:21] qense, if anyone is responsible it'll be someone like Bmurray [18:21] oh [18:21] qense: anyone can edit wikipages, they aren't owned by anyone [18:22] I know, but I thought that for important ones certain people would be assigned [18:22] james_w: sounds a nifty idea, yes [18:23] pitti has no specific qa role afaik. I think bmurray is head of bugs for canonical [18:23] pitti wrote apport, so that may be why he has some association with the page [18:24] yep [18:24] marnanel: all done [18:24] I think he may be the person who lasted edited it [18:24] pochu: cool, thanks [18:25] yeah, no-one seems to "own" it from looking at the revision history [18:25] qense: what would you like to know? would we be able to help? [18:27] pochu: thanks a whole lot :) [18:27] I want to ask them what to do with the information there and the yet-to-be-filled Bugs/Triaging page, I think it should be merged, but I want someone else's opinion [18:29] qense: I think they should probably be merged. [18:29] is there a reason that you didn't start out by extending what was there? [18:30] pochu: I have signed up to join ~ubuntu-bugcontrol now in case that lets me fix things faster, although tbh I already have my hands full for the next short while with what I *can* see :) [18:30] :-) [18:30] you mean DebuggingProcedures? [18:31] Bugs/Triaging is a new project, focussed more on information gathered from upstream packages isntead of areas/types [18:31] marnanel: there's quite a strict admissions procedure for bugcontrol, so I don't know if you'll get it. [18:31] we want to ask upstream maintainers what they want to be included with bug reports [18:32] marnanel: though if you talked to bdmurray and explained that you are just interested in metacity bugs he may make an exception. [18:32] qense: yes, but couldn't that be folded in to the information we have already? [18:33] qense: there's both the information upstream needs for a good report, and the ways in which you can work out what is going wrong, and they seem very related. [18:33] marnanel: ^-- if you can't get in ~ubuntu-bugcontrol anytime soon feel free to ping me to go through private bugs [18:34] qense: I'm not saying you've done the wrong thing, but as you are talking about merging the pages I just wanted to understand your reasons or not starting there. [18:34] ok [18:34] pochu: cheers [18:34] james_w: sure, and that's quite understandable. [18:34] it was the way the pages were named, the only way the pages at DebuggingProcedures are linked is via that very page [18:34] all names are different [18:35] and you've got information for specific packages but also for more general things [18:37] marnanel, bug control is like the ubuntu bug squad but with more perms, giving you access is a bit kludgy [18:37] we need a way of better integrating upstreams [18:38] assign bug managers for separate packages would be the best way in my eyes [18:38] assigning* [18:38] well maybe perms by package [18:39] * marnanel is always impressed with launchpad even with its rough corners here and there [19:01] marnanel: impressed positively or negatively? :) [19:02] impressed always means positively really [19:02] you cna get a negative impression, but you wouldn't then say you were impressed [19:03]