[00:22] <veebers> alesage: sorry missed the ping
[00:23] <veebers> alesage: "move it over"? As in take it out of the debian/tests folder and make it another module?
[00:25] <alesage> veebers, isn't that something we desire?  i.e. to live under ubuntu_sanity_tests?
[00:25] <alesage> facilitates testing at the least
[00:26] <veebers> alesage: yes it is, just wanted to confirm what your intentions are
[00:26] <alesage> veebers, MP forthcoming :)
[00:33] <veebers> elopio: you still around?
[00:34] <alesage> veebers, https://code.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/move-sanity/+merge/248325 <= elopio
[00:35] <veebers> alesage: which card does this correspond to :-)?
[00:52] <alesage> veebers, to one I'll create right now
[00:55] <alesage> veebers, I see you have reviews for me but I'm EOD, will take up tomw if they remain :)
[00:55] <veebers> alesage: ack, that would be appreciated (as I'm currently at my WIP limit ;-))
[00:56] <alesage> veebers, and with only one non-veebers card available for review ;)
[00:57] <veebers> alesage: heh, ack looking now
[03:58] <elopio> veebers: I got a ping earlier. Do you still need me?
[04:02] <veebers> elopio: hey, just had a question re: the blocked card and to ask if you could review the cards I hve in to-review
[04:03] <elopio> veebers: :)
[04:03] <elopio> for your pending reviews, I think I'm just missing to give them a run.
[04:03] <veebers> elopio: aight sounds good.  Probably won't be back on tonight
[04:04] <elopio> I dist-upgraded earlier and now phablet-network doesn't work. Let me workaround that, and I'll get your cards approved before my EOD.
[04:04] <elopio> veebers: ok, see you tomorrow.
[04:04] <veebers> let me know if you have any other issues with those branches to fix. And I'll hit it in my morning
[04:04] <veebers> o/ night
[06:28] <fgimenez> hi thomi
[08:32] <thomi> hi fgimenez - I accidentally left my IRC client on
[12:50] <doug5> balloons, hey, you there?
[13:03] <elfy> doug5: usually a bit later - Pacific time or something I think
[13:13] <doug5> elfy, shit, right
[14:39] <elopio> alesage: brendand_: a reminder that we are missing a review here: https://code.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/webbrowser-test-using-system-helpers/+merge/248080
[14:39] <elopio> it would be nice if one of you can get to it so we have it merged before veebers arrives anad he can get a new card.
[14:43] <brendand_> elopio, approved and top-approved
[14:44] <elopio> brendand_: thank you!
[14:44] <elopio> I will get to yours in a moment.
[14:48] <rhuddie> elopio, hey. did the sanity tests ever get run on emulator?
[14:49] <elopio> rhuddie: my emulator breaks my machine. I have to rseiub every time I try to run it.
[14:49] <elopio> so, unknown. I haven't been able to give it a try.
[14:51] <rhuddie> elopio, ok thanks. I am getting 'evdev.uinput.UInputError: "/dev/uinput" cannot be opened for writing'
[14:52] <elopio> rhuddie: hum, can you please leave that as a comment on the leankit card about running in an emulator?
[14:53] <rhuddie> elopio, sure. I am not totally sure my environment is correct, but everything esle seems to be working. I'll add the comment to the card.
[14:54] <elopio> rhuddie: and if you have some time, ask rsalvetti or sergiusens about it. We might need a new input type for autopilot, or they need to fix evdev on their side.
[14:54] <elopio> rhuddie: if you don't have time, don't worry. We'll do it as part of that card when jibel puts it in the top.
[14:55] <rhuddie> elopio, sure. I'm investigating running the automated sanity tests as part of silo landing process (emulator was easiest target to start with)
[14:56] <elopio> rhuddie: and that means writable image too, right?
[14:56] <rhuddie> elopio, for that I also raised a bug about being able to specify additional external tests more easily: https://bugs.launchpad.net/ubuntu-sanity-tests/+bug/1417556
[14:56] <rhuddie> elopio, yes, it would do.
[14:57] <elopio> rhuddie: the writable part needs a new card on the board, or a bug for sure. Please add one with all the info you can find.
[14:58] <rhuddie> elopio, I will do that
[14:58] <elopio> rhuddie: for that bug, what we can give you on friday is to first run the full sanity, and then run additional tests.
[14:59] <rhuddie> elopio, the purpose of the bug was to add a new method which could easily be called from a silo script, where you specify some additional tests that you want to run for a specific silo
[14:59] <rhuddie> elopio, as you need to specify the dependencies as well as the test ids in 2 different files
[15:00] <elopio> rhuddie: the dependencies bit sounds harder, but nice to have. And being able to run the internal and external tests + extra, with a single command is something I have no idea how to do. Maybe adding an argument --extra-tests.
[15:01] <elopio> rhuddie: if you need any of these requests by friday the 20th, please make sure to discuss about them with jibel. Today we will meet to define the top priorities for next sprint.
[15:02] <elopio> rhuddie: and thanks for all this, it's really useful to have somebody giving it a try.
[15:02] <rhuddie> elopio, ok. I don't have idea on time scale right now. just trying to find out what work is needed. I'll discuss.
[15:02] <rhuddie> elopio, yeah, its quite interesting to be using it as an end-user :)
[15:03] <rsalveti> I know I tested autopilot before on the emulator and it worked fine
[15:03] <rsalveti> not sure if there is any new specific thing we need to do now
[15:04] <rhuddie> rsalveti, good to know thank you. I'll keep investigating what is going on.
[15:17] <rhuddie> elopio, I was thinking that for adding new external tests and dependencies, a new "add_external_test()" method would be called first and would directly modify the testsuite_list and control file before running the tests as normal? that way no new command options needed.
[15:32] <dobey> pitti: can we *PLEASE* break the multiple tests feature of adt-run that nobody actually uses? the positional arguments thing is really annoying
[15:34] <pitti> dobey: I'm certainly open to that, but I can't know whether anyone is using that; this should at least get some discussion on the ML, perhaps CC'ing debian-devel@
[15:34] <pitti> (plus, it's quite some work, so it ceratinly won't happen overnight)
[15:36] <dobey> pitti: i just spent way too much time switching between utopic and vivid images with proposed enabled or not, only to discover that all the 404 issues were because the update and proposed were not actually being used, because i put the -U and --apt-pocket arguments after --setup-commands
[15:36] <dobey> :-/
[15:36] <pitti> dobey: well, -U and --apt-pocket are both setup-commands, so these will always stay order dependant
[15:37] <dobey> that makes no sense
[15:38] <dobey> and the documentation clearly doesn't specify that they must appear *before* the --setup-commands argument
[15:41] <elopio> rhuddie: I don't know about modifying the control field. That sounds like something we shouldn't do.
[15:41] <pitti> dobey: well, they don't :) they will be executed in the order you give them
[15:42] <pitti> dobey: so if your setup commands depend on having -proposed, you need apt-pocket and -U before; if enabling dist-upgrade depends on your setup-commands, you have -U after; etc.
[15:42] <rhuddie> elopio, I agree it seems a bit dubious... :)
[15:43] <elopio> rhuddie: I'm not quite sure the right way to do it is with a single adt-run call. Maybe one adt-run call, + one phablet-test-run will make things a little less messy.
[15:43] <elopio> rhuddie: but anyway, put all your ideas and input in the card. When it's time to write it, we'll research and discuss about it.
[15:44] <dobey> pitti: that is even more crazy :)
[15:45] <dobey> pitti: and i don't see why ubuntu-touch-session would depend on those being before
[15:45] <dobey> or why it would affect the argument parsing
[15:47] <rhuddie> elopio, yes. I was just thinking whether it should all need to be done in the sanity suite, or kept separate. In terms of reporting it would be easier to have it all as one suite, but as you say, phablet-test-run would also be a good option.
[15:48] <elopio> rhuddie: the tests for the silo should be specified in their debian/tests
[15:48] <pitti> dobey: well, it's the same as specifying --setup-commands twice -- these are for sure ordering dependant
[15:48] <elopio> rhuddie: so it's not like a random list of tests that you would like to run. We have a way to discover them and their dependencies.
[15:48] <elopio> of course, that's not happening now. But should.
[15:49] <dobey> pitti: but then surely -U must come after --apt-pocket (though that requirement doesn't exist)
[15:49] <pitti> dobey: right
[15:49] <dobey> though honestly, i don't see how this could ever really be usable without -U
[15:49] <dobey> even without --setup-commands or --apt-pocket
[15:50] <elopio> rhuddie: that might be easier. Receive a list of additional autopkgtests to run.
[15:50] <pitti> dobey: indeed I think --apt-pocket should do an apt-get update automatically
[15:50] <pitti> dobey: so that you can use it withoutu -U
[15:51] <dobey> pitti: right, but the only time not doing "apt-get update" is going to work, is if all the dependencies are already installed
[15:51] <dobey> which is basically never the case with qemu
[15:52] <pitti> dobey: oh, I pretty much always use it without -U locally, as it takes effing long and isn't needed when my VM is fresh :)
[15:52] <rhuddie> elopio, only problem with running all of them might be time constraints? it might be that we want to run a couple of high priority tests, instead of entire suites. But that's not clear right now.
[15:53] <pitti> dobey: it is true that currently just using --apt-pocket by itself doesn't make much sense without also running apt-get update (that's the issue I mentioned above)
[15:53] <dobey> pitti: well, if you're using lxc/chroot, then it's easy enough to have stuff already installed
[15:54] <pitti> dobey: I'm not entirely sure whether enabling -proposed (and apt-get update) *without* apt-get dist-upgrade makes a lot of sense; probably very little
[15:54] <pitti> dobey: so I'm ok with disallowing that use case, and make --apt-pocket imply -U
[15:54] <dobey> pitti: but even so, the ordering of such arguments as pased to adt-run should not be order-dependent. the execution of such things inside the VM may be though
[15:57] <dobey> pitti: so, i think any apt-related args (-U and --apt-pocket) should always be executed prior to any --setup-commands arguments, in the VM, regardless of where they appear in the arguments list to adt-run, and any shell scripts passed with --setup-commands should probably be executed in the order passed (because they are arbitrary scripts and requiring adt-run to know what they are doing would be excessive)
[15:57] <pitti> dobey: that means you could never use --setup-commands to enable e. g. a PPA or other third-party source
[15:57] <pitti> but we need that
[15:58] <pitti> or you couldn't use -U and had to spell it out
[15:58] <pitti> and that actually is current behaviour that people do use and depend on
[15:59] <dobey> pitti: it does. but it means your setup-commands should be doing an update as well, if they are touching apt stuff
[15:59] <pitti> right, which is precisely -U; -U is just a pre-defined --setup-commands
[15:59] <dobey> pitti: if you have a setup-commands script which adds an apt repository, but doesn't do apt-get update, then you're doing it wrong
[16:00] <pitti> well, it's --setup-commands "add-apt-repository foo" -U
[16:00] <dobey> pitti: that is an implementation detail though. exposing such an implementation detail via argument ordering, is bad :)
[16:00] <pitti> sure you could argue that we take away the -U shortcut for this case, but as I said that's something people do use
[16:08] <dobey> pitti: well, i'd say make it superfluous i guess, and deprecate it, telling people to do "add-apt-repository foo && apt-get update" instead. but as it is right now, i am finding it incredibly painful to use. :-/
[16:09] <pitti> dobey: add-apt-repository foo && (apt-get --quiet update || (sleep 15; apt-get update)) 2>&1'
[16:09] <pitti> very convenient to type :)
[16:09] <pitti> well, probably not necessary that often for a local run, but very important for CI
[16:10] <pitti> (all hail the dreaded apt hash sum mismatches..)
[16:12] <jderose> pitti: as something changed that's causing the hash mismatch to happen for frequently?
[16:13] <jderose> er, can't type
[16:13] <pitti> jderose: they've been a problem for years really
[16:13] <pitti> jderose: the above (or more clever variations thereof) has been copied into our buildds, Launchpad, and other places
[16:13] <jderose> maybe i'm just doing more automated stuff that get's hung up by it. happens a lot using the internal tools system76 uses for updating our images
[16:14] <pitti> we've had tons of spurious autopkgtest CI runs before I added that
[16:16] <jderose> pitti: gotcha, thanks
[16:19] <dobey> pitti: well, put it in a shell-script "smart-add-repository foo" :)
[16:32] <dobey> anyway, need to get lunh. bbiab
[17:37] <brendand_> elopio, i followed up on that MP
[18:19]  * alesage is doing some reviews
[18:20] <slickymasterWork> elfy, FYI http://cdimage.ubuntu.com/ is up now
[18:21] <elfy> not here
[18:22] <balloons> it's no longer up for me, but was yesterday. I snagged an image then :-)
[18:22] <balloons> elfy beat me too mentioning those issues on the list; thanks!
[18:24] <slickymasterWork> there's still a huge delay loading it, but it's up
[18:26] <balloons> I tried to clean up the milestones on the tracker.. wow was it a big list
[19:00] <alesage> elopio I too get the webbrowser failure, investigating, evidently not the same as the bug though
[19:01] <elopio> thanks alesage.
[19:07] <alesage> elopio, I stand corrected, same err as reported in bug for moi for webbrowser test
[19:07] <elopio> alesage: which bug are you talking about?
[19:08] <alesage> elopio, https://bugs.launchpad.net/ubuntu-sanity-tests/+bug/1408723
[19:08] <elopio> alesage: yup, same here.
[19:08] <elopio> reproduced in trunk, so nothing to do with brendan's branch.
[19:28] <elopio> brendand_: you need to resubmit your branch, to trunk.
[19:30] <brendand_> elopio, ! oh wth happened there. no wonder the jenkins tests didn't run
[19:36] <brendand_> elopio, alesage - you need to redo your approvals: https://code.launchpad.net/~brendan-donegan/ubuntu-sanity-tests/wizard_remove_connection/+merge/248440
[19:36] <brendand_> elopio, alesage - and a top approve
[19:51] <elfy> balloons: seems that sometimes you can actually download via the http links - try and do anything useful like zsync and it has a hissy fit
[23:14] <wxl> in lieu of my developers being awake, is it possible this could be fixed with a rebuild? sure is strange that it's only affecting one particular image and has no consistency across type of image or arch https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1417784
[23:46] <alesage> elopio, veebers another review pretty please https://code.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/move-sanity/+merge/248325
[23:51] <veebers> alesage: can do shortly


