[00:15] <secretlondon> !paste
[00:15] <ubotu> 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] <marnanel> 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] <james_w> marnanel: yes, but probably not for hardy
[00:53] <james_w> 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] <marnanel> Oh, I have to read a bedtime story.  bbiab.
[00:54] <james_w> :-)
[00:54] <james_w> 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] <mrooney> yeah we should start a nightly bedtime story ritual here
[00:55] <james_w> yay
[01:16] <nabcore> 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] <james_w> nabcore: I don't quite know what to make of that
[01:20] <james_w> is it the probing for the floppy that is slow?
[01:21] <nabcore> That's the conclusion I've come to
[01:21] <nabcore> it's weird
[01:21] <marnanel> okay, back... how would I get the patch into Hardy?
[01:21] <marnanel> I've tested it, and it does work
[01:24] <james_w> 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] <james_w> nabcore: I have seen a couple of reports about slow booting
[01:24] <james_w> I don't have numbers though I'm afraid
[01:26] <nabcore> 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] <marnanel> 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] <nabcore> james_w also, the beta does not seem to pick up correctly my Nokia 447v monitor, hence the resolution is quite low
[01:30] <nabcore> Setting it using "Screens and Graphics" and then logging out and in resolves this
[01:34] <james_w> marnanel: are you sitting comfortably?
[01:42] <marnanel> sure. (well, I'm still arranging things, but I'm listening)
[01:43] <marnanel> also I am apparently not the only one to be old enough that I listened to Listen With Mother in the seventies
[01:44] <james_w> 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] <james_w> you can then upload this diff to the bug and get it sponsored in to the archive.
[01:44] <marnanel> Okay, like a patch really, only across a whole package
[01:44] <marnanel> right.
[01:44] <james_w> yeah, exactly
[01:45] <marnanel> That makes sense.  Cool.
[01:45] <james_w> so you need 2 things, your patch, and the existing package
[01:45] <james_w> to get the latter use "apt-get source gnome-alsamixer"
[01:46] <james_w> which will create a directory with the unpacked source, so cd gnome-alsamixer-0.9.7~cvs.20060916.ds.1
[01:46] <marnanel> okay...
[01:46] <james_w> you may also need to install some things, so run
[01:47] <james_w> sudo aptitude install dpkg-dev devscripts dpatch
[01:48] <marnanel> aptitude doing its thing...
[01:49] <james_w> cool
[01:50] <james_w> are you familiar with the source package format at all?
[01:50] <james_w> or rather what goes in a debian/ directory?
[01:51] <marnanel> debian/rules and things?  Yes, but I haven't looked at it in a few years.
[01:51] <marnanel> Okay, aptitude is done at last
[01:53] <marnanel> Is there a good place to read up on the package format?  (Or you can tell me things, of course.)
[01:53] <james_w> ok, this package uses dpatch, are you familiar with it?
[01:53] <marnanel> No.
[01:53] <james_w> https://wiki.ubuntu.com/PackagingGuide
[01:53]  * marnanel goes to look
[01:53] <james_w> that's the most specific I can be off the top of my head
[01:54] <james_w> so, dpatch is a way of keeping separate upstream patches in debian/patches/ and then applying them at build time.
[01:54] <james_w> so we can just drop your patch in there and let it do its thing
[01:54] <marnanel> That makes sense.
[01:54] <james_w> however dpatch is a little strange, and so you have to run a highly cryptic command for the next bit
[01:55] <james_w> one that I am going to have to look up, one moment please
[01:58] <james_w> dpatch patch-template -p "04_<name of patch>" "<description of patch>" < <your-patch> > debian/patches/04_<name of patch>.dpatch
[01:59] <james_w> there are two redirections there, as well as the variables for you to fill in
[01:59] <marnanel> right
[01:59] <marnanel> what does the 04_ mean?
[01:59] <marnanel> I mean, obviously a filename prefix
[01:59] <james_w> 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] <marnanel> but why 04_ ?
[01:59] <marnanel> oh, because there are already three others
[02:00] <james_w> by convention they are numbered
[02:00] <james_w> exactly
[02:00] <james_w> the -p tells it to prepend that header to standard input
[02:00] <marnanel> awesome.
[02:00] <james_w> you should then check that the file created looks sane, you can pastebin it if you would like me to check
[02:00] <marnanel> right...
[02:01]  * marnanel tries to fix all this up to this point
[02:05] <marnanel> Does it make any difference what "name of patch" is?
[02:06] <james_w> nope, but it's helpful to make it slightly descriptive
[02:06] <marnanel> Makes sense.
[02:06] <james_w> fix_bugnumber is quite common
[02:06] <james_w> fix_whatever_it_fixes as well
[02:06] <marnanel> 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] <james_w> 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] <james_w> 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] <marnanel> oh, thanks-- I had started to wonder
[02:11] <james_w> yeah, dpatch works with both, but requires one as I remember
[02:13] <james_w> how's it looking?
[02:13] <marnanel> oops, I used 04-, it should be 04_
[02:13]  * marnanel does it again
[02:14] <james_w> I don't think it matters much
[02:15] <marnanel> 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] <james_w> cool, so the next step is to check that it applies
[02:18] <james_w> this means that it must also apply with the other three patches applied first.
[02:18] <marnanel> Okay...
[02:18] <james_w> I don't think there will be conflicts but it is good to check at this stage
[02:18] <james_w> to do that run dpatch apply-ll
[02:18] <james_w> apply-all sorry
[02:19] <james_w> ah, no, first we have to add it to the series file so that dpatch knows about it
[02:19] <james_w> so edit debian/patches/series and add the filename to the end
[02:21] <marnanel> Okay, sure
[02:22] <marnanel> Okay, and I ran dpatch apply-all, and it returned without printing anything.
[02:23] <james_w> hmm, that's not right
[02:24] <james_w> ah, crazy, it's not dpatch at all, it's quilt, but with dpatch headers in the files
[02:24] <marnanel> It also appears not to have applied the patched :/
[02:24] <marnanel> Oh, weirdness.
[02:24] <marnanel> Okay, so I run quilt?
[02:25] <james_w> yes, but quilt is not debian specific, so there's an environment variable to set
[02:25] <james_w> the easiest way to do this though is use debian/rules
[02:25] <james_w> so run ./debian/rules patch
[02:25] <james_w> ah, but I bet you'll have to "sudo aptitude install quilt"
[02:25] <james_w> first
[02:26] <james_w> oh, in fact "sudo aptitude install quilt cdbs"
[02:26] <james_w> this package uses cdbs, which is a set of makefiles try and simplify debian/rules in common situations
[02:26] <marnanel> It is thinking about it...
[02:26] <marnanel> right..
[02:29] <marnanel> Okay, installed.  (This is not the fastest computer in the world.)
[02:30] <james_w> okay, so does ./debian rules patch work now?
[02:31] <marnanel> make: *** No rule to make target `patch'.  Stop.
[02:31] <marnanel> Hm.
[02:32] <james_w> ah, sorry my fault the target is apply-patches
[02:36] <marnanel> oh, sorry!
[02:36] <marnanel> *tries*
[02:38] <marnanel> Hm, that patched everything but 04_ and that said: make: *** [debian/stamp-patched] Error 1
[02:38] <marnanel> Which wasn't very informative
[02:38] <marnanel> :(
[02:39] <james_w> there was no error above?
[02:39] <james_w> it may conflict then
[02:39] <marnanel> Oh, good point.  It doesn't conflict upstream but perhaps it does with the patched version.
[02:39] <marnanel> Would the output of patch have been saved somewhere?
[02:40] <marnanel> I can just reapply the patch to the patched version and see
[02:40] <james_w> I'm not sure, you can see it with
[02:40] <james_w> QUILT_PATCHES=debian/patches quilt push
[02:43] <marnanel> oh, silly me, I named the file foo.diff.dpatch for some reason
[02:50] <marnanel> yay, and found the other problem
[02:51] <marnanel> if you create a patch using svn diff and you're in trunk, which is the way we do it upstream
[02:51] <marnanel> then the filenames in the patch look like src/foo.c
[02:51] <marnanel> but it turns out debian-rules wants them like gnome-alsamixer/src/foo.c
[02:51] <james_w> ah, so you want to edit debian/patches/series and add -p0 to the end of the line
[02:51] <james_w> I think that's right
[02:52] <marnanel> 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] <james_w> that works too
[02:55] <marnanel> Okay, so I appear to have a working patch.  I should compile and link and test next?
[02:56] <james_w> well, it's better to test the final package, so we'll carry on with that
[02:56] <james_w> the clean target or debian/rules will take care of de-applying the patches, so we'll just do the next bit
[02:56] <james_w> that is to edit the changelog
[02:57] <james_w> there is a tools called "dch" (it's actually debchangelog I think)
[02:57] <james_w> if you run "dch -i" then you will be given a new changelog stanza to fill in your changes.
[02:58] <james_w> 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] <james_w> (or you can just edit it)
[03:00] <marnanel> Okay
[03:01]  * marnanel laughs.  I am apparently marnanel@localhost.localdomain
[03:01]  * marnanel fixes it up
[03:01] <james_w> well, it's kind of accurate
[03:01] <marnanel> true...
[03:02] <james_w> you can set DEBEMAIL in your environment to choose what you want to be known as for packages
[03:02] <james_w> man dch explains it all if you care
[03:02] <james_w> so you should explain what you are fixing and how.
[03:02] <james_w> also here you would put any notes to the release team as we are close to release
[03:03] <james_w> and also any notes to possible future people who work on the package
[03:03] <james_w> I don't think they apply here
[03:03] <james_w> 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] <marnanel> right.  What goes next to the * I can see?
[03:04] <james_w> that's where you put the change
[03:04] <james_w> you use a * for each separate change
[03:04] <james_w>   * Fix a
[03:04] <james_w>     - including this
[03:04] <james_w>   * Fix b
[03:05] <james_w> so you only need one
[03:05] <marnanel> Oh, okay.  But my name goes at the bottom with the -- next to it?
[03:05] <james_w> yep
[03:05] <james_w> 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] <james_w> so at the end of the change put (LP: #<bug number>)
[03:06] <marnanel> 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] <marnanel> okay...
[03:07] <marnanel> Do I need to do wordwrap or does it do that for me?
[03:07] <james_w> yeah, it's fantastic, I would recommend that every project adopt it
[03:07] <james_w> you need to wrap
[03:08] <james_w> use four spaces for any continuation lines
[03:08] <james_w> (only two are required by the format, but four is convention)
[03:09] <marnanel> Okay, sure
[03:09] <marnanel> 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] <james_w> there's only one way to find out :-)
[03:11]  * marnanel grins
[03:17] <marnanel> whoah, writing LP: #nnnnnn in Vim lights up in yellow
[03:18] <james_w> yep, useful to know you've got the right syntax.
[03:18] <james_w> so, once you've saved it you can try building the package
[03:19] <marnanel> And that's debian/rules something?
[03:19] <james_w> there's a wrapper, well, actually a wrapper of a wrapper, called debuild
[03:19] <james_w> so you wan't "debuild -uc -us"
[03:20] <james_w> those options tell it not to bother signing anything, as signatures don't matter for a test-build
[03:20] <marnanel> okay, great
[03:21]  * marnanel installs patchutils
[03:21] <james_w> ah, you'll need gnome-pkg-tools libgnomeui-dev libasound2-dev autotools-dev intltool as well
[03:22] <james_w> I guess you'll have at least some of them if you've been building the package already.
[03:24] <marnanel> apparently I have all of them, so here goes :)
[03:24] <marnanel> This is pretty awesome.  I wish we were this organised with tools and things
[03:25] <james_w> some would call it a mess
[03:25] <james_w> 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] <james_w> bug dch debuild etc. are good
[03:26] <marnanel> crunch.  link error.  clearly my problem.  *pours more tea*
[03:38]  * marnanel idles for a few minutes-- called away
[03:38] <marnanel> james_w: thank you for your help, in case you leave before I come back.  I appreciate it very much.
[03:39] <james_w> marnanel: yeah, it's late here, I'll be leaving shortly
[03:39] <james_w> I'll probably be around tomorrow if you are
[03:39] <james_w> also there is #ubuntu-motu where someone will probably be able to walk you through the last part
[03:40] <james_w> once you get the package built you should install and test it.
[03:40] <james_w> then make the debdiff
[03:40] <james_w> this is done by building a source package "debuild -S -uc -us"
[03:40] <james_w> and then calling debdiff old.dsc new.dsc
[03:41] <james_w> then attach that to the bug and subscribe ubuntu-universe-sponsors
[03:41] <james_w> but as I said, someone on #ubuntu-motu can help you out if I'm not around
[03:41] <james_w> also there is https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[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] <qense> hello
[10:36] <Iulian> G'morning
[10:37] <qense> hello
[10:37] <Iulian> Hi qense
[11:43] <salty-horse> 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] <salty-horse> I tried this command: "sudo apt-get update". when trying "sudo apt-get build-dep <something> 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] <salty-horse> \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] <salty-horse> 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 :)
[13:07] <danbee> hi guys, where do i report bugs for ubiquity?
[13:10] <james_w> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+filebug
[13:12] <danbee> james_w: thanks
[13:12] <james_w> no problem
[14:00] <elmargol> someone knows a place where I can get tarballs ob xulrunner snapshots?
[14:01] <elmargol> seems like mozilla only offers tarballs for releases
[14:06] <secretlondon> elmargol, asac will presumably know
[14:07] <asac> elmargol: -> #ubuntu-mozillateam
[14:07] <asac> ask fta
[14:31] <chantra> hi there, I have a debdiff for LP#188178
[14:31] <chantra> how to I submit it? attach it to the bug report?
[14:41] <secretlondon> yes
[14:41] <chantra> secretlondon: thks for confirming
[14:49] <qense> hello
[14:50] <secretlondon> hi
[14:59] <pochu> bug 188178
[14:59] <ubotu> 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
[15:28] <marnanel> 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] <secretlondon> marnanel, the hands on section of the packaging guide is good
[15:29] <secretlondon> I'm a packaging n00b and I always have problems with key signing etc
[15:29] <secretlondon> #motu is where you may find people with more packaging exerience too
[15:29] <secretlondon> experience
[15:29] <marnanel> awesome.  okay *gets more coffee, settles in*
[15:30] <marnanel> thanks
[15:30] <secretlondon> np
[15:35] <afflux> morning
[15:36]  * afflux found a gold source :)
[15:36] <qense> hello
[15:37] <afflux> screenlets has lots of bugs, with many of them being duplicates of others and some are really easy to fix
[15:37] <secretlondon> afflux, loads of packages are like that, unloved, especially if they've been synced untouched from debian
[15:37] <afflux> yep
[15:38] <afflux> btw., we are in feature freeze, so what should I do with bug 204894?
[15:38] <ubotu> Launchpad bug 204894 in screenlets "Screenlets .14 released--please add to repository" [Undecided,Confirmed] https://launchpad.net/bugs/204894
[15:38] <afflux> leave it confirmed, tell him that we'll put it in intrepid?
[15:38] <secretlondon> there is the exception process
[15:38] <secretlondon> does it fix loads of bugs?
[15:38] <crimsun> right, refer the reporter to the FFe process wiki page
[15:38] <afflux> don't think so, checking
[15:39] <afflux> okay
[15:55] <askand> 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] <ubotu> Launchpad bug 208836 in ubuntu "Feature Freeze Exception request for Transmission 1.10" [Undecided,New] https://launchpad.net/bugs/208836
[15:58] <afflux> uh, add-5-a-day ist extremly slow today :
[15:59] <crimsun> askand: src:transmission
[15:59] <afflux> took me ~5 minutes to push (no pulling) a single linge change
[15:59] <crimsun> askand: (i.e., the source package transmission)
[16:01] <askand> crimsun: please take a look again, I have changed
[16:16] <crimsun> askand: ok
[16:16] <crimsun> askand: keep in mind that transmission is a main source package; MOTU does not have jurisdiction over its FFe approval
[16:17] <crimsun> askand: as a result, please make sure you adhere to [the main component's] https://wiki.ubuntu.com/FreezeExceptionProcess
[16:29] <james_w> afflux: launchpad bzr is really slow at the moment
[16:29] <Nismo69> i need some help
[16:30] <Nismo69> my package manager will not work what do i need to do?
[16:31] <james_w> Nismo69: what is the error you are getting?
[16:33] <Nismo69> that i need to reload the list of packages
[16:33] <Nismo69> so it trys to do that and then it still doesn't work
[16:35] <Nismo69> hello?
[16:38] <Nismo69> i need help
[16:39] <stpere> Nismo69: try to open a terminal and type: sudo apt-get update
[16:39] <Nismo69> tried that too
[16:40] <james_w> and does that give you an error?
[16:40] <Nismo69> no
[16:42] <Nismo69> i cant load anything that is preloaded i can only load packages i download manually
[16:45] <secretlondon> Nismo69, #ubuntu is better for support queries, or you could try launchpad answers
[16:56] <afflux> I've subscribed for bugmail of "ubuntu/+source/screenlets/", do I get [NEW] notifications for private bugs  then? (I'm in bugcontrol)
[16:57] <pochu> don't think so
[16:57] <pochu> and don't know how to get them (if it's possible at all)
[16:58] <afflux> okay, I'll try asking in #lp
[16:58] <pochu> let me know if you got a reply :)
[16:58] <afflux> yep
[16:59] <pochu> 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] <pochu> only for those packages I'm a bug contact
[17:00] <afflux> yes, the team is ubuntu-crashes-{universe,main}
[17:00] <afflux> but I'm not sure how the general bugmail subscriptions are handled
[17:02] <secretlondon> afflux, yes you do if you are the bug contact
[17:03] <afflux> secretlondon: the bug contact is ~ubuntu-bugs
[17:03] <secretlondon> afflux, and I think for edits to bugs on packages you've subscribed to
[17:03] <secretlondon> I am subscribed to bugs on tuxpaint and get all new and I think all changes
[17:03] <afflux> right
[17:03] <thekorn> I think only 'direct' subscribers get notifications for private bugs
[17:03] <afflux> do you get private ones, too?
[17:04] <afflux> (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] <secretlondon> I haven't had any, but then I'm in bugcontrol so I can see crashes anyway
[17:04] <thekorn> when you subscribe to a package in ubuntu you are 'also notified', so no direct subscriber
[17:06] <afflux> thekorn: that may be the point, yes
[17:06] <thekorn> and this makes perfect sense
[17:07] <thekorn> everybody can subscribe to bugs, and the private option is the only one to control the access to a bug
[17:07] <thekorn> e.g. if there is private data
[17:07] <afflux> right
[17:09]  * afflux wants to have a check whether the "also notified" subscribers are also "indirect" "direct" subscribers. :P
[17:37] <jarlath> Hi folks. PCMCIA ethernet doesn't work for me in Hardy Beta. Are others experiencing this?
[17:40] <crimsun> vanilla Beta?
[17:40] <crimsun> you should dist-upgrade to current
[17:41] <jarlath> I can't without ethernet. It's the beta available from the ubuntu.com main page.
[17:41] <jarlath> I dont mean any of the alphas.
[17:42] <crimsun> I know, and to effectively troubleshoot, you need to reproduce it on a daily-live image
[17:42] <jarlath> Ah, now I understand what you mean.
[17:43] <jarlath> Are the daily images avaiable as ISOs ?
[17:44] <jarlath> Found it.
[17:44] <jarlath> Thank you crimsun.
[17:50] <secretlondon> marnanel, I don't know if we need to do anything so that your patch is noticed by people with commit access
[17:50] <marnanel> secretlondon: we can just wait?
[17:51] <marnanel> that's good, I have just started reading a novel. :)
[17:51] <secretlondon> I don't know, I hope it's a long one ;)
[17:51]  * marnanel laughs
[17:51] <marnanel> (and yes: "The Mists of Avalon")
[17:51] <secretlondon> did you tick the patch box?
[17:51] <marnanel> I did
[17:52] <marnanel> There's also a couple of reported segfaults in metacity I really ought to be seeing to
[17:52] <secretlondon> the wiki prob has some details (as ever!), it's probably a tag or subscribing a group
[17:52] <secretlondon> I'll go look
[17:52] <marnanel> Oh well, coffee was made to be drunk
[17:52] <marnanel> Oh
[17:53] <marnanel> Someone on motu said that I should subscribe the ubuntu-sponsors thing
[17:53] <marnanel> so I duid
[17:53] <marnanel> did
[17:53] <marnanel> ubuntu-universe-sponsors <-- that
[17:53] <secretlondon> marnanel, there may be more segfaults that you won't have access to as they haven't been checjed for personal data
[17:53] <secretlondon> marnanel, then it's sorted :)
[17:53] <marnanel> ah.  makes sense
[17:53] <marnanel> and: awesome
[17:53] <marnanel> is there a way that I can have access to segfaults which people can't see?
[17:54] <marnanel> I mean, I understand why people don't get access generally
[17:54] <marnanel> but I'm the maintainer, and I'm pretty trustworthy generally
[17:54] <marnanel> at least the upstream maintainer
[17:54] <secretlondon> I don't think there is a setting that can give the bug contact from upstream access
[17:54] <secretlondon> but I don't know
[17:54] <secretlondon> I get it through being a bug control
[17:54] <marnanel> Maybe if I became a sort of honorary downstream maintainer
[17:55] <secretlondon> in the bug control team
[17:55]  * marnanel nods
[17:55] <pochu> marnanel: you can join ~ubuntu-bugcontrol and you will have access to them
[17:55] <pochu> marnanel: but in the meantime I can check them for you and make them public
[17:56] <pochu> marnanel: 6 private crashes
[17:57]  * secretlondon can confirm that marn is from metacity
[18:15] <james_w> marnanel: you will normally get a response from u-u-sponsors in a day or two
[18:16] <james_w> 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] <james_w> it sounds like that would be perfect for you.
[18:17] <james_w> 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] <james_w> it's easier than joining bugcontrol :-)
[18:18] <pochu> james_w: that'd be awesome
[18:18] <secretlondon> james_w yep, we need that for upstreams
[18:18] <james_w> I think the idea was to discuss it with bdmurray when he is back, and then take it to the lp folks
[18:19] <qense> we should get upstream more involved into LP, and this would be a good way to do this
[18:19] <james_w> someone remind me to poke jcastro and bdmurray about it next week.
[18:20] <qense> btw, is Mark Pitt responsible for the wiki page DebuggingProcedures? I'd like to ask him a few things
[18:20] <james_w> does anyone know any other upstream that would be suitable
[18:20] <james_w> qense: I think you mean Martin Pitt
[18:21] <qense> yeah :)
[18:21] <secretlondon> qense: no, it's a wiki page
[18:21] <qense> ?
[18:21] <secretlondon> qense, if anyone is responsible it'll be someone like Bmurray
[18:21] <qense> oh
[18:21] <secretlondon> qense: anyone can edit wikipages, they aren't owned by anyone
[18:22] <qense> I know, but I thought that for important ones certain people would be assigned
[18:22] <marnanel> james_w: sounds a nifty idea, yes
[18:23] <secretlondon> pitti has no specific qa role afaik. I think bmurray is head of bugs for canonical
[18:23] <james_w> pitti wrote apport, so that may be why he has some association with the page
[18:24] <secretlondon> yep
[18:24] <pochu> marnanel: all done
[18:24] <secretlondon> I think he may be the person who lasted edited it
[18:24] <secretlondon> pochu: cool, thanks
[18:25] <james_w> yeah, no-one seems to "own" it from looking at the revision history
[18:25] <james_w> qense: what would you like to know? would we be able to help?
[18:27] <marnanel> pochu: thanks a whole lot :)
[18:27] <qense> 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] <james_w> qense: I think they should probably be merged.
[18:29] <james_w> is there a reason that you didn't start out by extending what was there?
[18:30] <marnanel> 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] <james_w> :-)
[18:30] <qense> you mean DebuggingProcedures?
[18:31] <qense> Bugs/Triaging is a new project, focussed more on information gathered from upstream packages isntead of areas/types
[18:31] <james_w> marnanel: there's quite a strict admissions procedure for bugcontrol, so I don't know if you'll get it.
[18:31] <qense> we want to ask upstream maintainers what they want to be included with bug reports
[18:32] <james_w> marnanel: though if you talked to bdmurray and explained that you are just interested in metacity bugs he may make an exception.
[18:32] <james_w> qense: yes, but couldn't that be folded in to the information we have already?
[18:33] <james_w> 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] <pochu> marnanel: ^-- if you can't get in ~ubuntu-bugcontrol anytime soon feel free to ping me to go through private bugs
[18:34] <james_w> 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] <qense> ok
[18:34] <marnanel> pochu: cheers
[18:34] <marnanel> james_w: sure, and that's quite understandable.
[18:34] <qense> it was the way the pages were named, the only way the pages at DebuggingProcedures are linked is via that very page
[18:34] <qense> all names are different
[18:35] <qense> and you've got information for specific packages but also for more general things
[18:37] <secretlondon> marnanel, bug control is like the ubuntu bug squad but with more perms, giving you access is a bit kludgy
[18:37] <secretlondon> we need a way of better integrating upstreams
[18:38] <qense> assign bug managers for separate packages would be the best way in my eyes
[18:38] <qense> assigning*
[18:38] <secretlondon> well maybe perms by package
[18:39]  * marnanel is always impressed with launchpad even with its rough corners here and there
[19:01] <pochu> marnanel: impressed positively or negatively? :)
[19:02] <secretlondon> impressed always means positively really
[19:02] <secretlondon> you cna get a negative impression, but you wouldn't then say you were impressed
[19:03] <crimsun> depends on the colloquialism.
[19:03] <crimsun> e.g., people do use "that's impressive" with a negative connotation
[19:04] <Flannel> But thats usually sarcastic, crimsun
[19:04] <Flannel> not a genuine negative impression
[19:05] <secretlondon> Flannel, I agree
[19:06] <crimsun> Flannel: I concur, since we're being pedantic.  However, "means" refers to connotation
[19:07] <secretlondon> I don't think marnanel's statement was ambiguous at all
[19:07] <crimsun> neither do I given the context
[19:08] <pochu> thank you all :)
[19:08] <pochu> (I'm not native speaker so I didn't know that)
[19:12]  * marnanel gets this all the time learning languages other than English
[19:13] <seb128> hey marnanel
[19:13] <seb128> marnanel: thanks for look at the bugs on launchpad, appreciated ;-)
[19:13]  * secretlondon nods
[19:13] <seb128> s/look/looking
[19:14] <marnanel> seb128: no problem, it always needs doing and I should have looked earlier
[19:15] <marnanel> pochu: it's a bit like if I said "The number of critical bugs in metacity is a fraction of what it was last year".  Now clearly 3/1 is a fraction...
[19:15] <seb128> marnanel: we are trying to send those on bugzilla with enough informations, but there is lot of bug and limited ressources
[19:15] <marnanel> seb128: yes, I've noticed that and I'm very glad of it.  I do try to keep up with LP too.
[19:16] <seb128> marnanel: it seems that the appearance capplet triggers quite some crashers in the theme preview code though, dunno if you noticed some bugs have several duplicates
[19:16] <marnanel> seb128: It would help if GNOME's bugzilla allowed bugs to be automaticlaly raised
[19:16] <marnanel> seb128: yes, just commented to that
[19:16] <seb128> right
[19:16] <marnanel> Apparently that needs bz 3 but we can't upgrade to that until someone does a ton of work which I could do but am too busy fixing window managers
[19:16] <secretlondon> seb128 There seems to be a problem with upstream maintainers not being given access to apport bugs until they are checked (we fixed for metacity)
[19:17] <marnanel> and, you know, going to work and playing with my kid and stuff. :)
[19:17] <seb128> secretlondon: that's a known issue and they are working to gix it
[19:17] <secretlondon> seb128 cool :)
[19:17] <seb128> s/gix/fix
[19:17] <seb128> the issue is that right now they don't have per component granularity
[19:17] <secretlondon> yep
[19:17] <fole> hi all, how should i deal with an apport bug where the CoreDump.gz still exists?
[19:17] <seb128> fole: remove it
[19:18] <fole> mark as invalid?
[19:18] <secretlondon> no
[19:18] <seb128> fole: bug number?
[19:18] <fole> or remove the file and ask for details
[19:18] <seb128> well, depends of the bug
[19:18] <fole> #193447
[19:18] <secretlondon> has any retracing happened?
[19:18] <seb128> bug #193447
[19:18] <secretlondon> bug #193447
[19:18] <ubotu> Launchpad bug 193447 in firefox-3.0 "firefox crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/193447
[19:19] <seb128> you can remove the dump and ask for informations
[19:19] <seb128> the versions changed since so it'll not be usuable
[19:19] <secretlondon> looks like apport hasn't looked at it
[19:19] <seb128> I would close and ask the submitter to open a new bug using apport if he still get the issue with the current version
[19:20] <seb128> secretlondon: it has, it has been untagged
[19:20] <secretlondon> ah
[19:20] <seb128> secretlondon: likely the retracing failed and the retracer just untagged, that happens sometime, retracer bugs
[19:20] <secretlondon> ok ty
[19:20] <fole> ok
[19:20] <fole> thanks
[19:24] <mrooney> I sure am having trouble deciding if one of bug 151564 and bug 151226 are duplicates of each other in any way
[19:24] <ubotu> Launchpad bug 151564 in ubuntu "[needs packaging] Gtk2::Sexy Perl bindings - libgtk2-sexy-perl" [Wishlist,Triaged] https://launchpad.net/bugs/151564
[19:24] <ubotu> Launchpad bug 151226 in checkgmail "Synaptic recommends libsexymm2, which is useless (missing Perl bindings)" [Undecided,Confirmed] https://launchpad.net/bugs/151226
[19:24] <mrooney> it seems like they aren't dups, but one depends on the other hmm
[19:26] <Tuv0k> http://pastebin.com/d6acd385b
[19:32] <crimsun> mrooney: not dupes, no.
[19:32] <mrooney> is there something else useful I could, some way to link them better?
[19:34] <crimsun> you could refer to 151564 in 151226
[19:35] <crimsun> I've seen some devs actually mark unrelated bugs dupes, but that's SEP.
[19:51] <warrend> hi
[19:51] <warrend> could someone look at this bug? https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/188764
[19:51] <warrend> (finally the correct channel :P)
[19:55] <mrooney> hi warrend
[19:55] <warrend> hi
[19:55] <mrooney> is usplash the loading screen with the progress bar, after grub?
[19:55] <warrend> yes
[19:56] <mrooney> argh I have this bug too after going to Hardy!!!
[19:56] <warrend> i find it personally a critical bug
[19:56] <mrooney> well yeah it looks pretty poor on my 1400x1050 display, whereas it was pretty slick before in Gutsy
[19:57] <warrend> yes
[19:57] <mrooney> though the High importance seems pretty fair, it doesn't have any functional consequences
[19:57] <warrend> would be nice to fix for hardy
[19:57] <mrooney> does it?
[19:57] <warrend> no
[19:57] <warrend> but it looks bad
[19:58] <warrend> but it is important enought to be fixed quikly in hardy i think
[20:01] <warrend> someone knoows if it will be fixed for hardy?
[20:01] <afflux> ...?
[20:02] <afflux> n/c :)
[20:07] <mrooney> whoa, did someone just change it?
[20:10] <afflux> "it"?
[20:15] <secretlondon> the bug priority?
[20:15] <secretlondon> well I agree it's not critical or high
[20:15] <secretlondon> it's a cosmetic issue
[20:15] <mrooney> bug 188764 that we were discussing, and I found the answer that yes someone changed it from High to Medium and invalidated it against usplash
[20:15] <ubotu> Launchpad bug 188764 in usplash "[hardy]640x480 usplash on all computers" [Undecided,Invalid] https://launchpad.net/bugs/188764
[20:15] <mrooney> both of which I disagree with and explained why in the comments :[
[20:16] <secretlondon> and said it is ubiquity
[20:16] <secretlondon> and medium
[20:16] <mrooney> but if the real solution is to detect in usplash, then it should be a bug against that as well, shouldn't it?
[20:16] <secretlondon> it doesn't have a severe enough impact for a high bug
[20:17] <secretlondon> well I presume the person who set it on ubiquity knows what the cause is
[20:17] <mrooney> fixing the issue in ubiquity is a workaround that would be temporarily good, but usplash is where the fix belongs I believe, as the other comments explain
[20:20] <afflux> andrea-bs: ping
[20:20] <andrea-bs> afflux: pong
[20:21] <afflux> mrooney has questions on the triaging of bug 188764
[20:21] <ubotu> Launchpad bug 188764 in usplash "[hardy]640x480 usplash on all computers" [Undecided,Invalid] https://launchpad.net/bugs/188764
[20:22] <mrooney> hehe
[20:22] <mrooney> andrea-bs: maybe you know more about the validity of fixing the issue in usplash than I do
[20:23] <mrooney> but it seems convincing to me based on the comments that the real fix belongs there and as such the bug is equally valid against both ubiquity and usplash
[20:23] <mrooney> perhaps more urgently in ubiquity than usplash, admittedly
[20:24] <afflux> by the way, someone with knowledge of g-s-d for bug 208365? I've no real idea about what the reporter talks :)
[20:24] <ubotu> Launchpad bug 208365 in gnome-settings-daemon "There was an error starting the GNOME Settings Daemon (timeout?)" [Undecided,Confirmed] https://launchpad.net/bugs/208365
[20:25] <secretlondon> There is no way it is high, it doesn't stop anyone doing anything, it just looks less pretty *whilst booting*
[20:25] <andrea-bs> mrooney: yeah, it seems an usplash package issue, thanks
[20:26] <andrea-bs> mrooney: I have to invalidate it in ubiquity since it only installs the deb
[20:27] <andrea-bs> mrooney: for the importance, I have to follow those rules: https://wiki.ubuntu.com/Bugs/Importance
[20:31] <mrooney> andrea-bs: yeah I understand in ways
[20:31] <mrooney> I just feel like usplash is a special exception, it is the first thing users see of Ubuntu, it is their first impression
[20:32] <mrooney> and not only that, but anyone around those users is going to see the loading screen, and that can give off an unprofessional impression to non-users as well
[20:32] <secretlondon> if you are affected by a bug it can seem really important, when overall it isn't
[20:32] <mrooney> secretlondon: yes, that is true
[20:33] <mrooney> I just feel like the first impression of the OS warrants more consideration and polish
[20:33] <andrea-bs> mrooney: I'm sure this is an important bug, but try to change point of view: there are more important bugs than this one ;)
[20:33] <mrooney> personally I don't care, I just figured it was an intentional feature
[20:33] <mrooney> well you could use that logic for all but the most important bug
[20:33] <secretlondon> there are loads of people having issues with pulse audio for example, and firefox 3
[20:33] <mrooney> I am not sure if that is particularly useful
[20:34] <secretlondon> these actually stop people doing things
[20:34] <mrooney> yeah I agree those are more important
[20:35] <mrooney> but the people who would fix a firefox or a pulseaudio bug probably aren't even the same people who would be fixing this
[20:38] <mrooney> andrea-bs: so you don't think the bug can be valid in both ubiquity and usplash?
[20:38] <andrea-bs> an High bug would be "usplash crashes" or "usplash doesn't start", but not "usplash starts with a low resolution", that's because this doesn't impede your work
[20:39] <andrea-bs> mrooney: ubiquity just run the postinst script which is in the usplash package
[20:40] <mrooney> ahh okay, that makes sense
[20:42] <andrea-bs> afflux: he has not enough ram memory
[20:43] <andrea-bs> afflux: I had the same problem with my 256MB PC, maybe the LiveCD should give an error before booting
[20:44] <andrea-bs> afflux: (I'm speaking about 208365)
[20:44] <afflux> jep
[20:44] <afflux>  right, I must have missed his ram size. well, I recall having read a note that the livecd is suitable only for 384MB+x, is that still true?
[20:45] <andrea-bs> probably, but I'm not sure
[20:45] <afflux> k, I'll ask in -devel.
[20:46] <andrea-bs> maybe -installer it's better
[20:47] <afflux> oh, a new channel :) didn't know that one
[20:52] <marnanel> Who do I cc if I add a debdiff to a main bug?
[20:52] <pochu> subscribe ~ubuntu-main-sponsors
[20:52] <marnanel> pochu: cheers
[20:52] <pochu> anytime
[20:53] <seb128__> marnanel: hardy will have GNOME 2.22.1 so if you commit something to the upstream svn you can just wait a week to get in hardy
[20:54] <seb128__> marnanel: but patching can be a good wait to get users trying the change before 2.22.1 ;-)
[20:58] <marnanel> seb128__: okay, sure
[20:58] <afflux> andrea-bs: ah, me again. bug 201649, did you mark it as commited because you're uploading something to ubuntu or because of the fix in the branch?
[20:58] <ubotu> Bug 201649 on http://launchpad.net/bugs/201649 is private
[20:59] <andrea-bs> afflux: because it's fixed upstream
[21:00] <afflux> andrea-bs: checking Bugs/Status, that's rather for "the changes are pending and to be uploaded soon (it's what PENDINGUPLOAD was in Bugzilla)"
[21:01] <afflux> (that is wiki.u.c/Bugs/Status)
[21:01] <andrea-bs> afflux: "For upstream projects, the fix is in CVS/SVN/bzr or committed to some place"
[21:01] <afflux> yes
[21:02] <afflux> the upstream project is "fix released", but the ubuntu package is not even being worked on
[21:03] <andrea-bs> so what's the problem? :)
[21:03] <afflux> in my understanding, the task on the ubuntu source package is entirely to reflect the progress on the ubuntu side
[21:03] <andrea-bs> I'm following standard procedures described in the wiki: <https://wiki.ubuntu.com/Bugs/Status>
[21:04] <pochu> we do that (set to fix committed when upstream has fixed it) for GNOME packages, but we now we will have a new release before Ubuntu is released, as the schedules are aligned
[21:05] <afflux> andrea-bs: yes, imo the page states that the upstream task gets fix committed when the fix is in a branch
[21:05] <andrea-bs> afflux: the fix is in a branch: http://bazaar.launchpad.net/~screenlets-dev/screenlets/trunk/revision/222
[21:05] <afflux> yes
[21:05] <afflux> it's even released
[21:06] <afflux> that's why the *upstream task* is "fix released"
[21:06] <pochu> that's an upstream branch though, not a packaging one
[21:06] <afflux> but not ubuntu :)
[21:06] <afflux> anyway, I'll set it to "in progress" as I'm preparing a debdiff for that and another screenlets bug
[21:44] <afflux> "Verification on package /var/cache/apt/archives/tzdata_2008b-1ubuntu1_all.deb failed!" where is this message from and what does it mean?
[21:44] <afflux> (see https://bugs.edge.launchpad.net/~dx4kubuntu )
[21:47] <pochu> Binary package hint: update-manager
[21:47] <pochu> perhaps he doesn't have the archive.ubuntu.com key
[21:48] <secretlondon> does sound like a key issue
[21:49] <pochu> mvo might know better. this cycle the code has changed as to warn if the packages aren't signed or the key isn't in the apt keyring I think
[21:55] <afflux> pochu: how can I check this?
[21:57] <pochu> afflux: sudo apt-key list
[21:57] <afflux> do you think that I can duplicte all of his bugs?
[21:57] <pochu> yes
[21:57] <afflux> I mean, all of the verification ones
[21:58] <afflux> k, thanks
[21:59] <pochu> thanks to you for dealing with them :)
[22:10] <afflux> should reporters in generall set their bugs back to "new" after they provided information when the bug was set to "incomplete"?
[22:18] <afflux> going to bed now, good night!
[22:38]  * DOOM_NX i'm gonna send u to outer space, to fiiind another race.