[00:20] <RoAkSoAx> hi all... Is there a way to list in what dependencies should a package depends (instead of just listing its current dependencies). Or, how can I know what dependencies does a library package needs?
[00:20] <RoAkSoAx> or how do I know what should a library link agaisnt?
[03:09] <ScottK> RoAkSoAx: What problem are you trying to solve?
[03:16] <ScottK> Ah, i see you solved it on another channel.
[03:32] <RoAkSoAx> ScottK: well it is not really solved actually...
[03:33] <ScottK> RoAkSoAx: OK.  What's the problem?
[03:34] <RoAkSoAx> ScottK: because of the new linker thingy pacemaker fails to build
[03:34] <ScottK> OK.  What's the error?
[03:34] <RoAkSoAx> ScottK: let me grab the log
[03:35] <RoAkSoAx> ScottK: this is the error: http://pastebin.ubuntu.com/532713/
[03:36] <RoAkSoAx> ScottK: complete build log: http://launchpadlibrarian.net/59133765/buildlog_ubuntu-natty-amd64.pacemaker_1.0.9.1%2Bhg15626-2ubuntu1_FAILEDTOBUILD.txt.gz
[03:36] <ScottK> The other's I've seen gave a more useful error.
[03:39] <RoAkSoAx> ScottK: and in maverick, it built but showed this warning: "dpkg-shlibdeps: warning: symbol sort_rsc_index used by debian/pacemaker/usr/lib/libpengine.so.3.0.0 found in none of the libraries."
[03:40] <ScottK> RoAkSoAx: So you need to figure out what packages provide those symbols.
[03:40] <ScottK> Right, that was unneeded indirect linking.
[03:40] <ScottK> (in theory anyway)
[03:41] <ScottK> RoAkSoAx: What I would do is put the binaries that it build depends on into http://qa.debian.org/cgi-bin/mole/seedsymbols and see which one provides the symbols in question.
[03:41] <ScottK> There's probably a more elegant way to do it.
[03:42] <ScottK> https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols is probably helpful, but is looking at the problem from the opposite direction.
[03:42] <RoAkSoAx> ScottK: yeah well, those symbels are provide by pacemaker itself (since the package is not yet split on a package per library)
[03:43] <ScottK> All the more reason it should be split then.
[03:44] <ScottK> You should just have to add them to the linker then.
[03:44] <RoAkSoAx> ScottK: yes I already have a diff with the split, but still experiencing the build failure, so this is why I was wondering if there was a way to see which library provided the symbols by looking to the library itself
[03:44] <ScottK> I'm sure there is.
[03:45] <ScottK> man ld to get started I believe.
[03:45] <RoAkSoAx> ScottK: i think i just found it with objdump -t
[03:45] <RoAkSoAx> i'll give it a try
[03:46] <ScottK> Yeah.
[03:46] <ScottK> That sounds right.
[03:47] <RoAkSoAx> ScottK: alright, thanks for the help. :) I'll let you know about the outcome
[03:48] <achiang> RoAkSoAx: sorry for the wild goose chase earlier
[03:50] <RoAkSoAx> achiang: It's fine :)! it had the same changes of working as of not working so it was worth to try
[03:53] <RoAkSoAx> achiang: ScottK ok this is sample output of objdump: 0000000000000000      D  *UND*0000000000000000              resource_location
[03:55] <ScottK> Right, so that's not gonna be much help I guess.
[03:55] <ScottK> Sorry, it's a bit late and I'd have to do a bunch of research to be more help.
[03:56] <RoAkSoAx> ScottK: that's fine. :) I appreciate the help though. I'll ping you tomorrow to see if we can get this resolved :)
[03:58] <RoAkSoAx> achiang ScottK: btw.. could it be because of missing (non existant) .pc files?
[03:58] <ScottK> RoAkSoAx: ask me a Python question.  Then maybe I'll know.
[04:00] <RoAkSoAx> ScottK: will do when I have one :)
[04:00] <achiang> RoAkSoAx: i don't think it's because of missing .pc files; i still kinda think it's an optimizer problem
[04:01] <RoAkSoAx> achiang: yeah, I guess we'll need to find were to actually make that work :)
[04:25] <achiang> ScottK: here's a python question - why am I seeing this on maverick? http://pastebin.ubuntu.com/532774/
[04:25] <ScottK> Not sure.
[04:26] <achiang> ScottK: i was being a little facetious. but the question is real - that error seems to point to a python interpreter error, not anything a script could have done, right?
[04:29] <ScottK> Probably now, but it's not 100% clear from that if it's Python itself, usb-creator-gtk, or something in between them that's at fault.
[04:29] <ScottK> now/not
[04:29] <ebroder> achiang: Could also be an extension module if there are any in the mix
[04:31] <achiang> ebroder: hm, what would be an example of an extension module?
[04:32] <kunal> facing an issue while using debuild command
[04:32] <kunal>  dh_install -a
[04:32] <kunal> dh_install: libomxil-bellagio-dev missing files (usr/share/pkgconfig/*), aborting
[04:32] <kunal> make: *** [binary-arch] Error 2
[04:32] <kunal> dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2
[04:34] <ebroder> achiang: Err, a C module, instead of a pure-python module
[04:34] <achiang> ebroder: hm, ok. it seems possible... usb-creator calls out to dbus and calls syslinux and/or grub at times
[04:35] <ebroder> achiang: Yeah, dbus seems like an obvious culprit. syslinux and grub are done just by shelling out, so those shouldn't be at fault
[04:36]  * achiang is trying to create a CLI frontend to usb-creator, and is having some success, but keeps getting strange errors during the "installing bootloader" phase
[04:41] <ebroder> achiang: Have you tried turning on apport and looking at the backtraces it gets?
[04:41] <achiang> ebroder: hm. i've never thought about that... i must admit i don't really know what apport does.
[04:42] <achiang> ebroder: i've been reading the log file in ~/.cache/usb-creator.log
[04:42] <ebroder> Or you could just run your frontend under gdb or something :-P
[04:42] <achiang> and sprinkling print statements around...
[04:42] <achiang> ebroder: i guess what i'd need to do is run gdb /usr/bin/python
[04:42] <ebroder> Try gdb --args ./whatever --you-were running-before
[04:42] <achiang> and set args script bla bla bla
[04:43] <achiang> i've never tried running python under gdb before. it's worth a shot
[04:43] <ebroder> I guess I don't know if gdb can interpret shebangs. Wouldn't surprise me, but your way sounds better
[04:43] <ebroder> achiang: It's not very useful if your problems are in Python-land, but segfaults don't happen in Python-land
[04:44] <achiang> nod
[04:48] <achiang> ebroder: well, i think i have two problems, the first one being that usb-creator uses threads and i'm not tall enough to use threads.
[04:49] <ebroder> achiang: Hmm...in general I'm not either; the only thing I know to do with threads is "t a a bt"
[04:50] <achiang> i think it's time for bed. or rather, something not related to computers
[05:54] <siretart> fta: sorry? natty already ships an rc4 prelease. I should rather look into getting rc4 finally out
[08:04] <dholbach> good morning!
[08:16] <apachelogger> ScottK: for kde test building we probably can apply the stuff I once recommended for quicker building on kubuntu-devel (cowdancer, chroot with base deps etc.) + hook into the build process and prevent deb creation, since that is of little interest I suppose
[08:17]  * apachelogger hugs dholbach good morning
[08:18]  * dholbach hugs apacheloggerback
[09:07] <iulian> Morning dholbach!
[09:08] <dholbach> hi iulian
[09:50] <zyga> hi
[09:50] <zyga> I'm working on my own application + set of ubuntu packages
[09:50] <zyga> I currently work in a ppa
[09:50] <zyga> should I be using -ubuntu0 suffix?
[09:51] <zyga> someone just recommended that I should have -0ubuntu1~zyga
[09:56] <ulysses> Hello, could you look at http://revu.ubuntuwire.com/p/hupnp please?
[10:30] <apachelogger> zyga: hi. in particular you should be using something like -0ubuntu1~zyga1. that way, if the version at hand gets included into Ubuntu, the Ubuntu version will supersede installation of your PPA version
[10:30] <apachelogger> 1.0-0ubuntu1~foo1 < 1.0-0ubuntu1
[10:30] <zyga> apachelogger, thanks
[10:31] <apachelogger> zyga: you're very welcome :)
[10:31] <zyga> apachelogger, I did that but the build process complained the maintainer address is not @ubuntu.com
[10:31] <zyga> apachelogger, I used my @linaro.org address and changed 0ubuntu1 to 0linaro1
[10:31] <zyga> (actually I just noticed I used -linaro0, not -0linaro0)
[10:32] <zyga> apachelogger, does that seem valid?
[10:32] <apachelogger> no :)
[10:32] <apachelogger> dpkg --compare-versions 1-linaro0 lt 1-0ubuntu1; echo $?
[10:33] <apachelogger> returns 1, i.e. your version would not be lower than the ubuntu version
[10:33] <apachelogger> dpkg --compare-versions 1-linaro0 lt 1-0; echo $?
[10:33] <apachelogger> also not lower than a debian version
[10:33] <zyga> hmm
[10:34] <zyga> so I should stick to 0ubuntu1 and not worry about the email addres warning?
[10:34] <zyga> (or perhaps I could use my ubuntu address for that)
[10:34] <apachelogger> zyga: ignoring should be just fine
[10:34]  * sebner pets apachelogger 
[10:35] <apachelogger> AFAIK the warning is only there so that ubuntu devs do not upload ubuntu specific packages without ubuntu maintainer (for which we have a policy)
[10:35]  * apachelogger hugs sebner
[10:35] <apachelogger> ulysses: that should be a version with ubuntu1 really
[10:36] <zyga> apachelogger, so my packages should have whatever-0ubuntu1~zyga1
[10:36] <zyga> apachelogger, and I should increase zyga2, zyga3 and so on, without touching the ubuntu part
[10:36] <zyga> apachelogger, correct
[10:36] <apachelogger> zyga: exactly
[10:37] <zyga> apachelogger, thanks
[11:00] <zyga> apachelogger, are you familiar with lauchpad build recipes?
[11:01] <zyga> apachelogger, I have a control file http://bazaar.launchpad.net/~linaro-infrastructure/linaro-python-json/packaging/annotate/head%3A/changelog and a recipe https://code.launchpad.net/~linaro-infrastructure/+recipe/linaro-python-json-daily-build
[11:01] <zyga> apachelogger, it seems that the version is not taken from the changelog but from the recipe script
[11:02] <apachelogger> ulysses: reviewed. is this your first package?
[11:02] <apachelogger> zyga: recipes add a new changelog entry
[11:03] <zyga> apachelogger, ah
[11:03] <zyga> apachelogger, so that explains it
[11:03] <apachelogger> changing 0+{revno} to 0+{revno}-0ubuntu1~zyga{revno:packaging} should do the tick
[11:04] <apachelogger> (I think)
[11:04] <zyga> let me try
[11:04] <zyga> apachelogger, is there any reference to the syntax and variables you can use there?
[11:05] <zyga> 0+, isn't that going to override the package version that I already have (?)
[11:05] <apachelogger> https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[11:05] <apachelogger> zyga: depends on the version you have ;)
[11:05] <zyga> apachelogger, 1.0.0~alpha
[11:05] <apachelogger> just use dpkg --compare-versions
[11:05] <zyga> ideally the PPA version should be that + the revno
[11:05] <apachelogger> zyga: 0<1
[11:05] <zyga> and be more recent
[11:06] <apachelogger> that 0+n has an effect as if the were n < 1 :)
[11:06] <zyga> so the PPA daily build version will always be smaller than non-daily version?
[11:07] <zyga> (if I ever dput that that is)
[11:07] <zyga> should it not be the other way around?
[11:07] <apachelogger> zyga: with the current recipe, yes
[11:07] <apachelogger> then you will need to change your recipe ;)
[11:07] <zyga> I'm asking about the principle, what it _should_ look like
[11:07] <ulysses> apachelogger: yes, I only made some rebuild previously
[11:09] <apachelogger> zyga: PPA should be 1.0.0~alpha1-0ubuntu1~zyga1  - a daily should be 1.0.0~alpha1+{revno}-0ubuntu1~zyga{revno:packaging}
[11:09] <apachelogger> ulysses: very good packaging for a first package I must say
[11:09] <ulysses> apachelogger: Riddell helped mi a lot
[11:09] <apachelogger> ah, cheating, I see ;)
[11:10] <zyga> apachelogger, can I use {debupstream} instead of 1.0.0~alpha1?
[11:10] <zyga> (assuming that's my upstream version
[11:10] <apachelogger> zyga: yes
[11:12] <dholbach> Laney, directhex, hyperair: did you get Richard Lee's mail? did anyone of you comment?
[11:12] <hyperair> what mail?
[11:13] <hyperair> i don't remember seeing any such mail though
[11:13] <hyperair> dholbach: where was it posted to?
[11:13] <dholbach> your ubuntu.com email address :)
[11:13] <hyperair> huh
[11:13] <hyperair> O_o
[11:13] <dholbach> shall I forward it to you again?
[11:14] <hyperair> yes please
[11:14] <dholbach> hang on
[11:14] <hyperair> what's the title?
[11:14] <dholbach> "(Basic) Mono packaging guide for Debian and Ubuntu"
[11:14] <hyperair> oh that!
[11:14] <hyperair> wasn't that some months back?
[11:14] <hyperair> i think someone might have replied.
[11:15] <dholbach> forwarded again
[11:15] <hyperair> lemme check
[11:15] <dholbach> 12 days ago :)
[11:15] <hyperair> dholbach: i guess time has been moving too fast over here >_>
[11:16] <dholbach> yeah, sounds like it ;-)
[11:19] <directhex> dholbach: just running through the instructions
[11:20] <dholbach> directhex, hyperair: I can't comment on these, so if you can help Richard to make this really useful everybody would be happy :)
[11:20] <ulysses> apachelogger: is this correct? Build-Depends: debhelper (>= 7.3.16), libqt4-dev (>= 4:4.7.0)
[11:21] <hyperair> hmm "Note that it tracks the *runtime* dependencies not the *build* dependencies" seems a bit vague.
[11:21] <hyperair> dholbach: are people supposed to have read anything before the guide?
[11:21] <dholbach> hyperair, I don't know
[11:22] <dholbach> hyperair, Richard talked to me about it since he wanted to document how he went about doing mono packaging (and he didn't find docs for it) and because I have no clue about mono packaging, I suggested to talk to you guys :)
[11:23] <hyperair> dholbach: i use http://pkg-mono.alioth.debian.org/cli-policy/ as my holy CLI packaging bible.
[11:23] <hyperair> but maybe it's a tad bit too wordy for a beginner's guide..
[11:24] <dholbach> I don't know if Richard knew about this
[11:24] <dholbach> it'd be really great if any of you could get in touch with him 0:-)
[11:26] <hyperair> dholbach: is he on irc?
[11:27] <hyperair> directhex: wasn't there another email... to pkg-cli-*-team list about a cli packaging guide?
[11:27] <directhex> hyperair: yes
[11:28] <hyperair> directhex: who was it who did that one?
[11:28] <directhex> hyperair: policy guide is very detailed, but not a great starting point for all. especially the md->autofoo stuff
[11:28] <hyperair> directhex: actually i'm clueless about the MD part.
[11:28] <hyperair> directhex: i've never actually used MD before, aside from starting it up and then closing it again
[11:29] <dholbach> hyperair, directhex, Laney: meet rhlee
[11:30] <dholbach> rhlee: meet hyperair, directhex and Laney :)
[11:30] <hyperair> aha.
[11:30] <dholbach> so hyperair mentioned http://pkg-mono.alioth.debian.org/cli-policy/ and something that was discussed on a pkg-cli mailing list
[11:31] <rhlee> hyperair + directhex + Laney: hiya guys
[11:31] <hyperair> i can't seem to find the email. hmm
[11:31] <hyperair> hiya rhlee
[11:31] <dholbach> I don't think I can contribute much to the discussion, but thought it'd be worthwhile bringing you in touch :)
[11:31] <hyperair> yeah thanks
[11:33] <hyperair> so anyway, rhlee, i was wondering whether people were supposed to have read something before reading this proposed document
[11:33] <directhex> replied
[11:33] <directhex> sorry, been busy
[11:33] <rhlee> directhex: np
[11:34]  * hyperair didn't recv anything though
[11:34] <rhlee> yes, the ubuntu packaging guide was a recommended prequisite for the guide
[11:34] <rhlee> https://wiki.ubuntu.com/PackagingGuide/Complete
[11:35] <hyperair> rhlee: so the readers would know the difference between runtime vs build deps then?
[11:35] <rhlee> i would assume so, or it that too much of an assumption?
[11:36] <zyga> when packaging python libraries can I somehow simplify the duplication of depends and build-depends
[11:36] <zyga> my package has virtually identical depends as build-depends
[11:36] <rhlee> hyperair + directhex + Laney: fyi the guide I provisionally published is here https://wiki.ubuntu.com/PackagingGuide/Mono
[11:37] <hyperair> rhlee: i'm not sure, i haven't actually touched the packaging guide for a long time. these days i refer to the debian policy manual if i need reference
[11:37] <directhex> zyga: i assume there's some pythony way of auto-tracking depends, like shlibs:depends
[11:38] <zyga> directhex, there is python:Depends
[11:38] <zyga> directhex, but it's not very helpful in my case, it does not pick up anything I have (I don't know how it works)
[11:38] <hyperair> rhlee: well apart from that i don't see anything wrong with the guide except for minor spelling issues.
[11:40] <directhex> hyperair: cli:depends is in there, which would lead to better packages than the occasional interloper in the archive
[11:40] <rhlee> hyperair: so I probably should elaborate more on the difference between runtime and build dependencies?
[11:41] <hyperair> rhlee: that's up to you. i figure the standard packaging guide should already mention it, right?
[11:41] <hyperair> if that's so then fine, otherwise you might want to, yeah.
[11:41] <hyperair> rhlee: also i've just corrected your spelling on the wiki page.
[11:42] <hyperair> and... are you that afraid of spam? =p
[11:42] <rhlee> yes, the standard packaging guide does mention it
[11:43] <rhlee> hyperair: thanks for the corrections
[11:43] <hyperair> alright, then i think it's fine to leave it be like that.
[11:43] <hyperair> =)
[11:43] <hyperair> thanks for doing the documentation
[11:44] <hyperair> like directhex mentioned, this should lead to cli packages of better quality in the archive.
[11:44] <rhlee> hyperair: np, re my email address: if it safe to leave it in properly?
[11:44] <rhlee> hyperair + directhex: thanks for your help
[11:44] <rhlee> directhex: got your email will go through it
[11:45] <hyperair> rhlee: it depends on how much you trust your spam filters, i guess.
[11:45] <hyperair> rhlee: i trust gmail's.
[11:46] <rhlee> hyperair: I'll probably leave as is then
[11:46] <hyperair> rhlee: and either way my email is all over the place, specifically wherever Maintainer: is displayed, or changelog entries.
[11:48] <rhlee> hyperair: i guess I can alway get canonical to change my email address if there is too much spam
[12:01] <zyga> apachelogger, thanks, you've helped me to build two packages :-)
[12:54] <zyga> I have a source tree with a script.py, how can I remove the extension when creating a debian package?
[14:49] <Rhonda> I would need to do a SRU to lucid for ejabberd because of bug #596676
[14:50] <Rhonda> I take it the version should be 2.1.2-2lucid1, what to put into the target of the upload? just lucid? lucid-updates?
[14:51] <Laney> lucid-proposed
[15:18] <geser> Rhonda: as version 2.1.2-2.1
[15:18] <Rhonda> geser: Why -2.1?
[15:19] <Rhonda> Wouldn't that hint it was pulled in unmodified from Debian?
[15:20] <Laney> adding ubuntu0.1 is common
[15:20] <Laney> but really it's only necessary to make sure there is an upgrade path
[15:21] <geser> Laney is right, it should be -2ubuntu0.1 (I should do more SRUs to remember it better :) )
[15:23] <Rhonda> Given that maverick has 2.1.5-3 I don't think there is a need for 0.1
[15:23] <Rhonda> erm, 2.1.5-2
[15:24] <geser> that's just the usual versioning scheme: add .1 (and ubuntu0 if needed)
[15:25] <geser> https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging describes the versioning scheme used for security updates but it also works for SRUs (and is linked from the SRU page)
[15:27] <Rhonda> Right. But adding ubuntu1 also fulfills the requirements of "be newer than the version being patched, but earlier than any version in the development branch" :)
[15:29] <geser> I just wanted to point you to the usual SRU versioning scheme, I don't know if the uploads gets rejected if you use one that also works but is different
[15:36] <Rhonda> hmm, a #redirect ion wiki.u.c/SRU would be helpful
[15:37] <Rhonda> oh, seems to be there
[15:38] <Rhonda> Actually I even had chosen to go with 2.1.2-2lucid1  :)
[15:38] <geser> else ask our bot (!sru) it knows many things :)
[15:39] <ebroder> Rhonda: 2.1.2-2lucid1 would be a lower version number than 2.1.2-2ubuntu1, which is what maverick would have had if there had been an Ubuntu-only change. That's why you add the 0ubuntu
[15:39] <ebroder> Err...wait. Never mind. That particular case would have been fine
[15:39] <ebroder> But that's the sort of thing you're watching for
[15:39] <Rhonda> ebroder: It being lower is the whole point of it. :)
[15:40] <ebroder> I think what I meant to say is that putting it in the same form means you don't have to think about whether it's higher or lower
[15:40] <Rhonda> erm, if there already would had been a -2ubuntu1 in lucid, of course I'd bump it to ubuntu2
[15:40]  * ebroder goes and gets coffee
[15:41] <Rhonda> But right, schemas are a good thing to reduce discussions like this. Thanks. ;)
[15:42]  * Rhonda . o O ( and editing another page, removing jaunty and adding maverick )
[15:45] <Rhonda> What will happen after release of zippy zebra?
[15:46] <jmarsden> Rhonda: We can start using letters from the Greek or Russian alphabet? :)
[15:46] <achiang> move to a different charset?
[15:47] <Rhonda> That will be 17.04, if I calculated right …
[15:49] <geser> Rhonda: perhaps we can use till then Unicode in version strings
[15:50] <Rhonda> You'll have to get that past manoj. Somehow I doubt that.
[15:50] <Rhonda> And I fear there are no animal names starting with unicode letters.
[15:52] <geser> or do it like ms excel: after Z comes AA :)
[15:52] <Rhonda> welsh names? :)
[15:52] <directhex> Rhonda: we could use 😸
[15:52] <directhex> that'd be an awesome release name
[15:52] <Rhonda> I only see <?>
[15:52] <directhex> geser: not just excel: also /dev/sd*
[15:52] <directhex> Rhonda: well, by 2017 your font will include that glyph
[15:53] <Rhonda> directhex: haha
[15:53] <directhex> Rhonda: important letters like GRINNING CAT FACE WITH SMILING EYES must be added to all fonts
[15:53] <Rhonda> directhex: Take this: "
[15:53] <Rhonda> Edvard Munch wouldU+1F631 at Unicode 6 t-shirtsEdvard Munch wouldU+1F631 at Unicode 6 t-shirts
[15:53] <Rhonda> bleah, stupid paste
[15:53] <Rhonda> directhex: http://www.zazzle.com/Lalobee
[15:54] <directhex> Rhonda: FACE SCREAMING IN FEAR ?
[15:54] <Rhonda> yep
[15:55] <Rhonda> Actually I really think I should order me my own shirt. :)
[15:55] <directhex> geser: yes device nodes go that high: Disk /dev/sdai: 23998.3 GB, 23998331092992 bytes
[15:55] <Rhonda> One of the most geeky ones, to be honest.
[16:01] <ari-tczew> if package has depends with [linux-any], it will works?
[16:03] <geser> should, I know I filed bugs about it and if I remember correctly they got fixed
[16:03] <ari-tczew> geser: but you mean Build-Depends or Depends?
[16:04] <geser> Build-Depends as this was a problem for the buildds
[16:04] <geser> Depends are handled by apt itself so should be less an issue
[16:04] <ari-tczew> geser: aha, ok
[16:06] <cjwatson> not to spoil the fun but I think Mark said we'd just cycle (though he might change / have changed his mind)
[16:06] <geser> and if I'm not mistaken [arch] isn't supported in Depends (but I have to check the Debian policy to be sure), but our fellow DDs might know it too
[16:07] <cjwatson> it is, fairly recently
[16:07] <cjwatson> provided the package is not Architecture: all
[16:07] <cjwatson> build-depends on [linux-any] were fixed - https://bugs.launchpad.net/launchpad-buildd/+bug/604981
[16:07] <cjwatson> I *think* it's basically OK now
[16:08] <cjwatson> https://bugs.launchpad.net/soyuz/+bug/669404 (Packages-arch-specific) is still open but not a major problem for most people
[16:10] <geser> the upload part for linux-any got also fixed (bug 605002)
[16:11] <cjwatson> indeed
[16:13] <ari-tczew> ok, I'm only asking
[16:13] <ari-tczew> BlackZ: ^^
[16:25] <kaushal> Hi
[16:25] <kaushal> https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/379329
[16:26] <kaushal> It says it has been fixed This bug was fixed in the package openssh - 1:5.2p1-1ubuntu1
[16:26] <kaushal> is this version available in hardy 8.04
[16:26] <kaushal> please suggest
[16:26] <ScottK> No.  It's not.
[16:27] <kaushal> oh i see
[16:27] <kaushal> so i need to add Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc
[16:27] <kaushal> in sshd_config and ssh_config
[16:27] <kaushal> ?
[16:28] <kaushal> and restart the sshd daemon
[16:28] <kaushal> as per that bug instruction
[16:28] <ScottK> I didn't read the bug, but if it gives a work around, you'll likely need it.
[16:29] <kaushal> ok
[19:18] <apachelogger> ulysses: about the build-dep change ... it is correct, and maybe not, if the code really only works with Qt >= 4.7 it is correct, if it is not the minimum requirement it is less correct (still good enough for me though :))
[19:18] <apachelogger> zyga: groovy :D
[19:26] <sebner> apachelogger: so, how did the test went?
[19:26] <sebner> *go
[19:34] <ricotz> sebner, hi
[19:38] <sebner> ricotz: hola
[19:38] <apachelogger> sebner: not terribly well
[19:39] <ricotz> sebner, could you help with a autotools problem?
[19:39]  * apachelogger is targetting ballmer peak right now -> free work hours from apachelogger this evening
[19:39] <sebner> apachelogger: don't worry, the next text surely comes :D
[19:39] <apachelogger> unfortunately :P
[19:40] <sebner> :D :D :D
[21:43] <ari-tczew> could someone ping me?
[21:43] <sebner> ari-tczew: ping
[21:43] <ari-tczew> sebner: could you again ping in next 10 seconds?
[21:44] <sebner> ari-tczew: ping
[21:44] <ari-tczew> sebner: I'm trying to reproduce bug in indicator-applet. I have to minimalize to tray.
[21:45] <ari-tczew> Rhonda: ping on chat, here :P
[21:45] <Rhonda> that's hilight, not ping
[21:48] <bdrung> ari-tczew: you could use two different irc apps and ping yourself in an self-created channel
[21:48] <sebner> Rhonda: ah!
[21:50] <ari-tczew> sebner, bdrung, Rhonda: That's right, my fault. I should say highlight. Sorry.
[21:52] <ari-tczew> Rhonda: could you then highlight me again? ;)
[21:52] <micahg> ari-tczew: you can have ubottu do it
[21:52] <Rhonda> I didn't hilight you before, and like bdrung noticed, you could actually do it for yourself with a second client, and using a test channel instead of in here.
[21:53] <bdrung> (that's what i do for debugging)
[21:53] <Rhonda> Actually when I have to test something with irssi which I maintain I fire up several instances and /join #randomfoo
[21:54] <ari-tczew> micahg: good point
[21:54] <ari-tczew> micahg: but I'm not sure whether he can hightlight me with delay :>
[21:55] <micahg> ari-tczew: which can be done in a PM as well, if you need a channel though, what the others have suggested is probably best
[21:55] <bdrung> ari-tczew: and you probably don't want your debugging stuff logged ;)
[21:56] <ari-tczew> bdrung: in this case I don't care
[21:56] <Rhonda> Actually we do :)
[21:56] <ari-tczew> don't be inflexible ...
[21:57] <ari-tczew> you can include this one to your report about my bad behavior!
[21:57] <micahg> ari-tczew: keep in mind there are 194 people in this channel that see all your tests
[21:58] <Rhonda> Actually such kind of responses to well-meant advices isn't really helping your case  :/
[21:59] <ari-tczew> Rhonda: very terrible. going back to my activities...
[22:03] <bdrung> ebroder: i included http://pastebin.ubuntu.com/532617/ and  it covers only 75% of the bugs. what should we do with merge requests?
[22:03] <ebroder> bdrung: for merge requests I'm assuming you just want to use when the request was created, no?
[22:03] <micahg> bdrung: separate section?  some sponsors aren't comfortable with them yet
[22:06] <ebroder> bdrung: The MPs that get listed on the queue currently are using the date the proposal was created, so that seems fine
[22:28] <bdrung> ebroder: MPs?
[22:28] <ebroder> merge proposals
[22:31] <bdrung> ebroder, micahg: please have a look at http://people.ubuntu.com/~bdrung/sponsoring/
[22:33] <micahg> bdrung: it's not grabbing the time for ubuntu-security-sponsors subscriptions
[22:34] <micahg> bdrung: also, can we sort by time in queue (not sure if ASC or DESC is more appropriate) with unknown going to the back of the queue?
[22:34] <bdrung> that's the current patch: http://pastebin.com/1Kfvyatn
[22:35] <micahg> bdrung: when I load the page, it's sorting by Date created ASC
[22:35] <bdrung> micahg: you can click on the column
[22:35] <ebroder> bdrung: Try changing line 56 of the diff to something like if activity.message in ["added subscriber Ubuntu Sponsors Team", "added subscriber Ubuntu Security Sponsors Team"]:
[22:35] <ebroder> or whatever they call themselves
[22:36] <micahg> bdrung: right, I know, but shouldn't the default reflect the more accurate order of time in queue vs date bug is created?
[22:37] <ScottK> It should be sortable the same ways an LP bug list is sortable.
[22:39] <ebroder> I'm having a hard time figuring out how to make an "unknown" value sort as being in the queue longer than anything else
[22:39] <micahg> ScottK: I think all the columns are sortable, my question was what the default view should be
[22:39] <ebroder> Maybe defaulting to 1970-0101?
[22:39] <ScottK> OK.
[22:39] <ari-tczew> geser: could you update also queue of task on Agenda?
[22:40] <ari-tczew> 2 requests have been added without number.
[22:40] <micahg> ebroder: well, maybe an s/-// and and then do a numeric comparison?
[22:42] <ebroder> micahg: sorttable.js can already deal with fields in a date format
[22:42] <micahg> ebroder: oh, cool
[22:42] <ebroder> but it guesses teh type of a column based on the first non-blank row
[22:43] <micahg> ebroder: can you hint as to the column type?
[22:43] <ebroder> Not that that matters, because a purely lexical sort would work, too
[22:43] <ebroder> micahg: Not that I see
[22:44] <geser> ari-tczew: done
[22:44] <bdrung> ebroder: no, the unknown items are at the wrong end
[22:44] <ebroder> micahg, bdrung: Oh wait, hmm...it looks like you can set a sorttable_customkey attribute on the <td> html tag
[22:44] <ebroder> So for unknown rows, do <td sorttable_customkey="0">unknown</td>
[22:44] <ebroder> Or thereabouts
[22:46] <bdrung> <td sorttable_customkey="0">unknown</td> doesn't seam to work
[22:46] <ebroder> I'm probably mis-reading the code
[22:46] <bdrung> now it doesn't sort it correctly
[22:48] <ebroder> oh - it's probably deciding that the column is numeric instead of dates
[22:48] <ebroder> What about sorttable_customkey="1970-01-01"?
[22:49] <ebroder> http://www.kryogenix.org/code/browser/sorttable/#customkeys is what I'm looking at, btw
[22:49] <bdrung> ebroder: yes, that works
[22:50] <bdrung> ebroder: but that's not valid xhtml
[22:51] <ebroder> bdrung: Yeah, that thought occurred to me. Not sure if there's a great answer for that
[22:51] <micahg> bdrung: what's not?
[22:51] <ebroder> micahg: Any of sorttable's custom attributes
[22:52] <micahg> ebroder: because of the underscore?
[22:52] <ebroder> micahg: Because XHTML specifies what attributes an element can have
[22:54] <micahg> here's the bug for that: http://www.kryogenix.org/bugs/sorttable/data-attributes.html
[22:55] <micahg> bdrung: use the XHTML transitional DTD?
[22:55] <bdrung> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
[22:57] <bdrung> micahg: IIRC xhtm 1.1 doesn't have a transitional dtd
[22:57] <micahg> no, I guess not
[22:57] <ebroder> Downgrade?
[22:57] <bdrung> why not fix it by getting the unknown ones from the list?
[22:58] <micahg> bdrung: I think they were added before there were logged
[22:58] <micahg> except for the security sponsors one
[22:58] <ebroder> micahg: Actually, my theory is that it relates to the ubuntu-{universe,main}-sponsors -> ubuntu-sponsors transitions
[22:59] <micahg> we could just unsub/resub and bump to front of queue?
[22:59] <ebroder> Look at the 4th from the bottom on https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/44609/+activity for instance
[22:59] <micahg> ebroder: yeah, that seems to be part of it
[22:59] <ebroder> It's a queue not a stack! :-P
[22:59] <ebroder> (At least in theory...)
[22:59] <micahg> ebroder: hence I said front and not top :)
[23:00] <micahg> depending on how you look at it
[23:00] <bdrung> ebroder: it's a queue with random access :P
[23:00] <micahg> or back I guess if you're going from the oldest (which I don't think most people do)
[23:01] <bdrung> sponsors bunch :)