[03:28] <ScottK> It doesn't.
[04:08] <micahg> ScottK: would you mind a featureful upload for bug 375038 in precise?  i.e. add the enable flag and upload with a +xps version
[04:24] <jbicha> micahg: libgxps is in universe in Precise though, right?
[04:58] <ScottK> micahg: Is it a regression?
[05:01] <jbicha> ScottK: no, it's a new feature
[05:03] <ScottK> Then I do mind.  It's not SRU material. It should be done in backports.
[05:19] <ajmitch> micahg: someone submitted seamonkey to the arb. I pointed them in your direction but I'm not entirely convinced they'll contact the team :)
[05:19] <micahg> ScottK: I was asking for backports, sorry :)
[05:36] <micahg> ajmitch: hrm, it needs to be updated every 6 weeks, if it's easier to do that through the ARB, then go for it
[05:36] <micahg> with someone willing to commit
[05:36] <micahg> ajmitch: unless bkerensa objects (he's working on it for the distro)
[05:37] <micahg> I'm normally against such things, but it's a real bear
[05:37] <ajmitch> micahg: definitely not a candidate for the ARB due to size
[05:37] <ajmitch> I know you probably don't want to commit time to it
[05:37] <micahg> ajmitch: ok, well, as I told bkerensa, I'm willing to sponsor uploads if people are willing to do the work to maintain it
[05:38] <micahg> jbicha: yeah, that's why I was thinking backports ;)
[05:39] <bkerensa> ajmitch: Whats up?
[05:39] <bkerensa> >.<
[05:39]  * bkerensa looks up
[05:40] <bkerensa> the arb handles packages too?
[05:40] <bkerensa> Hmm is someone looking to maintain seamonkey or whats the purpose of going to the arb versus having someone sponsor it?
[05:40] <ajmitch> what do you mean by 'handles packages'?
[05:41] <ajmitch> they submitted a binary tarball
[05:41] <bkerensa> ajmitch: I thought they only did like applications for independent developers or something that needs introduction not established things
[05:41] <bkerensa> ahh
[05:41] <bkerensa> ajmitch: do you not what version of Seamonkey the tarball they submitted was?
[05:42] <ajmitch> 2.10.1
[05:42] <ajmitch> & yes, submissions ought to be from someone associated with the project
[05:44] <bkerensa> well I dont object... In fact I might welcome it especially if they are interested in collaborating on maintaining it
[05:44]  * jbicha points to the confusingly named Debian package http://packages.qa.debian.org/iceape
[05:45] <ajmitch> bkerensa: I told him to contact the mozilla team if he's interested in helping out
[05:47]  * micahg keeps getting mails about chromium
[05:47] <ajmitch> offers of help?
[05:48] <micahg> no, questions where people can get updates ;)
[05:48] <ajmitch> hah
[05:48]  * micahg should just say Debian unstable :)
[05:49] <micahg> we really need someone like fta :)
[05:49] <ajmitch> what, someone with lots of time & energy?
[05:50] <micahg> yes, and crazy computing power :)
[05:52] <jbicha> did Canonical ever fill that Webkit/Chromium job they were hiring for?
[05:53] <jbicha> I'm assuming not
[05:55]  * micahg doesn't see the opening on the website
[06:18] <micahg> xnox is going to be so happy that boost1.50 just landed in unstable :)
[06:18] <ajmitch> heh
[06:19] <ajmitch> so glad you found a willing maintainer ;)
[06:19]  * micahg never touched the stuff :)
[06:20] <ajmitch> you're missing out
[06:20]  * micahg will add it to his bucket list....
[06:20] <ajmitch> 101 easy ways to make you want to kick the bucket?
[06:21] <micahg> heh
[06:22] <bkerensa> micahg: the emails are probably my fault
[06:22] <bkerensa> >.<
[06:22] <micahg> bkerensa: I'm just glad it linked to my LP profile :)
[06:23]  * ajmitch still can't reach svn.webkit.org, it's rather odd
[06:23] <bkerensa> micahg: oh I wouldnt put anyones public e-mail
[07:04] <dholbach> good morning
[07:05] <ajmitch> hi dholbach
[07:06] <dholbach> hey ajmitch
[07:11] <bkerensa> gnight micahg ajmitch
[07:12] <ajmitch> night bkerensa
[07:12] <micahg> night bkerensa
[07:16] <dupondje> bdrung: there ? :)
[08:57] <AmberJ> Hello
[08:57] <AmberJ> Do I get it right that we do 'debuild -S -sa
[08:59] <AmberJ> *Do I get it right that we run 'debuild -S -sa' on the host system to create the source package (and do only 'pbuilder build file.dsc' inside pbuilder chroot)?
[09:00] <AmberJ> Do we only build inside pbuilder chroot? Or, are we supposed to create source package (using 'debuild -S') inside pbuilder chroot as well?
[09:01] <_ruben> do you dont do any chroot'ing yourself, the pbuidler command will do the building within a clean chroot environment, the source package indeed is built in the host system
[09:03] <AmberJ> yes, we don't do chrooting ourself.. but I thought maybe we are supposed to use
[09:03] <AmberJ> Damn RETURN key!
[09:04] <AmberJ> **yes, we don't do chrooting ourselves.. but I thought maybe we are supposed to use 'pbuilder --execute' to create source package inside pbuilder chroot as well
[09:04] <AmberJ> I just thought of confirming. Ok, I'll create source package on host system then. Thanks _ruben
[09:07] <tumbleweed> normally, building the source pa ckage doesn't actually require all the dependencies
[09:08] <tumbleweed> so it can easily be done on whatever you are running
[09:08] <tumbleweed> if it won't build, just disable cleaning (-nc) if you're are doing all your building in a pbuilder, that'll be safe to do
[09:23] <AmberJ> ok
[09:25] <AmberJ> And, if I have package from a Launchpad PPA as a build dependency, the preferred way to install it inside chroot is to use 'pbuilder --execute' to install package from PPA inside pbuilder chroot?
[09:27] <Zhenech> tumbleweed, clean should work (and be done) always, or you end up with a diff.gz that is unclean and refuses a new build when someone downloads it
[09:30] <tumbleweed> Zhenech: if you haven't done anything to make it dirty, it'll be clean
[09:30] <Zhenech> tumbleweed, but then -nc wouldnt be needed :)
[09:30] <tumbleweed> Zhenech: I don't follow
[09:33] <Zhenech> tumbleweed, rereading your sentence: you meant -nc when building *source*, not *binary*?
[09:33] <tumbleweed> yes, if you do all your binary building in a pbuilder
[09:34] <Zhenech> ok, my mind read *binary* at the first occurence too -.-
[09:34] <Zhenech> coffee please
[09:34]  * tumbleweed re-reads and sees it was totally unclear :)
[09:35] <Zhenech> two coffee then :)
[09:36] <tumbleweed> it's been a frustrating morning. international connectivity is crawling because a submarine cable is down :/
[09:37] <Zhenech> homeoffice today here, so rather chilly :)
[10:58] <bdrung> dupondje: now
[11:03] <dupondje> bdrung: https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/1018087
[11:03] <dupondje> got a patch for audacious
[11:04] <dupondje> want to do a fix in debian and then sync or?
[11:10] <bdrung> dupondje: the best way would to get the patch into upstream before getting it into Ubuntu through Debian (because audacious upstream is difficult and often complained about ubuntu patching bugs into it)
[11:11] <dupondje> bdrung: its upstream for 3.3.x
[11:12] <dupondje> https://github.com/audacious-media-player/audacious-plugins/commit/1957913f4857df0845ae7e15dadc93e38c248a0e
[11:12] <bdrung> dupondje: good.
[11:12] <dupondje> but its not clean imo
[11:12] <dupondje> it will break on GTK+ < 3.5
[11:13] <bdrung> hm
[11:13] <dupondje> they should keep the hack for GTK+ < 3.5
[11:13] <dupondje> but ok :p
[11:15] <Laney> add something like "#if !GTK_CHECK_VERSION(3,5,0)" then
[11:15] <bdrung> gtk 3.4 is in unstable, so we need an improved patch
[11:15] <dupondje> see http://redmine.audacious-media-player.org/issues/138
[11:15] <dupondje> I proposed a patch with GTK_CHECK_VERSION ...
[11:17] <Laney> oh well, maybe they want the stock behaviour
[11:18] <dupondje> Laney: applying their patch, will change the behavious for current users ...
[11:18] <dupondje> so
[11:18] <dupondje> its not preferred I guess :)
[11:19] <Laney> but you're only going to have it in quantal.
[11:20] <dupondje> Laney: depends if bdrung prefers to upload it first in debian :)
[11:20] <Laney> why would he do that when it definitely would change behaviour? and one day before the freeze.
[11:21] <bdrung> dupondje: it prefer debian first. i can do the upload if you give me a patch
[11:21] <bdrung> the patch should work for gtk < 3.5
[11:21] <Laney> sounds like you're poking upstream with a stick there
[11:21] <Laney> he explicitly refused that patch
[11:22] <dupondje> http://redmine.audacious-media-player.org/attachments/download/89/slider_fix.patch
[11:22] <bdrung> okay, then let's carry that patch in ubuntu
[11:23] <dupondje> upstream should get slapped
[11:23] <dupondje> breaking current behaviour for GTK+ <= 3.4
[11:24] <dupondje> so bdrung, just do it in ubuntu ?
[11:24] <bdrung> dupondje: upstream is not very packager friendly
[11:24] <bdrung> dupondje: yes
[11:24] <dupondje> i'll fix it then :)
[11:24] <bdrung> dupondje: can you state in the commit that this patch can be dropped in 3.3?
[11:25] <dupondje> sure
[11:44] <dupondje> bdrung: https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/1018087 could you upload it for me ? :)
[12:20] <dupondje> thx :)
[12:50] <ScottK> micahg: For backports, things like that are totally fine as long as it's an actual backport (fix it in the development release first).
[16:34] <PaoloRotolo> Hi all!
[18:44] <jbitcm-> hello can you help me to undestand how i can adopt a package
[18:47] <ScottK> jbitcm-: Ubuntu doesn't have a concept of package maintainers, so adoption is purely informal and something you do by just doing the work to keep the package in shape.
[18:48] <jbitcm-> ScottK, thanks for answer but now i have a pbuilder system and i want to help to package in ubuntu
[18:49] <ScottK> OK.  That's a much more general question.  My usual advice is to find bugs in things that you use and are bothering you and then see if you can figure out how to fix them.
[18:53] <tumbleweed> if you are looking for something easy to get started with: https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
[19:14] <ScottK> ajmitch: boost1.50 just hit quantal (in Universe, not Main).
[19:14]  * ScottK waits for the twitch.
[19:33] <micahg> autosync FTW
[19:41] <Laney> ajmitch is The Boost Guy now?
[19:41] <ScottK> Definitely.  Him or xnox.
[19:42]  * Laney likes them apples
[19:42]  * ScottK too.
[20:19] <ajmitch> ScottK: micahg told me about 1.50 earlier. The responsibility has definitely passed to xnox
[20:20] <ScottK> Fortunately he doesn't hang out here, so he can't defend himself.
[20:22] <ajmitch> even better
[20:31] <AmberJ_> I'm trying to get extra packages installed in pbuilder.
[20:31] <AmberJ_> I'm using: sudo pbuilder update --extrapackages python-software-properties sudo
[20:31] <AmberJ_> But it won't install 'sudo' ... I'm sure I'm messing up with the format of command.
[20:32] <micahg>  --extrapackages [packages-to-add on pbuilder create]
[20:34] <AmberJ_> micahg: Do I need to add those square brackets as well?
[20:34] <micahg> AmberJ_: no, that just means it only works on create, not update
[20:34] <tumbleweed> but you can do anything you want with a pbuilder login --save-after-login
[20:35] <AmberJ_> micahg: Ah, that means I should use something like 'sudo pbuilder create --extrapackages PAC1 PAC2 ...' ... right?
[20:36] <xnox> Who has been talking about me, behind my back?!
[20:36] <xnox> ajmitch: ScottK ????
[20:36]  * ScottK whistles.
[20:36] <ajmitch> I wouldn't do a thing like that
[20:36]  * Laney wonders how information managed to leak out of this fortress
[20:37] <tumbleweed> he must have an informer
[20:37] <ajmitch> as long as he gets boost uploaded...
[20:38] <AmberJ_> tumbleweed: 'man pbuilder' says (about --login): "Only use this for temporary and debugging purposes." ... So I thought of staying away from --login
[20:39] <tumbleweed> AmberJ_: it's the easiest way to make changes to the chroots
[20:39] <micahg> pbuilder hooks are a good way to make temporary or per-build changes
[20:40] <xnox> It was discussed on the release team bug about boost1.49, that boost1.50 will be released in time, but there will not be another boost transition! It takes 2-3 months to do in Debian.
[20:41] <xnox> And I do not want more than one boost transition in a cycle, thank you very much.
[20:41] <xnox> =))))))))))))))))))))))))))
[20:41] <ajmitch> but they're fun
[20:41]  * micahg doesn't think we should have 2 versions of boost
[20:41] <xnox> well we currently, already do!
[20:41] <ajmitch> and it already causes issues
[20:41]  * micahg files for removal
[20:42] <xnox> 1.46 and 1.49
[20:42] <micahg> 1.46 is going away
[20:42] <xnox> well yeah.
[20:42] <micahg> and we're early enough for another transition
[20:42] <xnox> when are archive rebuilds scheduled for?
[20:43] <xnox> micahg: will boost1.50 bee blacklisted?
[20:43] <micahg> after DIF
[20:43] <xnox> cause I fear that loads of packages that do not link against boost, but use it's templates may FTBFS in funny gcc-4.7 kind of ways
[20:43] <micahg> xnox: well, if I file for removal, yes
[20:43] <xnox> micahg: please do ;-)
[20:44]  * xnox is busy packing the house for moving
[20:44] <micahg> ScottK: does this sound reasonable?
[20:44] <AmberJ_> ok, I'll try --login and hooks now..
[20:45] <ScottK> micahg: I think having 1.50 in Universe is OK.
[20:45] <ScottK> Some developers always want the latest boost, so it's good to provide it.
[20:45] <AmberJ_> Thanks micahg tumbleweed!
[20:45] <ajmitch> except when they build-depend on a package whcih depends on an older boost
[20:45] <ScottK> Yes.  Then it can get fun, but you can't have everything.
[20:45] <xnox> boost1.50 by itself is fine, as long as boost-defaults doesn't get switched with an autosync
[20:46] <ScottK> xnox: Exactly.
[20:46] <ScottK> Debian isn't changing the default now, so it's fine.
[20:46] <ajmitch> with debian freezing, I doubt that there'll be a switch to 1.50 there
[20:46] <xnox> but we can do the rebuilds easily if boost1.50 is in the archive
[20:46] <micahg> ok, well, it doesn't seem to get updated in stable anyways, so it can stay :)
[20:47] <xnox> simply have a ppa with boost-defaults switched to 1.50, build depend on that and voila rebuild environment ready
[20:47] <ScottK> Yep.
[20:47] <xnox> ajmitch: I have been killing packages that build-depend on versioned boost-dev libs.
[20:47] <xnox> ajmitch: I adjusted the tracker to take those into account. But maybe I need more
[20:48] <xnox> regexp/different tracker to kill all of those
[20:48] <ajmitch> xnox: just trying to recall if the problem I came across was something that was in the archive or not
[20:48] <ajmitch> upstream was using 1.48 features, anyway
[20:48] <xnox> ajmitch: http://people.canonical.com/~ubuntu-archive/transitions/boost1.49.html
[20:49] <xnox> ajmitch: oh boost1.48 was funny. It was in the archive, but it never became the boost-defaults (not in ubuntu at least) as far as I can see
[20:49] <xnox> ajmitch: what is your launchpad id?
[20:49] <ajmitch> right, because it was transitioning in debian too late, causing too many issues
[20:49] <ajmitch> my lp id is ajmitch
[20:50] <xnox> for boost1.49 transition these are the remaining bugs: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=boost1.49
[20:50] <ajmitch> the situation with 1.48 is what we're talking about with 1.50 - get it in, but don't make it default
[20:50]  * ajmitch got suckered into patching boost one day to fix a python problem
[20:51]  * ajmitch blames ScottK for that one
[20:51] <ScottK> ;-)
[20:52] <ScottK> xnox: For packages that are actively maintained in Ubuntu, I think the versioned build-depends are fine.  Personally, I don't want to change boost versions by accident.
[20:54] <xnox> ScottK: actively maintained packages don't typically cause any issues. It's unmaintained stuff which causes the most amount of time
[20:55] <ScottK> Yeah.  I just mention it so you don't go overboard on killing off the versioned ones.
[20:55] <xnox> ScottK: I am actually very conservative, at least I think so....
[20:55] <ScottK> OK.
[20:57] <AmberJ_> How do you guys test your build inside pbuilder chroot if your build depends on Launchpad PPA?
[20:58] <AmberJ_> How do you tell pbuilder chroot to include the PPA as build depends?
[20:59] <xnox> AmberJ_: https://wiki.ubuntu.com/PbuilderHowto#Building_With_Local_Packages
[21:00] <xnox> AmberJ_: or you can do --login --save-after-exec
[21:00] <xnox> add the sources line, update / dist-upgrade
[21:00] <xnox> logout
[21:00] <xnox> and do your builds again
[21:00] <AmberJ_> Right thanks xnox.
[21:01] <AmberJ_> The wiki page link reminds me that I should read the whole wiki page first before asking questions!
[21:05] <xnox> ScottK: who does / did ubiquity Qt/KDE frontend?
[21:05] <ScottK> Various people over time.  Of the people that are still around, Ridell has done the most.
[21:06] <xnox> ok. I will ping him about LVM/LUKS stuff then
[21:07] <xnox> as far as I know I didn't break Qt frontend with my bits, but I didn't implement LVM/LUKS for Qt either
[21:21] <ScottK> My recollection is that cjwatson said foundations was going to do that (not you necessarily).
[21:21] <ScottK> It's critical for dropping the Kubuntu alternates.
[21:37] <xnox> I know
[21:38] <xnox> ScottK: It's just I only fiddled with pyqt for a couple of hours back in the qt3 time
[21:38] <xnox> and I don't know C++ / Qt
[21:38] <ScottK> It's PyQt/PyKDE anyway.
[21:39] <xnox> i can read C++ and I did many patches.... but I still claim that I have no formal knowledge of these technologies.
[21:39] <xnox> with gtk+ it's like: "huh?! why would you write this, when you can do this in a rather less complicated and more straight forward way"
[21:40] <xnox> but again, I am one of those people who loves and enjoys C *a lot*
[22:14] <Laney> xnox: 29/06 23:11:23 <rlb> fwiw, emacs24 has been uploaded to unstable
[22:16] <xnox> Laney: YEAH! =)
[22:16] <ajmitch> now that has to make it into precise-backports
[22:17] <xnox> Laney: can't find dsc
[22:17] <Laney> probably NEW?
[22:20] <xnox> Laney: can't see in NEW, nor incomming, nor the archive
[22:20] <Laney> Timestamp: 29.06.2012 / 22:00:06 (UTC)
[22:20] <Laney> want to bet it's there next time?
[22:22] <xnox> Laney: should we make emacs24 default in quantal?
[22:22] <Laney> I guess
[22:22] <ScottK> What's default in Wheezy?
[22:22] <Laney> depends on the rdeps I suppose
[22:22] <xnox> me, you, barry and loads of other people will be happy!
[22:22] <xnox> ScottK: emacs23
[22:23] <ScottK> Then we're on our own for updating rdepends.
[22:23] <ScottK> I'd investigate how much work that is before deciding.
[22:23]  * xnox runs emacs24 from the ppa with no trouble what's so ever
[22:23] <xnox> but then again i am a light user of rdepends
[22:24] <xnox> ScottK: there is an AppStore for emacs24 now, so if it isn't the default it should still be ok.
[22:31] <Laney> I suppose we should have it as a non-default option for a while.
[22:31] <xnox> Laney: are you going to snitch the dsc from new and upload it?
[22:32] <Laney> you can't get files out of new
[22:32] <xnox> =((((( incomming?
[22:32] <Laney> no
[22:32] <xnox> =(((((
[22:32] <xnox> ok
[22:32] <Laney> well, you can in general, but that doesn't work for new stuff
[22:32] <Laney> we'll just have to wait
[22:33] <xnox> patience is a virtue
[22:33] <Laney> I imagine it might sneak its way into wheezy
[22:33] <xnox> *grin*
[22:34] <xnox> good night everyone!
[22:34] <xnox> off to bed
[23:16] <AmberJ> Laters