[22:55] <mmcc> Hi, I'm trying to familiarize myself with ubiquity in order to help out on the ubuntu one plugin that mvo started - is there a README or wiki page somewhere with a description of how to set up a test environment for working on plugins?
[23:18] <xnox> mmcc: hello. It's mostly wiki.ubuntu.com/Ubiquity
[23:18] <xnox> and pages from there.
[23:19] <xnox> You can run ubiquity from your host but it's not advised. It's better to boot into a VM and replaces files/packages in the life system and restart ubiquity.
[23:19] <xnox> try ubuntu is the easiest, while "install only" mode is less resource hungry.
[23:20] <xnox> You can switch to tty1 and stop lightdm, pkill -9 X and then modify files as needed (e.g. wget from host <IP_ADDRESS> and start ubiquity again with $ sudo start ubiquity)
[23:20] <xnox> mmcc: I thought mandel was already working on the U1 plugin.
[23:21] <xnox> some of the code is here: https://code.launchpad.net/~mvo/ubiquity/ssologin
[23:21] <xnox> mandel: did you have anything more?
[23:29] <mmcc> xnox: thanks. I was following the notes in mvo's branch in a raring vm, but it appears to be missing some things
[23:29] <xnox> mmcc: hm?
[23:29] <xnox> mmcc: note that we build from lp:ubiquity branch
[23:29] <xnox> and that ubiquity in addition to it's own source code embeds a few other packages.
[23:30] <mmcc> I started from https://code.launchpad.net/~mvo/ubiquity/ssologin/+merge/137264
[23:30] <xnox> So to build .debs either: $ bzr bd _or_ ./debian/rules update-local && fakeroot ./debian/rules binary
[23:31] <xnox> mmcc: mvo's work was work in progress and not completed, somebody needs to pick it up, test and fix up things that are missing / not implemented.
[23:31] <mmcc> ah, that sounds better. the comments that mvo wrote just had a few 'sudo cp' etc
[23:31] <mmcc> xnox: yes, that somebody is me. mandel did start it but got moved around
[23:32] <xnox> mmcc: Ok =) welcome on board. I can help you out with ubiquity side of things, as long as you fiddle with sso side of things enough for it to correctly authenticate, get the cookie/token and store it for the user correctly.
[23:32] <mmcc> I will also have dobey helping, so do not despair :)
[23:33] <mmcc> thanks! I believe mvo actually got pretty far with that. I'm still getting up to speed with how far, though - this assignment happened last thursday
[23:35] <xnox> mmcc: yeah. he did do a bit. The visuals & wireframes have changed since then. I can help with hooking this new plugin into the correct places in the installer & integrate transition to it and from it to the shutdown. But I haven't run mvo's code yet.
[23:38] <mmcc> xnox: do you have time for a few dumb questions or is it past EOD for you?
[23:42] <xnox> mmcc: i just came from volleyball training =) and I have a bit of time for a quick Q&A.
[23:42]  * xnox is reading email, RSS and other random stuff =)
[23:42] <xnox> go on =)
[23:43] <mmcc> ah, ok thanks. So I suspect the instructions on the wiki assume I'm using kvm
[23:43] <mmcc> do you know if anyone has tried using virtualbox?
[23:43] <xnox> kvm, virtualbox, vmware all should work.
[23:43] <xnox> virtualbox both free and oracle edition.
[23:43] <mmcc> ok
[23:45] <mmcc> so I'm not totally clear on what I would need to get from <IP_ADDRESS> , which you mentioned and is also on the wiki. That's a bridge to the host, correct?
[23:45] <xnox> right. so boot into live cd -> try ubuntu.
[23:45] <xnox> you should get normal desktop
[23:46] <xnox> check that you have internets.
[23:46] <xnox> then in the terminal you can either bzr branch or wget or whatever retrieve the new bits.
[23:47] <xnox> then you can either monkey patch into /usr/lib/ubiquity/plugins (it's all python ;-) ) or install/upgrade a proper/fully built .deb
[23:47] <xnox> then just launch ubiquity and see how far you get.
[23:47] <xnox> this typo of development cycle is a bit long, but it's easy enough to start with.
[23:48] <mmcc> ok, I see.
[23:48] <xnox> you notice that plugins in the begging have priorities, e.g. AFTER = 'language' WEIGHT=12 will move your plugin to be the second page (first page is language).
[23:48] <xnox> this is quite long-winded.
[23:49] <mmcc> hmm, all this is slightly complicated by the fact that I'm working on a mac (mac os x host, linux VM)
[23:49] <mmcc> (the mac u1 client is what I was hired to work on, initially :)
[23:50] <xnox> heh wel mac is almost a unix which is almost like linux.
[23:50] <mmcc> close enough for a lot of things, but unfortunately I think building a .deb isn't well supported :)
[23:51] <infinity> fink?
[23:51] <xnox> mmcc: I know that ev uses mac os x host & he even had like a folder sharing between mac os x & the VM and then he would just script copying files over.
[23:51] <xnox> mmcc: in that case just work on the python plugin & drop it into /usr/lib/ubiquity/plugins/
[23:52] <xnox> the only thing we need to do is skip past all the installation BS and go straight to user configuration.
[23:52] <mmcc> infinity: I haven't used fink in a long time, but I'm not sure it'd help me build a deb on the mac that could be installed in ubuntu... (but I could be wrong)
[23:52]  * xnox ponders if one can execute oem-config from the live environment.
[23:53] <mmcc> xnox: that leads me to another question I had - do I need to be using raring to work on this?
[23:53] <mmcc> the reason I ask is that the virtualbox guest additions didn't install correctly on raring, so the shared folder stuff doesn't work. (I use it regularly on quantal and it works great)
[23:55] <xnox> mmcc: in the end it has to work on raring. It must be in python3, you can use python3-oauthlib (if you need oauth).
[23:56] <xnox> mmcc: the diff between raring and quantal ubiquity is ~ 1000 in total, but the plugin interface didn't change that much.
[23:57] <xnox> i think you should be ok using quantal.
[23:57] <mmcc> ok, thanks - I'll probably be able to make raring work, but it's good to know I'm not stuck.
[23:58] <xnox> mmcc: mvo did a test-loader plugin such that one can load just one plugin and unit-test it.
[23:59] <xnox> that means that the bulk of U1 integration can be done on e.g. mac os x without the VM. with test driven development.
[23:59] <xnox> but you should be using/targeting python 3.3


[09:52] <bassem> thelinuxer, hi
[09:56] <thelinuxer> bassem: hi
[09:57] <bassem> thelinuxer, why there's two loggin bot in the channel?
[09:58] <thelinuxer> lubotu3 is a factoid bot
[09:58] <thelinuxer> what is ubuntu ?
[09:59] <thelinuxer> sorry can't remember how it works
[10:00] <bassem> lubotu3, hi
[10:00] <bassem> lubotu3, bash
[10:01] <bassem> lubotu3, cloud
[10:01] <thelinuxer> sa7 keda :D
[10:01] <bassem> thelinuxer, good, thank you and thanks to lubotu3 :-)
[10:01] <thelinuxer> bassem: lol
[10:02] <bassem> thelinuxer, he ignored me :-(
[10:03] <thelinuxer> lol
[10:03] <thelinuxer> lubotu3: thanks
[10:05] <bassem> lubotu3, I hate you!
[10:05] <thelinuxer> lol
[10:05] <bassem> lol, <lubotu3> Sorry, I don't know anything about 'I hate you!'
[10:05] <bassem> lubotu3, what do you know?
[20:57] <DigitalFlux> okie d4de, shoot them :)
[20:58] <d4de> shoot ... hah, hey fellas, where is Bahaa?
[20:58] <d4de> also does anyone know of a guy called Anis?
[20:58] <d4de> we'd like to have a chat with him
[20:58] <DigitalFlux> Bahaa El Sayed ?
[20:58] <DigitalFlux> Anas ya man
[20:58] <d4de> yeah
[20:59] <DigitalFlux> Yes i can get Bahaa too
[20:59] <d4de> he lives nearby me in Alex and I don't know ... the admin of ubuntu-eg?
[20:59] <DigitalFlux> just to confirm, the guy from Alex ?
[20:59] <DigitalFlux> Yes i know the guy
[20:59] <DigitalFlux> he hangs around IRC too ?!
[20:59] <d4de> hmm, from time to time yes
[20:59] <DigitalFlux> God, if i only can link my social networks to IRC
[20:59] <DigitalFlux> lemme check his phone number, i think i've got it
[21:00] <d4de> DigitalFlux, seems like refaey is hovering on your back big time tonight :-P
[21:00] <DigitalFlux> hehe, more like pushing, yes
[21:02] <d4de> I'd tuck him in myself
[21:02] <DigitalFlux> hehe
[21:02] <d4de> jesus, this guy really needs to lighten up on culture
[21:02] <DigitalFlux> Bahaa Salama is the same Bahaa El Sayed, right ?
[21:02] <DigitalFlux> ya seedy
[21:03] <d4de> I mean, he practically doesn't understand any thing about Netiquette
[21:03] <d4de> yep
[21:03] <DigitalFlux> I've got a bahaa salama on my phone, not sure if this the guy
[21:03] <d4de> gimme the number I'll verify it
[21:03] <d4de> notice it to me
[21:03] <DigitalFlux><PHONE_NUMBER>
[21:03] <DigitalFlux> poff
[21:03] <d4de> sheesh lol
[21:03] <DigitalFlux> that should have gone into a notice
[21:04] <DigitalFlux> Darn you Quassel
[21:04] <d4de> nop ... straight into the plain
[21:04] <d4de> yes, verified, its our guy
[21:05] <d4de> "This is AV81, confirm UTZ ... This is UTZ verifying ... Confirmed, roger!"
[21:05] <DigitalFlux> cool, so what is he superb at ? what exactly do we need from him ?
[21:05] <DigitalFlux> cool, so what is he superb at ? what exactly do we need from him ?
[21:05] <TheNightPhoenix> echo
[21:06] <DigitalFlux> ever saw someone that can post a text into IRC in the same second twice ? :)
[21:06] <d4de> I don't know, lets see for ourselves
[21:06] <DigitalFlux> i just did
[21:06] <DigitalFlux> okie
[21:06] <d4de> I can do IRC on a pure telnet session ;-)
[21:06] <d4de> I talk the protocol like if it were C to me
[21:06] <DigitalFlux> hehe, you know the whole protocol ?
[21:06] <d4de> yessir
[21:07] <d4de> I remember RFCs in my head
[21:07] <DigitalFlux> Ahh, we need to get a life then
[21:07] <d4de> I've implemented a couple myself too
[21:07] <d4de> Pfft, I threw that outside the window long ago
[21:07] <DigitalFlux> That's the reason i guess
[21:07] <DigitalFlux> That Quassel IRC client is pretty cool
[21:07] <d4de> though, I seem to have some very decent group of friends anywhere I go
[21:07] <d4de> and actually freinds that do matter ;-)
[21:08] <DigitalFlux> only through IRC ?
[21:08] <d4de> nop in real life
[21:08] <d4de> well some through IRC of course
[21:08] <DigitalFlux> Ah about that life thingy
[21:08] <DigitalFlux> ofc
[21:08] <DigitalFlux> this channel looks lame
[21:09] <d4de> you know what works best for me ... prioritize, establish assets, and plan
[21:09] <d4de> its boring as hell
[21:09] <d4de> have you been on securitychat.org before?
[21:09] <d4de> I'm talking DoD, DHS, Intelligence community, etc.
[21:09] <DigitalFlux> nope
[21:10] <d4de> of course you won't find channels there with the title "DOD" lol ... you just stumble upon people you know :-)
[21:10] <DigitalFlux> interesting ..
[21:10] <DigitalFlux> so when did you get freakish about security techs ?
[21:11] <d4de> you know what's even more interesting? LinkedIn .. I mean this thing just worked
[21:11] <d4de> when I was 14 years old finished my first cryptographic algorithm
[21:11] <d4de> of course it was nothing compared to the algorithms I do now
[21:11] <DigitalFlux> Yup, it used to be super .. and that was before they integrated it with twitter, it's kinda useless for me now !
[21:11] <d4de> http://amrali.se/160/ccrng-schematic-v2/
[21:12] <DigitalFlux> Oh, you climbed the ladder when you were young
[21:12] <d4de> I started coding BASIC on a MSX-170 machine
[21:12] <d4de> that's pre PC era right there
[21:12] <DigitalFlux> I started with a Sincular computer that used cassette tapes :)
[21:13] <d4de> I used to load games and programs off of audio tape cassette
[21:13] <DigitalFlux> But i didn't continue the journey quite right :)
[21:13] <DigitalFlux> LOL !
[21:13] <d4de> oh there you go :-D
[21:13] <DigitalFlux> me too !
[21:13] <d4de> jinx!
[21:13] <d4de> haha ... man, good old days!
[21:13] <DigitalFlux> ROFL, yeah i used to load a game called Hunter bayen in about 30 minutes
[21:14] <d4de> I've known how to clear the motherboard CMOS password when I was in the 5th grade (and I knew few words in English only), I've opened the manual and read it like 10 times
[21:14] <DigitalFlux> That was the only game i had
[21:14] <d4de> and BINGO! lol
[21:14] <DigitalFlux> besides a Basic enterpreter
[21:14] <d4de> I had two bags full of tabs lol
[21:14] <DigitalFlux> haha
[21:14] <d4de> man the culture back then was just AWESOME
[21:15] <d4de> people knew each other back then that had these kind of computers done some scary shit
[21:15] <d4de> I've taken over the central telcom station nearby when I was like 11
[21:15] <DigitalFlux> Oh, yeah i used to dream of stuff like that, never got to do it or to even learn how to do it :)
[21:16] <DigitalFlux> so how come, did you used to communicate a lot with outsides ?
[21:16] <d4de> it seems like you've not been reading a lot of phreak
[21:16] <DigitalFlux> I mean, you didn't Google that !, wait Google was not there yet :)
[21:16] <DigitalFlux> Well, that magazine needs some GFX work man :D
[21:16] <d4de> I've had internet access through the EUN network in 94'
[21:16] <d4de> hah GFX!! lol
[21:17] <d4de> dude, phreak you just read and download the wisdom in your brainz
[21:17] <DigitalFlux> ASCII FTW
[21:17] <d4de> its the one place most visited and sync'ed on by basically all military and intelligence agencies in the world
[21:17] <d4de> shit happens there
[21:17] <DigitalFlux> yeah, i missed a lot
[21:17] <DigitalFlux> alrighty then
[21:18] <d4de> Aleph One's paper on shellcodes was the pioneer for shellcoding
[21:18] <DigitalFlux> let see if they even cared to send e-mail notifications of new stuff
[21:18] <DigitalFlux> or a twitter account, /me hopes
[21:18] <d4de> yeah I doubt it, but I never looked for that.
[21:18] <d4de> well ... if you are on IRC you must hear the rumors about when its going to release
[21:19] <d4de> cuase they don't have an exact release date
[21:19] <DigitalFlux> Wow
[21:19] <d4de> some issues were years apart
[21:19] <DigitalFlux> it still at #68 !
[21:19] <d4de> yes
[21:19] <DigitalFlux> yeah, why is that ?
[21:19] <d4de> that's how intensive each release is
[21:19] <DigitalFlux> that #68 was the last time i check it !
[21:19] <d4de> you didn't read any phrack before, did you now?
[21:19] <DigitalFlux> the world is moving man
[21:19] <DigitalFlux> i did read a couple of articles i think
[21:20] <d4de> well read the whole thing
[21:20] <DigitalFlux> i don't even remember when
[21:20] <d4de> it contains very organized and state of the art articles about certain subjects
[21:20] <d4de> these things take time and effort
[21:20] <DigitalFlux> indeed
[21:20] <d4de> its not just some magazine
[21:21] <DigitalFlux> and that existed in 94 ?
[21:22] <d4de> I believe it existed since 1985
[21:22] <DigitalFlux> oh great, i was just 2 years old then ..
[21:22] <d4de> hah
[21:23] <DigitalFlux> k man, always exciting to have a chat with you, gotta eat something before i disappear out of hunger now :)
[21:23] <DigitalFlux> lets see how that cloud day will go


