[12:47] <imbrandon> nixternal: ping
[01:14] <nixternal> imbrandon: pong?
[01:15] <nixternal> imbrandon: highlight me when you come back, I am working on a paper and will have irssi tucked away in yakuake
[01:19] <imbrandon> nixternal: i was just gonna let you know there was a bunch of wordpress database errors on blog.nixternal.com ( i was adding a link to my blogroll )
[01:19] <nixternal> ya
[01:19] <nixternal> stupid 2.3 update
[01:19] <imbrandon> yea i'm customizing my 2.3 install now
[01:19] <nixternal> I is odd, the one that is causing errors isn't causing errors in the other part...I need to go through the code and probably change the post2cat to post2term and what not
[01:19] <nixternal> s/I/It
[01:20] <nixternal> we all know I am already odd
[01:20] <imbrandon> heh well actualy i think there was a script to fix the db on planet.debian.org the orther day
[01:20] <nixternal> I think categories -> terms, cat_id -> term_id, and I forgot the other one I need to look at
[01:20] <nixternal> hrmm, I will take a look at it
[01:20] <nixternal> that stupid blog has been annoying as all hell
[01:21] <imbrandon> heh i just re-did mine today after months
[01:21] <imbrandon> fresh install
[01:21] <nixternal> my admin page hasn't worked for the past 3 releases, and wordpress devs said it was my servers fault, and then when I upgrade to 2.3, it all of a sudden works again
[01:22] <nixternal> you going to UDS?
[01:22] <imbrandon> heh
[01:22] <imbrandon> not sure
[01:22] <nixternal> ya same here...I am going to try and at least hit up fosscamp and meet up with some of the KDE guys
[01:23] <imbrandon> i like my theme alot better now
[01:23] <imbrandon> but i still am tweaking it  for tags now
[01:23] <nixternal> ahh, congrats btw...didn't know you got married
[01:24] <nixternal> of course I have to read it on your freakin' blog :p
[01:24] <imbrandon> heh yea a few months ago
[01:51] <Fujitsu> Oh dear, not mplayer patches :(
[01:51] <Fujitsu> The mplayer codebase *suck*.
[01:52] <Fujitsu> *sucks
[01:55] <imbrandon> Fujitsu: heh
[01:56] <zul> imbrandon: welcome back to the cult btw
[01:57] <imbrandon> zul: :)
[01:58] <Fujitsu> It has been almost a year since their last release candidate, and the diff since is absolutely enormous.
[02:07] <gnomefreak> is there a core-dev i can borrow for a minute i was told i need a core0dev to sponser a source changing backport
[02:07] <gnomefreak> core-dev even
[02:09] <macogw> i made a source package for fusion-icon, the little notification-tray icon that lets you control compiz-fusion like beryl had.  compiz is in main, but can i still submit the fusion-icon source package to motu?
[02:12] <imbrandon> macogw: yes
[02:16] <macogw> and what kind of numbering should the version have? i put it in my ppa on launchpad beta with fusion-icon-0.0.0~git20070930-0ubuntu1-maco2 (it took me 2 tries to get build-deps right) because it's version according to the source is 0.0.0-git and i checked it out of git on sept 30
[02:16] <macogw> imbrandon: ^
[02:17] <Fujitsu> macogw: I'd probably say 0.0.0+git20070930-0ubuntu1 for the one in Ubuntu, and 0.0.0+git20070930-0ubuntu1~ppa1 for your PPA.
[02:18] <macogw> ok
[02:26] <Simon80> is anyone interested in merging bochsbios from debian to fix Bug #123185?
[02:26] <ubotu> Launchpad bug 123185 in bochs "bochsbios too old for Windows XP with qemu" [Medium,Confirmed]  https://launchpad.net/bugs/123185
[02:35] <bluefoxicy> Google isn't helping
[02:35] <bluefoxicy> why does virtualbox ose have a dfsg
[02:35] <azeem> upstream has a bad track record
[02:35] <azeem> bluefoxicy: did you take a look at debian/copyright?
[02:36] <imbrandon> hrm whats the crontab ubuntu uses ? anacron ?
[02:36] <bluefoxicy> azeem:  something about removing microsoft files?
[02:36] <azeem> I don't know, I'm just saying debian/copyright is the obvious place to look
[02:37] <macogw> bluefoxicy: is removing microsoft files a bad thing?  i thought deleting microsoft's products from a computer were called "fixing" it
[02:37] <bluefoxicy> macogw:  it's not marked  "Debian did this because of DFSG"
[02:37] <bluefoxicy> so I don't know why it's there :)
[02:37] <azeem> where is it marked?
[02:37] <bluefoxicy> also I'm reading /usr/share/doc/virtualbox-ose/copyright
[02:38] <bluefoxicy> Due to license issues, parts of the Guest Additions have to be removed from the
[02:38] <bluefoxicy> sourcecode. Some of the files were (c) Microsoft with an license which have to be
[02:38] <bluefoxicy> considered non-free.
[02:38] <bluefoxicy> ^^^ No indication if Innotek said "Yeah we deleted this" or if Debian just tacked that onto the end of pre-existing copyright from Innotek or what :)
[02:38] <Toadstool> hola here
[02:39] <bluefoxicy> but ok
[03:07] <bddebian> Heya gang
[03:07] <slangasek> can someone tell me how to get Ubuntu's dch -i to not append "ubuntu<n>" to the version number when preparing an upload of an Ubuntu-specific package?
[03:08] <bddebian> The backspace key? :-)
[03:10] <slangasek> kinda defeats the purpose of having a tool with commandline options, doesn't it?
[03:10] <slangasek> also, I'm left worried that dch -i has been modified in other ways that are inappropriate for this upload
[03:11] <bddebian> It adds a changelog entry, how much more can it be modified?
[03:14] <imbrandon_> heya bddebian
[03:14] <bddebian> Hi imbrandon_
[03:14] <slangasek> why should I assume that a package with one wrong behavior has *only* one wrong behavior?
[03:15] <bddebian> It's not the *wrong* behaviour when it's intended.  It's just *wrong* for what you want it to do
[03:15] <imbrandon_> actualy thats the correct behavure but in this case you can see the outp[ut
[03:18] <bddebian> slangasek: You are certiainly welcome to add a changelog entry by hand if you don't "trust" dch
[03:18] <slangasek> no, "no one's figured out how to detect the difference between Ubuntu-specific and Debian packages and adjust the behavior accordingly" != "correct"
[03:19] <bddebian> What denotes an "ubuntu-specific" package?
[03:19] <imbrandon_> slangasek: a debian package should be built and worked on in a debian chroot thus with debians dch
[03:21] <slangasek> bddebian: is that a thinly-veiled attempt to trick me into working out the solution for this bug on the spot, or is it really not obvious to you what I mean by "Ubuntu-specific"?
[03:22] <bddebian> Not it is not obvious.  If you mean a native package, at times those come from or go back to Debian as well so we typically make -0ubuntuX versions
[03:23] <slangasek> fine then, I mean ubuntulooks
[03:24] <imbrandon_> ahh you mean native package, not "ubuntu-specific"
[03:24] <slangasek> I can see a case for using ubuntu<n> version numbers for such a package as well, but in practice that's not what's been done
[03:24] <slangasek> imbrandon_: no, I mean Ubuntu-specific.
[03:24] <imbrandon_> ubuntulooks iirc is a native package is it not ?
[03:24] <slangasek> nope
[03:25] <imbrandon_> then why are you not appending ubuntuX ?
[03:25] <azeem> http://changelogs.ubuntu.com/changelogs/pool/main/u/ubuntulooks/ubuntulooks_0.9.12-7/changelog
[03:26] <white> weird
[03:26] <white> i am building packages with epochs, but the final deb does not show the epoch (e.g. 2% for 2) in the version number
[03:27] <bddebian> slangasek: I would say that because probably 90 some % or more of our changes append ubuntuX, it makes sense but if you feel it's wrong, you can certainly take it up with #u-devel or file a bug.
[03:27] <imbrandon_> hrm and i still dont see how you think ubuntulooks is not a native package, looks native to me
[03:29] <bddebian> imbrandon: It would probably never go to Debian since it's specific to Ubuntu so it makes sense.
[03:31] <imbrandon> right , the very definition of native
[03:31] <slangasek> no, the definition of native is "has no diff.gz".
[03:31] <bddebian> Aye
[03:32] <imbrandon> well if ubuntu is the upstream as it looks to be in this case
[03:32] <imbrandon> then that matters not
[03:32] <imbrandon> its a packageing mistake
[03:32] <imbrandon> dosent make it non-native
[03:32] <slangasek> no, you're using the term "native" to mean something it doesn't.
[03:34] <imbrandon> no
[03:34] <slangasek> the package has a non-native version number an non-native packaging; it's not native by any definition, whether or not you think it should be
[03:36] <imbrandon> ok so lets reverse this then and i'll conceede to its not native, that still dosent mean its *shouldent* have a ubuntuX version per our guidelines even if it hasent been done in the past by that reasoning
[03:36] <imbrandon> slangasek ^
[03:37] <slangasek> that's fair
[03:37] <gnomefreak> jdong: miss a channel?
[03:39] <bddebian> Heya Hobbsee
[03:42] <Hobbsee> heya bddebian
[04:11] <bddebian> What size are menu icons supposed to be again?  32x32?
[04:49] <imbrandon> bddebian: yea afaik
[04:49] <bddebian> Thx :)
[05:07] <mekius> http://pastebin.com/mb63fed2 <-- known?
[05:07] <mekius> gutsy
[05:10] <jdong> mekius: I've heard that many times, I'd say known.
[05:12] <mekius> jdong: ok :)
[05:12] <mekius> wasn't sure, i don't use ubuntu, working on a project to build a live cd
[05:12] <mekius> and i've been cursing apt for years heh
[05:21] <minghua> Are these "symlinking doc dir to save space" changes tested at all?
[05:22] <minghua> You would think having one "fail to install" bug two weeks before release is already too many, let alone two.
[05:28] <bddebian> What fun would it be without? :-)
[05:50] <minghua> Good, the US mirror has the fixed version now.
[05:52] <gnomefreak> how do i make a debdiff without the /tmp/ changes showing up?
[05:53] <bddebian> If you are diffing the resulting .dsc files there shouldn't be any /tmp/ changes
[05:54] <gnomefreak> ther eis for some reason though
[05:54] <bddebian>  as in like debian/tmp/foo ?
[05:55] <slangasek> do you have patchutils installed?
[05:55] <gnomefreak> bddebian: http://paste.ubuntu.com/615/
[05:55] <gnomefreak> slangasek: no i dont
[05:55] <gnomefreak> maybe that would help?
[05:56] <bddebian> Ah, you need that :-)
[05:56] <gnomefreak> ah
[05:56] <slangasek> yes, you should have gotten a warning message about the inability to use interdiff
[05:56] <bddebian> aye
[05:58] <bddebian> gnomefreak: Also, you didn't have to regenerate any files did you?  Like autoreconf or anything?
[05:59] <gnomefreak> bano
[05:59] <gnomefreak> bddebian: no
[05:59] <bddebian> It was patchutils?
[06:00] <gnomefreak> bddebian: dont know give me a few minutes g/f is talking/yelling at me
[06:00] <bddebian> Oh, heh
[06:00] <bddebian> Oh bano was a tab completion error .. :-)
[06:05] <tonyyarusso> gnomefreak: and you're listening?
[06:07] <gnomefreak> yes i have to listen
[06:07] <gnomefreak> bddebian: no it didnt help
[06:08] <gnomefreak> hmmmm
[06:08] <gnomefreak> yep still gives the tmp shit
[06:09] <gnomefreak> hmmmmmmm
[06:10] <gnomefreak> no matter how i do it it comes with the cruft
[06:11] <bddebian> Oh holy crap, you are debdiffing a totally new upstream version?
[06:15] <slangasek> right, that's the other case where debdiff will give you that - it can't use interdiff because of the nature of the changes so it has to unpack everything to /tmp
[06:16] <gnomefreak> is there  a way to prevent this?
[06:16] <slangasek> not use debdiff on things that are changed so much that they have to be unpacked to compare? :)
[06:16] <gnomefreak> i was thinking maybe building with -i,bzr
[06:17] <gnomefreak> slangasek: to fix this can i remove all tmp sections?
[06:17] <slangasek> remove what then?
[06:17] <gnomefreak> in the debdiff
[06:17] <bddebian> gnomefreak: Why are you trying to debdiff an newer version?
[06:17] <slangasek> it's hard for me to give any concrete recommendations here without seeing the package in question
[06:17] <gnomefreak> bddebian: backport
[06:18] <bddebian> Hrm
[06:19] <gnomefreak> hobbsee got mad because the tmp stuff was in there she fixed it (removed tmp sections) but never showed me the fixed debdiff
[06:20] <gnomefreak> oh and told me never to give her anything like that again
[06:23] <minghua> gnomefreak: To be honest, I don't see big problem with your debdiff.
[06:23] <gnomefreak> she said it failed to build iirc
[06:23] <gnomefreak> failed to apply
[06:23] <gnomefreak> not build
[06:24] <bddebian> I would never apply a debdiff for an upstream version change but what do I know
[06:24] <RAOF> Looks like it should've applied with -p 3.
[06:24] <RAOF> bddebian: flashplugin-nonfree is special.  A new upstream means a changed MD5 hash :)
[06:24] <minghua> RAOF: -p4, I believe.
[06:25] <RAOF> minghua: Whatever :)  Increment p until it applies cleanly :)
[06:25] <gnomefreak> she tried p0 and p1
[06:26] <slangasek> -p3
[06:26] <slangasek> but at that point it is probably simpler to just provide a tarball
[06:27] <bddebian> RAOF: Don't all new upstream versions?
[06:28] <bddebian> They would all have new orig.tar.gz
[06:29] <RAOF> bddebian: Yeah, but the flashplugin-nonfree package doesn't include anything but debian/
[06:29] <bddebian> Ah
[06:30] <RAOF> There's no .orig.tar.gz :)
[06:34] <gnomefreak> can someone look at this and tell me if all looks good. http://paste.ubuntu.com/616/
[06:35] <gnomefreak> main concern is the /flashplugin-nonfree-..... in the diff headers/lines
[06:53] <bddebian> Gnight folks
[07:24] <mumbly> hi ... I would like to upload on REVU. Got a launchpad account and i'm a member of Ubuntu Universe Contributors team... Could you re-sync the REVU uploaders keyring as described on the REVU wiki page ? Thanx.
[08:36] <norsetto> hello all
[08:44] <dholbach> good morning
[08:50] <norsetto> dholbach: morning master
[08:50] <dholbach> hey norsetto :-)
[08:50] <dholbach> master... tssss - whose master?
[08:52] <StevenK> dholbach: Now whisper "Precioussssss" :-P
[08:53] <dholbach> hahaha
[08:58] <norsetto> dholbach: is there someone we can contact about sigsegv in a canonical buildd?
[08:58] <StevenK> What SEGV'd?
[08:59] <slangasek> you can file a bug on whatever segfaulted? :)
[08:59] <StevenK> And if you build it locally does it segfault?
[08:59] <slangasek> (what package?)
[08:59] <dholbach> norsetto: do you have the build log?
[09:00] <norsetto> StevenK: its an ia64 build
[09:00] <norsetto> http://launchpadlibrarian.net/9800524/buildlog_ubuntu-gutsy-ia64.gnome-mplayer_0.5.0-0ubuntu2_FAILEDTOBUILD.txt.gz
[09:00] <StevenK> I've so seen this before on ia64
[09:01] <StevenK> Okay, I've not
[09:01] <StevenK> Setting up shared-mime-info (0.22-2ubuntu2) ...
[09:01] <StevenK> Segmentation fault
[09:01] <StevenK> norsetto: So your first step is to buy an ia64.
[09:01] <StevenK> :-P
[09:01] <slangasek> nah, your first step is to find the fix for this a while back in Debian
[09:02] <slangasek> because I'm pretty sure I've seen that one get fixed over there
[09:02] <slangasek> (but not in shared-mime-info itself I guess, which is current)
[09:03] <slangasek> alternatively you can leave it for lamont to figure out :)
[09:08] <norsetto> the funny things is that this same version was not sigsegv before ....
[09:09] <slangasek> then my money is on libxml2
[09:10] <norsetto> slangasek: ok, let me check
[09:16] <norsetto> slangasek: there is a recent change for libxml2, but its just a rebuild
[09:19] <dholbach> norsetto, slangasek: debian bug 439843 fixes my evolution crashing on startup (and other occurences of crashers with other gnome apps) - is http://daniel.holba.ch/temp/libxml2.debdiff OK for upload?
[09:19] <ubotu> Debian bug 439843 in libxml2 "libxml2: Version 2.6.30.dfsg-1 breaks Azureus and evolution (until now)" [Critical,Fixed]  http://bugs.debian.org/439843
[09:19] <dholbach> (I just said that in #ubuntu-devel)
 it seems to fix __xmlParserInputBufferCreateFilename() sort of crashers
[09:21] <dholbach> norsetto: seems that doko already has an upload queued up with that fix
[09:22] <norsetto> dholbach: ok, I was about to issue a bug report but I'll wait to see if that fixes it, thx
[09:22] <dholbach> let's hope the upload is accepted soon
[09:22] <dholbach> bug 147144 for reference
[09:22] <ubotu> Launchpad bug 147144 in libxml2 "xslt:copy element is broken in 2.6.29" [Medium,Confirmed]  https://launchpad.net/bugs/147144
[09:49] <mumbly> hi ... I would like to upload on REVU. Got a launchpad account and i'm a member of Ubuntu Universe Contributors team... Could you re-sync the REVU uploaders keyring as described on the REVU wiki page ? Thanx
[09:49] <dholbach> MOTU Q&A session in #ubuntu-classroom in 10 minutes
[09:52] <TheMuso> Is it just me, or has work been done on GNOME to make it perform better on older hardware?
[10:34] <huats> morning all
[10:39] <dholbach> hey thekorn, hey huats
[10:45] <thekorn> hey dholbach
[10:46] <dholbach> how's it going?
[11:11] <pkern> mumbly: I would suggest you to wait until tomorrow. The keyring is automatically resynced during the European night.
[11:12] <Hobbsee> revu isnt.
[11:12] <Hobbsee> pkern: i'm assuming that's what you're meaning?
[11:14] <pkern> Hobbsee: Uh, is it broken?
[11:14] <Hobbsee> pkern: has been since the great canonical community machines loco stuff breakage.
[11:14] <pkern> i.e. didn't siretart re-cron it? (Ok I didn't read exactly that, I only assumed it.)
[11:15] <pkern> Heh.
[11:15] <Hobbsee> he may well hvae done, he didnt mention it to me
[11:15] <Hobbsee> if it still poitns to sparky, though...
[11:15] <pkern> Ok. He's away now anyway.
[11:16] <pkern> Ew. DNS does not respond.
[11:16] <Hobbsee> dat not good.
[11:16] <Hobbsee> right, so it must have moved machines then.
[11:16] <Hobbsee> which means the cron is likely to supposed to be on
[11:18] <pkern> Considering that tauware.de's DNS servers are all down, it's probably another problem.
[11:19] <pkern> Yeah, back up (:
[11:19] <Hobbsee> sorry, all i was saying was the the machine that it was on, si still up
[11:19] <pkern> Still points to sparky.
[11:19] <Hobbsee> so siretart should appear real soon now
[11:20] <Hobbsee> oh, taht's interesting.
[11:20] <Hobbsee> ah yes, must have been dns only, as i could ping sparky, by another address.
[11:20] <Hobbsee> there we are.
[11:20] <Hobbsee> siretart: cron resync hasnt been turned back on, has it?
[11:22] <huats> asac:  sorry to bother you again with bug #138167, but is there something I can do about the last comment from pkern  ? (daniel told me to see that with you)
[11:22] <ubotu> Launchpad bug 138167 in gmail-notify "gmail-notify menu item tooltip is not HIG compliant" [Low,Fix released]  https://launchpad.net/bugs/138167
[11:23] <pkern> huats: If he confirms that it's ok to call it iceweasel-torbuttom I'm ok with that.
[11:23] <asac> bug 138167
[11:23] <pkern> Wrong bug no ;)
[11:23] <asac> ok ;)
[11:23] <asac> huats: ?
[11:23] <huats> asac:  sorry
[11:24] <huats> bug #137513
[11:24] <ubotu> Launchpad bug 137513 in torbutton "[UNMETDEPS]  torbutton: auto-synced, depends on iceweasel" [Medium,Confirmed]  https://launchpad.net/bugs/137513
[11:24] <huats> that is the correct one
[11:25] <asac> huats: since when do we have that package?
[11:25] <huats> I think gutsy, let me check
[11:25] <asac> huats: you could at least produce a binary package: torbutton-extension ... and provide a transitional package for iceweasel-torbutton
[11:25] <asac> huats: did it ever build?
[11:26] <asac> huats: if not, just rename the binary package name like above
[11:26] <pkern> asac: It was uninstallable.
[11:26] <pkern> asac: Due to the non-satisfyable iceweasel dep. Ever since.
[11:26] <huats> it is installable right now, since I added a dependency on firefox too
[11:26] <asac> huats: ok .. rename the binary package name then ... renaming the source is not needed for now.
[11:26] <asac> yes, but its not in the archive
[11:27] <asac> huats: i think that renaming just the binary is good, because then we will still get merges from debian et al.
[11:27] <huats> ok so I rebuild it with anothr binary name
[11:27] <huats> ok
[11:27] <asac> yeah
[11:27] <asac> please don't include the mozilla product name
[11:27] <asac> thats bad in my personal opinion
[11:27] <norsetto> mozilla is evil .....
[11:28] <asac> e.g. torbutton-extension
[11:28] <huats> ok
[11:28] <asac> some might think different, but i don't see the real benefit of it
[11:29] <asac> huats: could you verify wheteher app-install includes torbutton alreaedy?
[11:29] <pkern> norsetto: Look at that:
[11:29] <pkern> [troubadix]  ~ > aptitude search iceweasel|grep 'lightweight'
[11:29] <pkern> i   iceweasel                       - lightweight web browser based on Mozilla
[11:29] <pkern> Same for firefox, but not Ubuntu box reachable one SSH hop away.
[11:30] <huats> asac: I will .... or I'll ask someone do to it for me, since I cannot at the moment upgrade to something higher that tribe4
[11:30] <huats> asac: and if it includes it, I'll do my  best to change it
[11:33] <asac> huats: why can't you upgrade?
[11:34] <huats> asac: network connection problems...
[11:34] <huats> asac: cannot do that at my company office (forbidde to plug my own computer) and no internet connection at home (I just moved)
[11:39] <asac> yeah ... try to find someone to help out then :)
[11:39] <dholbach> lucas: the version you depends on in your ubuntu-dev-tools patch is not in ubuntu yet
[11:40] <dholbach> grrrrr, I was stupid enough to upload it
[11:42] <dholbach> lucas: so you need the patch in debian bug 445144 for it to work?
[11:42] <ubotu> Debian bug 445144 in reportbug "reportbug: please add support for Usertags: pseudo-headers" [Wishlist,Open]  http://bugs.debian.org/445144
[11:42] <dholbach> Hobbsee: is bug 123414 fixed with your upload?
[11:42] <ubotu> Launchpad bug 123414 in reportbug "reportbug shouldn't unconditionally attempt to relay via fiordland" [Medium,Confirmed]  https://launchpad.net/bugs/123414
[11:43] <dholbach> lucas: I'll back out the patch again :-/
[11:44] <Hobbsee> dholbach: nope
[11:44] <BugMaN> hi all
[11:48] <huats> asac: in which package it might be present to be in the app-install ? is it app-install-data ?
[11:48] <dholbach> Hobbsee: ok thanks
[12:06] <amarillion> This is odd: if I do "fakeroot debian/rules binary", my new package builds just fine, but if I do "debuild -b -rfakeroot", I get a linker error.
[12:06] <amarillion> Doesn't debuild simply call debian/rules binary? What is different?
[12:07] <gnomefreak> dpkg-buildpackage -b -rfakeroot work?
[12:08] <amarillion> trying... yes it does
[12:08] <amarillion> but pbuilder doesn't work
[12:09] <slangasek> the difference is that calling "fakeroot debian/rules binary" runs all targets under fakeroot, whereas debuild -b first calls debian/rules build and then calls fakeroot debian/rules binary
[12:11] <amarillion> ok... so I guess that means my rules file is screwed up, because normally binary depends on build, right?
[12:11] <slangasek> no
[12:11] <slangasek> that is, it doesn't automatically mean it's a problem with the rules file
[12:14] <amarillion> Ok, but if I do "fakeroot debian/rules clean" "debian/rules build" and "fakeroot debian/rules binary" it still works.
[12:15] <amarillion> I'm thinking I must have two versions of a static library around
[12:19] <asac> huats: yes
[12:19] <asac> huats: let me check
[12:21] <amarillion> I fixed it :) Indeed I had two version of liballegro
[12:21] <amarillion> now the build consistently fails :p
[12:47] <lucas> dholbach: that's mentioned in the LP bug report
[12:48] <dholbach> lucas: yeah, apparently it was not obvious enough for me at that time of day
[12:50] <lucas> :-)
[12:50] <dholbach> but it'll be nice to have
[12:52] <lucas> dholbach: if you can review the reportbug patch, maybe we could integrate it
[12:52] <lucas> I didn't upload because I'm not a python expert, and prefered someone else to review it so late in the release cycle
[12:53] <dholbach> lucas: the patch looks ok to me, I would somehow just have preferred it to be in upstream first
[12:53] <dholbach> but maybe somebody else is more comfortable uploading it
[12:54] <lucas> regarding reportbug's bug status, it's unlikely to happen really soon ...
[12:54] <mok0> I need some advice for building a meta package
[12:54] <dholbach> hrm
[12:54] <mok0> Is is better to build it as a binary or a source package?
[12:55] <dholbach> there is no 'OR' - you need the source package to build the binary from that
[12:56] <mok0> dholbach: It's not that kind of binary I mean
[12:56] <mok0> dholbach: It's the type where you create the directory in debian/ yourself
[12:57] <dholbach> mok0: what do you mean then?
[12:57] <dholbach> does       apt-get source meta-telepathy     help as an example?
[12:57] <mok0> http://tldp.org/HOWTO/html_single/Debian-Binary-Package-Building-HOWTO/
[12:59] <broonie> mok0: Normally in Debian/Ubuntu a meta package is a package which depends on other packages in order to allow you to install a suite of packages as one.
[12:59] <mok0> broonie: this one needs no dependencies. It only needs to run a maintainer script to modify /etc/profile
[01:00] <mok0> meta-telepathy could do as a template...
[01:00] <broonie> Like I say, that's not what people would normally call a meta package in Ubuntu.
[01:01] <mok0> broonie: what would you call it?
[01:02] <broonie> Just a package.
[01:02] <mok0> broonie: Ah :-)
[01:03] <mok0> Well, thanks, I think I can go on from here...
[01:30] <mok0> In a maintainer script, can you count on grep and sed being there?
[01:32] <Hobbsee> if they're priority essential, iirc yes
[01:33] <mok0> They are, thx
[01:34] <TheMuso> internode even
[01:41] <ScottK> Good morning all
[01:41] <Hobbsee> hi ScottK
[01:42] <ScottK> Hello Hobbsee.
[01:46] <_MMA_> dholbach: Ubuntu likes to push the for art but it can be anything that fits the DFSG right?
[01:46] <_MMA_> gah
[01:46] <dholbach> _MMA_: what do you mean?
[01:46] <_MMA_> *Ubuntu likes to push the CC-Share Alike ...
[01:47] <_MMA_> (missed some text.)
[01:47] <zul_> morning
[01:47] <dholbach> _MMA_: if you use some dfsg license, that's cool
[01:48] <mok0> Hello ScottK
[01:48] <ScottK> hello mok0.
[01:48] <_MMA_> dholbach: Ok. I thought I saw a preference from Ubuntu at one time. Just trying to clarify.
[01:48] <dholbach> _MMA_: you can ask kwwii about that too
[01:53] <_MMA_> dholbach: Yeah. I think he was a little unsure outside of CC-Share Alike as well. No big deal. Just making up rules for art submission on the wiki. ;)
[01:53] <dholbach> _MMA_: for ubuntustudio?
[01:55] <_MMA_> Specifically for us but I was wondering for Ubuntu as well as I am helping out somewhat there.
[01:58] <_MMA_> dholbach: ie: Im working on the rules for Ubuntu Studio now but the question arouse days ago in #ubuntu-artwork and kwwii just mentioned CC-Share Alike. So I just needed to know if it applied to all Ubuntu projects. Guess not. :)
[02:00] <dholbach> if you decide to use some other dfsg license, that's fine
[02:00] <norsetto> hi scottk
[02:00] <ScottK> Hi norsetto
[02:03] <norsetto> dholbach: do you have the logs of this morning session somewhere?
[02:04] <dholbach> norsetto: yes, in .xchat2/xchatlogs :)
[02:05] <DarkMageZ> dholbach, hi. me from the libvisual-plugin patches. if you diffstat the diff file instead of the debdiff it gets a clean result. see, when i was unpacking the previous version, i removed debian's autotooling crud, which is now regenerated in 90_
[02:05] <norsetto> dholbach: off!?
[02:05] <dholbach> norsetto: I'll upload it in a sec
[02:05] <dholbach> DarkMageZ: hm? I don't understand
[02:06] <dholbach> DarkMageZ: I just don't understand why the debdiff is so big?
[02:08] <DarkMageZ> dholbach, well, you see. 1ubuntu2 had autotool changes applied directly in the diff. so that was purged. then i've gone and made changes which make debians autotool stuff obsolete. then regenerated new useful copy into a patch aka 90_
[02:09] <DarkMageZ> so the debdiff shows the removing of debian autotool cruft and a big patch which is the retooling.
[02:09] <dholbach> ah ok
[02:09] <dholbach> can you add that information on the bug report?
[02:09] <DarkMageZ> it's afew comments up i thought
[02:10] <dholbach> oh ok
[02:10] <dholbach> norsetto: http://daniel.holba.ch/temp/motu-qa.log
[02:13] <DarkMageZ> dholbach, ah. i'll add a comment on that. looks like i only told persia on irc
[02:14] <dholbach> ok great
[02:15] <pkern> Yay@lool wants to become a MOTu, too. (:
[02:16] <pkern> Uh, he has a canonical.com address.
[02:19] <lucas> pkern: surprised? :P
[02:22] <pkern> lucas: Difficult question. ;-)
[02:24] <ScottK> Has he ever been here?  I don't recall seeing that nick.
[02:24] <pkern> You don't have to be here to get MOTU? ;o) He attended the QA meeting.
[02:24] <lucas> which QA meeting?
[02:25] <lucas> ah you mean Q&A ?
[02:25] <pkern> Yeah sorry.
[02:25] <zul> pkern: damn what am i doing here then
[02:26] <pkern> zul: It helps. ;)
[02:26] <lucas> zul: pkern meant that the alternative solution is to get a job at canonical, probably ;)
[02:26] <zul> that usually works
[02:26] <pkern> lucas: DD bonus and some contacts with the MOTU council members could also be sufficient I guess. ;)
[02:27] <ScottK> Speaking of MOTU Council...
[02:27] <ScottK> dholbach: How goes the process for finding MC nominees?
[02:29] <dholbach> ScottK: good, we passed a list on to TB and CC
[02:29] <ScottK> Any timeline for them to pass on it?
[02:29] <dholbach> I think the hardest part is done now
[02:30] <dholbach> it won't be that long, I guess
[02:32] <proppy> hi
[02:33] <norsetto> dholbach: any idea whats wrong with this: Your message to:      ubuntu-motu-mentors@lists.ubuntu.com did not reach the following recipient(s): mubuntu-motu-mentors@lists.ubuntu.com
[02:33] <norsetto> hi proppy
[02:33] <dholbach> norsetto: hu? weird
[02:33] <dholbach> norsetto: any other message about it?
[02:34] <norsetto> dholbach: never mind, got the bugger :-)
[02:34] <dholbach> ok good
[02:35] <norsetto> dholbach: copy link address in kde copies the mailto: too ....
[02:37] <ScottK> norsetto: There should be an option to just copy the e-mail address (IIRC) - FYI for next time.
[02:38] <norsetto> scottK: yes, copy email address (sorry about the typo)
[02:38] <ScottK> Copy e-mail address should't include the mailto part.
[02:38] <norsetto> ScottK: thats what I used but includes the mailto: too (not a big deal now that I know)
[02:39] <ScottK> Odd.
[02:39] <ScottK> What KDE application is this in?
[02:40] <norsetto> its not a kde specific one, its thunderbird
[02:41] <norsetto> scottK: do you know any idot?
[02:41] <norsetto> s/idot/idiot
[02:42] <ScottK> Ah.
[02:42] <ScottK> Yes, I know lots of idiots.  I'm even related to some.  Not sure why you ask?
[02:43] <ScottK> norsetto: Have you tried using Kontact/Kmail?
[02:43] <norsetto> ScottK: well, because I obviously did use copy link and not copy email address .....
[02:44] <Hobbsee> lucas: they claim it doesnt happen that way.  who knows if htey're right.
[02:44] <ScottK> norsetto: Ah.  Well we all do stuff like that now and then.
[02:44] <norsetto> ScottK: yes, thats what I tried first but couldn't get the hand on it, so I passed to thunderbird
[02:45] <ScottK> I see.
[02:45] <ScottK> Depending on how much mail you deal with, you might find Thunderbird gets overwhelemed.
[02:46] <lamont> StevenK: I forget which library it was... I'll go track it down
[02:46] <norsetto> ScottK: its ok actually, better than evolution I must say (even though I miss the filters, guess there is an addon somewhere if I ever get round to search for it)
[02:47] <ScottK> Kmail has pretty good filters.
[02:47] <ScottK> IME anyway.
[02:48] <Hobbsee> norsetto: i was set as away :P
[02:48] <_polto_> hello all
[02:49] <norsetto> scottk: you know, I don't think I ever tried kmail, only kontact, I can't find any icon for it in the k-menu
[02:49] <ScottK> norsetto: It's the Mail part of Kontact
[02:49] <ScottK> Kubuntu doesn't give you a default way to get just Kmail.
[02:50] <ScottK> hello _polto_.
[02:50] <_polto_> hello
[02:53] <_polto_> Fujitsu, hi. did you got my e-mail about mplayer patch and network cameras? I do not know if it is the good place here to discuss it, but we would be happy to see this patch applied by default on Ubuntu.
[02:53] <lamont> norsetto: gnome-mplayer given-back
[02:53] <norsetto> lamont: you mean the ftbfs?
[02:54] <lamont> yeah
[02:54] <norsetto> lamont: cool, was it libxms2?
[02:54] <lamont> yeah
[02:54] <lamont> libxml2
[02:55] <norsetto> lamont: thx
[02:56] <ScottK> _polto_: Last night (my time) he said: [19:51]  <Fujitsu> Oh dear, not mplayer patches :( - [19:51]  <Fujitsu> The mplayer codebase *suck*. - [19:52]  <Fujitsu> *sucks
[02:56] <ScottK> _polto_: I'd say he knows.
[02:57] <_polto_> :(
[02:58] <_polto_> ok i tryed it out for several years now. it work.
[02:58] <ScottK> _polto_: My advice is to stick around and speak with him directly.
[02:58] <_polto_> ScottK, thanks
[02:59] <leonel> hi ScottK !
[02:59] <ScottK> hi leonel.
[02:59] <ScottK> leonel: It's probably about time we did another Feisty clamav backport, don't you think?
[03:01] <leonel> ScottK: would be  great
[03:02] <ScottK> leonel: If you'd test it and file the backports bug, I'll ack it for you.
[03:02] <leonel> ScottK: how  about use   ppa  to  keep a  the newest clamav  for   dapper edgy feisty  and  next  gutsy ?
[03:02] <leonel> ScottK: ok
[03:03] <zul> ScottK: the disksearch uvfe the patch is in their cvs i just checked
[03:03] <ScottK> leonel: I'm not comfortable with the current PPA terms of service.  Generally backports is a better way to go where we can.
[03:03] <ScottK> zul: I expected so.
[03:03] <leonel> ScottK: ok
[03:06] <Fujitsu> ScottK: Um, did I miss my induction into motu-uvf? (bug #148801)
[03:06] <ubotu> Launchpad bug 148801 in lyx "[UVFe]  lyx 1.5.0 -> 1.5.1" [Medium,Confirmed]  https://launchpad.net/bugs/148801
[03:07] <ScottK> Fujitsu: Gah.  Sorry.
[03:08] <ScottK> Fujitsu: For some reason (probaby still on my first cup of coffee) I did a StevenK/Fujitsu transposition in my head.  Thanks for pointing it out.
[03:09] <Fujitsu> Heh, interesting.
[03:11] <StevenK> How?
[03:11] <StevenK> I can't spell Fujitsu with my name.
[03:12] <Fujitsu> StevenK: I'm sure you can make it fit somehow.
[03:12] <ScottK> I tend to sort MOTU geographically in my head.
[03:12] <Fujitsu> Yeah, darn Australians, all looking the same.
[03:12] <ScottK> Don't worry to much about it.  It's a general mess in there.
[03:12] <Fujitsu> Heheh.
[03:12] <_polto_> Fujitsu, hi
[03:12] <Hobbsee> yeah, darn all those similarly looking australians with accents.
[03:13] <_polto_> Fujitsu, i send you an e-mail about mplayer patch for openhardware network cameras.
[03:13] <Fujitsu> _polto_: Hi.
[03:13] <_polto_> Fujitsu, did you had some time to read it ?
[03:13] <Fujitsu> I read it, haven't done much more than glanced at the patch yet.
[03:13] <Fujitsu> Has upstream given any reason for not accepting it yet?
[03:18] <_polto_> Fujitsu, no. I know well DonDiego, Alex and some other peoples from mplayer team. At least those who come to LinuxTAG. But they just did not applied it for 3 years now without any reason or critics.
[03:22] <Fujitsu> _polto_: So this change is needed because of the high res of the images returned by your cameras?
[03:23] <_polto_> yep
[03:43] <bddebian> Heya gang
[03:44] <norsetto> hya bddebian
[03:44] <bddebian> Hello norsetto
[03:44] <polto_> sorry, i was disconnected ..
[03:45] <norsetto> scottK: dunno why I didn't like it, kmail seems nice
[03:45] <polto_> Fujitsu, any idea of what i can do to promote the patch ?
[03:46] <ScottK> norsetto: Cool.
[03:48] <gameldar> heya all - I have a couple of questions about a fix I have for a bug I've found - given that I'm not a motu - am I in the right place?
[03:50] <lamont> gameldar: discussing patches is always on-topic. sup?
[03:52] <gameldar> lamont: bug #126314 - as I've added in the bug I've got a patch for it.. and would like to follow through the processes of submitting it for review etc
[03:52] <ubotu> Launchpad bug 126314 in anjuta "Anjuta crashes on opening or creating a glade file" [Undecided,Confirmed]  https://launchpad.net/bugs/126314
[03:53] <gameldar> also in fixing that I've found a problem that hasn't been fixed upstream (actually I still need to check their svn repo)
[03:54] <gameldar> I guess that second question is - is the normal process to file it as a bug upstream and wait for a fix to come through, or to create a patch via the debian patch mechanism?
[03:54] <lamont> ScottK: I waited like 2 minutes before I said anything...
[03:54] <zul> gameldar: i would send it upstream so that both debian and ubuntu can beenfefix
[03:54] <zul> benefit even
[03:55] <ScottK> lamont: Just having fun with you.
[03:55] <lamont> gameldar: the preferred method is to file the bug at the top of the food chain (esp if it includes a patch), and then either poke the downstream distro(s) to pick up the patch directly, or not, depending on how bad the issue is and how soon a new upstream release is due out
[03:56] <lamont> zul: your first spelling was more interesting. :-)
[03:56] <zul> lamont: lack of caffine and too much asterix comics last night
[03:57] <gameldar> lamont, zul: ok - thanks. In the case of anjuta gutsy is already a (stable) release behind
[03:57] <lamont> gameldar: and it'll most likely stay that way, given that it releases this month.
[03:58] <lamont> hardy will get whatever version is in sid.
[03:58] <lamont> then.
[04:00] <ScottK> gameldar: The process for inclusion in Ubuntu of your change is to prepare a debdiff for a new revision and subscribe ubuntu-universe-sponsors to the bug.  Then a MOTU will look at it and perhaps upload it if they agree with it.
[04:07] <gameldar> lamont, scottk: ok thanks. Just looking at the trunk version the bug still exists (its an abi change in libglade) - in which case previous versions will be linked to an older version of the appropriate library and won't be updated?
[04:08] <lamont> IIUC, not until they're rebuilt (which may require source changes if there was a significant change)
[04:08] <ScottK> gameldar: Do we have the new or old ABI in Gutsy?
[04:08] <gameldar> scottk: we have the new one.
[04:08] <ScottK> Then IMO the package should work with the new one as there's no guarantee it won't get rebuilt.
[04:09] <ScottK> It that requires a source change, then we ought to get that in.
[04:09] <gameldar> ok
[04:09] <ScottK> Does that make sense?
[04:10] <gameldar> yeah that makes sense - basically the two are dependent, if we fix the primary bug (what is listed - basically the glade plugin is not being compiled at the moment), then the second change also needs to happen.
[04:11] <ScottK> Then do as I suggested above about a proper debdiff (ask here if you need help).
[04:12] <gameldar> so - basically I would 1) file a bug with anjuta so that it'll eventually flow down stream. 2) fix the bugs for the ubuntu package.
[04:13] <gameldar> the patch I need to make is following the debian patch mechanism though isn't it (i.e. a file in debian/patches) rather than just the diff on the original source?
[04:19] <ScottK> gameldar: Does anjuta have a patch system in the pacakge already?
[04:19] <gameldar> not currently, no
[04:20] <ScottK> gameldar: If the package has a patch system, use it, but for a one liner like that it's not essential (in Ubuntu - Debian is different) that you use one.
[04:20] <ScottK> Also, given we are ~ 2 weeks from release, deal with getting Ubuntu fixed first and file upstream later.
[04:22] <gameldar> scottk: ok. I'm just looking at https://wiki.ubuntu.com/MOTU/School/PatchingSources atm :)
[04:23] <ScottK> gameldar: It's better to use a patch system, but not essential.  If you can add it, then great.  That's the right place to be looking.
[04:24] <gameldar> scottk: Ok - I haved used dpatch before - but only with a package with an existing dpatch mechanism, so I'm not sure of the steps of setting it up from scratch. I guess regardless of the method here its the hooking it into the build that I haven't seen.
[04:24] <lamont> ScottK: I probably shouldn't mention that I just transitioned my packages away from using a patch system, to using git. :-)
[04:25] <ScottK> lamont: No.  You shouldn't.
[04:25] <ScottK> ;-)
[04:25] <ScottK> gameldar: More trouble than it's worth for a one liner, but man dpatch tells you want you need to do if you want to give it a shot.
[04:26] <lamont> it's different when there's a good revision control system for the source...
[04:26] <lamont> dpatch is probably better for most things
[04:26] <lamont> the others are either more complex, or worse, or both.
[04:43] <Hobbsee> ScottK: it's a bejewelled replacement.  bejewelled rocks.
[04:48] <lamont> ScottK: and dbs is _never_ the answer
[04:51] <rexbron> hey all
[04:51] <rexbron> Can debian/control's Section: key have more than one item?
[04:56] <norsetto> rexbron: AFAIK no
[04:56] <rexbron> ok
[04:57] <DktrKranz> ScottK: have you some time for a question related to bug 57025 ?
[04:57] <ubotu> Launchpad bug 57025 in ivtools "uninstallable" [Medium,Confirmed]  https://launchpad.net/bugs/57025
[05:13] <ScottK> DktrKranz: Sure
[05:14] <DktrKranz> ScottK: thanks. I've a little doubt if this is relevant for feisty and gutsy.
[05:14] <ScottK> lamont: In general I'm increasingly inclined to agree, but for packaging basic Python modules/apps CDBS actually works pretty well.
[05:15] <ScottK> DktrKranz: I'm not sure what you mean.  Is it fixed for Gutsy already?
[05:16] <lamont> I didn't say cdbs.  _dbs_ is never the answer
[05:16] <lamont> cdbs I have very mixed emotions about
[05:16] <ScottK> Ah.  Right.  Agreed then.
[05:18] <DktrKranz> ScottK: I'm not sure if this fix should be applied to Gutsy. IIRC, we only support upgrades from near releases (e.g. dapper => edgy) or LTS
[05:18] <ScottK> DktrKranz: So upgrading from Feisty to Gutsy works?
[05:19] <DktrKranz> yes
[05:19] <ScottK> I'd call that fixed for Gutsy then.
[05:19] <DktrKranz> that error only occours from dapper to edgy
[05:19] <ScottK> OK.  That's the part that wasn't clear to me.
[05:20] <DktrKranz> nice :)
[05:20] <DktrKranz> so, I think feisty and gutsy target are not needed. should I close them?
[05:20] <ScottK> DktrKranz: Done
[05:21] <DktrKranz> ah, thanks :)
[05:22] <ScottK> DktrKranz: You'll need a different version number though.
[05:23] <ScottK> With the version number in your debdiff, Edgy would end up with a higher version number than Feisty.  Not good.
[05:23] <DktrKranz> definitely!
[05:24] <DktrKranz> what version number should I use in this cases?
[05:25] <ScottK> Not sure.
[05:25] <Hobbsee> DktrKranz: libvisual-plugins was used for amarok before, wasnt it?
[05:26] <DktrKranz> Hobbsee: no idea, sorry :(
[05:27] <ScottK> Any suggestions from the assembled crowd on how to version an SRU when the next release has the same version number?
[05:27] <Hobbsee> oh, perhaps not.  perhaps we only intended it.
[05:28] <Hobbsee> ScottK: er....anything remotely sane, that it wont get upgraded by the version above.
[05:28] <Hobbsee> as in, the version above what's already there.
[05:28] <Hobbsee> er, in proper enlgish
[05:28] <Hobbsee> anything that doesnt make the next upload of the package in question fall over.
[05:28] <Hobbsee> ScottK: at that point, i'd consider a nochange rebuild SRU for the package in the release above.
[05:29] <ScottK> Right.
[05:29] <DktrKranz> Hobbsee: sounds good
[05:29] <Hobbsee> ScottK: because, really, you're screwed whatever you do - it's going to break an upgrade path, unless you bump all o fit.
[05:29] <DktrKranz> probably that's the only solution we have...
[05:29] <ScottK> DktrKranz: Additionally, even though we don't support Dapper -> Gutsy, we will support Dapper -> Hardy, so we might as well go ahead and deal with it.
[05:30] <ScottK> Hobbsee: That's what I was afraid of.
[05:30] <Hobbsee> ScottK: but i wouldnt expect that to require an entire SRU process for all of them.
[05:30] <Hobbsee> unless it's a frankenstinean package
[05:30] <DktrKranz> ScottK: since we should prepare a SRU for feisty too...at this point we can go on and include it
[05:30] <DktrKranz> and fix it for gutsy as well
[05:31] <ScottK> Yes.
[05:31] <DktrKranz> so, we include it for hardy automatically
[05:31] <ScottK> Ywes
[05:31] <ScottK> Yes even
[05:31] <ScottK> DktrKranz: Then what I'd do is call the Edgy version 1.0.1 and the Feisty version 1.1
[05:32] <DktrKranz> it should be safe
[05:32] <ScottK> That also then gives you head room for further changes if needed.
[05:32] <DktrKranz> yes
[05:32] <Hobbsee> debian kde extras team tends to do that, and it usually has to be done each time the toolchain changes, it seems
[05:35] <DktrKranz> ScottK, Hobbsee:if you agree, I'll reopen Feisty and Gutsy tasks including our "brainstorm session"
[05:35] <Hobbsee> DktrKranz: i've no idea which bug you're talking about, but sure
[05:36] <DktrKranz> so we can easily track down the whole thing
[05:37] <pkern> ScottK: What was the version problem here?
[05:38] <Hobbsee> pkern: releasex has version foo, release x+1 has version foo, and they want to do a SRU for version x.
[05:39] <Hobbsee> pkern: which will then be higher, no matter waht it is, than version x+1
[05:40] <pkern> For a problem which does not affect x+1? Yeah, ok.
[05:41] <Hobbsee> pkern: yup
[05:41] <Hobbsee> pkern: although it'd be weird that it wouldnt affect x+1, come to think of it...
[05:42] <pkern> That's a nice corner case example. (:
[05:43] <huats> pkern: regarding the iceweasel-torbutton pb, it has been decided to change the binary name to torbutton-extension (I don't know it you were here went we talked about that)
[05:43] <pkern> huats: I was.
[05:43] <pkern> huats: As said as soon asac ACKs it I'm ok with that.
[05:43] <huats> pkern: ok, so sorry for duplicating the info
[05:44] <pkern> I would probably have gone for firefox-torbutton, but well.
[05:44] <pkern> huats: And you did also change the description?
[05:44] <asac> huats: i am ok with the name
[05:45] <huats> pkern: I tend to agree with asac
[05:45] <huats> asac: I hope, it was you idea :-)
[05:45] <huats> pkern: yes I also changed the description
[05:45] <pkern> How is the icedove^Hthunderbird extension called?
[05:45] <huats> pkern: I haven't changed that one...
[05:46] <huats> it was not in the bug report... but I can
[05:46] <pkern> Fun.
[05:46] <huats> pkern: it is called icedove-torbutton
[05:46] <pkern> And depends on icedove?
[05:46] <pkern> That would be fun.
[05:46] <huats> pkern: let me check
[05:47] <pkern> The package in the archive does.
[05:47] <pkern> Package icedove-torbutton version 1.0.4-2 has an unmet dep: Depends: icedove (>= 1.5.0.10.dfsg1-3)
[05:47] <pkern> Yep.
[05:48] <huats> I can also fix it...
[05:48] <huats> the question is : how to call the binary :-)
[05:48] <pkern> Same problem. How would you call it? I would rather not merge the two, as that diverges too much from Debian.
[05:49] <asac> huats: is it a different extension?
[05:50] <asac> huats: or just a duplicate?
[05:51] <huats> asac: from my point of view it is a duplicate
[05:51] <pkern> It's a duplicate, yes.
[05:52] <pkern> Just different extensions dirs.
[05:53] <huats> asac: so I can simply add a link....
[05:53] <huats> and remove the second binary to simply have one ?
[05:54] <pkern> And remove the dependencies on thunderbird and firefox not to pull the other one in if one doesn't want it?
[05:55] <huats> pkern: you mean to a dependency on firefox or thunderbird
[05:55] <huats> ?
[05:55] <huats> pkern: you mean to have a dependency on firefox or thunderbird, not necesseraly both... right ?
[05:56] <pkern> Yep.
[05:56] <huats> I can do that :-)
[05:56] <huats> asac: your opinion ?
[06:04] <gameldar> ok... I have my debdiff now... should the requestsponsor script work in gutsy?
[06:08] <gameldar> ack - I can't see any more.. I'll have to leave that till tomorrow ... seeya all
[06:08] <YokoZar_> I want to rebuild the ia32-libs package...what's the best way to do this?  It needs to have freshened packages and also have libssl0.9.8 added
[06:27] <ScottK> jdong: Just so you know...  I see that you've disapproved Postfix backports in the past.  I just disagreed and backported Postfix 2.4.5 to Dapper.  Postfix upgrades are about the safest thing there is because of the care Weitse Venema puts compatibility between releases.  The fact that lamont's packaging is good helps too.
[06:27] <YokoZar_> ScottK: I've almost got another Wine package ready
[06:27] <ScottK> OK.
[06:27] <ScottK> Once it's ready ask \sh to look at it and if he's cool I'll upload it for you.
[06:28] <jdong> ScottK: the only reason I disapproved is that it tends to be one of those things that WILL get security updates in the future, but when that ahppens the package may no longer backport, and backports overrides -security, and I get everyone chasing after me with flaming pitchforks :)
[06:28] <asac> pkern: the right way to do that is to ship the extension in /usr/share/torbutton-extension ... and then add links to the thunderbird and firefox direcoty
[06:28] <YokoZar_> ScottK: Right now I need to add libssl0.9.8 to ia32-libs first though, as Wine needs it.
[06:28] <lamont> ScottK: you made core-dev?
[06:28] <jdong> ScottK: but if you feel comfortable with doing it, I've got no objections
[06:28] <asac> pkern: (if you haven't figured out)
[06:28] <asac> pkern: of course only if the extension is the same for both
[06:28] <asac> ;)
[06:28] <lamont> (/me doesn't pay that much attention to such tings)
[06:28] <ScottK> lamont: No.  For a no-change backport it's not required.  Only for source backports with changes.
[06:29] <lamont> oh.  somewhere in my head, I think I moved wine to main for a minute
[06:29] <jdong> lamont: hahahahaha
[06:29] <jdong> AHAHAHAHAHAHAHA
[06:30] <ScottK> Twich
[06:30] <lamont> yeah
[06:30] <ScottK> twitch even
[06:30] <lamont> brainfart.  my bad
[06:31] <jdong> lamont: I supposed you missed automatix-by-default too right?
[06:31] <ScottK> Wine in Main is scary enough I couldn't even spell twitch correctly.
[06:31] <lamont> jdong: to date, the only security patches to postfix are dealing with ssl libraries being bad
[06:32] <jdong> lamont: ok, I feel better then :) I've just managed to dig myself into too many holes with that :)
[06:32] <Hobbsee> oh, shudder.
[06:32] <leonel> ScottK:  so  how the  security updates for backports  are handled ?  Like  any other package in MOTU or  there's need to ask for a new backport ?
[06:32] <keescook> best emulator ever: runs viruses perfectly!
[06:33] <ScottK> leonel: New backport.
[06:33] <YokoZar_> ScottK: So, that's the exact idea I'm going to propose for UDS :)
[06:33] <leonel> ScottK: ok thanks
[06:33] <lamont> jdong: and Wietse is probably the most pedantic person I've seen about putting fixes into a stable release.  Of course, that means nothing, since dapper has 2.2 and the backport is for 2.4
[06:33] <ScottK> YokoZar_: Good luck with that
[06:33] <ScottK> Right, but for Postfix an upgrade 2. anthing to 2.4 is a safe thing to do.
[06:33] <jdong> leonel: backport a fixed version, or (worst case scenario) source change patch uploaded by core-dev approved by -archive
[06:34] <jdong> leonel: the latter case can be scarring :)
[06:34] <lamont> jdong: there's also the interesting(???) fact that -security does not look at either -updates or -backports when doing the build
[06:34] <YokoZar_> ScottK: We don't have to support any actual Wine apps, just have a standardized stable Wine version for others to target.
[06:35] <ScottK> I say again.... Good luck with that.
[06:35] <jdong> lamont: it's good that it doesn't look at -backports, but -updates can be worrisome?
[06:35] <YokoZar_> :)
[06:35] <lamont> jdong: IOW, if LP won't let you upload a version of source that is >> -security and << -backports, it's a launchpad bug
[06:35] <lamont> foo-security is foo+foo-security. period.
[06:35] <lamont> foo-updates is less restrictive on what can get into it.
[06:35] <lamont> for the truly retentive, -security is
[06:36] <lamont> everything _else_ should be looking at foo+foo-security+more
[06:36] <lamont> I think the ogre model for that _should_ be: foo -> foo-security -> foo-updates -> foo-backports
[06:37] <lamont> that is, everything listed includes everything before it on the list
[06:39] <pochu> ScottK, Hobbsee, soren: mind looking at bug 144258 when you have a minute? Thanks :-)
[06:39] <ubotu> Launchpad bug 144258 in scribes "[UVFe]  Please sync scribes (universe) 0.3.2.9-1 from Debian Unstable (main)" [Medium,New]  https://launchpad.net/bugs/144258
[06:39] <ScottK> jdong: Next on the list is Samba.
[06:40] <jdong> ScottK: come on, samba is not NEARLY as predictable in backportability.... and security patches are fairly common. at least 1 or 2 per release cycle.
[06:40] <man-di> lamont: OT: How often do you process mails that request changes to srcdep/Packages-arch-specific in Debian?
[06:41] <ScottK> jdong: Right.  That's why I'm not going to do it unless the ubuntu-server team stands behing keeping it up to date.
[06:41] <lamont> man-di: almost every time I get one... well, maybe more like 80% :-)
[06:41] <lamont> why
[06:41] <lamont> ?
[06:41] <ScottK> behing/behind
[06:41] <jdong> ScottK: agreed
[06:41] <man-di> lamont: I send you a request to remove charva from that list some time ago
[06:41] <lamont> ah...
[06:42] <lamont> man-di: I don't seem to have the email
[06:42] <lamont> what was the request?
[06:42] <man-di> lamont: charva is currently only i386 but it should build on any arch
[06:42] <man-di> so it needs to be removed afaik
[06:43] <ScottK> pochu: Ack'ed.  I'm easy.
[06:45] <pochu> ScottK: It was easy :-) Thanks a lot.
[06:45] <lamont> man-di: so it doesn't depend on j2sdk1.3 any more, eh? (comment in PaS)
[06:46] <lamont> man-di: committed
[06:51] <pkern> asac: And depend on what_
[06:52] <asac> pkern: at best we would have links to _all_ known apps: thunderbird/icedove/iceweasel/firefox ... then natuarally depend on
[06:52] <bddebian> I have a dumb user question. :-)  Whats the best way to grab screenshots in gnome?
[06:52] <asac> firefox | thunderbird | iceweasel | icedove
[06:53] <pkern> asac: With the intention to get it into Debian that way?
[06:53] <asac> eases sharing of code ... yes
[06:53] <zul> bddebian: Application->Accesories
[06:53] <asac> suggest debian maintainer to use our scheme ... then contribute to debian and synch
[06:53] <man-di> lamont: it depends on free runtimes now
[06:53] <man-di> lamont: thanks
[06:54] <lamont> man-di: ah, ok
[06:54] <minghua> bddebian: or "gnome-screenshot"
[06:54] <pkern> asac: Are we allowed to put out-of-archive depends in place in Debian?
[06:54] <bddebian> zul: Thanks.  Is there a keyboard combination to do it?
[06:54] <minghua> bddebian: printscreen?
[06:54] <zul> not that i know of
[06:54] <lamego> bddebian, ALT - PRINT SCREEN
[06:54] <lamego> for the window
[06:54] <bddebian> Ah, like Windows.  Thanks folks!
[06:55] <asac> pkern: i hope so ... as long as the depends can be fullfilled i don't see an issue with having non-existing depends
[06:55] <sladen> bddebian: the printscreen button.  Or I tend to use the gimp for editing and more complicated shots (eg. when a menu is open and the keypress would be ignored)
[06:55] <asac> pkern: i do it for enigmail as well
[06:55] <pkern> asac: Ok, then it sounds reasonable. (:
[06:56] <asac> pkern: if the extension is already compatible with firefox-3.0 we should install it there as well
[07:04] <YokoZar_> So there's a bug in gnome-screenshot: tell it to grab current window with a delay of 0, and it'll grab the whole desktop.
[07:23] <AstralJava> Howdy Masters! :) A question, if you may, on https://wiki.ubuntu.com/PbuilderHowTo there is a section that describes universe support, but then actually talks about Debian (and etch). Was just wondering, is this by accident?
[07:25] <lamont> AstralJava: it looks  like it's telling you how to do universe, oh, and also debian.
[07:25] <lamont> it might want to be more explicit about that though
[07:26] <AstralJava> lamont: Well, yeah. :)
[07:27] <AstralJava> lamont: Okay, but the COMPONENTS=... part is enough to enable all the other repos?
[07:28] <lamont> uh... it's not like I actually _use_ pbuilder...
[07:28] <ScottK> AstralJava: There is a pbuilder-dist script in ubuntu-dev-tools for Gutsy that is pre-set to work with Universe.
[07:29] <AstralJava> ScottK: Okay, thanks! :)
[07:31] <ScottK> AstralJava: You have to rename the script to the dist you want e.g. pbuilder-gutsy.
[07:31] <frafu> Hello everybody. I have been asked by the developer of a package, whether I would be interested in becoming the maintainer of it. I have a personal interest in that package, but does not know what being maintainer involves.
[07:31] <frafu>  One point is certain: I don't have all the necessary knowledge required currently. I have already built a simple debian package for ubuntu a few times, but probably not with all Ubuntu requirements). I have never applied a patch, but several years ago, I did a little C programming, from which I only remember little things.
[07:32] <frafu> What would you advise me: Should I accept?
[07:33] <frafu> Would it make sense to accept, hoping to learn the required skills along the way?
[07:36] <frafu> If I should accept, how will I become the maintainer. Is this a decision of the developer himself? Will he have to specify it on launchpad where the project is hosted?
[07:36] <ScottK> frafu: In Ubuntu we do team maintenance, so I'm not sure what you are asking.
[07:37] <ScottK> Do you mean upstream maintainer of the actual program or maintainer of the Ubuntu packaging for it?
[07:37] <minghua> frafu: My question is, what do you mean by "become the maintainer of it"?  To maintain the package in Ubuntu?
[07:38] <frafu> I don't know myself
[07:39] <frafu> there is no upstream yet for that package as it has been developed for ubuntu during this gsoc
[07:39] <ScottK> Ah.  What package?
[07:39] <frafu> Are you talking only about main or also about universe?
[07:40] <ScottK> Both.
[07:40] <ScottK> In Main and Universe we all have different packages we tend to focus on, but it's a group effort.
[07:40] <minghua> Now I'm interested.  Which package indeed?
[07:40] <frafu> https://launchpad.net/mousetweaks/
[07:43] <frafu> In other words, if I get you right that package needs a general maintainer and a maintainer specific for ubuntu..
[07:43] <minghua> Hmm.  Aren't you suppose to have an mentor for GSoC project?
[07:46] <frafu> I am not the developer; as I wrote most of the spec and communicated with him during the development, he asked me whether I would be interested in becoming the maintainer; but the developer himself does not really know what it requires.
[07:48] <frafu> minghua: gsoc is over.  should it nevertheless be the mentor to look for it to get into ubuntu?
[07:48] <minghua> frafu: Sorry I don't know much about GSoC procedure either.  Can't help you here.
[07:48] <minghua> frafu: IIRC the mentor is supposed to write a report.
[07:49] <lamego> frafu,  if you want to be a package maintainer you just need to follow the official processes as for any other universe packaging :)
[07:50] <lamego> there is no other formal requirement, as far as I know
[07:52] <frafu> lamego: by submitting it to revu, will I automatically become maintainer of the package (with the help of others).
[07:53] <lamego> well, this depends on your definition for maintainer, if I upload a package, and don't care about it anymore, I am just an uploader :)
[07:53] <minghua> frafu: As ScottK said, in Ubuntu packages are team maintained.  The concept of "maintainer" doesn't really exist.
[07:53] <lamego> a maintainer is expected to "maintain", like keeping it updated, etc etc :)
[07:57] <frafu> ok; once it is accepted a team will do the necessary to package it for ubuntu. And now, what about being the upstream maintainer? Is this a decision of the developer alone?
[07:58] <frafu> Does he have to specify it on the page on launchpad, where it is hosted?
[08:01] <ScottK> frafu: It is the decision of the developer alone.  I have no idea what LP changes are needed for that.
[08:03] <frafu> Thanks for your help: so  "maintainer" is a concept that varies from package to package and there is no specific rule for it.
[08:03] <ScottK> Right.
[08:04] <frafu> ScottK: but it is possible to set a specific maintainer in launchpad?
[08:04] <ScottK> Upstream decides whatever they decide.
[08:04] <ScottK> frafu: I have no idea.
[08:04] <lamego> frafu, on Debian there is a package maintainer concept, someone which follows upstream changes
[08:04] <ScottK> I don't maintain any code in Launchpad myself.
[08:05] <lamego> on Ubuntu, a maintainer, can be a "real" maintainer, or just someone which checks random software from time to time
[08:05] <frafu> ScottK: so, I will have to talk to the author and see with him...
[08:08] <frafu> lamego: so there is not a real policy of following if there are changes upstream in ubuntu. (I can imagine that it is not necessary with the 6 months release cycle)
[08:08] <ScottK> frafu: Generally we get stuff from Debian and automatically sync from them.
[08:10] <frafu> Do you also get gnome through debian, or directly from gnome?
[08:10] <ScottK> frafu: Dunno.  I think some of both, but I'm a KDE person.
[08:11] <lamego> gnome is main, probably whoever maintains does it both ways, but is just a guess
[08:12] <ScottK> lamego: Not all of it.
[08:12] <minghua> I believe there is close collaboration between Debain GNOME maintainers and Ubuntu's GNOME team.
[08:12] <ScottK> KDE is the same way.
[08:12] <ScottK> That's how it is in KDE.
[08:13] <frafu> What about packages that are not part of gnome and  debian; do they have a special policy or are updates simply ignored until the next release?
[08:13] <lamego> frafu, only critical and security bugfxies are applied after releases
[08:14] <minghua> frafu: We don't have many packages that aren't in Debian.
[08:15] <minghua> Either we sync/merge from Debian, or we push our packages back to Debian (and sync from there afterwards).
[08:15] <lamego> frafu, https://wiki.ubuntu.com/MOTU/SRU
[08:16] <frafu> So universe also comes from debian? (i assumed it was not the case)
[08:16] <lamego> frafu, most packages yes, not all
[08:17] <frafu> Do you also push packages to gnome? I suppose that mousetweaks, the package that I have in mind would rather belong to gnome.
[08:22] <lamego> frafu, pushing packages into gnome ?
[08:22] <frafu> yes?
[08:22] <zul> frafu: submitting patches to gnome yes
[08:22] <lamego> gnome does not provide packages :) It provides source ;)
[08:25] <bddebian> Hmm, I can't get a screenshot of full-screen alien-arena :-(
[08:25] <frafu> Does this mean that gnome provides packages without debian dir, while debian also includes debian directories?
[08:25] <zul> frafu: yes
[08:27] <frafu> So Ubuntu does not push source packages to gnome?
[08:27] <ScottK> No
[08:27] <lamego> frafu, packages and source have no relation, source is provided by upstream authors, packages (/debian) are provided by maintainer
[08:27] <lamego> frafu, Ubuntu, pushes patches, into gnome source
[08:28] <lamego> Ubuntu, uses and changes source from 3rd parties, it only provides for a few packages which are created by the Ubuntu developers
[08:30] <lamego> uff, 3 crashes in 2 hours, not a great sign for Gutsy
[08:34] <frafu> many thanks for all the explanations and especially for inside that you gave me about what happens behind the scenes. Maybe somebody from the documentation team should add it to the wiki packages about packaging.
[08:34] <frafu> I have to leave now. Bye
[08:35] <bluefoxicy> http://www.bibi.org/box/2004/agosto/firefox_plush_toy.jpg  I want one of these
[08:35] <bluefoxicy> :|
[08:35] <bluefoxicy> and the bug on mozilla hasn't gotten any attention
[08:36] <ScottK> frafu: It's a wiki.  Anyone (meaning YOU) can add to it.
[08:36] <zul> well you are complaining in the wrong channel
[08:36] <ScottK> zul: I doubt any other channel is likely to be more effective ;-)
[08:37] <zul> ScottK: true but I had to comment i think the mozilla team has their channel
[08:37] <ScottK> IIRC they do, but I'm bitter today.
[08:37] <zul> ScottK: im just moody
[08:38] <ScottK> Cool.  Bitter and Moody.  Sounds like a good day for UVFe review.
[08:38] <zul> only when i get home
[08:38] <zul> or when i wake up a bit
[08:38] <ScottK> But you might be in a better mood then and where's the fun in that?
[08:39] <zul> heh
[08:46] <minghua> bddebian: Is that a game on top of X?  If yes, maybe you can try xwd.
[08:49] <minghua> bluefoxicy: I am pretty sure that toy was sold on mozilla.org store before.
[09:08] <bddebian> minghua: I'll try that, thx
[09:14] <AstralJava> Does anyone have a bit of time to help me find out what's wrong with my approach, I've got some stuff online @ http://pastebin.ubuntu-nl.org/39690/ and basically the problem is that pbuilder doesn't make use of my local file repo that I created according to pbuilder user manual @ http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html
[09:16] <geser> AstralJava: how do make /var/cache/pbuilder/result available inside the chroot?
[09:17] <pkern> AstralJava: Of course you did the dpkg-scanpackages stuff?
[09:17] <pkern> geser: pbuilder uses bindmounts
[09:17] <geser> pkern: automatically? cool
[09:18] <pkern> geser: Semi. Look at http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#usingspecialaptsources
[09:18] <AstralJava> Good grief!! Where has it dropped out of?!
[09:18] <pkern> :-P
[09:19] <bddebian> Heya geser
[09:19] <geser> Hi bddebian
[09:19] <lamego> is there any advantage on using pbuilder versus sbuild ?
[09:19] <pkern> sbuild is a bloody piece of software.
[09:19] <geser> easier to setup?
[09:20] <lamego> I found sbuild easier to setup
[09:20] <pkern> Take cowbuilder. Just as fast and you don't have screwed up chroots.
[09:20] <lamego> I don't have screwed chroots, there is the end-session command for such cases :)
[09:22] <pkern> Very bad example (don't try this at home): A hostile build system does rm -rf ${BUILD}/ -- but BUILD is unset. This will basically wipe your chroot. With cowbuilder it's just a copy of another one, no problem. With sbuild you are screwed.
[09:25] <AstralJava> Alright, thanks for correcting me :) However, the problem persists, and the culprit I think is that it ignores the ./ Packages file, as it says. Here's the updated online stuff, if it matters... http://pastebin.ubuntu-nl.org/39691/
[09:27] <geser> AstralJava: can you add a "ls -l /var/cache/pbuilder/result" to the hook to see if the dir contains the expected content?
[09:27] <AstralJava> geser: Sure thing, gimme a sec.
[09:27] <pkern> I want to see the content of /var/cache/pbuilder/result/Packages (and this somehow depends on the content geser looks for)!
[09:29] <AstralJava> pkern: Yes, I did. :) However, you are on to something. It cannot find anything at that location.
[09:30] <geser> reminder: MOTU meeting
[09:30] <geser> in 30 minutes
[09:31] <pkern> geser: Oh.
[09:31] <pkern> geser: Topic list is appreciated! (And don't point me to the wiki. ;)
[09:32] <AstralJava> Okay, I had done a mistake, and commented out BINDMOUNTS in my ~/.pbuilderrc, thinking that it was in global one, which wasn't the case. Now it finds stuff again, but still insists on ignoring ./ Packages
[09:32] <pkern> La la la
[09:34] <bddebian> la la la laaaaaa
[09:35] <lamego> pkern, where is that rm -rf BUILD code with an unset var ?
[09:35] <pkern> lamego: I am bad at pondering examples. Point is that I already had that the sbuild chroot was left in an inconsistent state.
[09:35] <pkern> Due to some postinst screwing up.
[09:35] <geser> pkern: the wiki lists only "sponsored merge workflow" and the usual fixed items for todays meeting
[09:35] <pkern> geser: Thought that@merge workflow.
[09:36] <pkern> How sensible is this to discuss on IRC. Heh. Anyway I don't think I should attend, due to that bloody exam tomorrow.
[09:36] <lamego> pkern, probably because you didn't knew how to use it, lvm snapshots and file based schroots created copies, it is not possibled to get an inconsistent schroot because you never use the original
[09:37] <lamego> directory based schroots, are just pointers, plain chroots
[09:37] <geser> pkern: exams on a saturday?
[09:37] <pkern> Well it was yonks ago.
[09:37] <pkern> geser: Aye.
[09:37] <geser> pkern: good luck
[09:37] <pkern> geser: Thanks. I'm entirely not confident.
[09:39] <AstralJava> Hmpf! It wasn't ignoring said file after all (even though it says so), it just needed another dependency package I had somehow overlooked.
[09:41] <AstralJava> Thanks to everyone who helped with this. :) I really was in need of a reality check it seems. :)
[09:45] <AstralJava> Okay, the FreezeExceptionProcess page mentions to attach an install log along with the bug, what does this really mean?
[09:47] <ScottK> AstralJava: Copy/paste what you get in the console when you install it.
[09:47] <norsetto> AstralJava: just copy and paste the install messages from your terminal
[09:47] <ScottK> Show that it installs.
[09:47] <ScottK> Mentioning what testing you've done to see that it works is always nice too.
[09:47] <AstralJava> ScottK: norsetto: Thank you. :)
[09:47] <ScottK> No prolbem.
[09:47] <ScottK> problem even
[09:49] <norsetto> scottK: perhaps it is worth expanding the wiki page on that ...
[09:49] <ScottK> norsetto: Feel free.
[09:50] <Joe_CoT> hey, what project would i report a bug against for a bug in deluge? The deluge project don't use bugs
[09:51] <osmosis> if I want to know more about how a package is put together, what files do I look at ?
[09:51] <ScottK> Joe_CoT: If that package is in Ubuntu, report it against deluge in Ubuntu.
[09:52] <pkern> ScottK: Install logs are an Ubuntu invention. I guess they result out of a specific event? ;)
[09:53] <ScottK> pkern: I'm reletively new here (in the last 10 months) so I don't know all the history.
[09:53] <ScottK> I think asking for evidence that the new version is installable is reasonable.
[09:54] <AstralJava> I'm very new with these things, and I must say it is certainly reasonable to ask that I do that. Makes perfect sense. :)
[09:54] <osmosis> ScottK: you can ask all you want.
[09:54] <osmosis> ScottK: new version of what ?
[09:55] <ScottK> osmosis: Sure and if I don't get it, the requestor doesn't get their UVFe approved.  Fine with me.
[09:55] <ScottK> osmosis: It's for the UVF exception request.
[09:55] <pkern> Well, probably I am biased because I do rebuilds etc. for Debian sponsorships anyway (i.e. I have to do them). So you depend entirely on the submitter of the debdiff here.
[09:55] <osmosis> ScottK: im new in the last 10 minutes.  Whats a UVFe ?
[09:55] <pkern> Probably reasonable considering the amount of packages we manage here.
[09:55] <ScottK> Ah.
[09:55] <ScottK> osmosis: Upstream Version Freeze exception request.
[09:55] <osmosis> ive just been a ubuntu user so far. Im interested in how packages work though.
[09:56] <osmosis> ScottK: yah,..those must be confirmed. Distro stability depends on it.
[09:58] <norsetto> osmosis: you may want to check these out: https://wiki.ubuntu.com/MOTU & https://wiki.ubuntu.com/UbuntuDevelopment
[09:58] <Joe_CoT> ScottK: found the bug. Thanks :D
[09:59] <osmosis> norsetto: for example, i heard that the xen kernel used in ubuntu has a bunch of custom patches. How would I see what these patches are ?
[10:00] <Joe_CoT> https://bugs.edge.launchpad.net/ubuntu/+source/deluge-torrent/+bug/149050
[10:00] <ubotu> Launchpad bug 149050 in deluge-torrent "Deluge torrent client: Cannot set file priority, as it continually claims that Full Allocation is not set" [Undecided,Confirmed] 
[10:01] <Joe_CoT> The submitter suggests updating to 5.5 from 5.4 to resolve the bug. What are the odds of that happening at this point?
[10:02] <norsetto> osmosis: you should check out the source package and changelog
[10:03] <osmosis> norsetto: all i know is  apt-get install xen-hypervisor-3.1   ...how do I check out the source package and changelog ?
[10:04] <norsetto> osmosis: https://edge.launchpad.net/ubuntu/+source/xen-3.1 and to get the source: apt-get source xen-3.1
[10:05] <norsetto> osmosis: just in case you have a problem with these links, just delete the "edge" from them
[10:08] <imbrandon> ahh finaly
[10:10] <geser> somebody interested in a MOTU meeting now?
[10:16] <amarillion> Is there a way to target a package to multiple releases at the same time, e.g. "libalfont-dev (1.91-0ubuntu1~ppa3) feisty, gutsy; urgency=low" ?
[10:17] <ScottK> amarillion: Ask in #launchpad. This is not a PPA help channel.
[10:17] <geser> amarillion: no
[10:17] <norsetto> amarillion: no
[10:17] <amarillion> ok :)
[10:18] <DktrKranz> did anybody notice a failure like debian 441490 ?
[10:18] <ubotu> Debian bug 441490 in ivtools "ivtools - FTBFS: stl_algobase.h:226:56: error: macro "min" passed 3 arguments, but takes just 2" [Serious,Open]  http://bugs.debian.org/441490
[10:18] <AstralJava> bug 145538 now has lots of stuff to counter the unmetdeps problem of wammu
[10:18] <ubotu> Launchpad bug 145538 in wammu "[UNMETDEPS]  wammu has unmet dependencies (dup-of: 144488)" [Medium,Confirmed]  https://launchpad.net/bugs/145538
[10:18] <ubotu> Launchpad bug 144488 in wammu "gutsy wammu dependency problem" [Medium,Confirmed]  https://launchpad.net/bugs/144488
[10:19] <AstralJava> Ouch, sorry I didn't catch it was a dupe already.
[10:38] <fraco> do universe bug reports also go to bugs.launchpad.net?
[10:38] <persia> fraco: Yes.
[10:38] <fraco> k thnx
[10:38] <bddebian> persia!
[10:38] <persia> bddebian!
[10:39] <blueyed> Hi.
[10:39] <norsetto> bddebian: persia: !!
[10:39] <blueyed> Is there a script to adjust debian/control according to the DebianMaintainerField spec?
[10:39] <geser> blueyed: yes
[10:40] <geser> update-maintainer from ubuntu-dev-tools (gutsy)
[10:41] <geser> https://edge.launchpad.net/ubuntu/+source/ubuntu-dev-tools/
[10:43] <blueyed> omg. I've just moved my sources.list file away to test a bugfix. *lol*
[10:43] <bddebian> persia: Haven't seen you on IRC much lately??
[10:44] <persia> bddebian: I came down with life, but I'm recovering.
[10:44] <bddebian> Heh, I hear ya man
[10:46] <superm1> hi persia, long time no see :)
[10:47] <persia> superm1: Hi
[10:48] <superm1> persia, last time i remember talking to you on irc was before i was MOTU :)
[10:48] <persia> superm1: Yep.
[10:49] <superm1> persia, you back for the rest of the bug fixing cycle, or joining again for hardy?
[10:50] <persia> superm1: I'll be around for some of the remainder, and for Hardy.
[10:50] <superm1> persia, you joining for UDS too?
[10:51] <persia> superm1: I won't be able to make it to Boston, but I'll be virtually around some.
[10:51] <superm1> cool
[11:04] <bluefoxicy> minghua:  yes, it was.  It's no longer sold there.
[11:05] <bluefoxicy> minghua:  it's mozilla.org bug #322367
[11:06] <blueyed> geser: update-maintainer is great. I've updated the wiki (https://wiki.ubuntu.com/DebianMaintainerField?action=diff)
[11:09] <pkern> blueyed: update-maintainer, not update-notifier
[11:11] <blueyed> thx pkern. fixed.
[11:19] <AstralJava> ScottK: Hi, and thanks for ACKing the bug! However I just realized that using requestsponsor script requires an MTA locally, and I don't have one. How to proceed? By PPAPUT?
[11:20] <ScottK> AstralJava: What are you trying to do with the request sponsor script?
[11:21] <ScottK> I think what you want is requestsync.
[11:21] <norsetto> good night all
[11:22] <AstralJava> ScottK: Ahh... I'm confused now, I haven't seen that mentioned anywhere. :) Can you explain more? What I want is someone to re-sync python-gammu from debian unstable.
[11:23] <ScottK> AstralJava: In ubuntu-dev-tools there is a requestsync script.  Use it with the -s option to request a sponsor for a sync.
[11:25] <AstralJava> ScottK: So.... something like: requestsync -s python-gammu_0.22-2 gutsy
[11:25] <ScottK> Yes.
[11:26] <ScottK> But no need to file that until you have your UVFe approved.
[11:28] <AstralJava> Alright, well the FreezeExceptionProcess only mentioned that one ACK, so I thought it'd be alright. :)
[11:30] <ScottK> No, when it's approved it'll get set to "Confirmed."
[11:31] <AstralJava> Okay, yeah, the Exception bug that you marked invalid for the time being, and it will be marked as "Confirmed" if it can be synced?
[11:54] <persia> How frozen is universe currently?  Does UserInterfaceFreeze mean I shouldn't add a gksu to a .desktop file?  Are approvals required for crash fixes?
[12:01] <slangasek> persia: universe is now completely frozen, https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-October/000345.html
[12:02] <slangasek> that means anything that's uploaded has to be hand-approved, and the only things that will be are bugfixes
[12:03] <persia> slangasek: Ah.  Thanks.
[12:12] <persia> slangasek: I'm a little confused about the timing of the freeze.  Should https://wiki.ubuntu.com/GutsyReleaseSchedule be updated to show a ReleaseFreeze in week 24?  The freeze your mail describes appears to match the freeze for week 25, unless I'm misreading something.  (And no, I don't propose the freeze be changed, just the documentation).
[12:14] <slangasek> persia: I do think that https://wiki.ubuntu.com/GutsyReleaseSchedule is a little unclear about this (since this is my first time through an Ubuntu release I had to piece my own answer to that question together from a few different sources), but I also don't see the freeze you're talking about listed in week 25?
[12:14] <persia> slangasek: https://wiki.ubuntu.com/ReleaseCandidate : "From here until..."
[12:15] <slangasek> anyway, it's intended that there be a full freeze a week before the release candidate; which means yesterday, but it was pushed back a day to keep the release team's hands free from having to approve a bunch more packages
[12:15] <persia> slangasek: On the other hand, I don't see a (slightly) softer freeze for the RMs to manage getting everything smooth before the RC, so I'm not sure it's not better to have a week 24 freeze.
[12:15] <slangasek> persia: ok, sure.  The difference between the current freeze, and what's listed under ReleaseCandidate, is that the fixes allowed right now aren't just showstoppers
[12:17] <persia> slangasek: there's a rule that only release managers are allowed to change the schedule.  Would you mind putting a note there to indicate this freeze (which is probably good).
[12:17] <bicchi> I would like to know if Gutsy is going to upgrade its version of mono to 1.2.5.1 before been released?
[12:18] <persia> bicchi: It's very unlikely.  Version 1.2.4-6ubuntu4 just went in recently.
[12:19] <slangasek> bicchi: it is distinctly not going to
[12:19] <slangasek> persia: I'll try to figure out what the freeze should be called in discussion with the release team and get something updated, yes
[12:20] <persia> slangasek: Thanks.
[12:25] <bicchi> By the looks of it the current version of mono in gutsy is a bit outdated. OpenSuse came out with the 1.2.5. Does anyone knows of a repository that has the packages up to date?
[12:34] <Fujitsu> Um, did the entire archive just freeze without any kind of notice that it was going to happen, or did I miss the announcement?
[12:35] <lamego> slangasek> anyway, it's intended that there be a full freeze a week before the release candidate; which means yesterday, but it was pushed back a day to keep the release team's hands free from having to approve a bunch more packages
[12:36] <persia> Fujitsu: Yep.
[12:36] <slangasek> Fujitsu: yes, the lack of notice was entirely my fault
[12:36] <Fujitsu> In every previous release, universe has been unfrozen until like 24 hours before.
[12:37] <persia> I'd argue this is a good way to do it, but the notice means I won't spend the weekend the way I might otherwise have.