[00:00] <fader> Yeah, I'd imagine you're probably right.  :)  Still seemed worth filing a bug though.
[00:01] <persia> I don't know if it's related, but r669 of oem-config has the comment "Declare GTK frontend as "NotShowIn=KDE;" rather than
[00:01] <persia> "OnlyShowIn=GNOME;XFCE;" (LP: #163518)."
[00:01] <persia> bug #163518
[00:01] <ubot4> Launchpad bug 163518 in oem-config ".desktop files say OnlyShowIn=GNOME, should be NotShowIn=KDE;" [Wishlist,Fix committed] https://launchpad.net/bugs/163518
[00:03] <fader> persia: I'm not sure if that's related or not.  My guess is that the .desktop file for the 'prepare for shipping' icon should have been created in ~oem somewhere, but it wasn't on my system
[00:04] <fader> Does anyone have an OEM Kubuntu install still up?
[00:06] <persia> fader, Hrm.  My reading of that was that the icon wasn't to show in KDE anyway.  I presume someone is working on a proper KDE port of the tool, which would get it's own icon.
[00:08] <fader> persia: Yeah, tough to say without a system to compare it to. :/  Though it sounds like it worked for davmor2 on the live CD, so I'm leaning toward bug on the alternate
[00:08] <fader> Or user error, I still haven't ruled out that I munged something :)
[00:10] <persia> IF it worked on the alternate, than it may be that r669 hasn't been pushed into images yet.
[00:10] <persia> s/alternate/live/
[00:11] <persia> Or there may already be a KDE front-end.
[00:26] <fader> Okay, rerunning the OEM install... let's see what happens.
[00:37] <eeejay> cr3, hey hey
[00:37] <cr3> eeejay: yo ho ho
[00:37] <eeejay> cr3: question: how do you edit the glade file?
[00:37] <fader> bork bork bork
[00:37] <eeejay> cr3: glade-3 effed it up
[00:37] <cr3> eeejay: glade-2
[00:38] <cr3> <!DOCTYPE glade-interface SYSTEM "http://glade.gnome.org/glade-2.0.dtd">
[00:38] <eeejay> cr3: for real?
[00:38] <eeejay> cr3: ok
[00:38] <cr3> eeejay: dude, that file dates back a long time
[00:38] <eeejay> cr3: so we could skip glade3 and go straight for gtkbuilder
[00:39] <cr3> eeejay: you know, I once considered making it possible for plugins to define their own glade in order to customize the interface
[00:39] <cr3> that got postponed because there wasn't that much need for it and I fear it might start making the interface inconsistent
[00:40] <cr3> I like the fact the user can predictably know that each manual test will look more or less the same
[00:40] <eeejay> cr3, i borked the glade file when i opened it in glade-3, so i started prototyping directly in pygtk
[00:40] <cr3> you could also prototype in gimp :)
[00:40] <eeejay> cr3: it will also cause a split between cli and gtk
[00:41] <eeejay> true
[00:41] <cr3> eeejay: that's another thing I like, the base UserInterface class provides a fixed set of user interactions which can be derived by each of the interface implementations, to which I'd like to add qt one of these days
[00:42] <eeejay> cr3: yeah, i like that setup too
[00:42] <cr3> if we get package testing useful enough for the kde folks, I should ask them for an implementation
[00:43] <fader> Allegedly QT Designer can import glade files.
[00:43] <cr3> eeejay: I tried to make the show_* methods in the UserInterface class kinda generic, with show_test as the only real exception
[00:43] <fader> It might not be too tough to get a KDE UI
[00:47] <fader> Hmm, still get the same issue with the alternate kubuntu CD in OEM mode
[00:48] <fader> persia: ^^
[01:17] <fader> Outta here for the night...
[01:17]  * fader waves.
[06:52] <ara> good morning all :)
[17:32] <eeejay> cr3, morning ho
[17:32] <cr3> eeejay: ya man
[17:33] <eeejay> cr3, would you be receptive of a checkbox branch that uses gtkbuilder?
[17:34] <cr3> eeejay: I'm not very familiar with gtkbuilder, is it like glade but more better?
[17:34] <eeejay> cr3, glade is being deprecated
[17:35] <eeejay> cr3, next GNOME release is supposed to have zero glade reliance
[17:36] <cr3> eeejay: such a branch would be quite welcome then :)
[17:36] <eeejay> cr3, excellent, thanks :)
[17:36] <cr3> eeejay: but before, I think heno and ara would prefer we land mago integration so that it can start being used
[17:37] <eeejay> cr3, it's a 30 minute deal, i spent time converting accerciser a while ago, so i know the tricks
[17:38] <cr3> eeejay: gtk-builder-convert and voila? :)
[17:38] <eeejay> cr3, a bit code massaging
[17:38] <cr3> eeejay: cool, could you push gtkbuilder migration as a branch separate from mago integration?
[17:39] <eeejay> cr3, of course
[17:39] <cr3> man, I wish I had to be converted so that I could get a massage too :(
[17:46]  * cr3 steps out for grub, the other boot loader
[22:49] <Cut_em2_it> hello
[22:49] <Cut_em2_it> ?
[22:50] <cr3> Cut_em2_it: hi there
[22:51] <Cut_em2_it> on your testing page, it says that the next test is on March 30, 2009?
[22:51] <cr3> Cut_em2_it: oups, which page is that?
[22:51] <cr3> Cut_em2_it: sorry, I need to step out for a moment, back in a moment
[22:51] <Cut_em2_it> https://wiki.ubuntu.com/Testing/UbuntuTestingDay/20090330
[22:51] <Cut_em2_it> k
[23:06] <cr3> Cut_em2_it: I'll send an email out to a couple people about that page and the parent page
[23:09] <Cut_em2_it> ok
[23:09] <Cut_em2_it> thanks
[23:15] <eeejay> hey cr3: more silly questions
[23:16] <eeejay> cr3: what are, and how do i use test attachements?
[23:16] <eeejay> cr3, it doesn't seem like any plugin uses them
[23:24] <cr3> eeejay: attachments: /etc/shadow
[23:25] <cr3> or attachments: cat /etc/shadow
[23:25] <cr3> it's just a newline separated list of files or commands
[23:25] <eeejay> cr3, yeah. i understood that from the code
[23:25] <eeejay> cr3, are attachments things that get attached after a test has run?
[23:25] <cr3> checkbox-certification/suites/bootchart.txt uses it
[23:26]  * eeejay looks
[23:26] <cr3> it gets attached upon reporting. I'm not sure if launchpad supports that concept, I haven't implemented it anyhow
[23:27] <cr3> I only use it on the commercial side
[23:27] <eeejay> interesting concept
[23:28] <eeejay> cr3, so i think perhaps the mago log should be an attachment
[23:28] <cr3> eeejay: my original idea named the parameter "debug" because I thought it would be useful to attach supplementary debugging information to tests
[23:28] <eeejay> cr3, the problem being that it is singleton (ie. not associated with a set of results)
[23:28] <eeejay> cr3, but with the actual test
[23:29] <eeejay> cr3, so consecutive runs would overwrite it
[23:29] <cr3> eeejay: that should be fine, as long as it "overwrites" rather than "appends"
[23:30] <cr3> eeejay: err, maybe my understanding is premature: if mago will be run multiple times during one checkbox run, then that may pose a problem indeed
[23:30] <eeejay> cr3, yeah, but i am afraid a split might occur, between results and mago log
[23:30] <cr3> if that's the case, maybe I should reconsider associating attachments with results rather than tests
[23:31] <eeejay> zactly
[23:31] <cr3> just to make sure we understand each other, it would work if the logs were captured immediately after the test is run, right?
[23:31] <eeejay> cr3, what i started doing was making a structure in results.data
[23:31] <eeejay> yeah, that would be the idea
[23:32] <cr3> I didn't have a use case for associating attachments with results before but now I do, I'll report a bug and make the necessary changes soonish
[23:32] <cr3> it sounds like attachments are what you need rather than shoving everything in result.data
[23:32] <eeejay> cr3, yeah
[23:33] <eeejay> cr3, i would like to have an attachment, and a field for user comments
[23:33] <eeejay> cr3, so the comments would stay in data
[23:33] <cr3> eeejay: agreed, that's the way it ought to be
[23:34] <eeejay> cr3, did you see my gtkbuilder branch? does it kick ass?
[23:35]  * eeejay uses test.attachment in the meantime.
[23:36] <cr3> eeejay: I've subscribed you to the bug I created, #386545
[23:36] <cr3> eeejay: by the way, my current attachment implementation makes the assumption that if a test is skipped then attachments should be ignored. do you think that's reasonable?
[23:36] <eeejay> cr3, um kinda
[23:37] <eeejay> cr3, we have a mago concept of error
[23:37] <cr3> eeejay: I haven't noticed your gtkbuilder branch, have you submitted it for review?
[23:37] <eeejay> cr3, when things go horribly wrong in the automation
[23:37] <eeejay> cr3, yup
[23:37] <eeejay> cr3, anyway I thought of using "skip" with the error message
[23:38] <eeejay> cr3, https://code.launchpad.net/~eeejay/checkbox/gtkbuilder/+merge/7391
[23:38] <cr3> eeejay: hm, that's an interesting use case but I'm not sure I agree
[23:39] <cr3> eeejay: but I don't really have a solution though
[23:39] <eeejay> cr3, it is not perfect. but that was my plan, re: your question
[23:39] <cr3> it seems like we need another status like "the test itself failed"
[23:39] <eeejay> cr3, yeah: "error"?
[23:39] <cr3> but I'm really afraid to introduce more statuses, I want to keep things freaking simple
[23:39]  * eeejay agrees
[23:40] <cr3> I'll have a look at the some posix testing standard if I can find it, maybe it could convince me to have more statuses
[23:42] <cr3> eeejay: is there any problems in running the gtkbuilder version on older releases of ubuntu, like dapper or gutsy for example?
[23:43] <eeejay> cr3, possibly, yes
[23:44] <cr3> eeejay: dapper and gutsy are about to be eol, so we should at least make sure it runs on hardy and we could release soonish
[23:45] <cr3> I think dapper is going eol on July 1st, so I'd be comfortable releasing gtkbuilder on that date... assuming hardy works, of course
[23:46] <eeejay> cr3, ok
[23:47] <cr3> eeejay: your changes look good but I'll need to look deeper into the hypertextview part, it seems hairy
[23:47] <eeejay> cr3, yeah, i created a catalog for it
[23:49] <cr3> eeejay: I thought we'd dispense with glade altogether
[23:49] <eeejay> cr3, dispense?
[23:50] <cr3> grep -ri glade * || echo 'no more glade'