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