[02:48] <infinity> Riddell / ScottK: calligramobile is no longer, what do you want to do about it being seeded in active?  Switch to calligra, drop it entirely...?
[02:51] <JontheEchidna> s/calligramobile/calligraactive/
[02:51] <JontheEchidna> just a rename on upstream's part
[02:53] <infinity> JontheEchidna: Ahh, I missed the rename.  Thanks.  Will update the seeds and meta.
[02:54] <JontheEchidna> though one could make the argument that a transitional package would be desirable
[02:55] <infinity> JontheEchidna: One could, perhaps, though kubuntu-active was barely even a tech preview in precise, so I'm not sure how valuable littering the archive with transitional cruft would be.
[02:55] <JontheEchidna> true
[02:55] <infinity> I guess it did have an i386 release.  *shrug*
[02:56] <infinity> I'll leave that up to other people, I'm just fixing uninstallables. ;)
[03:06] <RAOF> Ok. I've just totally dropped context. Time for lunch!
[03:06] <RAOF> @pilot out
[03:44] <kira__> hi everybody :)
[03:45] <kira__> I have stupid question..
[03:45] <kira__> I have ARM5 based Huawei 8110 ( Qualcomm)
[03:45] <kira__> so where I can get u-boot for it?
[03:46] <micahg> kira__: you might want to ask in #ubuntu-arm
[03:46] <kira__> ok.. thank for advice.
[03:46] <kira__> thanks
[03:46] <kira__> bb
[03:53] <hyperair> RAOF: banshee has a microrelease exception. does it still need to complete the SRU stuff for the bugs?
[03:56] <RAOF> hyperair: Not by my understanding of the process, which is why I accepted it into precise-proposed.
[03:57] <hyperair> RAOF: oh, it's accepted?
[03:57] <hyperair> whoops. =p
[03:57] <RAOF> hyperair: You shouldn't have switched to dh9, though.
[03:57] <hyperair> ah
[03:57] <hyperair> =\
[03:58] <RAOF> It's fine in quantal, obviously, but that's not useful in an SRU
[04:51] <pitti> Good morning
[04:52] <pitti> dobey: it was already, I think
[05:11] <slangasek> pitti: hi, has anyone brought bug #1013171 to your attention yet this morning?
[05:12] <slangasek> pitti: it looks to me like apport should be rolled back to python2 until this is resolved
[05:12] <pitti> slangasek: not this morning, but we discussed it yesterday
[05:12] <pitti> it said ogra already fixed the package hook in his branch, so perhaps we can just upload the fixed hook instead, if the full port isn't ready yet?
[05:12] <slangasek> pitti: there are at least 10 affected packages
[05:12] <pitti> "many package hooks" is indeed a bit misleading
[05:13] <pitti> most of them are symlinks to source_xorg.py
[05:13] <pitti> "critical"? that seems very excessive to me
[05:13] <slangasek> it breaks upgrades
[05:13] <pitti> how so?
[05:13] <slangasek> /usr/share/python3/runtime.d/apport.rtupdate gets called and fails
[05:14] <pitti> uh, ok
[05:16] <pitti> slangasek: actually, it's not supposed to pre-compile the hooks in the first place; perhaps I should just (or also) drop that pycompile bit?
[05:16] <slangasek> how do you mean, not supposed to?
[05:16] <pitti> the python modules go into /usr/lib/python3.2/
[05:16] <pitti> the hooks are not python modules
[05:16] <pitti> they are plugins which get parsed and run dynamically
[05:17] <pitti> this .rtupdate thingy is bogus
[05:17] <slangasek> ok
[05:17] <slangasek> that's a much faster fix then :)
[05:18] <pitti> so something in our dh_python2/3 stuff overeagerly tries to compile everything that looks like .py in any package directory?
[05:19] <slangasek> well, it's the sensible default assumption
[05:19] <pitti> hm, any idea how this bug can be reproduced? I tried sudo apt-get install --reinstall python3.2 apport
[05:19] <slangasek> though perhaps there's a dh_python3 bug here in creating a .rtupdate for a directory that apport doesn't ship any .py files in
[05:20] <pitti> oh, it does ship .py files in there (and python scripts which are not named .py)
[05:20] <slangasek> I think you have to install a new version of python to trigger it... so a precise->quantal upgrade, or remove + reinstall python3.2&apport
[05:20] <pitti> ah, I see
[05:20] <slangasek> I think the tools are smart enough to not be fooled by a --reinstall
[05:20] <pitti> sudo /var/lib/dpkg/info/python3.2.postinst configure -- not that either, hmm
[05:21] <pitti> I'll keep trying
[05:21] <pitti> oh, silly me
[05:21] <pitti> not the python3.2 package, the python3 -meta package
[05:21] <pitti> sudo apt-get install --reinstall python3
[05:29] <slangasek> pitti: so I think dh_python3 --skip-private should be sufficient; testing now
[05:31] <pitti> slangasek: I'm in the middle of fixing the (hopefully) last remaining autopkgtest failure (ETA 20 mins), then I'll do a new upload
[05:31] <pitti> with either --skip-private, or just rm'ing the file
[05:42] <slangasek> pitti: alternatively, dump_acpi_tables.py can be renamed to dump_acpi_tables
[05:42] <slangasek> pitti: either should suffice
[05:42] <slangasek> anyway, tested the --skip-private solution and pushed
[05:42] <pitti> slangasek: but apparently it also considers subdirectories? i. e. /usr/share/apport/package-hooks/ is what's causing all the mess?
[05:43] <pitti> slangasek: nice, thanks!
[05:43] <slangasek> pitti: I don't know if it looks at the subdirs or not
[05:43] <slangasek> but if apport doesn't ship any files named .py in that directory in the first place, dh_python3 won't think it needs to provide a rtupdate script for private modules
[05:44] <pitti> slangasek: thanks for the urlib fix, I'll commit that upstream
[05:44] <pitti> slangasek: ok; I can see where that script is being used, but I think it's only in source_linux.py hook
[05:44] <pitti> so we can rename it easily
[05:44] <pitti> but --skip-private sounds more robust either way
[05:45] <slangasek> yes, probably
[05:46] <pitti> slangasek: OOI, how did you notice the urlopen() bug? there is no python3-launchpadlib, or do you have a secret one?
[06:00]  * pitti gets a dreaded cron mail from ddebs.u.c. running out of space again
[06:01] <pitti> slangasek: do you happen to have some superpowers to bump RT #52633 ?
[06:04] <mumbler> pitti: about the title of bug 1013171 -- feel free to change "many package hooks".  :)  That was just my quick-n-dirty attempt to say "not just an xdiagnose bug".
[06:04] <pitti> mumbler: seems fine to me
[06:06] <mumbler> pitti: ok, thanks.  do you have time for a couple apport questions while we are here?  if not, I should go to bed now, anyway...
[06:06] <pitti> mumbler: just shoot
[06:06] <pitti> I'm wrapping a new release to fix that bug and the autopkg tests, but I can answer in between
[06:07] <mumbler> great.  I saw a claim, maybe in someone's blog from UDS-Q, that apport was being phased out in favor of more from whoopsie, and I know not what.  That doesn't seem true now.
[06:08] <mumbler> So I was going to submit some small doc patches for apport.  Is that still a good idea?
[06:08] <pitti> it's never been true
[06:08] <pitti> mumbler: jockey is being phased out
[06:08] <pitti> mumbler: the thing we introduced was whoopsie, to let apport run in stable releases, too
[06:08] <pitti> to send crashes to errors.ubuntu.com instead of Launchpad
[06:09] <pitti> everything else is either a misunderstanding or a secret plot against me :)
[06:09] <mumbler> pitti: thanks -- I'm not sure what this bad source was, but I will pass that my cell leader^H^H^H correct it if I see it again. :)
[06:10] <pitti> *chuckle*
[06:10] <pitti> mumbler: Tertiary Adjunct of Unimatrix Zero-One?
[06:12] <mumbler> pitti: We have no knowlegdge of such a sector, or a plot, nor would they be relevant if We could acknowledge them.
[06:12] <mumbler> pitti: so, sometime I will try to make a small patch, to document .apport-ignore.xml a little, in the manpage.
[06:13] <pitti> mumbler: thanks
[06:13] <pitti> (or should I say "that is agreeable")
[06:14] <mumbler> pitti:  :)   I was going to try to speak borg, but I'm sleepy, and it's coming out more like queen victoria, "we are not amused"
[06:17] <mumbler> hm, I was going to ask about client-side duping a little, but I'm sleepy and you're working, so I'll try to come back another time.  thank you, and good night/morgen.
[06:33] <jk-> stgraber: ping?
[07:08] <dholbach> good morning
[08:14] <jamespage> @pilot in
[08:14] <jamespage> morning all
[08:23] <tsdgeos> when can one start complaining about a MIR being ignored?
[08:25] <seb128> tsdgeos, complaining is usually not really constructive, just mention what is blocking you and we will find a way to unblock you
[08:25] <seb128> tsdgeos, can you give the bug number?
[08:25] <tsdgeos> seb128: https://bugs.launchpad.net/ubuntu/+source/openjpeg/+bug/1011487
[08:26] <seb128> tsdgeos, oh, that was rejected in the past
[08:26] <tsdgeos> well
[08:26] <tsdgeos> it was a bad idea then D:
[08:26] <tsdgeos> seb128: why was it rejected?
[08:26] <seb128> tsdgeos, bug #711061
[08:26] <seb128> tsdgeos, if you can address the comments from doko please do
[08:27] <tsdgeos> seb128: read this one, has no reason at all for closing
[08:27] <seb128> tsdgeos, because doko believes that libjpeg should do everything libopenjpeg does
[08:27] <tsdgeos> doko has no clue then
[08:28] <seb128> tsdgeos, see https://bugs.launchpad.net/ubuntu/+source/openjpeg/+bug/711061/comments/3
[08:28] <seb128> tsdgeos, well, that's possible he doesn't know about everything, nobody does know about everything and doing MIR review is an hard job, I don't think saying people "have no clue" is helpful though
[08:29] <seb128> tsdgeos, he asked question and nobody replied ... maybe you could be productive and share your knowledge on the bug and reply to his questions?
[08:29] <tsdgeos> seb128: well, he didn't care to search that libjpeg is regular jpeg and openjpeg is jpeg2000 that is a total different format
[08:29] <tsdgeos> and that's like 5 minutes of searching
[08:29] <seb128> tsdgeos, did you read the comment I just pasted
[08:29] <tsdgeos> more like 1
[08:29] <tsdgeos> seb128: the one about embedded libtiff?
[08:30] <seb128> tsdgeos, the "FILE FORMAT WARS" comment from libjpeg
[08:30] <tsdgeos> seb128: sure, so libjpeg developers hate jpeg2000
[08:30] <didrocks> tsdgeos: want to be part of the MIR team? there are only 3 semi-active persons on the team who have a lot of other hats and other works to do. Help is welcomed
[08:30] <tsdgeos> what does that mean?
[08:30] <tsdgeos> seb128: are we letting other people shut down stuff?
[08:30] <tsdgeos> didrocks: i'm not even an ubuntu developer, don't think i can/should be part of the MIR team
[08:31] <didrocks> tsdgeos: you can start by that then :)
[08:31] <seb128> tsdgeos, you are not being constructive there, if you read the bug doko mainly asked for an example of image that is not rendered by our current main stack, can't you just provide one?
[08:31] <tsdgeos> seb128: sure i can, i already did in my bug
[08:32] <seb128> tsdgeos, I will mark yours duplicate and reopen the old one, he already has some history and record of review
[08:32] <tsdgeos> seb128: i am being constructive, i am trying to get our user to get better rendering
[08:32] <tsdgeos> and people are closing bugs on uninformed decisions
[08:32] <tsdgeos> and i'm the one not being constrcutive?
[08:32] <tsdgeos> seb128: good
[08:32] <seb128> tsdgeos, right, and calling the MIR reviewer clueless is not the way to get things approved, yes they don't know about everything, better helping them to understand the issue than to insult them
[08:33] <tsdgeos> didrocks: had a look at the process, seemed to cumbersome
[08:33] <seb128> tsdgeos, I'm sure there are topic you have little clue about as well, MIR reviewer is not an easy job
[08:33] <tsdgeos> didrocks: besides i know *nothing* about packaging
[08:33] <seb128> tsdgeos, like try to help them to understand the issue rather than blaming them for not knowing what you know
[08:33] <tsdgeos> seb128: there's lots of topics i have no clue, but i don't make decisions on them :-)
[08:34] <didrocks> tsdgeos: well, we are 3 on the team, do you think 3 people can cover the whole stack?
[08:34] <tsdgeos> didrocks: nope i don't
[08:34] <didrocks> so, please, bear that in mind
[08:34] <didrocks> and help rather than critize
[08:34] <seb128> tsdgeos, well, to be fair details where asked on this bug, and it got closed because nobody provided a good rational in a reasonable timeframe, and they garbage collect the bug to keep a managable queue
[08:35] <seb128> tsdgeos, bugs closing are not the end of the world, they can be reopened if the requested details are provided
[08:35] <tsdgeos> seb128: sure, it's fine, that was back then, don't blame me for that, i wasn't using ubuntu so i didn't care you guys closed the bug
[08:35] <tsdgeos> i'm using ubuntu now, so i do care about my pdf viewer sucking
[08:35] <seb128> ;-)
[08:35] <seb128> great
[08:35] <seb128> so let's move on and get that fixed
[08:40] <slomo> seb128: you already have a jpeg2000 library in main btw (afaik). libjasper
[08:40] <seb128> libjasper1: JasPer JPEG-2000 runtime library
[08:40] <seb128> slomo, hum, indeed!
[08:40] <seb128> tsdgeos, I guess poppler can't use that one?
[08:41] <tsdgeos> seb128: unless you write code for it :D
[08:41] <tsdgeos> seb128: besides jasper is worse
[08:41] <tsdgeos> have a few images lying around that openjpeg renders and jasper doesn't
[08:41] <tsdgeos> lying around == sent to a kde mailing list a few years ago
[08:42] <tsdgeos> besides jasper is unmaintained afair
[08:42] <tsdgeos> and openjpeg no
[08:42] <seb128> ok
[08:43] <slomo> and libjasper doesn't bundle the world (libpng, libtiff, libz, liblcms2) ;)
[08:43] <RAOF> You wouldn't happen to know if the various rdepneds of libjasper happen to build against openjpeg?
[08:44] <slomo> RAOF: no, the API is different
[08:45] <RAOF> :/
[08:45] <seb128> tsdgeos, it's a bit annoying, gdk and kde seems to use jasper
[08:45] <tsdgeos> seb128: i know
[08:45] <tsdgeos> never got myself to rewrite kde's support to use openjpeg
[08:45] <tsdgeos> blame that on lazzyness
[08:46] <tsdgeos> we still us ps for pdf preview generation
[08:46] <tsdgeos> .D
[08:46] <tsdgeos> err
[08:46] <tsdgeos> gs i mean
[08:46]  * RAOF wonders if fixing jasper is quicker and easier than porting to openjpeg
[08:47] <pitti> seb128: erk, DSL reconnect; got my message?
[08:47] <pitti> pitti | seb128: looking at the gvfs loop bug ATM; sorry, didn't get to it yesterday
[08:47] <tsdgeos> RAOF: doubt it
[08:47] <seb128> pitti, no I didn't, thanks
[08:47] <tsdgeos> jpeg2000 is kind of non trivial stuff
[08:48] <tsdgeos> seb128: https://bugs.launchpad.net/ubuntu/+source/openjpeg/+bug/711061/comments/10
[08:48] <tsdgeos> seb128: anything i forgot to answer?
[08:49] <seb128> tsdgeos, not that I know about, I guess the MIR team will be a bit unhappy about having 2 implementation of jpeg2000 in main though, that's the sort of things we don't like to duplicate
[08:50] <seb128> not sure if that will annoy them enough to force us to converge on one of the two though to accept it
[08:50] <jamespage> please could someone with the right permissions delete/reject this MP - https://code.launchpad.net/~smoser/ubuntu/precise/tgt/lp977621-start-on-install/+merge/101321
[08:51] <tsdgeos> sorry my router restarted itself
[08:51] <tsdgeos> anything i missed?
[08:51] <slomo> seb128: jasper could be unmaintained upstream, so it might make sense to switch to the other one after checking if that's really the case (there was at least no release since a very long time)
[08:51] <slomo> seb128: so it might make sense to compare both and then maybe settle on one
[08:51] <seb128> tsdgeos, <seb128> tsdgeos, not that I know about, I guess the MIR team will be a bit unhappy about having 2 implementation of jpeg2000 in main though, that's the sort of things we don't like to duplicate
[08:51] <seb128>  not sure if that will annoy them enough to force us to converge on one of the two though to accept it
[08:52] <tsdgeos> i see
[08:52] <tsdgeos> tx
[08:52] <seb128> from the look of things we should converge on openjpeg
[08:54] <tsdgeos> for one it has an accessible repo, accessible developers, accessible mailing list
[08:54] <tsdgeos> which jasper has not afaik
[08:54] <seb128> yeah, jasper didn't get an update in Debian since 2007 as well
[08:55] <seb128> like it got only one version ever
[08:55] <seb128> only packaging revision since
[08:57] <seb128> RAOF, tsdgeos, slomo: the gdk jpeg2000 loader seems small enough, it shouldn't be too much work porting it to openjpeg I guess if somebody wants to do that
[08:58] <slomo> seb128: i think everybody is only using jasper because it was earlier and everybody important (gdk-pixbuf, kde stuff) is using it. at least that was the main reason why we chose it in gstreamer
[08:58] <tsdgeos> the thing is that almost noone has any jpeg2000 image around
[08:58] <tsdgeos> so it doesn't matter much for the desktop itself
[08:59] <tsdgeos> but somehow it seems more common inside pdf files
[08:59] <tsdgeos> don't ask me why
[09:00] <slomo> tsdgeos: well, jpeg2000 is quiete important for video nowadays (digital cinema for example is using jpeg2000). but for plain images i didn't see it used much either, most probably because the advantage over jpeg is minimal compared to switching to a new format
[09:02] <seb128> tsdgeos, slomo: the gdk bug where jpeg2000 support was added mentions "The one reason for having a jpeg2000 loader at all is that OS X icons apparently store their payload in this format..."
[09:03] <tsdgeos> he he
[09:12] <seb128> grrrrr, "Many package hooks not ported to python3" spamming
[09:12] <seb128> we should forbid people to do those "let's open 1 bug and make it affect a ton of sources"
[09:12] <seb128> if you are subscribed to any of the sources you get spammed to no end :-(
[09:13] <pitti> but it's much easier to delete one huge thread than 50 small ones?
[09:13] <seb128> ScottK, not thanks for that one :-(
[09:13] <pitti> and you can mute that bug for you if you aren't interested
[09:13] <Laney> seb128: you can mute individual bugs in LP now
[09:13] <seb128> pitti, I wouldn't get emails about the 49 sources I'm not subscribed to and would have nothing to delete
[09:14] <seb128> Laney, I'm interested about the comments related to the source I'm following
[09:14] <StevenK> 49 tasks on one bug makes Launchpad *VERY* sad.
[09:14] <pitti> well, I'm actually interested in the progress of that bug, regardless of which packages it affects; it's not a "package" bug, it's a "project-wide task"
[09:15] <seb128> pitti, it's like "let's open a ftbfs bug and make it affect all the packages in the archive which ftbfs"
[09:15] <pitti> seb128: not the same root cause usually
[09:15] <seb128> well, there neither
[09:15] <pitti> if it's "30 packages FTBFS due to a glib change", then that should/could be one bug, yes
[09:15] <seb128> ok, let's agree to disagree with that
[09:16] <seb128> it seems people like the spamming for some reason, I will just mute the bug, but if any of my packages are in there you will need to reach me through another mean then
[09:17] <pitti> I do like the spamming, yes
[09:17] <seb128> pitti, the proper way would be to open different bugs, tag them and have you subscribe the to tag
[09:17] <seb128> pitti, not to impose the spam to any subscribe to any of the sources
[09:17] <seb128> subscriber
[09:17]  * pitti sticks with "agree to disagree"
[09:17] <seb128> ok, fair enough ;-)
[09:18] <seb128> let's move on
[09:18] <pitti> I'd consider the alternative way too much overhead
[09:18] <xnox> pitti: you could have used a tag =) a check the progress of the tag.... just saying =)
[09:18]  * xnox prefers many sources/tasks in a single bug
[09:18] <seb128> xnox, I just said that, I think that's what he considers "too much overhead"
[09:19] <pitti> xnox: I didn't open it in the first place, but I've been guilty in the past of doing the same approach for similar situations
[09:19] <pitti> xnox: you can't subscribe other people to a tag
[09:19] <pitti> and even doing it yourself is something that someone needs to ask you to do
[09:19] <xnox> =(
[09:19] <pitti> and it would meen tag inflation, too
[09:19] <seb128> well let's hope it's not a practice that goes increasing
[09:19] <seb128> but that's the best way to make sure people do stop reading their bug emails
[09:20] <seb128> just spam them to no end about stuff they are not subscribed to because one thing they care happens to be in the middle of somebody's transition
[09:20] <xnox> fair enough. pitti, I'm not familiar with apport API, I did 2to3 & compileall is there any way I can test the apport hook with python3?
[09:27] <pitti> xnox: for the syntax errors you can just run "python3 source_foo.py"
[09:28] <pitti> xnox: many hooks actually have a __main__ for testing
[09:28] <pitti> xnox: for the remainder, run apport-bug srcpackage, and watch for tracebackes
[09:31] <xnox> ok. thanks.
[09:43] <tsdgeos> do you guys know if .deb packages support filenames with newlines?
[09:43] <tsdgeos> having a look at the md5sums file inside the control tar inside the deb, it would seem no
[09:43] <tsdgeos> since the format seems to be
[09:43] <tsdgeos> md5 filename<newline>
[09:43] <tsdgeos> md5 filename<newline>
[09:44] <tsdgeos> etc
[09:44] <tsdgeos> so if the filename contains a newline it'd probably get confused
[09:51] <pitti> I've never seen one, and I would not ever accept a deb with a file name containing a line break, and usually not even spaces
[09:55] <tsdgeos> can i quote you on that?
[09:56] <cjwatson> .md5sums is ancillary, but the .list format would be broken by a file containing newlines.
[09:56] <cjwatson> Which is much more important.
[10:00] <cjwatson> I don't see any code that specifically forbids it, but I haven't spent much time looking for it and I haven't actually tried it.
[10:01] <cjwatson> I would tend to say that if dpkg doesn't refuse to unpack such a .deb, it would be a bug, since its own file formats would be corrupted by it (unless it has some escaping that I've missed).
[10:01] <cjwatson> At any rate if you have somebody asking you whether they can put newlines in their filenames in a .deb then the answer is certainly no.
[10:02] <pitti> tsdgeos: the only place I've ever seen newlines in file names are exploits; I see no legitimate reason for them in packages
[10:02] <pitti> tsdgeos: and yes, you can quote me on that (but it's my personal opinion, not quoted from a policy document)
[10:02] <tsdgeos> pitti: sure
[10:02] <tsdgeos> tx
[10:02] <pitti> spaces in file names, maybe (e. g. in /usr/share/doc/ for .html files)
[10:03] <tsdgeos> cjwatson: well, i'm prototyping/defining something that is similar/replacement/complementary to .deb
[10:03] <tsdgeos> and knowing that .deb is doesn't support (or at least we don't seem to have any deb with) newlines, makes it easier for me to argue not to support that either
[10:04] <tsdgeos> and use the newline as "separator" in the file format
[10:04] <cjwatson> Spaces in file names are valid and I've seen them in .debs.
[10:04] <cjwatson> If you don't mind the file format being binary, though, IMO the correct inter-file-name separator in a non-text file is NUL
[10:04] <cjwatson> Since that genuinely is invalid in a Unix file name
[10:04] <tsdgeos> yep
[10:04] <tsdgeos> problem is it makes it much more difficult to read
[10:05] <cjwatson> Indeed
[10:05] <cjwatson> Which is probably why dpkg went for \n
[10:05] <tsdgeos> and people seem to struggle then why can have char * with a NUL that is not the end of the char *
[10:05] <tsdgeos> s/why/they
[10:20] <larsduesing> sorry, again a question: What's about these "Related source package recipes" in launchpad bzr - are they needed?
[10:24] <larsduesing> example in: https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-1007408
[10:25] <ScottK> seb128: If you want to do the extra work of filing all the individual bugs and removing all the 'extra' tasks from that one, I'm not stopping you.
[10:26] <pitti> that alone could be scripted, but it's spreading out information that belongs together
[10:27] <pitti> particularly for bugs where you need to discuss a solution
[10:30] <debfx> barry: does apturl-common need to depend on python3-aptdaemon? only the gtk backend seems to use it.
[10:38] <seb128> pitti, the info doesn't belong together, udisk and xorg (taking random example) probably having different python3 incompatible issues, we don't do one bug "we should port the archive to python3" affecting all the ubuntu python2 sources
[10:40] <xnox> is there a ppc64 ubuntu port?
[10:44] <xnox> xnox: confired that there isn't one
[10:47] <cjwatson> xnox: No
[10:48] <xnox> ok
[10:49] <rbasak> Is there a generic way of determining what arches come from which main mirrors (eg. archive.ubuntu.com/ubuntu for amd64 and ports.ubuntu.com/ubuntu-ports for armhf) and if not where would be appropriate to add this? distro-info?
[10:50] <rbasak> Right now every script seems to have its own lookup table, and the number of these is growing. Eg. debootstrap, lxc, previously cobbler and now MAAS
[10:51] <bvad> Hey guys, anyone knows where can I find the source for the sound indicator applet in Unity?
[10:52] <seb128> bvad, lp:indicator-sound
[10:52] <bvad> seb128: thanks
[10:52] <seb128> yw
[10:52] <seb128> bvad, https://code.launchpad.net/indicator-sound
[10:52] <bvad> Thanks a bunch seb128
[11:08] <bvad> I'm trying to get the sound indicator applet to start the default gnome sound preferences dialog, instead of the unity one.. How'd I do that?
[11:11] <seb128> bvad, you log into a non unity session?
[11:11] <seb128> bvad, we do session detection on the system settings side
[11:11] <seb128> bvad, why do you want to do that? is there an issue with the unity one?
[11:16] <bvad> Sort of, when I connect an HDMI cable to my laptop, the HDMI option does not always show up - which means no sound over HDMI. Using the fglrx driver
[11:17] <bvad> Usually un-plugging and plugging it in again works, but sometimes a reboot is required
[11:18] <bvad> I'd check out if it was possible to either modify the code for the unity sound settings, or replace it by the stock gnome one. Sorry for the multiple messages
[11:30] <seb128> bvad, you should report a bug and get that fixed
[11:31] <seb128> bvad, you can get the GNOME dialog by running "XDG_CURRENT_DESKTOP=GNOME gnome-control-center sound"
[11:37] <jamespage> cjwatson, would you be happy for me to sponsor a new upstream release of biosdevname into quantal?
[11:37]  * jamespage notes that cjwatson is the maintainer of the package
[11:40] <cjwatson> jamespage: Go ahead
[11:40] <jamespage> cjwatson, OK
[11:41] <jamespage> thanks
[11:41] <cjwatson> np, thanks for taking care of that
[11:47] <bvad> seb128, thank you. I think the bug was already reported
[11:48] <seb128> bvad, do you have the number? is that bug #986547
[11:54] <bvad> seb128, let me look into it
[11:58] <bvad> seb128: It looks more like bug #974963
[11:58] <seb128> bvad, thanks, I will try to see if we can get those issues addressed in a stable update
[11:59] <bvad> seb128: A solution might be to always show the HDMI audio option, even without a cable plugged in, like the stock gnome settings does. Though this is sort of ignoring the problem at it's core...
[12:04] <tkamppeter> doko, hi
[12:05] <jamespage> @pilot out
[12:10] <larsduesing> jamespage: kthx :-)
[12:10] <jamespage> larsduesing, np
[12:17] <doko> tkamppeter, see my email about pysmbc, pycups is in the works. would be nice if you could do system-config-printer yourself
[12:56] <larsduesing> oh... Can anybody describe me what: https://code.launchpad.net/~ubuntu-branches/ubuntu/quantal/aiccu/quantal-201206042007 means? "Created by Ubuntu Package Importer on 2012-06-04 and last modified on 2012-06-04"
[12:56] <larsduesing> an unmerge proposal by package importer?
[12:58] <SpamapS> ugh, collectd is such a bear to get compiled
[12:58] <SpamapS> its almost as bad as PHP with all the libraries to link
[12:59] <SpamapS> larsduesing: that means there were pending changes for aiccu in that branch when somebody uploaded something else
[13:00] <larsduesing> most certainly me... (as I am the only one working on that package...)
[13:00] <larsduesing> ok, looking after that
[13:13] <SpamapS> larsduesing: its worth bumping the uploader that they need to check the branch before uploading. :)
[13:14] <larsduesing> :P
[13:15] <larsduesing> no, there were some troubles with a bug with bzr-builddeb
[13:15] <larsduesing> https://bugs.launchpad.net/bzr-builddeb/+bug/1006611
[13:15] <larsduesing> I think it's all about that
[13:20] <hallyn> slangasek: are there any plans of jumping qemu-linaro to 1.1 during quantal?
[13:21] <hallyn> if i upload the new qemu-kvm 1.1, the one thing i've foudn will break is qemu-kvm-spice.  i believe bc of a bios mismatch.  if need be i should be able to have qemu-kvm-spice temporarily use a different bios...
[13:21] <xnox> larsduesing: and even if you apply them yourself... they get different fileids and conflict on merge
[13:22] <larsduesing> somehow... yes
[13:41] <stgraber> @pilot in
[13:44] <hrw> does someone know when ARM became equal to x86 in Ubuntu?
[13:44] <stgraber> jk-: pong
[13:48] <barry> debfx: i think you're right.  should be an easy fix.
[13:51] <SpamapS> doko: is it possible the recent gcc 4.7 update fixed some problems with hand-optimized assembler that would go all the way back to gcc 4.6?
[13:52] <SpamapS> hrw: what do you mean "became equal" ?
[14:00] <vibhav> mdeslaur: ping
[14:02] <hrw> SpamapS: packages.ubuntu.com listing arm packages atleast
[14:03] <hrw> SpamapS: I can live with ports.ubuntu.com != archive.ubuntu.com but so far arm is second citizen
[14:03] <SpamapS> hrw: I'd guess sometime around 10.10 ?
[14:03] <SpamapS> but I really don't know :p
[14:04] <hrw> SpamapS: 10.10 is past ;D
[14:06] <seb128> ev, hey, whoopsie question for you ... the issues are reported only once or does the same issue keeps being reported every time it happens to the user?
[14:06] <SpamapS> hrw: from my point of view, its definitely *not* a second class citizen
[14:07] <ev> seb128: the intention is for the report to be sent every time it happens to the user, but I believe apport stops showing after the 2nd or 3rd report at the moment
[14:07] <ev> I believe mpt has a bug open for this
[14:07] <seb128> ev, ok, I'm wondering why the numbers of errors.ubuntu.com have dropped so low compared to after release for some issues which didn't get fixed
[14:08] <ev> seb128: apport's been broken
[14:08] <seb128> ev, I assume that's because we get reports only from new users
[14:08] <seb128> ev, in precise?
[14:08] <ev> quantal
[14:08] <ev> but yeah, interesting
[14:08] <ev> I see your point
[14:08] <ev> well, fixing apport to always send the report will fix this in any case
[14:09] <vibhav> If a change in an ubuntu delta is transfered to debian, do I need to mention that the change has been tranfered to debian
[14:09] <ev> I just haven't had the time to do it myself
[14:09] <seb128> ev, right, thanks for confirming
[14:09] <xnox> vibhav: reamaining changes; dropped changes; new stuff:
[14:09] <vibhav> thanks xnox
[14:09] <seb128> ev, it also mean the current view is not a reflect of what issues are the most frequents atm
[14:09] <xnox> vibhav: if all changes are dropped and no new onces introduced -> requestsync
[14:10] <ev> yeah
[14:12] <seb128> ev, btw is the "if all updates were installed" setting working? it seems to not, like if I unselect "actual" there is no graphs displayed and the report is not changing compared to when "actual" was selected
[14:12] <ev> seb128: not yet
[14:12] <seb128> ev, or asked different "can I select the month view and select out fixed issues"?
[14:12] <ev> can you elaborate? I don't follow
[14:13] <seb128> ev, if I go on https://errors.ubuntu.com/, change the "Most common problems in the past  " combo to "month" ... does that include fix commited,released bugs?
[14:14] <seb128> ev, like the ones that collected 5000 tickets during 2 weeks but are fixed for 3 days?
[14:14] <ev> seb128: yes - I have a branch that fixes this, but haven't landed it on trunk yet due to issues using launchpadlib
[14:14] <seb128> ev, ok, I guess the simple question was "is the errors.ubuntu.com a view of all errors or of the non fixed errors"
[14:15] <seb128> I guess it's all errors atm
[14:15] <ev> it currently greys out those rows
[14:15] <ev> all at the moment, yes
[14:15] <ev> currently> in this branch I have
[14:15] <seb128> ev, ok, excellent, thanks!
[14:15] <seb128> ev, that's enough questions from me for today, keep up the good work ;-)
[14:15] <ev> but that's just to see if we get any false positives. We may end up permanently hiding those
[14:15] <ev> heh, thanks!
[14:15] <ev> and thanks for the constant input
[14:15] <ev> it definitely helps direct development
[14:16] <ev> I just need a small army to do everything we need done
[14:16] <hrw> SpamapS: arm as architecture when it comes to support is first class. but when it comes to infrastructure support it still 2nd class
[14:16] <seb128> I know that feeling ;-)
[14:16]  * ev goes back to teaching errors.u.c to expose "create bug" links where we don't already have a bug number
[14:16] <tsdgeos> jdstrand: about https://bugs.launchpad.net/ubuntu/+source/openjpeg/+bug/711061 i wonder if i should mention also that we only ship 1.3 when current version is 1.5 ?
[14:16] <hrw> SpamapS: for example: try to find out which version of omap4 kernel is recent one...
[14:16] <seb128> ev, oh, another quick one, is there a way to point an errors.ubuntu.com to a bug number? or to correct a wrong reference?
[14:17] <ev> seb128: that's what I'm working on right now. It's fairly involved though and requires a new backend to crash-digger (so that the apport duplicate db and errors.ubuntu.com duplicates share bug references)
[14:17] <jdstrand> tsdgeos: yes please
[14:18] <seb128> ev, ok, things as on track I see, I will let you work, thanks again for the replies ;-)
[14:18] <ev> seb128: anytime! cheers
[14:18] <doko> Spads, I can't see anything obvious ...
[14:18] <doko> SpamapS, ^^^
[14:18] <Spads> °.º
[14:18] <Spads> ☺
[14:19] <doko> spam ...
[14:19] <ev> lol
[14:19] <SpadapS> \〠/
[14:19] <tsdgeos> jdstrand: done
[14:19] <vibhav> Spads: Please stop that
[14:20] <jdstrand> thanks
[14:20] <jdstrand> SpamapS: I like that last one :)
[14:21] <jdstrand> I don't know what it is, but I like it
[14:27] <kelemengabor> pitti: hi, got a few minutes?
[14:28] <kelemengabor> according to https://wiki.ubuntu.com/Translations/PreciseLanguagePackReleaseSchedule it is time to move some updated langpacks to -proposed for the second language pack update cycle - could you do that?
[14:28] <kelemengabor> okay, we are a week late, but better late than never :)
[14:29] <kelemengabor> I'll modify the wiki page and send out the call for testing mail - dpm, are you happy with that?
[14:30] <dpm> kelemengabor, I definitely am, thanks for staying on top
[14:57] <larsduesing> hmm, all aiccu bugs but one suggestion are incomplete or invalid. Mission accomplished? :-)
[15:02] <zul> bdmurray: ping
[15:06] <mpt> mterry, to try and answer your question: This morning I had Update Manager offering to give me a "partial upgrade", i.e. updates that didn't include glib. It turned out (once I ran Synaptic) that all it needed to do, to install all updates, was remove a -dbgsym package.
[15:08] <mpt> mterry, I reported bug 955022 about abolishing the "Not all updates can be installed"/"Partial Upgrade" dialog, but it needs technical sanity-checking.
[15:08] <tkamppeter> doko, OK. Is there somewhere documentation about migrating Python 2 -> 3?
[15:09] <cjwatson> tkamppeter: http://wiki.ubuntu.com/Python/3
[15:09] <tkamppeter> cjwatson, thanks.
[15:10] <xnox> mpt: partial upgrade is generally not a good idea. wait for the archive to settle. Generally it means that a library transition is still in progress.
[15:11] <xnox> mpt: oh just one -dbgsym package
[15:11] <xnox> mpt: use command line $ apt-get dist-upgrade
[15:11] <xnox> =)
[15:11] <mpt> mterry, for updates that would remove some other package, Ubuntu Software Center potentially has that issue as well, with the Conflicts field. So probably it should be part of Aptdaemon. Next week I'll be going through error and edge cases like that one with glatzor.
[15:12] <mpt> xnox, that is a concise demonstration of why we should get rid of the dialog, yes. ;-)
[15:12] <mterry> mpt, OK.  Yeah, your proposal in that bug looks reasonable, but would require some thinking of how to present packages that will be removed.  The normal "Updates Available" screen does that now
[15:12] <mpt> mterry, Synaptic's does, but I don't remember ever seeing update-manager offer to remove stuff.
[15:12] <mterry> Sorry, does NOT do that now
[15:12] <mpt> ok :-)
[15:12] <mterry> mpt, ^
[15:13] <mterry> I hate that screen.  It's odd too because "Partial Upgrade" is actually a more complete update than a normal update.  Not very partial
[15:14] <mterry> I'm assuming it's using Upgrade in the distro upgrade sense
[15:14] <mpt> ev, seb128: The bug where you don't get repeat reports is bug 989800
[15:15] <ev> mpt: thanks!
[15:16] <seb128> mpt, thanks
[15:49] <mterry> mpt, FYI I'm assuming that in the SoftwareUpdates spec where we say something like "Ubuntu 12.04" the updater should say "Xubuntu 12.04" if appropriate.
[15:49] <mpt> mterry, yep
[15:49] <mterry> mpt, I'm trying to figure out how to determine which it is...  But lsb_release seems to give the same output for both.  :(
[15:50] <cjwatson> That's necessary
[15:51] <mterry> cjwatson, the lsb_release bit?  Do you know of a good way to determine what the system was installed as?
[15:52] <stgraber> mterry: you don't really have a way of knowing. One way would be to look at the install media in /var/log/installer but it's not necessarily there nor it's reliable. Another is to look for the -desktop packages but there again, you can have more than one installed
[15:52] <mterry> stgraber, yeah, I would be happy enough to know what it was at first installation
[15:52] <cjwatson> What he said
[15:52] <mterry> Seems silly that we can't do that
[15:53] <mpt> Plymouth thinks I'm running Xubuntu solely because I installed XFCE
[15:53] <xnox> one way to do this is to check what type of desktop session is running
[15:53] <Daviey> mpt: can't be worse than when everyones splash screen was switched to a different flavour by accident :)
[15:54] <xnox> if I have both KDE/Kubuntu and XFCE/Xubuntu - if I'm running update in the XFCE session say 'Xubuntu', if the KDE session say 'Kubuntu'
[15:54] <cjwatson> That probably isn't awful, yeah
[15:55] <xnox> as I would expect the frontend to match current desktop sessions, regardless of what packages are installed and which media was used
[15:55] <mterry> We do have XDG_CURRENT_DESKTOP for that now
[15:55] <xnox> excellent =)
[15:55] <stgraber> mterry: /var/log/installer/media-info will contain what was used to install the system, but only for these installed from a media. If you netinstall you won't get it.
[15:56] <xnox> stgraber: or debootstrap the way some of my friends prefer to install ubuntu.....
[15:56] <stgraber> mterry: (had to check in a VM as all my systems are netinstalled from PXE and don't have that file)
[15:56] <Daviey> OEM installs probably don't expose that?
[15:56] <mterry> stgraber, thanks!
[15:57] <mterry> Sounds like I can't rely on that stuff and should just use the current desktop environment and map them to derivative names myself
[15:57] <stgraber> Daviey: I can't remember us explicitly stripping it for OEM installs in Ubiquity, but it's perfectly possible that OEMs wipe /var/log on their installs before imaging
[15:57] <cjwatson> XDG_CURRENT_DESKTOP> of course provided the updater isn't running inside something that strips the environment, like sudo
[15:57] <stgraber> mterry: you know I'll open a bug because Edubuntu won't work if you do that, right? :) same thing for ubuntu studio I believe
[15:58] <cjwatson> I think you need heuristics whatever way you slice it.
[15:58] <stgraber> mterry: we have multiple flavours running with unity, multiple flavours running with xfce and at the moment, only one flavour running kde. So you'll need some extra logic to figure out exactly what the system is :)
[15:58] <cjwatson> Two flavours - there's Kubuntu Active.
[15:59] <stgraber> ah right
[16:00] <mterry> stgraber, :(
[16:00] <stgraber> starting to wonder if it'd make sense to have some file storing the name of the flavour installed and use the good old alternatives to have it changed to the right value by the -artwork packages of the various flavours
[16:00] <stgraber> that'd probably make it consistent with what's done for plymouth, distributor-logo and some other things
[16:01] <mterry> ahem, got dropped
[16:01] <mterry> stgraber, an alternatives would be good
[16:02] <azorin> Hello everyone! I'm having some issues with building a package on Launchpadl.
[16:02] <mterry> stgraber, maybe I should post to ubuntu-devel and get some feedback.  But seems simple enough to do
[16:02] <Daviey> Unrelated, but i'd quite like to see something like, if [ "$(pidof X)" ] ; then echo "Desktop Running" ; fi .. added to apport bugs.
[16:03] <mterry> Daviey, you mean to determine which desktop environment is running?
[16:03] <Daviey> mterry: no, to determine IF X is running.. Metric that it might be a desktop or server.
[16:04] <mterry> ah
[16:04] <mvo> mterry: you can look at the installed metapackages
[16:05] <stgraber> mvo: no, see above, it's not reliable :) (edubuntu-desktop depends on ubuntu-desktop and some others are co-installable)
[16:05] <mterry> mvo, and just iterate on all the known ones?
[16:05] <mvo> yes, that is what the release upgrader is doing
[16:07] <Daviey> stgraber: Surely some logic can be determined based on installed as a dep or explicitly.. not clean, but there is certainly hints that could be formulated
[16:08] <stgraber> Daviey: right
[16:09] <mterry> mvo, OK, so it looks like DistUpgradeCache has code to guess the best meta package.  And then we can just map to names...
[16:11] <azorin> I'm having some issues with building a package on Launchpad. I would greatly appreciate any suggestions if anyone may have any. Full details of the problem are here: http://goo.gl/mrVdl
[16:12] <SpamapS> doko: indeed, I was mistaken and I'm still experiencing my problems
[16:13] <mterry> azorin, #ubuntu-motu might be a better channel?
[16:13] <azorin> Thanks mterry! I'll check it out right now
[16:13] <mterry> azorin, but try moving the xwinwrap.o part of the link line before the LDFLAGS
[16:16] <didrocks> ev: is there any particular order for e.ubuntu.com to show the stacktraces?
[16:16] <didrocks> ev: like, I want to see the latest one
[16:16] <ev> didrocks: the instances of a problem?
[16:17] <ev> off a bucket page
[16:17] <ev> I should really rename that to problem
[16:17] <didrocks> ev: right :)
[16:17] <arges> SpamapS,  hi. Noticed some packages are ftbfs that depend on php5  (>= 5.4.1). Was wondering when that will be bumped? thanks
[16:17] <didrocks> ev: like, I'm almost sure that I fixed oneconf0.2.6.90.2.8.1
[16:18] <ev> not at present - there's a bug there in that they're ascii sorted rather than sorted by the time component of the uuid
[16:18] <didrocks> grrr, space missing from copy and paste
[16:18] <ev> I noticed that last night
[16:18] <ev> it's a tricky one to fix, but I will get to it once things calm down
[16:18] <didrocks> ev: it seems that e.u.c it telling that it's still present on 2.8.1, which isn't really possible from the new code, so I wanted to see that particular stacktrace :)
[16:18] <infinity> SpamapS: Any plans to merge php5 soon (you, or someone else...)
[16:19] <ev> (cassandra does not support changing the comparator - you need to migrate the data to a new column family)
[16:19] <ev> didrocks: if this is precise, someone is likely hitting the bug wherein if you upgrade a package while the binary is running
[16:19] <ev> and it crahses
[16:19] <ev> it will use the new package version
[16:19] <ev> rather than the version the binary was actually from
[16:19] <didrocks> ev: yeah, same issue that what we have with old good apport?
[16:19] <ev> pitti fixed this in quantal
[16:19] <didrocks> oh?
[16:19] <ev> yes
[16:20] <didrocks> how so?
[16:20] <ev> in quantal it doesn't send the report :)
[16:20] <didrocks> ok, it knows "the upgrade has been done in this session, don't send the crash"
[16:20] <ev> exactly
[16:20] <SpamapS> infinity: Suhosin is still not available for 5.4
[16:21] <didrocks> excellent, that would help :)
[16:21] <SpamapS> infinity: I had wanted to treat w/ the security team before dropping it
[16:21] <SpamapS> infinity: though I'm pretty sure we're dropping it.. *everybody* else has.
[16:21] <infinity> SpamapS: Ahh.  Fair enough.  Seems like a bunch of autosyncs are build-depending on newer php5-dev, so would be nice to sort it.
[16:21] <didrocks> ev: but I still wanted to double check, so if you can tackle the other issue (or just order if you know the timestamp as a quick workaround), that would be awesome :)
[16:21] <SpamapS> infinity: but yes, I'd like to get that resolved soon.
[16:21] <SpamapS> infinity: yeah, soon.
[16:21] <infinity> SpamapS: I was against adding suhosin in the first place, but I lost that argument.  or gave up caring.
[16:22] <ev> didrocks: I fully intend to
[16:22] <ev> I was polishing the bucket/problem page last night
[16:22] <ev> so it now displays python tracebacks there, as well as the thread stacktrace, IN FULL COLOR ;)
[16:23] <didrocks> ev: yeah, I noticed that, it's nice! :)
[16:23] <seb128> ev, didrocks: the apport fix for the "don't send reports for binaries that got upgraded" has been SRUed as well (it's in proposed waiting to be verified)
[16:23] <ev> and noticed that said giant list of uuids is A) not labelled, and B) not time-sorted
[16:23] <ev> right now it's just grabbing the first 100 ascii-sorted
[16:23] <ev> but I'll fix the time sorting and put in pagination
[16:23] <didrocks> excellent, thanks ev!
[16:23] <didrocks> seb128: wooow! ;)
[16:23] <ev> sure thing!
[16:23] <didrocks> ev: also, I guess you are aware/hear about a lot of sso failure when trying to access a bucket page?
[16:24] <ev> no? Are you running into this?
[16:24] <didrocks> yeah, a lot
[16:24] <didrocks> like, 1/3 of my connexion works
[16:24] <didrocks> the rest, I get denied access
[16:24] <SpamapS> infinity: it has mitigated almost every major flaw in PHP..
[16:24] <didrocks> or "errors"
[16:24] <didrocks> also, it reasks me for sso each time I'm trying to access a bucket
[16:25] <SpamapS> infinity: not totally prevented it, but most of the time reduced remote code execution to DoS
[16:25] <ev> yes, the reasking thing is because we're currently using an IS-provided open id wrapper
[16:25] <SpamapS> infinity: that said, the maintenance burden is getting higher as Stefan Esser cares less and less ;)
[16:25] <didrocks> most of the time, as I don't spend a lot of time on the page, it's fine, but still frustrating
[16:25] <ev> and so there's no caching of credentials
[16:25] <didrocks> ev: that would be fine if I don't end on this constant errors when logging in
[16:26] <ev> I'm going to fix that, but doing it with python-openid-auth requires persisting information to the db, via an ORM, which I'm not fond of
[16:26] <ev> yeah, that one is surprising
[16:26] <didrocks> yeah, I understand :/
[16:26] <ev> I'll talk to webops and see if they get logs for these
[16:26] <didrocks> ev: I'm in London the whole next week, we can have a look together mayve?
[16:26] <didrocks> maybe*
[16:26] <ev> didrocks: yes, definitely
[16:27] <didrocks> ev: excellent, thanks a lot :)
[16:27] <ev> no problem
[18:01] <stgraber> @pilot out
[18:01] <zul> slangasek: ping
[18:01] <larsduesing> ahm... who is to be informed on "bugs" in man-pages?
[18:02] <larsduesing> "sponsor-patch.1"
[18:02] <larsduesing> "Should any checks (or the build fail), the user has an option  to  edit the patched source and try building it again
[18:03] <larsduesing> I think the word fail should be outside of the brackets :-)
[18:06] <infinity> doko: *poke*
[18:06] <mhall119> ScottK: ping
[18:08] <infinity> larsduesing: Ideally, you should file the bug with Debian (unless it's an Ubuntu-only package).  Carrying a delta for small manpage fixes isn't generally worth the hassle.
[18:08] <larsduesing> infinity: sponsor-patch is part of ubuntu-dev-tools
[18:08] <larsduesing> :)
[18:08] <infinity> larsduesing: Oh.  Right then.
[18:09] <infinity> larsduesing: Then file a bug with a patch in launchpad. ;)
[18:09] <larsduesing> So I will file a bug with bzr branch *G*
[18:09] <dobey> larsduesing: i suppose you should push a branch and propose it for merging into the upstream tree or whatever :)
[18:09] <larsduesing> I'll do.
[18:19] <larsduesing> But should I really do a changelog-entry for an edit of 1 line in the man-page?
[18:22] <slangasek> pitti: urlopen> hmmm; I got a rather opaque popup about "module something something named urlopen", and grepping the code this looked like the bit that was to blame, but maybe there's another bug lying somewhere still?
[18:23] <slangasek> zul: pong - but I'm off today, please just ask your question :)
[18:23] <slangasek> hallyn: qemu-linaro 1.1> well I intend to get us up to date with the releases for quantal, but I know I'm behind, sorry about that
[18:23] <zul> slangasek: ah it was about an SRU review but I can find someone else
[18:24] <hallyn> slangasek: would be ok either way, was just wondering which way i'd have to go.  thanks
[18:25] <slangasek> pitti: RT 52633> it seems unlikely that we'll be able to get a speedy resolution to that, AIUI it's taking a while to get new hardware through the system... I can certainly give it a priority bump but it seems to already /have/ a priority bump from IS
[18:29] <larsduesing> dobey, infinity: done :)
[18:30] <larsduesing> https://code.launchpad.net/~lars.duesing/ubuntu/quantal/ubuntu-dev-tools/ubuntu-dev-tools_correct-sponsor-patch-manpage
[18:30] <larsduesing> (but didn't create a bug for that...)
[18:44] <bryceh> I've got a package version 2.5 in precise, 2.7 in quantal, that I'm both the author and package maintainer of.  I want to do an SRU to precise; what's the best way to craft the version number?  2.5ubuntu1?  2.5-0ubuntu0.1?  2.5.1?
[18:47] <infinity> bryceh: It's native?
[18:48] <infinity> bryceh: And Ubuntu-specific?
[18:48] <infinity> bryceh: If both of those are true, 2.5.1, or 2.5.0.1, or 2.5.0.12.04, or anything along those lines. :P
[18:49] <infinity> bryceh: If it's not Ubuntu-specific, and just happens to be in sync with Debian, 2.5ubuntu1 (or ubuntu0.12.04, or whatever)
[18:52] <bryceh> infinity, yes native and ubuntu-specific
[18:52] <bryceh> infinity, thanks, 2.5.1 it is :-)
[19:17] <ScottK> mhall119: pong
[19:21] <mhall119> ScottK: key, I'm working on a blog post about the new 'Download for Ubunt' buttons in which I'm going to be telling upstreams what to do in order to get newer versions of their apps into precise-backports
[19:21] <mhall119> and I wanted to check and see if there is anything specific that I should include or warn against
[19:22] <ScottK> The first thing about backports is we backport from the development release first.
[19:22] <ScottK> So before you get to precise-backports, you have to get to quantal.
[19:23] <ScottK> Also we require some basic testing in the target environment (that it builds/installs/runs).
[19:23] <ScottK> This is not generally for packages with lots of reverse dependencies and the rdepends will have to be tested too.
[19:24] <ScottK> broder or Laney: Can you think of anything else?
[19:27] <mhall119> thanks ScottK
[19:28] <micahg> mhall119: please advise people to use the requestbackport script from ubuntu-dev-tools when requesting a backport, it'll include information on what testing needs to be done as well
[19:29] <mhall119> micahg: I will
[19:30] <mhall119> micahg: for upstreams who aren't running Ubuntu, can they just file a bug against the backports project, and then someone else can update the bug description with the requestbackport output?
[19:30] <micahg> mhall119: I suppose, I think broder was working on something that makes that easier for us
[19:31] <broder> micahg: for that specifically i thought i talked tumbleweed into doing that
[19:31] <broder> (requestbackport --rewrite)
[19:32] <micahg> broder: oh, ok, that works as long as someone is doing it :)
[19:33] <mhall119> is that a work in progress, or something already available?
[19:33]  * micahg doesn't see it in trunk yet
[19:34] <mhall119> ok
[19:53] <Laney> mhall119: you should link to https://help.ubuntu.com/community/UbuntuBackports and https://wiki.ubuntu.com/UbuntuBackports
[19:59] <mhall119> thanks Laney
[20:00] <Laney> np
[20:14] <mhall119> can someone verify for me that packaging fixes are allowed at any time, they don't need backports or SRUs?
[20:14] <micahg> mhall119: hrm?
[20:14] <mhall119> say, if a package was missing a dependency or something
[20:14] <micahg> where?
[20:14] <mhall119> hypothetical
[20:15] <micahg> hypothetically where? :)
[20:15] <mhall119> if an upstream app developer says "Hey, people can't use the package for my app in Ubuntu because it's missing a dependency on libfoo", we can just add that in a -ubuntu2 version of the package right?
[20:16] <micahg> mhall119: it depends, it might need an MIR
[20:16] <mhall119> MIR?
[20:16] <micahg> !mir | mhall119
[20:16] <mhall119> what if it's in Universe?
[20:16] <micahg> mhall119: if it's in a stable release, you'll need to do an SRU and give the justification for the addition
[20:17] <mhall119> ok, so SRU is still required, even if the app itself wasn't changed, just it's packaging
[20:17] <micahg> mhall119: the package?, then in the dev release you could add it most likely
[20:18] <mhall119> what if it's correct in the dev release, but wrong in the stable release?
[20:18] <micahg> mhall119: yeah, the SRU process is meant to avoid regressions and breakage, the bar should be pretty low for a missing dependency though
[20:19] <micahg> mhall119: you can just propose an SRU assuming it's in the same component
[20:19] <micahg> err...assumingthe dependency is met in the appropriate components
[20:19] <mhall119> ok
[20:20] <mhall119> I'm just trying to let upstream devs know what their options are if our packages aren't giving them the best user experience
[20:21] <micahg> mhall119: missing dependency can be easy to fix (much easier than a new upstream version :))
[20:23] <mhall119> right, new upstream should be backported instead, right?
[20:24] <micahg> usually, yes
[20:45] <Laney> it doesn't really matter what the fix is
[20:45] <Laney> the SRU process is the same
[21:42] <Laney> mhall119: I think you should mention that SRUs can contain bug fixes to the application's code as well as to the packaging
[21:42] <Laney> and it doesn't really 'lock' versions like you said
[21:48] <micahg> mhall119: I'm also a little worrisome of "  So if we’ve done something wrong on our end that is giving your app a hard time, we’ll fix it", in most cases, we get stuff unchanged from Debian, so it would take someone who cares to submit the SRU (not just a bug report as we're drowning in those)
[21:51] <micahg> mhall119: and in case you're interested, the bottom paragraph appears funny in khtml (akregator rendering engine)
[21:52] <micahg> hmm, looks fine in konqueror so must be an akregator quirk
[21:52] <micahg> er..not exactly fine, but not the same weird