[01:57] <jgoguen> Bug 397504, would that be Low because the most common IRC commands have GUI alternatives, or Medium because this makes Empathy unusable as an IRC client if commands without GUI alternatives are needed?
[01:57] <ubot4> Launchpad bug 397504 in empathy "Basic IRC commands not working (Karmic)" [Undecided,Confirmed] https://launchpad.net/bugs/397504
[01:58] <hggdh> jgoguen, I would mark it as medium. This was the reason I quit using empathy right now...
[01:58] <micahg> hggdh: shouldn't it be high since empathy will be default in karmic?
[01:59] <hggdh> micahg, yes, you are correct. High it is.
[01:59] <jgoguen> But IRC isn't installed for Empathy by default
[01:59] <jgoguen> Or is that another bug :)
[02:00] <hggdh> heh.
[02:00] <hggdh> BTDNW. (Bloody thing does not work)
[02:00] <jgoguen> +1
[02:01] <hggdh> jgoguen, still, I think micahg is correct. If Empathy is going to be the default, it has to perform
[02:01] <jgoguen> Sounds good, High it is
[02:01]  * hggdh meanwhile still suffers on xchat
[02:03] <hggdh> well, to be honest, this is also because I am used to /this and /that on IRC, and prehaps empathy dev will elect not to use them.
[02:03] <jgoguen> From the upstream bug, I think they're leaning toward "not a bug"
[02:04] <hggdh> to even more honest, this might, perhaps, be also caused by a bit of not-so-kosher wine during dinner. But, of course, this would not be the case (or cause ;-))
[02:04] <jgoguen> Except that there's no replacement for /kick, /ban, /part.../quit and /join are just annoying
[02:04] <micahg> from what everyone said before I don't know what the rush is to have it in karmic
[02:05] <jgoguen> Neither do I, it's behind Pidgin in functionality and stability IMO
[02:05] <jgoguen> And apparently also can't connect to Groupwise servers, which means I can't use it at work...
[02:06] <Pici> Is there at least a /quote or /raw command?
[02:06] <hggdh> micahg, I do not know either. I do know that empathy devs are doing their best, and empathy (or telepathy) does have an interesting future
[02:06] <hggdh> Pici, not one that I could find
[02:07] <jgoguen> Pici: No, only /me works
[02:07] <Pici> :(
[02:07] <hggdh> and barely
[02:07] <jgoguen> The user list doesn't distinguish users from users with voice or ops either
[02:07]  * micahg will stick with Pidgin :)
[02:08]  * hggdh will still stick with <shudder/> xchat. irssi turned out to require more effort than expected
[02:08] <maxb> I actually like xchat. and irssi
[02:09]  * micahg wants to learn irssi so as to always be on :)
[02:09] <hggdh> maxb, get someone to start an encrypted session with you. Then you may reconsider xchat. irssi is cool, just requires a bit of relearning shortkeys, and I was not in the mood for that
[02:09] <maxb> irssi has a builtin proxy module - when I use xchat, I just connect it to my existing irssi session :-)
[02:10] <micahg> hggdh: who would that be that starts encrypted sessions ;)
[02:10] <hggdh> micahg, I would respectfully beg not to answer ;-)
[02:11] <hggdh> maxb, this proxying is cool. I wil reconsider, now
[02:11]  * micahg was inferring his own guilt
[02:11]  * hggdh did not want to throw blame on anyone but the beastly programme
[02:12] <hggdh> program
[02:16] <LimCore> my hard drive still fails...  sata link dies, any ideas? https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/409639
[02:16] <ubot4> Launchpad bug 409639 in linux-meta "sata hard drive connection fails with link is slow to respond, please be patient (ready=0) ; SRST failed (errno=-16) ; hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK" [Undecided,New]
[02:17] <hggdh> LimCore, looking at it
[02:19] <LimCore> I bought 1 TB hard drive,  and linux tell me I have a new 1 TB device, and also a 2 TB one; Oh man if this is true then this is the best hardware shop ever
[02:28] <LimCore> hggdh: I added a comment with a bit more details
[02:30] <LimCore> Also there seem to be.... typos in the /var/log/messages O_o   Perhaps this is another bug being exposed by this bug causing so many errors being logged (thousands at once) ?    Or some memory corruption resulting from, or causing, the SATA problem.   https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/409639/comments/1
[02:30] <ubot4> Launchpad bug 409639 in linux-meta "sata hard drive connection fails with link is slow to respond, please be patient (ready=0) ; SRST failed (errno=-16) ; hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK" [Undecided,New]
[02:36] <LimCore> if any feedback or ideas or tests to do then please comment there (Im idle)
[02:40] <hggdh> LimCore, sorry got a call, back to it now
[02:41] <Slick666> hi all, just wanted to let you folks on the bugs channel that the syracuse are NY loco is having it's own bug jam
[02:41] <Slick666> https://wiki.ubuntu.com/NewYorkTeam/Events/20090808
[02:42] <Slick666> It's kind of a test run of the facility and partly something easy that we can put togeather
[02:42] <Slick666> just thought you guy would get a kick out of it
[02:44] <hggdh> Slick666, good! Consider announcing it on planet (if you have access), and on the mailing lists
[02:46] <hggdh> LimCore, I myself have had two instances of unresponsive SATA, resolved on reboot. There is always the chance yours is caused by a real faulty drive, or SATA hardware, but I really do not know what else you should do
[02:46] <Slick666> I've already hit up the regional mailing lists
[02:46] <Slick666> but I'm missing the "planet" reference
[02:46] <hggdh> LimCore, a temp of 80C is sort of high, but I do not know how this would impact you...
[02:47] <Slick666> oh, http://planet.ubuntu.com/ cool
[02:48] <hggdh> Slick666, planet is the channel Ubuntu member have to publish blogs (although I personally have never used it, I do not think I have much of importance to publish)
[02:48] <hggdh> LimCore, could you try booting with Karmic, and trying it off the liveCD to see how it behaves?
[02:56] <LimCore> hggdh: I could try that in few days
[02:56] <hggdh> cool.
 LimCore, FAR too high    <ceil420> i can barely stand 30 C, personally   <LimCore> wtf?    <ceil420> (oh, you mean hardware)
