[00:14] <lfaraone> cjwatson: I'm actually having trouble uploading the fix to Debian, dpkg-source has been dieing on their end but not on mine. I'll reupload and see what happens...
[00:15] <cjwatson> lfaraone: if you still have trouble, mail me the logs and a pointer to the source package and I'll see what I can do
[00:16] <lfaraone> cjwatson: sure, thanks!
[07:00] <dholbach> good morning
[07:01] <philipballew> morning dholbach
[07:03] <dholbach> hi philipballew
[08:08] <iulian> Morning.
[08:12] <nigelb> Morning iulian
[08:44] <hrw> hi
[08:44] <hrw> uploading packages to universe requires approval now?
[08:45] <cjwatson> hrw: we can only freeze the whole archive or none
[08:46] <hrw> sure
[08:46] <cjwatson> so yes, any upload to Ubuntu requires approval at the moment, although universe uploads are typically waved through if they look correct and don't get in the way of CD builds
[08:47] <hrw> ok, whom with I should talk then? 6 packages of cross compilers in my queue
[08:48] <cjwatson> just upload them
[08:48] <cjwatson> you don't need to ask for approval in advance, and in fact generally we'd prefer you didn't
[08:48] <hrw> ok
[08:49] <cjwatson> they'll sit in the queue where we have tools for reviewing them
[08:50] <hrw> ok. uploaded 2 of them - with next ones I prefer to wait for first ones to build.
[08:50] <hrw> maybe should add versioned build dependencies
[09:41] <Rhonda> Hmm
[09:42] <Rhonda> I wonder what the regulations are for universe in Ubuntu, especially with respect to build-depends
[09:43] <Rhonda> Hmm, and nvidia-settings is also in universe …
[09:43] <Rhonda> Shouldn't it be in multiverse, when it's in contrib in Debian?
[09:49] <RAOF> Rhonda: I think that's one of the differences in policy between Debian and Ubuntu; IIRC nvidia-settings is GPL and doesn't require non-free build-dependencies, so it's in Universe.
[09:50] <cjwatson> *in general* Debian contrib/non-free map to Ubuntu multiverse, and main+universe should be closed under depends+build-depends
[09:50] <cjwatson> however sometimes we take a different decision about what's free
[09:51] <cjwatson> often a mismatch is just a mistake though
[10:03] <Rhonda> I'm currently digging into the conky issue, to be honest.
[10:04] <Rhonda> Which was wrongly moved to main in Debian with flawed reasoning, and I wanted to check if that might affect Ubuntu too.
[10:04] <Rhonda> But it seems to have always been in universe in ubuntu, so …
[10:05] <Rhonda> I'm uncertain anyway why nvidia-settings is stuck in contrib in Debian. Because it requires the nvidia X driver to be useful?
[10:05] <directhex> Rhonda, indeed
[10:05] <Rhonda> I really would like to see such information stored in the copyright file in a clear voice.
[10:06] <Rhonda> I stumbled upon it because I noticed it as debian backports ftp master and had to reject it, in case you wonder. :)
[10:10] <cjwatson> Rhonda: an instruction to that effect was added to Policy 12.5 a few years back
[10:10] <cjwatson> debian-policy 3.8.0.0
[10:10] <cjwatson>      Packages in the _contrib_ or _non-free_ archive areas should state in
[10:10] <cjwatson>      the copyright file that the package is not part of the Debian
[10:10] <cjwatson>      distribution and briefly explain why.
[10:11] <Rhonda> Unfortunately "should" parts are seldomly followed …
=== azeem_ is now known as azeem
[10:20] <cjwatson> indeed, but gives you additional justification for a bug report :-)
[12:25] <hrw> bug 835743 - can someone take a look?
[12:25] <ubottu> Launchpad bug 835743 in simple-ccsm (Ubuntu Oneiric) "simple-ccsm version 0.8.2-0ubuntu1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/835743
[12:26] <hrw> debdiff attached
[12:27] <jtaylor> hrw: is the debian-changes-0.8.2-0ubuntu2 intentional?
[12:28] <hrw> ouch
[12:28] <hrw> moment
[12:28] <hrw> will recreate
=== pan1nx is now known as theseinfeld
[12:30] <hrw> uploaded
[12:30] <hrw> forgot to drop one file before debuild -S
[12:32] <jtaylor> changing from pycentral to dh_python2 requires a ffe
[12:33] <hrw> it is still pycentral not dh_python2
[12:33] <hrw> dh_pycentral
[12:33] <jtaylor> you removed dh_pycentral
[12:33] <hrw> it is called anyway - probably by cdbs/python-distutils.mk
[12:35] <jtaylor> ups yes there is a PYTHON_SYSTEM above
[12:36] <hrw> I am looking at 'arm-porting-jam' buglist and this was first entry which looked easy enough for <30 minutes work.
[12:37] <jtaylor> if you want something hard try finding the gcc bug causing pari to ftbs :)
[12:39] <hrw> I already have ~40 bugtabs opened to check
[12:39] <hrw> ruby, mono, java, othercrap
[12:39] <jtaylor> hrw: langpack.mk was removed in favor of dh_translations, but I don't see it called for this one
[12:40] <hrw> I checked with dh_translations and without - package was same
[12:41] <jtaylor> yes also just cheked the result is the same
=== theseinfeld is now known as pan1nx
=== med_out is now known as medberry
[13:04] <hrw> bug 833880 is in multiverse - simple build-dependency fix
[13:04] <ubottu> Launchpad bug 833880 in mush (Ubuntu Oneiric) "mush version 7.2.5unoff2-25.1ubuntu1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/833880
[13:04] <jtaylor> hrw: is patch 02 necessary? also the desktop file created should be removed in clean
[13:05] <hrw> jtaylor: it was done that way before so I preferred to not change it
[13:05] <hrw> but patch 02 was part of debian diff
[13:06] <jtaylor> yes but it gets overwritten by the build latter
[13:06] <lfaraone> cjwatson: I forwarded you the error and a link to the dsc.
[13:06] <lfaraone> .
[13:07] <jtaylor> it appears it was added by accident
[13:07] <jtaylor> due to the incomplete clean target
[13:08] <cjwatson> lfaraone: ok, thanks
[13:08] <hrw> jtaylor: like installed_files in my first debdiff probably
[13:20] <hrw> jtaylor: v3 attached
[13:31] <jtaylor> please base the debdiff on the package in the archive, else it seems fine
[13:34] <jtaylor> also its not installable due to compiz breaks on it
[13:35] <jtaylor> but that should be an upstream issue
[13:37] <hrw> arhg. changelog this time
[13:38] <jtaylor> and rules
[13:39] <hrw> too many things at once
[13:50] <hrw> jtaylor: v3 is against archive version
[13:53] <jtaylor> hrw: does not apply cleanly, e.g. rules has no langpack line and changelog also rejects
[13:54] <hrw> k
[13:59] <hrw> v4 version applies
[14:18] <jtaylor> thx
[15:27] <nigelb> Laney / tumbleweed - around?
[15:27] <tumbleweed> nigelb: hi (I think Laney is on holiday)
[15:27] <nigelb> tumbleweed: Ah!
[15:27] <nigelb> I was looking for suggestions on what to do about challenges.
[15:28] <nigelb> It looks like it needs further planning for next cycle.
[15:28] <nigelb> But if you want to start that discussion now over email, I can do that
[15:28] <tumbleweed> yeah, it does, we skimmed over it a lot at UDS
[15:28] <nigelb> I won't be at UDS, so someone will have to take it up :)
[17:50] <joru> what happens when a bug reported by apport is being marked as private?
[17:50] <joru> and why?
[17:50] <joru> did i click somewhere i shouldnt have clicked?
[17:51] <Rhonda> security related, potential sensitive information?
[17:51] <joru> ok, well i'm the noob so i've got no idea =)
[17:51] <joru> just know that i didnt click somewhere i shouldnt have then
[17:54] <jtaylor> all crash reports by apport are marked private by default
[17:54] <jtaylor> they could contain private information in tracebacks and coredumps
[17:55] <jtaylor> after successful retracing the coredump will get removed and you can check the attachments
[17:55] <jtaylor> when there is nothing private in there, set it to public
[18:05] <astraljava> Hey guys, got a silly little question. One of our team members (ubuntustudio-dev) just pushed a commit to a branch (ubuntustudio-menu). Am I to expect a new version in the repositories sometime soon, or does the freeze effect that now?
[18:05] <astraljava> effect could possibly be affect, sorry, English is not my native language. :)
[18:08] <joru> jtaylor: ah that figures. then i understand
[19:56] <joru> jtaylor: so if i've found a bug when running a live-cd what could be private?
[19:57] <joru> jtaylor: maybe a password supplied to the install-process?
[19:57] <joru> jtaylor: otherwise i cannot see what is private for me in a live session
[19:57] <jtaylor> probably nothing, but making bugs private is default behavior
[19:57] <joru> jtaylor: although i hope not passwords are logged in cleartext
[19:57] <jtaylor> if its your bug you can make it public yourself
[19:57] <joru> jtaylor: okidoki, well i'll switch it from private to public
[19:58] <joru> thanks for pointing that out
[20:46] <handschuh> hi
[20:46] <handschuh> what if a package that is already in the repos changed its way of versioning the packages (i.e. past: date, present: version number)
[20:47] <handschuh> this causes problems since the package manager things the older package with the date is newer than the one with the version number
[20:48] <DktrKranz> handschuh: you have to add an epoch (e.g. 1:version)
[20:48] <handschuh> I see, thank you!
[20:48] <DktrKranz> you're welcome
[20:52] <handschuh> another qq: the revu page has a 'nuke' link on archived packages. If I click on that, I am redirected at the main page but the package is still there. Is the real nuke delayed?
[20:53] <DktrKranz> I think that's limited to sponsors
[20:53] <DktrKranz> (or rewievers)
[20:54] <handschuh> sponsors are the people that upload the packages, right?
[20:54] <handschuh> so in my case, I am trying to nuke packages that I uploaded some time ago
[20:55] <DktrKranz> I can do it for you, if you want
[20:55] <DktrKranz> which packages?
[20:55] <handschuh> "jaolt"
[20:55] <handschuh> and "	libauvitoapiaxis-java"
[20:59] <DktrKranz> done
[21:00] <handschuh> thanks a lot!
[21:01] <handschuh> hmm I am still able to access the packages
=== medberry is now known as med_out