[02:57] <hggdh> heh
[03:01] <LimCore> hggdh: you think this could be a driver/kernel issue?
[03:02] <hggdh> LimCore, it might be. There were many changes from 2.6.28 to 2.6.31; also, temperature might be a factor (not only CPU temp, but temps around the mainboard)
[03:03] <LimCore> can kernel execute full reboot of a device and it's link, as full as on reboot?
[03:03] <LimCore> "full power cycle" etc
[03:03] <LimCore> or only reset/power switch
[03:04] <hggdh> yes, it can do a cold boot. Power switch is also easily done, if in doubt
[03:04] <LimCore> if yes then  this kernel could  be better at auto-fixing the problemn
[03:04] <LimCore> mhm, I ment,  could it fully reset hdd + sata controller, without restarting system
[03:04] <LimCore> if yes then it should
[03:04] <LimCore> in such case
[03:05] <hggdh> for a while (I think at the beginning of the Karmic cycle) I was getting warn reboots (i.e., no BIOS). Now I get BIOS reboot
[03:05] <hggdh> so if BIOS would reset the controllers, you are good to go. Otherwise, a power cycle is needed
[03:06] <hggdh> ("power off, count to ten, power on again" type. Of course, I would wait longer to allow for capacitors discharge)
[03:51] <hggdh> Esta alma, que sedenta e si não coube,
[03:51] <hggdh> no abismo vos sumiu dos desenganos.
[04:07] <micahg> ping hggdh
[11:26] <gnomefreak> what bug would we file running processes under? example ps aux |grep gdm shows 6. IMHO 6 is a bit high
[11:26] <gnomefreak> someone else has 102 udevd running
[11:27] <ogra> erm
[11:27] <ogra> did you look what processes these 6 are actually ?
[11:27] <ogra> your grep is quite broad
[11:27] <gnomefreak> yes lib bin ect..
[11:28] <ogra> gdm runs a complete gnome session nowadays and was split into multiple binarys
[11:28] <gnomefreak> oh
[11:28] <ogra> (assuming you talk about karmic)
[11:28] <gnomefreak> ogra: yeah
[11:28] <gnomefreak> http://paste.ubuntu.com/248566/
[11:28] <ogra> right, completely new design
[11:29] <kklimonda> gnomefreak: you should see ps aux |grep gvfs ;)
[11:29] <gnomefreak> ok thanks. im guessing 102 udevd processes is too many and file under udevd?
[11:30] <gnomefreak> kklimonda: 6
[11:30] <kklimonda> heh, it's 12 for me :)
[11:31] <gnomefreak> i only have a terminal open
[11:31] <gnomefreak> ok X keeps restarting
[11:31] <gnomefreak> thats bad
[11:32] <gnomefreak> restarting maybe flickering is better word
[16:06] <bddebian> Boo
[19:33] <Chris_S> I have a bug report etiquette question (which I hope is appropriate for here): if a bug I submitted gets its status updated to Invalid, what is the correct/best way to disagree with the new status? Is writing a comment explaining why sufficient, or should I change the status back to New? (This is bug 407459 if anyone wants to look at the specifics.)
[19:33] <ubot4> Chris_S: Error: Could not parse data returned by Launchpad: The read operation timed out
[19:36]  * hggdh kicks ubot4
[19:36] <hggdh> bug 407459
[19:36] <ubot4> Launchpad bug 407459 in procmail "Procmail opens $HOME/.procmailrc before dropping setuid permissions" [Undecided,Invalid] https://launchpad.net/bugs/407459
[19:40] <hggdh> Chris_S: just reopen NEW. It owuld be good if you could provide such an attack^b scenario. I do not have NFSs, so cannot really show it
[19:40] <hggdh> Chris_S: you can also go to #ubuntu-hardened, and discuss it there
[19:42] <Chris_S> Okay, thanks; I've reopened/reset it to New status. I'll look into #ubuntu-hardened too.
[19:43] <Chris_S> (An attack scenario doesn't need NFS, just I think pointing $HOME/.procmailrc to something that has side effects when opened, especially by root.)
[19:47] <hggdh> Chris_S: agreed. But I do not have -- say -- a tape either... and no test system right now I am willing to sacrifice to the gods of correct triage ;-)
[19:53] <ssam> grip has been dropped from karmic (and debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515887 ). should its old bugs be marked invalid (with a message explaining why)?
[19:53] <ubot4> Debian bug 515887 in ftp.debian.org "RM: grip -- RoM" [Normal,Open]
[19:54] <ssam> ditto for the last xmms bug #139754
[19:54] <ubot4> Launchpad bug 139754 in xmms "[GUTSY] XMMS is missing the Flac plugin from repositories" [Undecided,Confirmed] https://launchpad.net/bugs/139754
[20:05] <hggdh> ssam: they may be out of karmic, but still valid on previous supported releases (although the chance of getting a fix is probably low)
[20:08] <ssam> what about xmms, i think that was last in dapper.
[20:11] <hggdh> xmms itself was last on dapper (which is still supported); a series of xmms-* are also available on Gutsy/Hardy; xmms2 seems to have replaced (if indeed they are the same thing) from there on
[20:12] <hggdh> I remember reading something about xmms, I think on the -devel (or -devel-discuss) mailing lists some time ago
[20:12] <ssam> isn't dapper only supported on the server now?
[20:13] <ssam> xmms2 is a rewrite, so the bug would not apply there
[20:14] <hggdh> yes, only on the server (for dapper)
[20:15] <hggdh> so if the bugs are on the desktop, you could go ahead and close them
[20:15] <hggdh> oups
[20:16] <hggdh> ssam: I beg your pardon. bug 139754 was opened against gutsy, so it is a drop indeed
[20:16] <ubot4> Launchpad bug 139754 in xmms "[GUTSY] XMMS is missing the Flac plugin from repositories" [Undecided,Confirmed] https://launchpad.net/bugs/139754
[20:17] <ssam> its confusing, packages.ubuntu.com says does not list a gutsy package for gutsy, only for dapper. is that because gutsy is EOL even though its newer
[20:17] <maxb> yes
[20:18] <ssam> https://launchpad.net/ubuntu/+source/xmms lists a hardy package, and then that its deleted, does that mean it was only in hardy during development
[20:18] <maxb> yes
[20:19] <hggdh> now I would like a question where maxb could answer 'no' ;-)
[20:20] <ssam> is there a such a question, maxb?
[20:20] <ssam> :-)
[20:21] <maxb> yes
[20:21] <hggdh> darn!
[20:22] <hggdh> would you answer no if I asked you to answer yes?
[20:22] <ssam> mental note: in april 2011 close these bugs https://bugs.launchpad.net/ubuntu/+source/grip
[20:23] <hggdh> ssam: you can always ask if it is still an issue for the reporter
[20:26] <ssam> i suspect they have not been fixed. grip upstream version has been at 3.3.1 since 2008
[20:26] <ssam> 2005 sorry
[20:28] <hotblack23> Hi, any xorg specialists here that can take a look at launchpad bug 380009?
[20:28] <ubot4> Launchpad bug 380009 in xorg-server "[Needs quirk] Huge font in GDM on HP Compaq nc8430" [Undecided,New] https://launchpad.net/bugs/380009
[20:29] <hggdh> yes. But the reporter may have gone to a different option. If grip is dead at Debian, and upstream development orphaned/abandoned/went MIA, then -- unless and until someone takes it over, we will drop (have already dropped) it here
[20:34] <ssam> should i do a message along the lines of "Are you still suffering from this issue? Grip is no longer being maintained by upstream or debian, it will be dropped from Karmic (unless someone takes over maintenance), hence the change of this being fixed is small." and set to needs info
[20:35] <ssam> (i reported one of the bugs :-) )
[20:35] <ssam> s/needs info/incomplete/
[21:39] <kamusin> what status should I mark for some report that is not a bug exactly?, actually is a default parameter set in his configuration file (sudo package)
[21:42] <micahg> Well, if it's a support request (i.e. how to configure) you can convert to question
[21:43] <hggdh> kamusin, what is the bug # ?
[21:48] <kamusin> yep but this person think is a bug
[21:48] <kamusin> bug #410022
[21:48] <ubot4> Launchpad bug 410022 in sudo "sudo doesn't propagate $PWD" [Undecided,New] https://launchpad.net/bugs/410022
[21:51] <BUGabundo> hey guys
[21:54] <hggdh> kamusin, I agree this is not a bug. The user can set any environment variables needed to be maintained by editing env_keep
[21:55] <hggdh> you can transform it into a question, as micahg pointed out, and then go ahead and answer it there ;-)
[21:55] <kamusin> okidoki! thanks hggdh
[21:56] <hggdh> you aew welcome, kamusin. Thank you for helping
[21:59] <kamusin> hggdh: no problem sir ;)
[22:32] <grepory> hmmm