[10:12] <tsdgeos> dandrader: there?
[10:15] <tsdgeos> greyback: you there?
[10:15] <dandrader> tsdgeos, yes
[10:15] <greyback> tsdgeos: yep
[10:16] <tsdgeos> greyback: dandrader: do you know what is creating the QTouchEvents? is it the qtmir qpa?
[10:16] <tsdgeos> in the phone
[10:16] <dandrader> tsdgeos, QtEventFeeder
[10:16] <tsdgeos> dandrader: where's the code of that?
[10:17] <dandrader> tsdgeos, src/platforms/mirserver/qteventfeeder.h
[10:17] <dandrader> tsdgeos, src/platforms/mirserver/qteventfeeder.cpp
[10:17] <tsdgeos> in qtmir?
[10:17] <dandrader> tsdgeos, yes
[10:17] <tsdgeos> oki tx
[10:21] <tsdgeos> dandrader: greyback: can i compile qtmir on the phone with this qmake or do i need some special flags?
[10:22] <dandrader> tsdgeos, I always build it on the phone
[10:22] <dandrader> tsdgeos, with qmake. nothing special
[10:22] <tsdgeos> ok, no special flag, just run qmake, good
[10:22] <dandrader> tsdgeos, but I pass it CONFIG+=no_tests to speed up the build
[10:22] <tsdgeos> oki
[10:22] <dandrader> tsdgeos, check the readme
[10:23] <tsdgeos> sorry ^_^
[10:24] <dandrader> tsdgeos, I also pass it PREFIX=/usr, although I'm not sure it it's really needed
[10:26] <greyback> dandrader: for qmake, that's not needed
[10:29] <Saviq> or!
[10:29] <Saviq> x-build!
[10:30] <Saviq> the cmake-based qtmir is migrating now ;)
[10:40] <pstolowski> tsdgeos, hey, there is conflict in https://code.launchpad.net/~aacid/unity8/list_on_bottom_swipe, can you update?
[10:40] <tsdgeos> dandrader: if i put a qDebug in QtEventFeeder::dispatchMotion should i see it in the unity-dash.log if it's the dash i'm pressing over?
[10:41] <tsdgeos> pstolowski: hmmm
[10:41] <tsdgeos> $ bzr merge ../unity8/
[10:41] <tsdgeos> Nothing to do.
[10:41] <tsdgeos> maybe i have not pushed?
[10:41] <dandrader> tsdgeos, no
[10:41] <dandrader> tsdgeos, it will be in unity8.log
[10:41] <tsdgeos> ok
[10:41] <tsdgeos> pstolowski: it's pushed
[10:41] <tsdgeos> pstolowski: conflict with what?
[10:41] <dandrader> tsdgeos, QtEventFeeder lives in the unity8 process. it takes an event out of mir and puts it into unity8's QQuickWindow
[10:42] <tsdgeos> dandrader: but unity8-dash has a different window, how events get there?
[10:42] <dandrader> tsdgeos, if you wanna track the input events that unity8 sends to client apps check MirSurfaceItem in qtmir
[10:42] <tsdgeos> dandrader: well i have an input event that "seems" wrong
[10:42] <tsdgeos> i'm trying to track where goes wrong
[10:42] <tsdgeos> or if it's just sent wrong by autopilot
[10:43] <tsdgeos> ok, tx for the pointers
[10:44] <pstolowski> tsdgeos,  debian/control
[10:44] <tsdgeos> pstolowski: merging which branches?
[10:45] <dandrader> tsdgeos, src/modules/Unity/Application/mirsurfaceitem.cpp:615
[10:45] <pstolowski> tsdgeos, trunk. unity8 just landed
[10:45] <dandrader> tsdgeos, that's where unity8 sends a mir input event down to the client app
[10:45] <pstolowski> tsdgeos, i mean, another chanes in unity8 landed
[10:46] <tsdgeos> pstolowski: ah unity8 just landed
[10:46] <tsdgeos> k
[10:46] <dandrader> oh... qtmir trunk now uses CMake
[10:47] <greyback> yep, proper cros building now possible
[10:47] <tsdgeos> noooooooooooooo
[10:47] <dandrader> greyback, Saviq, qtmir README still talks about qmake :)
[10:47] <tsdgeos> nooooooooooooooooo
[10:48]  * tsdgeos shakes fist
[10:48] <greyback> d'oh
[10:48] <tsdgeos> 107 tags updated.
[10:48] <tsdgeos> Saviq: ↑
[10:48] <Saviq> mterry!!!!
[10:48] <dandrader> greyback, do we have a CONFIG+=no_tests equivalent?
[10:48] <greyback> dandrader: probably not
[10:48] <dandrader> grrrrr
[10:49] <greyback> sorry
[10:49] <Saviq> easy to add
[10:49] <Saviq> copy/paste from usc
[10:49] <tsdgeos> pstolowski: ok, merged
[10:51] <pstolowski> tsdgeos, thanks
[10:53] <tsdgeos> mzanetti: merge your branches plz
[10:53] <tsdgeos> Text conflict in debian/unity8-common.install
[10:53] <tsdgeos> 1 conflicts encountered.
[10:53] <mzanetti> again :D
[10:53] <mzanetti> tsdgeos: ack, will do. thanks
[11:08]  * tsdgeos keeps digging up
[11:08] <tsdgeos> dandrader: who calls QtEventFeeder::dispatch ?
[11:11] <tsdgeos> i guess mir
[11:11] <dandrader> tsdgeos, yes
[11:11]  * tsdgeos ends where he didn't want to end
[11:15] <Saviq> greyback_, dandrader, I had to overwrite lp:qtmir and lp:qtmir/gles
[11:15] <Saviq> it has dome dumb empty commits from the train on top
[11:16] <Saviq> s/has/had/
[11:16] <Saviq> s/dome/some/
[11:16] <greyback_> ok
[11:30] <mzanetti> greyback_: hey, I had to push some change to the uninvert-launcher branch
[11:30] <mzanetti> greyback_: mind reapproving?
[11:30] <tsdgeos> meh i want to build mir but don't have enough space in the phone :/
[11:30] <greyback_> mzanetti: ok looking
[11:30] <mzanetti> greyback_: so the issue is that the launcher changed in trunk, which I merged
[11:30] <mzanetti> greyback_: unfortunately had to clip
[11:31] <greyback_> naughty
[11:35] <dandrader> tsdgeos, to the ubuntun image resize trick!
[11:35] <dandrader> tsdgeos, and use mako, not krillin
[11:35] <tsdgeos> dandrader: i'm on mako, my krillin has enough space :D
[11:36] <dandrader> if you say so
[11:36] <greyback_> tsdgeos: I've not rebuilt mir for phone in a while, but I know the team use their own chroot-based Xcompile scripts
[11:36] <Saviq> tsdgeos, for when x-building doesn't work, I started using a chroot in $HOME on the device
[11:36] <tsdgeos> right
[11:36] <tsdgeos> that makes sense-ish
[11:36] <Saviq> can get you a rootfs
[11:36] <dandrader> tsdgeos, just in case http://paste.ubuntu.com/9381191/
[11:37] <Saviq> yeah that's not gonna work on krillin
[11:37] <Saviq> we have real partitions there
[11:37]  * Saviq recommends chroots
[11:37] <Saviq> they survive flashing etc.
[11:37] <Saviq> and it's real easy to debootstrap into a folder
[11:38] <mzanetti> tsdgeos: merged 'em all
[13:47] <dandrader> Saviq, so have 107 stale tags leaked into unity8?
[13:47] <Saviq> dandrader, yes, mterry managed to land them yesterday
[13:47] <dandrader> Saviq, your script doesn't seem to detect them
[13:48] <Saviq> dandrader, you might not have the latest instalment http://people.canonical.com/~msawicz/unity8/strip-tags.py
[13:48] <Saviq> this should remove all the invalid tags
[13:48] <dandrader> Saviq,  yeah, now it works
[14:36] <seb128> where is the app details page come from in unity8/touch (the one you get when you long press on an app icon)
[14:41] <Saviq> seb128, the click store in general
[14:41] <Saviq> seb128, falling back to the .desktop file
[14:41] <seb128> thanks
[14:48] <Saviq> mzanetti, think you could prep a vivid silo? I'd want to focus on the first ota landing
[14:49] <Saviq> mzanetti, don't build yet, list_on_bottom_swipe is migrating already, but it's blocked in proposed for a while still
[14:50] <mzanetti> Saviq: sure. is there a spreadsheet entry already?
[14:50] <Saviq> mzanetti, no
[14:52] <mzanetti> ack
[14:55] <tsdgeos> mzanetti: what do you mean in https://code.launchpad.net/~aacid/unity8/deparment_jumping/+merge/243639 ?
[14:56] <mzanetti> tsdgeos: I open the store and even though the department selection says "all" I only see the music section
[14:56] <tsdgeos> mzanetti: in the navigation list? or as part of the results?
[14:56] <mzanetti> tsdgeos: results
[14:56] <tsdgeos> mzanetti: the list is still full of stuff?
[14:56] <mzanetti> no, only has the media section too, and "all"
[14:58] <tsdgeos> weird
[14:58] <tsdgeos> i'll check
[14:58] <tsdgeos> maybe it really needs the scopes shell part
[15:00] <Saviq> greyback_, can you have a look at bug #1394645 please
[15:01] <ubot5`> bug 1394645 in The Webapps-core project "OSK doesn't appear after OA login" [Critical,Confirmed] https://launchpad.net/bugs/1394645
[15:04] <greyback_> Saviq: sure
[15:13] <Saviq> greyback_, it seems from the last comments like we might be on the hook there
[15:18] <greyback_> Saviq: yeah I think you're right
[15:27] <tsdgeos> Cimi: you're reviewing my debug output to try to find what's wrong :D
[15:27] <tsdgeos> sorry should have marked as DO NOT REVIEW YET
[15:28] <Cimi> tsdgeos, I saw you filled the description so I thought it was good to go :)
[15:43] <kgunn> Saviq: i don't think these are unity8....do you agree ?
[15:43] <kgunn> bug 1398427
[15:43] <ubot5`> bug 1398427 in qtmir (Ubuntu RTM) "Can't use earphone to answer or disconnect a call" [Critical,In progress] https://launchpad.net/bugs/1398427
[15:43] <kgunn> bug 1394645
[15:43] <ubot5`> bug 1394645 in The Webapps-core project "OSK doesn't appear after OA login" [Critical,Confirmed] https://launchpad.net/bugs/1394645
[15:43] <Saviq> kgunn, the latter one is between u8 and qtmir it seems
[15:43] <Saviq> kgunn, the former we're debating, have asked for design feedback to start with
[15:44] <Saviq> kgunn, they're "ours" in the sense there might be little or more work in it
[15:44] <Saviq> for us
[15:46] <tsdgeos> Cimi: ok, you can review https://code.launchpad.net/~aacid/unity8/autopilot_drag_more/+merge/243367 now, but better let it run in CI and see if it passes
[15:46] <tsdgeos> i had it running on the phone for 45 minutes and succeded all the time so is looking good
[15:46] <tsdgeos> but you never know
[15:48] <Cimi> tsdgeos, if it is a workaround, add a comment linking the bug
[15:48] <tsdgeos> i can't
[15:48] <tsdgeos> i have not filed the bug yet
[15:48] <Cimi> ok so file it :P
[15:48] <Cimi> you said filed in the commit :P
[15:49] <tsdgeos> i am a lier
[15:49] <tsdgeos> you got me
[15:49] <Cimi> :D
[15:50] <Cimi>  * Did you make sure that your branch does not contain spurious tags?
[15:50] <Cimi> hah
[15:50] <Cimi> I think I lied sometimes on that
[15:50]  * Cimi slaps himself
[15:55] <tsdgeos> Cimi: happier now? https://code.launchpad.net/~aacid/unity8/autopilot_drag_more/+merge/243367
[15:55] <Cimi> tsdgeos, the comment was to be added in the code :P
[15:56] <tsdgeos> that's nonsense
[15:56] <tsdgeos> what do we have commit logs for then?
[15:56] <Saviq> mterry, looks like bug #1363400 is coming your way
[15:56] <ubot5`> bug 1363400 in unity8 (Ubuntu) "[wizard] allows to "Continue" without connecting to network" [High,Triaged] https://launchpad.net/bugs/1363400
[15:56] <Cimi> tsdgeos, why? we usually add FIXME in code for this reason
[15:56] <Cimi> when we workaround things
[15:56] <tsdgeos> which i complain every single time we do that
[15:56] <tsdgeos> if we're going to make our commit logs useless we may as well keep them empty
[15:57] <mterry> hmm, Cimi knows that code better than me -- do you know what's going on with the above bug? ^
[15:57] <tsdgeos> Cimi: but sure, i'll add it there
[15:57] <tsdgeos> not that i care :D
[15:57] <Cimi> tsdgeos, I am happy both ways, just we need to keep going with the same rule
[15:58] <Cimi> let's discuss with saviq and others
[15:58] <Cimi> mterry, there is a stupid counter for wifi
[15:58] <Cimi> mterry, we need more capability from network indicator, like a value saying "wifi is connected"
[15:58] <mterry> Cimi, it doesn't tell us that?
[15:59] <Cimi> mterry, it didn't when I wrote that code iirc
[15:59] <tsdgeos> Cimi: added
[15:59] <mterry> Cimi, can I assign the bug to you?
[16:00] <Cimi> mterry, is not on me...
[16:00] <mterry> Cimi, right, but someone needs to do the u8 side and make sure the network side gets done
[16:00] <Cimi> mterry, ok then
[16:01] <Cimi> mterry, just looked at the code
[16:01] <Saviq> Cimi, if we need more from some backends, add a task for it
[16:01] <Cimi> Saviq, yeah, months ago answer was "not a priority"
[16:02] <Cimi> Saviq, will chase again
[16:02] <mterry> Cimi, thanks!
[16:03] <Saviq> Cimi, it just became a priority as the bug is targeted for the milestone in 2 weeks
[16:03] <Saviq> Cimi, so you got some push behind you this time
[16:05] <mterry> Saviq, if it's targetting rtm, the code change will be in u-s-s
[16:05] <Saviq> mterry, ah right
[16:05] <Saviq> mterry, this is going to be a tricky one
[16:05] <Saviq> mterry, so it affects unity8 (Ubuntu) but u-s-s (RTM
[16:05] <mterry> Saviq, heh, right
[16:07] <Saviq> greyback_, fix for bug #1365673 still on hold?
[16:07] <ubot5`> bug 1365673 in unity8 (Ubuntu) "/usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene:6:qt_message_fatal:QMessageLogger::fatal:UbuntuClientIntegration::UbuntuClientIntegration:UbuntuMirClientIntegrationPlugin::create:loadIntegration" [High,Confirmed] https://launchpad.net/bugs/1365673
[16:07] <greyback_> Saviq: yeah, I suspect it breaks something else
[16:08] <Saviq> greyback_, any chance for a fix for 18.12?
[16:09] <greyback_> Saviq: well if it's some other issue (which this far I've been unable to determine/reproduce) then unlikely. If it's just that, then looks good
[16:09] <Saviq> greyback_, ok, I'll leave it in for that milestone for now then
[16:11] <tsdgeos> mzanetti: you tried  lp:~aacid/unity8/deparment_jumping  on rtm or vivid?
[16:13] <mzanetti> tsdgeos: vivid
[16:15] <tsdgeos> ok
[16:20] <dandrader> mterry, got an MP for you to review https://code.launchpad.net/~dandrader/unity8/greeterRefactoring/+merge/243823
[16:21] <dandrader> mterry, I cherry picked it out of the shellRotation work
[16:21] <mterry> dandrader, oof ok
[16:21] <dandrader> mterry, so it can be reviewed separately.
[16:21] <mterry> nice, thanks
[16:25] <Saviq> tsdgeos, I'll wait for moreAsyncDash before landing the other bits in rtm, ok?
[16:25] <tsdgeos> Saviq: sure
[16:26] <tsdgeos> Cimi: actually you want to give it more time on https://code.launchpad.net/~aacid/unity8/moreAsyncDash/+merge/241524 or ?
[16:26] <Cimi> tsdgeos, ccan we retrigger ci?
[16:26] <tsdgeos> sure
[16:27] <Cimi> so for monday we are ok to go?
[16:27] <tsdgeos> hmmm
[16:28] <tsdgeos> actually did i lose the hability to retrigger builds?
[16:28] <tsdgeos> Saviq: any idea? ↑
[16:29] <Saviq> tsdgeos, seems I have, too
[16:29] <tsdgeos> Cimi: so no, can't retrigger a build :D
[16:29] <tsdgeos> i'll merge
[16:29] <Saviq> tsdgeos, ah, it's all the network etc. issues in CI
[16:29] <tsdgeos> that should trigger one
[16:29] <Saviq> tsdgeos, it won't
[16:29] <Cimi> tsdgeos, great
[16:29] <tsdgeos> oh :/
[16:29] <Cimi> ah
[16:29] <Saviq> tsdgeos, there's still issues in the lab they're working on
[16:33]  * greyback_ hates that QtCreator just fails to open cmake project if a dependency is missing
[16:49] <Saviq> greyback_, +1, but I'm not sure it's QtC's fault.., cmake just doesn't generate the list of files that QtC uses then
[16:49] <Saviq> (I think)
[16:50] <greyback_> Saviq: sure I get that, but that's a technical reason which I don't hugely care about. Prompt me, force cmake to generate as much as it can, and disable building
[16:50] <greyback_> then I can still read & edit code
[16:50] <Saviq> maybies
[16:59] <Saviq> greyback_, btw, seems kgunn threw bug #1394645 josharenson's way
[16:59] <ubot5`> bug 1394645 in The Webapps-core project "OSK doesn't appear after OA login" [Critical,Confirmed] https://launchpad.net/bugs/1394645
[16:59] <greyback_> Saviq: ok
[16:59] <kgunn> unless greyback_ you wanna give josharenson an early christmas present :)
[16:59] <kgunn> and just fix it
[16:59] <josharenson> :-D
[17:00] <greyback_> will see
[17:00] <josharenson> I have another question for you greyback_ before you go eow, gimmie a min
[17:00] <greyback_> not sure where focus has gone to
[17:00] <greyback_> ok
[17:07] <josharenson> greyback_ so current screenshot logic (the actual screengrab) is handled in qml now...
[17:07] <josharenson> so does USC/mir have the ability to take screenshots already?
[17:08] <greyback_> josharenson: it does, just via a different mechanism.
[17:08] <josharenson> greyback_ I figured.. ok ill go look for it
[17:09] <greyback_> josharenson: have a look at mir::scene::Session::take_snapshot
[17:09] <josharenson> cool
[17:10] <greyback_> an example of it being used is in qtmir: src/modules/Unity/Application/applicationscreenshotprovider.cpp
[17:13] <josharenson> ack, thanks
[17:18] <josharenson> hummm so if screenshots are handled in USC, how will the user receive feedback
[17:20] <greyback_> josharenson: what feedback should the user get? Noise being played? Screen flash?
[17:20] <josharenson> greyback_ yes
[17:20] <josharenson> :-p
[17:20] <josharenson> greyback_ also, I assume it should be encoded via something like libping rather than being converted to a QImage
[17:21] <josharenson> libpng
[17:21] <mzanetti> josharenson: QImage::saveToFile()
[17:22] <josharenson> mzanetti, trying to avoid the use of qml in usc, unless that isn't an issue
[17:22] <josharenson> well qy
[17:22] <josharenson> qt*
[17:22]  * josharenson can't type today
[17:23] <greyback_> josharenson: I didn't know you could use Qt. You can use the qmultimedia stuff to play back sound - not sure if it'll work as root user, but one way to find out
[17:23] <greyback_> the white flash, well, 1 form of feedback is probably enough? Sound should do it, no (sorry hearing-impaired people)?
[17:23] <josharenson> greyback_ trying not to use Qt....
[17:24] <greyback_> josharenson: then you've hard work ahead of you :(
[17:24] <greyback_> can probably use pulseaudio C library to play sound
[17:24] <josharenson> greyback_ is there any reason not to use qt? kgunn had asked me about it and I told him I would avoid it
[17:24] <mzanetti> josharenson: there's already Qt in there
[17:24] <mzanetti> at least it links qtcore and qtdbus
[17:25] <josharenson> mzanetti, so... any disadvantage to adding more? Just trying to keep screenshots shell agnostic
[17:26]  * greyback_ might've heard that people wanted to remove Qt dependency from USC
[17:26] <greyback_> kgunn: ^^ any truth to that?
[17:26] <josharenson> greyback_ is there any way shell can listen to USC for events?
[17:27] <greyback_> josharenson: via dbus would be only way
[17:27] <josharenson> greyback_ thats not bad... then any shell could listen for the screenshot dbus signal and notify the user however it wants
[17:28] <greyback_> true
[17:28] <josharenson> and libpng could, I assume, save the raw pixel data to $USER
[17:28] <josharenson> well after encoding
[17:29] <greyback_> well if you have qt, I don't see why you shouldn't just use it
[17:29]  * mzanetti is a bit lost here
[17:30] <josharenson> mzanetti, I guess the tl;dr is I want to move screenshot logic entirely to USC and minimize (or not at all) use of Qt
[17:31] <mzanetti> yeah... I understand that... did anyone tell you to avoid Qt?
[17:32] <josharenson> mzanetti, kgunn had asked me something like "will moving screenshots to usc mean there will be more qt in usc?"
[17:32] <josharenson> so I assumed it was discouraged
[17:34] <mzanetti> ah... you I guess you'll have to clarify if that's true. would be news to me.
[17:36] <kgunn> mzanetti: i don't know if it's a completely bad thing...but there was some reason we were thinking we wanted to pull qml out of u-s-c
[17:36] <kgunn> i guess more of a "is this really a necessary dependancy?" kind of thot
[17:36] <kgunn> alan_g: AlbertA ^
[17:38] <alan_g> AIUI there were security concerns about Qt in a privileged task. (But I wasn't directly involved in those discussions)
[17:41] <AlbertA> kgunn: josharenson: why move screenshots to USC?
[17:41] <greyback_> kgunn: alan_g: whatever these "security concerns" are, the other side of the argument should be development time and convenience. the phrase "security concerns" always sounds like FUD to me
[17:41] <AlbertA> I thought we convinced ourselves it was not a good idea for it to be in USC
[17:42] <kgunn> AlbertA: but why ?
[17:42] <AlbertA> kgunn: well one reason was encrypted user folders
[17:42] <kgunn> i recall the conclusion, but not the reason
[17:43] <mzanetti> hmm... I guess that's a good point
[17:43] <AlbertA> kgunn: and you would be screenshotting the root server
[17:43] <josharenson> AlbertA, was because we wanted to switch screenshots to power + volume, and power key was in USC
[17:43] <mzanetti> AlbertA: so the reason this happens is because we thought using the power key would be a better idea than up/down
[17:44] <kgunn> e.g. workingn around volume notification is hard+hacky
[17:44] <kgunn> in shell
[17:44] <mzanetti> but I can see the point about moving the shotting logic to usc might be a bad idea
[17:44] <kgunn> so expose shell to power key instead ?
[17:44] <AlbertA> mzanetti: kgunn: ok...but how would volume + power key help? doesn't it still popup the volume notification?
[17:45] <kgunn> usc would filter i suppose
[17:45] <mzanetti> AlbertA: power + volume would help though
[17:45] <mzanetti> yeah, exposing the power key to unity might be way to go
[17:45] <josharenson> What if we just added the delay to volume key presses (and cancel on release) as we talked about earlier
[17:46] <kgunn> hacky
[17:46] <kgunn> mainly...but i thot it would work
[17:46] <AlbertA> mzanetti: sorry I still don't get it...how does power + volume help? I mean the volume notification comes in during a volume press
[17:46] <josharenson> kgunn, we should do that anyway as to make the button press order independent
[17:46] <mzanetti> AlbertA: well, we trigger the notification in the shell if the volume key is pressed down
[17:46] <kgunn> josharenson: don't have to convince me :)
[17:46] <alan_g> greyback_: if someone has to vet all the Qt code that could slow things a lot
[17:47] <mzanetti> AlbertA: but we can if() that with isPowerButtonPressed
[17:47] <greyback_> alan_g: we rest a huge percentage of the platform on qt
[17:47] <AlbertA> mzanetti: aaahh ok...
[17:48] <greyback_> if the policy is to avoid using qt for root-user processes, then there'll be a development time cost
[17:48] <AlbertA> greyback_: there's only a tiny bit of QT in USC, which can easily be replaced with dbus-cpp and process-cpp
[17:48] <alan_g> greyback_: I'm speculating - as I said I wasn't involved in the discussions
[17:49] <greyback_> AlbertA: sure, but I'm asking if doing that is worth the trouble
[17:50] <AlbertA> mzanetti: josharenson: well anpok has a branch that kinda exposes the power key stuff through dbus, but it needs some work
[17:50] <alan_g> Anyway "don't use Qt in USC" dates from the "previous administration". We might want to check current thinking.
[17:50] <AlbertA> mzanetti: josharenson: including disabling taking action on power key presses
[17:50] <mzanetti> alan_g: ah... I thought that would be a new thing... would have surprised me
[17:50] <AlbertA> greyback_: well there's already a desire to refactor USC
[17:51]  * josharenson notes that could be helpful with orientation sensors as well
[17:51] <AlbertA> greyback_: that would just be part of that refactoring
[17:51] <mzanetti> AlbertA: josharenson: yes, that sounds like the way to go
[17:51] <camako> Last time I asked why we have the nested configuration, the response was because we don't trust Qt, whereas, say, Google uses trusted code in their "shell".
[17:51] <greyback_> AlbertA: ok great, then this is a good time to decide to use Qt in USC, or not. Mixing Qt and other libs is wasteful
[17:52] <AlbertA> greayback_: right!
[17:52] <mzanetti> but seriously... doing everything ourselves can't be more secure
[17:52] <josharenson> ok so, keep screenshots in shell, but use power key?
[17:53] <mzanetti> josharenson: yeah
[17:53] <josharenson> mzanetti, ok follow up question...\
[17:53] <AlbertA> mzanetti: josharenson: I mean as a bandaid pending anpok's work...
[17:53] <alan_g> mzanetti: we do as little as possible in USC
[17:53] <greyback_> kgunn: if security/trust is the main reason against Qt in USC, can we have a meeting to discuss this topic with some security team people?
[17:53] <josharenson> mzanetti, you are ok with adding a delay to the notification onVolumeKeyPressed, but canceling the delay onVolumeKeyReleased?
[17:54] <AlbertA> mzanetti: josharenson: just have USC not take action on power key presses if a volume key is also currently pressed down
[17:54] <josharenson> so you can do Vol + Power || Power + Vol for a screenshot
[17:54] <greyback_> kgunn: just so we make the decision clear for all
[17:55] <mzanetti> josharenson: getting away with any delay/timers is the main thing we're doing this...
[17:55] <josharenson> AlbertA, do we support holding VolumeDown + Power for a hard reset?
[17:55] <mzanetti> josharenson: I guess Power+Vol, in that order, is enough
[17:55] <josharenson> mzanetti, ok so you think we should keep the screenshot button sequence order dependent...
[17:55] <josharenson> ok
[17:55] <AlbertA> josharenson: it should be button sequence independent
[17:55] <mzanetti> AlbertA: :D
[17:56] <josharenson> impossible to do without some kind of delay
[17:56] <AlbertA> josharenson: yo can know if a volume key is currently pressed and not released
[17:56] <josharenson> I know
[17:56] <mzanetti> AlbertA: but... then we need a delay, and we don't want to delay the volume notification that everyone uses, for the screenshot feature that noone uses
[17:56] <josharenson> but if you want to display the notification without a delay, then it will always be in screenshots
[17:56] <AlbertA> josharenson: oh yeah heh
[17:57] <josharenson> so you get delay, or order dependence... I'll implement order dependence, but make it easy to switch
[17:57] <AlbertA> josharenson: well actually maybe we can change USC so that it takes action on power key release rather than press
[17:58] <josharenson> AlbertA, but don't you hold power key for shutdown?
[17:59] <AlbertA> josharenson: yeah...I guess the 2s delay is too short....
[18:00] <AlbertA> I remember now why I avoided the power key in the first place :
[18:00] <josharenson> ok, doing it the mzanetti way, and I'll add you all as reviewers so you can have a final argument ;-)
[18:00] <AlbertA> :)
[18:00] <josharenson> ha
[18:00] <mzanetti> :D
[18:02] <AlbertA> mzanetti: josharenson: so it's too convoluted to tell the volume notification to dissappear?
[18:02] <kgunn> ah good...didn't miss anything
[18:03] <josharenson> AlbertA, thought of that... but what if you WANT the volume notification in the screenshot
[18:04] <AlbertA> josharenson: :) well then there's nothing to change
[18:04] <josharenson> lol
[18:04] <mzanetti> AlbertA: you might only want it in the pic *sometimes*
[18:04] <mzanetti> :D
[18:05] <mzanetti> no?
[18:05] <josharenson> yeah
[18:05] <AlbertA> mzanetti: make it a system settings option ;)=
[18:05] <josharenson> 99% of the time you don't want it... but you might want to show someone how loud you are listening to a song at
[18:05] <mzanetti> AlbertA: requires it's setting in the welcome wizard, even
[18:07] <AlbertA> mzanetti: josharenson: so the main obstacles are, if power key press should come first, then how can USC know to ignore taking action? but it's the opposite in the shell....
[18:07] <AlbertA> that means USC has to take actions on power key release, except for holding power key down for a period of time...
[18:07] <josharenson> AlbertA, you have to assume that the delay for a screenshot is shorter than that for shutdown
[18:08] <josharenson> so.. bad
[18:08] <AlbertA> then in that case the user has to race agains the 2S limit before the shutdown dialog comes in
[18:08] <mzanetti> AlbertA: yeah, that's already happening afaik
[18:08] <mzanetti> AlbertA: you only turn the screen off on release
[18:08] <mzanetti> AlbertA: so if then a vol button comes in, we'd need to cancel the shutdown menu
[18:09] <AlbertA> mzanetti: oh true....
[18:09] <mzanetti> actually... the shutdown menu is already in the shell, so no problem with that
[18:10] <mzanetti> it's be nice to cancel the screen blanking on release though
[18:10] <AlbertA> mzanetti: right...
[18:10] <mzanetti> how do we cancel the screen blanking onRelease when the shutdown menu opens?
[18:10] <mzanetti> isn't it just setting event.accepted=true in the shell?
[18:11] <josharenson> I'm assuming this is why screenshot currently doesn't involve the power key
[18:11] <AlbertA> mzanetti: you would still race agains the 5sec shutdown timeout too though...but 5s should be enough time for the user to get a vol key in there and cancel that in USC as well
[18:11]  * josharenson checks android behavior
[18:11] <AlbertA> mzanetti: there's already some logic in USC
[18:12] <AlbertA> to ignore power key presses within the 2sec window :)
[18:13] <greyback_> how about something different? if you hold power & tap on the screen, it takes a screenshot?
[18:15] <josharenson> greyback_ so do you disable all other touch events when power is down?
[18:15] <mzanetti> greyback_: doesn't really solve that issue though
[18:15] <AlbertA> greyback_: I think you could probably get spurious screenshots while trying to shut off the phone
[18:15] <mzanetti> and you still need to cancel the screen blanking
[18:15] <josharenson> or if you had a fullscreen app, and touching the screen changed its state in any way, the screenshot would not be what the user expected
[18:15] <greyback_> thinking out of the box here
[18:15] <mzanetti> AlbertA: so that new upcoming api will allow us to do that?
[18:16] <mzanetti> in that case, lets do it properly when we can...
[18:17] <AlbertA> mzanetti: well here's the branch: https://code.launchpad.net/~andreas-pokorny/unity-system-compositor/expose-powerkey-state-and-screen-toggle-controller-interface/+merge/240834
[18:17] <AlbertA> anpok: ^
[18:19] <AlbertA> mzanetti: you could potentially receive power key press, receive volume key press, disable screen toggling, take screenshot, and renable screen toggling after getting power key release
[18:20] <AlbertA> seems a bit dangerous though...as in....if abused or not done right, the user may not be able to shut off the screen
[18:20] <AlbertA> so maybe the API should be just disable screen toggling until the next power key release
[18:23] <mzanetti> AlbertA: yeah... sounds about right
[18:24] <mzanetti> although I think it wouldn't be that risky to disable and re-enable it in unity...
[18:39] <anpok> AlbertA: aye - still need to rework it


[00:02] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [sync] (focal-proposed) [1.173.2~20.04.1]
[00:02] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [sync] (bionic-proposed) [1.173.2~18.04.1]
[01:55] <rs2009> vorlon: looks like snaps are no longer getting installed: https://launchpadlibrarian.net/625309274/buildlog_ubuntu_kinetic_amd64_ubuntu-unity_BUILDING.txt.gz
[03:19] <vorlon> rs2009: I did a test build with -proposed enabled; livecd-rootfs still needs to migrate to the release for it to work in daily builds
[03:20] <vorlon> and it looks like I might need to fix some autopkgtests for that to happen
[03:20] <vorlon> rs2009: ah no the autopkgtests were failing for the same reason the ubuntu daily images were failing.  I'll retrigger the autopkgtests now
[23:53] <Eickmeyer> Apparently all .iso image builds are stalled.


[01:13] <LjL> wasn't price british?
[01:14] <Tm_T> no?
[01:14] <Seeker`> LjL: huh?
[01:14] <LjL> i dunno i think i kind of confuse yall english speakers
[01:15] <Tm_T> like me?
[01:15] <Seeker`> :P
[01:15] <Seeker`> I speak proper English, I do
[01:16] <LjL> Tm_T: yääs lääik yööu
[01:17] <Seeker`> how much more testing do the floodbots require?
[01:17] <Tm_T> Seeker`: until you go nuts
[01:18] <ubotu> In #xubuntu, somerville32 said: !icons-#xubuntu is <alias> xfce-themes
[01:18] <LjL> Seeker`: until nalioth says they don't need more :P
[01:18] <LjL> yes, also until you go nuts
[01:18] <LjL> both
[01:18] <LjL> related
[01:19] <nalioth> don't worry, Seeker`.  i'm sure they can be programmed to randomnly ping you with dictionary entries after they go live
[01:21] <LjL> Etymology:
[01:21] <LjL> Middle English seken, from Old English sēcan; akin to Old High German suohhen to seek, Latin sagus prophetic, Greek hēgeisthai to lead
[01:21] <LjL> Date:
[01:21] <LjL> before 12th century
[01:21] <LjL> Seeker`: you're way dead, go away
[01:22] <Tm_T> ?
[01:22] <LjL> no 12th century ghosts are allowed here
[01:22] <Seeker`> aww
[01:22] <Seeker`> but I was ahving fun! :P
[01:23] <Seeker`> Tm_T: You are assuming that i'm not nuts already?
[01:23] <Tm_T> ahving?
[01:23] <Tm_T> Seeker`: not enough
[01:23] <Seeker`> pfft, you wont let a 900 year old ghost off some typos?
[01:23] <Tm_T> nope, sorry
[01:23] <Seeker`> :(
[01:24] <LjL> Seeker`: thou shalt not make typoes
[01:24]  * Seeker` sulks
[01:25] <ubotu> inversekinetix called the ops in #ubuntu ()
[01:26] <Tm_T> LjL: hmmh
[01:28] <Seeker`> well, that was odd
[01:30] <LjL> Tm_T: palyndrome mumbling!
[01:30] <Tm_T> true
[01:32] <ubotu> In #xubuntu, somerville32 said: !xfce-icons is <reply>  To install icons, unpack them to ~/.icons/ - Visit http://www.xfce-look.org/ for all kinds of eyecandy for your Xfce4 desktop! - See also !themes for other GNOME theme sites
[02:10] <LjL> !xfce-icons is <reply>  To install icons, unpack them to ~/.icons/ - Visit http://www.xfce-look.org/ for all kinds of eyecandy for your Xfce4 desktop! - See also !themes for other GNOME theme sites
[02:10] <ubotu> I'll remember that, LjL
[02:11] <poeloq> hi again
[02:11] <poeloq> is it possible to add to ubotu database?
[02:12] <LjL> poeloq, not directly, we have to check the submitted factoids - but yeah just tell ubotu "x is y" and it'll be reviewed
[02:13] <poeloq> LjL: how do i tell ubotu x is y ? ;)
[02:13] <crdlb> LjL: lies! y is a totally different letter :(
[02:13] <crdlb> ubotu: x is y
[02:13] <ubotu> In #ubuntu-ops, crdlb said: ubotu: x is y
[02:14] <LjL> ubotu: x is historically the greek letter χ, which in western alphabets, which lacked an aspirate, came to be used in place of eastern ξ, to indicate the sound sequence "ks".
[02:14] <ubotu> But x already means something else!
[02:14] <LjL> crdlb: happy?
[02:14] <crdlb> lol
[02:20] <ubotu> In #ubuntu, poeloq said: ubotu: !Atheros is is a developer of semiconductors for wireless communications commonly found in laptops. Atheros WiFi chips can be used in Ubuntu using the restricted drivers manager.
[02:21] <poeloq> is that a correct example?
[02:23] <tritium> poeloq: careful with the porn urls you were IMing earlier that got pasted in #ubuntu
[02:23] <poeloq> tritium: porn links I IMed in #ubuntu ?
[02:23] <poeloq> oO
[02:24] <poeloq> tritium: are you serious?
[02:24] <tritium> poeloq: yes
[02:24] <LjL> poeloq not too informative imho. sounds mostly like a dictionary definition, with only a passing reference to the fact that the restricted manager can do something with it. most factoids should contain a wiki link at least, or some specific instructions
[02:24] <poeloq> LjL: sadly, I couldn't find a wiki link
[02:24] <poeloq> and i thought it would be better than nothing
[02:25] <poeloq> and it is my first attempt to create a factoid, i will get better with time ;)
[02:25] <poeloq> tritium: which porn links and when?
[02:25]  * poeloq is really confused about this porn link business
[02:26] <tritium> 19:03 poeloq T1m0thy: and btw, youporn.com seems to mess up Flash sound support for the session, so maybe.... ;)
[02:26] <tritium> Shouldn't be so confusing...
[02:26] <poeloq> tritium: that wasn't a mistake. That was a serious comment
[02:27] <poeloq> Is that not allowed? Is #ubuntu censored to be child friendly? If so, I am sorry and I didn't know
[02:27] <LjL> yup
[02:27] <LjL> !language
[02:27] <ubotu> Please watch your language and topic to help keep this channel family friendly.
[02:27] <poeloq> oh
[02:27] <poeloq> I am sorry, i didn't know that rule. I have been in the Wikipedia community too long ;)
[02:28] <LjL> poeloq, about atheros, with the information you and i can find right now at a cursory googling, the best i think we can do is
[02:28] <LjL> !atheros is <alias> wifi
[02:28] <ubotu> I'll remember that, LjL
[02:28] <LjL> !atheros
[02:28] <ubotu> Wireless documentation can be found at https://help.ubuntu.com/community/WifiDocs
[02:28] <LjL> what they develop and what sort of computers they target isn't really very relevant to ubuntu
[02:28] <poeloq> LjL: I was about to do the same
[02:28] <LjL> https://wiki.ubuntu.com/WirelessChipsets mentions Atheros as supported
[02:28] <LjL> at least some chips
[02:28] <poeloq> ok :)
[02:29] <LjL> i know zilch about wifi cards, so
[02:29] <poeloq> it works for me out of the box anyhow
[02:29] <poeloq> I installed 7.10 new yesterday and the Atheros HAL was automatically installed
[02:32] <poeloq> anyhow, need to be off to bed
[02:32] <poeloq> g'night
[04:41] <ubotu> ardchoille called the ops in #kubuntu (Silouck needs to be reminded about the coc)
[05:24] <maynards-girl> hello, i'm trying to join #ubuntu but I'm unable too.  i've already changed my port to 8001
[05:24] <maynards-girl> how do i join #ubuntu
[05:26] <maynards-girl> how can i be tested?
[05:32] <ubotu> scguy318 called the ops in #ubuntu (twolazy)
[05:32] <ubotu> scguy318 called the ops in #ubuntu (toolazy)
[06:02] <ubotu> scguy318 called the ops in #ubuntu (Manottt)
[06:03] <nixternal> nalioth: you see these people from ##sporks spamming chans?
[09:04] <Tm_T> nalioth: when you're up, slap me
[10:03] <ubotu> amidaniel called the ops in #ubuntu (kr4L)
[12:02] <stefg> Hi, can we update the !build factoid to represent the feisty/gutsy situation? Universe is now enabled by default, so the last part is confusing
[12:02] <stefg> !build
[12:02] <ubotu> Compiling software from source? Read the tips at https://help.ubuntu.com/community/CompilingSoftware (But remember to search for pre-built !packages first: not all !repositories are enabled by default!)
[13:42] <dukebody> Hello, some people were trolling in #ubuntu-es
[13:42] <dukebody> Could somebody help me to kick them?
[13:42] <dukebody> I couldn't contact any #ubnutu-es ops listed by ChanServ.
[15:33] <ubotu> stdin called the ops in #ubuntu (Crazymethjesus bad language and abusive)
[16:00] <FloodBot2> WARNING: ChanServ is not replying, removing limit
[16:32] <FloodBot2> !ops | mass join
[16:33] <ubotu> sproingie called the ops in #ubuntu ()
[16:33] <stdin> --> FloodBot4<EMAIL_ADDRESS>has joined #ubuntu <<<
[16:33] <Tm_T> stdin: ?
[16:34] <stdin> Tm_T: that's not our flood bots, it's someone else
[16:34] <Tm_T> 1833 -!- FloodBot4 is "#ubuntu guard bot"
[16:34] <Tm_T> interesting realname then
[16:35] <stdin> Tm_T: looks like it is ours :p the cloak came late
[16:35] <Tm_T> yup
[16:40] <LjL> [17:39:28] <cool> LjL-Temp, , whats FloodBot for ?
[16:40] <LjL> [17:40:16] [Whois] cool is<EMAIL_ADDRESS>(gaurish sharma)
[16:40] <LjL> i think i know this ident
[16:42] <stdin> shows a few entries on the bantracker
[16:42] <stdin> most from you
[16:42] <LjL> indeed.
[16:42] <Tm_T> yup
[16:43] <ubotu> In ubotu, erUSUL said: java is To install a Java runtime/interpreter on Ubuntu, look at https://help.ubuntu.com/community/Java - For the Sun  Java runtime install sun-java5-jre from the !Multiverse repository
[16:43] <ubotu> In ubotu, erUSUL said: java is To install a Java runtime/interpreter on Ubuntu, look at https://help.ubuntu.com/community/Java - For the Sun  Java runtime install sun-java6-jre from the !Multiverse repository.
[16:43] <Tm_T> erm
[16:43] <Tm_T> !java
[16:43] <ubotu> To install a Java runtime/interpreter on Ubuntu, look at https://help.ubuntu.com/community/Java - For the Sun Java runtime install sun-java5-jre from the !Multiverse repository. Enable the backports repository on Edgy to install sun-java6-jre
[16:44] <Tm_T> wheres java7 bits from factoid?
[16:45] <stdin> is there a java7 in the repos?
[16:45] <Pici> !find java7
[16:45] <ubotu> Found: icedtea-java7-bin, icedtea-java7-demo, icedtea-java7-doc, icedtea-java7-jdk, icedtea-java7-jre (and 2 others)
[18:54] <PriceChild> rawr
[18:56] <ompaul> thats not a rawr this is a RAWR!
[18:57] <PriceChild> please don't hurt me
[18:57] <PriceChild> *cowers*
[18:57] <ompaul> hehe
[18:57]  * ompaul wants to start his life over from the beginning - but with what I know today :)
[18:58] <ompaul> now that should be scarey
[18:58] <PriceChild> I'm reasonably happy with what I've done.
[19:02] <ompaul> PriceChild, na - I got involved with openstreetmap it rocks on some levels
[19:38] <jussi01> Hmmm, do we have a factoid for people who ping you, and you only because you helped them previously?
[19:42] <Tm_T> not that I know
[19:42] <Tm_T> jussi01: do search database, if not, make one please
[19:43] <jussi01> Tm_T: yeps, I will if there isnt one... well suggest it anyway...
[19:43] <jussi01> but Im pretty sure there is one
[19:45] <nalioth> !tell jussi01 about msg
[19:46]  * jussi01 hugs nalioth
[19:46] <nalioth> jussi01: i usually help the person and send that at the end of the help session
[19:46] <jussi01> nalioth: I knew it was there, just couldnt remember it/find it
[20:15] <seanw> LjL, oh I see
[20:16] <seanw> re; unregged
[20:16] <Tm_T> meh
[20:16] <Tm_T> ?
[20:18] <ubotu> bruenig called the ops in #ubuntu ()
[21:00] <ubotu> In #kubuntu, draik said: Ubotu is great with most info. !apt is helpful.
[21:06] <ubotu> posingaspopular called the ops in #ubuntu-us ()
[21:19] <PriceChild> vorian, who did you want as contacts for ny and ne btw?
[21:19] <vorian> ausimage
[21:19]  * ikonia nods evening respect to the channel
[21:20] <PriceChild> I guess I'd better check those with atoponce seen as he's contact for -us.
[21:20] <PriceChild> nalioth, are you around?
[21:20] <vorian> what a joke
[21:21] <PriceChild> vorian, hmm?
[21:21] <vorian> atoponce isn't even a team leader
[21:21] <PriceChild> why's he contact for -us then?
[21:21] <stefg> ops, ready for some factoid cleanups ?
[21:21] <PriceChild> stefg, suggest them :)
[21:21] <vorian> he regged the channel when he, Zelut and myself started the us-teams project
[21:21] <LjL> nnnoooo
[21:21] <stefg> !build
[21:22] <ubotu> Compiling software from source? Read the tips at https://help.ubuntu.com/community/CompilingSoftware (But remember to search for pre-built !packages first: not all !repositories are enabled by default!)
[21:22] <nalioth> PriceChild: around the house?
[21:22] <stefg> this is outdated... universe is now enabled by default. COnfusing last sentence
[21:22] <vorian> and technically, there is no US LoCo Team
[21:22] <PriceChild> nalioth, "probably" got a couple of channels -us would like back...
[21:22] <PriceChild> !-build
[21:22] <ubotu> build is <alias> compiling - added by Seveas on 2006-06-18 17:36:53
[21:22] <PriceChild> !-compiling
[21:22] <ubotu> compiling aliases: gcc, compile, b-e, build, build-essential, make, g++, build-essentials, compiler - added by LjL on 2006-07-18 22:50:25
[21:23] <nalioth> probably?
[21:23] <PriceChild> !no compiling is <reply> Compiling software from source? Read the tips at https://help.ubuntu.com/community/CompilingSoftware (But remember to search for pre-built !packages first)
[21:23] <ubotu> I'll remember that PriceChild
[21:23] <stefg> !packaging
[21:23] <ubotu> packaging is The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[21:23] <PriceChild> vorian, ok... so there isn't really any kind of leadership either?
[21:23] <vorian> no
[21:23] <stefg> someone had teh 'packaging is' in the command.....
[21:24] <PriceChild> ok
[21:24] <vorian> PriceChild: atoponce and Zelut are adamant about no leadership or governing structure for the US Teams project
[21:24] <PriceChild> vorian, ok then.
[21:24] <PriceChild> vorian, so you want #ubuntu-us-ny to ausimage, what about #ubuntu-us-ne?
[21:25] <vorian> Each state team is as independent as a country team would be
[21:25] <vorian> dthacker for ne
[21:25] <PriceChild> yharrow (contact for ny is online... just talking)
[21:25] <vorian> NY has a team President, which is ausimage
[21:25] <vorian> but yharrow may be the better choice
[21:26] <PriceChild> vorian, oh he's not someone random?
[21:27] <vorian> no
[21:27] <PriceChild> so leave it as it is?
[21:28] <PriceChild> nalioth, any chance of getting dthacker #ubuntu-us-ne ?
[21:28] <nalioth> you want dthacker as contact ?
[21:29] <PriceChild> Yes please.
[21:31] <ubotu> In ubotu, Daemon said: nooooooo thx is thanks :D:D:D
[21:32] <vorian> that is very odd
[21:32] <vorian> team contact and a team president
[21:33] <nalioth> changed
[21:34] <PriceChild> Thanks nalioth :)
[21:36] <FloodBot1> Synced to #ubuntu, 1253 users present
[21:59] <FloodBot2> Synced to #ubuntu, 1242 users present
[23:19] <FloodBot1> Synced to #ubuntu, 1210 users present
[23:36] <FloodBot1> Synced to #ubuntu, 1208 users present
[23:36] <PriceChild> *looks oddly at -fr's access list*
[23:39] <Seeker`> PriceChild: what is wrong with it?
[23:39] <PriceChild> just an "unusual" scheme
[23:40] <Seeker`> with everyone @ 40?
[23:40] <Seeker`> well, almost
[23:40] <PriceChild> everyone getting set & access etc
[23:44]  * Seeker` doesnt know how many people frequent -fr
[23:47] <PriceChild> Seeker`, it seems quite busy
[23:47] <FloodBot1> Synced to #ubuntu, 1210 users present
[23:47] <PriceChild> old channel
[23:50] <FloodBot1> Synced to #ubuntu, 1207 users present
[23:50] <FloodBot2> Synced to #ubuntu, 1207 users present
[23:50] <LjL> [00:49:49] <pjeide> I believe your script may've autobanned be from #kubuntu for running a /ctcp #kubuntu version.
[23:50] <LjL> [00:50:10] <pjeide> I apologize for any inconvenience, I was simply curious what clients others with kubuntu were using.
[23:50] <LjL> [00:50:16] <pjeide> mind lifting the ban?
[23:50] <LjL> unban?
[23:53] <PriceChild> LjL, yes once if agrees never to do it again.
[23:57] <Tm_T> LjL: also he must understand that he should ASK not probe
[23:59] <FloodBot1> Synced to #ubuntu, 1205 users present


[00:19] <TheMuso> AlanBell: ah ok, you have filed a bug about that. I'll set it to be displayed when I next upload Orca.
[03:05]  * UndiFineD 404 @ TheMuso,
[06:25] <TheMuso> UndiFineD: ??
[06:25] <UndiFineD> bug 778749
[06:25] <ubot2> Launchpad bug 778749 in pulseaudio "[Realtek ALC892] ALSA test tone not correctly played back" [Undecided,Incomplete] https://launchpad.net/bugs/778749
[06:26] <UndiFineD> that link you give is a 404 for me
[06:29] <valorie> works here, UndiFineD
[06:29] <UndiFineD> Log
[06:29] <UndiFineD> This page does not exist yet. You can create a new empty page, or use one of the page templates.
[06:31] <valorie> interesting
[06:32] <valorie> I click that link, and FF opens it right up
[06:32] <valorie> have you tried a different browser?
[06:33] <UndiFineD> done, same
[06:34] <UndiFineD> it is the link luke mentioned to me
[06:34] <UndiFineD> the but page opens just fine ... but not the suggested page in the solution
[06:36] <valorie> oh, I see
[06:37] <valorie> that's because PulsaAudio is misspelled
[06:38] <valorie> https://wiki.ubuntu.com/PulseAudio/Log works, I bet
[06:38] <valorie> heh
[06:39] <UndiFineD> ah .. too early to spot that
[06:39] <UndiFineD> thanks valorie
[06:39] <valorie> :-)
[06:40] <valorie> glad I could help
[06:40] <valorie> and that page looks useful
[06:48] <UndiFineD> TheMuso, the logfile is attached
[07:29] <TheMuso> UndiFineD: Thanks, and apologies. Been doing a lot of typing today, and I also think I need a new keyboard.
[07:31] <UndiFineD> TheMuso, i still want my optimus maximus
[07:31] <UndiFineD> oled


[00:05] <spiv> Does the branchscanner run on qastaging?
[00:06] <wgrant> Not regularly, AFAIK.
[00:08] <spiv> That's going to make QA'ing bug 813349 inconvenient :/
[00:08] <_mup_> Bug #813349: hard to get from mp to per-revision diffs <qa-needstesting> <Launchpad itself:Fix Committed by spiv> < https://launchpad.net/bugs/813349 >
[00:09] <StevenK> spiv: You can request it to be run manually
[00:17] <wgrant> Anyone feel like reviewing https://code.launchpad.net/~wgrant/launchpad/retarget-bugtask-model/+merge/68761?
[00:31] <StevenK> wgrant: r=me
[00:32] <wgrant> Thanks.
[00:32]  * StevenK prods wallyworld about OCR
[00:33] <wallyworld> StevenK: sorry, i was caught up finishing a branch
[00:34] <wgrant> lifeless: How is HA-librarian going?
[00:39] <lifeless> wgrant: rt something or other
[01:03] <LPCIBot> Yippie, build fixed!
[01:03] <LPCIBot> Project devel build #909: FIXED in 5 hr 43 min: https://lpci.wedontsleep.org/job/devel/909/
[01:22] <wgrant> lifeless: Hah, subtle.
[01:23] <poolie> destroy beta testers?
[01:23] <poolie> life imitates glados
[01:23] <wgrant> Heh
[01:26] <lifeless> wgrant: ?
[01:26] <wgrant> lifeless: The progress bar.
[01:26] <lifeless> wgrant: heh yes
[01:49] <wallyworld> jtv: you around? want to mentor https://code.launchpad.net/~gary/launchpad/bug812335/+merge/68762 ?
[01:50] <jtv> wallyworld: no, I'm not here.  It's almost 4 AM here.
[01:50] <wallyworld> jtv: oh, sorry! you still in europe then i assume
[01:50] <jtv> Yup
[01:51] <wallyworld> when are you back?
[03:05] <nigelb> wallyworld: It seems the intersection of my freetime + your available hours don't collide, so I wonder if I can take it to email? :)
[03:09] <wallyworld> nigelb: otp, talk soon
[03:12] <wallyworld> nigelb: you can email me. or ping me on irc. i'm normally lurking in my evening and will respond to any queires
[03:25] <nigelb> wallyworld: I finally landed something I had pending yesterday, so I can work on linkfying + titling bugs with XHR.
[03:25] <wallyworld> nigelb: excellent, well done.
[03:26] <nigelb> where is it that I should start looking? :)
[03:26] <nigelb> lib/lp/bugs/javascript?
[03:26] <wallyworld> ok, there's 2 places - the javascript which makes the xhr call and the python code which runs serverdide
[03:27] <wallyworld> serverside
[03:27] <wallyworld> justa moment, i'll grab the file names
[03:28] <wallyworld> the javascript file is lp/lp/app/javascript/lp-links.js - this harvests potential links when the page loads and makes a single xhr call to have those processed
[03:29] <wallyworld> lp/app/browser/linkchecker.py is the python code which receives the xhr call, does the work, and returns the results as a json data structure. the js code above then processes the result and pokes the dom to update the page
[03:30] <nigelb> so, I need to update the python code to return title and process that extra information in the js.
[03:30] <wallyworld> the bit which wires it up is the +checklinks browser:page section in lp/app/browser/configure.zcml
[03:31] <wallyworld> yes, that is correct
[03:31] <wallyworld> you can add extra fields to the json dict returned by the xhr call
[03:31] <wallyworld> and then update things like the title attribute of the anchor or whatever in the js
[03:32] <wallyworld> make sense?
[03:32] <nigelb> Yes
[03:32] <nigelb> Does this already check if the bug exists?
[03:33] <wallyworld> looking at the code, it only handles branch links so far, but it does check that the branch exists
[03:33] <wallyworld> so you would need to extend it to support harvesting and processing bug links
[03:33] <nigelb> ah
[03:34] <wallyworld> you could make the xhr call send a dict with a branches and a bugs list
[03:34] <nigelb> The current linkyfing seems to be server-side. Is that the right wway?
[03:35] <wallyworld> yes, the serverside is the place to check the validity or permission to access info about the bug/branch
[03:36] <wallyworld> what is it you want to do exactly?
[03:38] <nigelb> I'd like to look for "bug 1234" type links, check if they exist, get the title, add the title attribute if it exists and remove the linkification if the bug doesn't exist.
[03:38] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[03:39] <wallyworld> are these would appear in text fields like comments, merge proposal descriptions and the like?
[03:40] <nigelb> Yeah, the same
[03:42] <wallyworld> there's a file lp/app/browser/stringformatter.py with a method linkify_bug_numbers() which parses the text and does the initial linkification
[03:42] <wallyworld> this is done when the view is rendered
[03:42] <nigelb> so, does this make sense.
[03:42] <nigelb> add a css class for all the bugs, fetch all of the links with that class, send xhr request, modify dom.
[03:44] <wallyworld> yes. the comment on the code which does the initial linkification says:
[03:44] <wallyworld>         # Don't look up the bug or display anything about the bug, just
[03:44] <wallyworld>         # linkify to the general bug url.
[03:44] <wallyworld> so the work you are proposing would be post-processing in effect to add the extras
[03:44] <nigelb> yeah, it wwas removed for performance.
[03:44] <wallyworld> like for the branches, make invalid (or invisible due to privacy) links grey etc
[03:45] <nigelb> yep!
[03:45] <wallyworld> so using a css class to mark the bug links is good because that's how the current code for branch link processing works
[03:46] <wallyworld> all the plumbing is there, you just need to extend the js and python ti support another different type of link processing
[03:47] <nigelb> oh cool! I'll try tonight to start step by step. I'll update you by email since your times don't match very well.
[03:48] <wallyworld> ok. but feel free to try and ping me on irc if you want. i may have a glass of red in hand but should be coherent enough to type :-)
[03:48] <nigelb> haha
[03:48] <nigelb> ok :)
[03:48] <wallyworld> i have soccer first too, so it will be late evening before i am in front of the laptop again
[03:49] <nigelb> the problem is your late is still early enough for me that I'd be at work.
[03:50] <wallyworld> what time is it now where you are?
[03:50] <nigelb> 9:20 AM
[03:50] <wallyworld> so you ate 4.5 hours behind me
[03:50] <wallyworld> are
[03:51] <wallyworld> so except for fridays when i have soccer, i am normally pingable at a time which would be close to EOD for you
[03:53] <nigelb> ah, I'll note that :)
[03:54] <wallyworld> or even at start of your day, it's only afternoon for me :-)
[03:54] <wallyworld> so we do have a fair bit of overlap
[03:54] <nigelb> heh, start of the day is often problematic. I tend to sleep late and wake up fairly late :)
[03:55] <wallyworld> np. i used to do that before kids :-(
[03:57] <nigelb> heh, off to work. Laters!
[05:07] <StevenK> wgrant, lifeless: Do either of you want to mentor wallyworld's review of https://code.launchpad.net/~stevenk/launchpad/dsp-vocab-issues/+merge/68763 ?
[05:24] <wgrant> StevenK: Done.
[05:25] <StevenK> wgrant: Thanks!
[05:35] <wgrant> wallyworld: Around?
[05:37] <wgrant> We have yet another form picker regression.
[05:37] <wgrant> They don't populate the textbox.
[05:37] <wgrant> Works OK on lpnet.
[05:37] <wgrant> But there are no picker changes since then.
[05:37] <wgrant> So WTF?
[05:43] <wallyworld> wgrant: yo
[05:44] <wgrant> wallyworld: See #launchpad-ops.
[05:44] <wgrant> qastaging ninja-updated.
[05:44] <wgrant> So there was in fact a relevant rev: r13485
[05:44] <wgrant> Reverting now.
[05:44] <StevenK> That makes you fairly distracted if it takes 50 minutes to update and you didn't notice :-P
[05:45] <wgrant> It was mostly updated when I started looking at it, and crucially when I loaded the deployment report :)
[05:46] <wgrant> I think jcsackett may have failed at conflict resolution with wallyworld's work.
[05:46] <wgrant> The extra arg to create() is missing.
[05:46] <wgrant> So it never gets hooked up to anything.
[05:46] <wgrant> Anyway, reverting.
[07:06] <jtv> Hi wallyworld :)
[07:07] <wallyworld> jtv: hello
[07:09] <jtv> wgrant: I don't think I touched the archivecruftchecker as such.
[07:10] <wgrant> $ bzr diff -c13478 lib/lp/soyuz/scripts/tests/test_archivecruftchecker.py | diffstat test_archivecruftchecker.py |   19 ++++++++-----------
[07:10] <wgrant> Oh.
[07:10] <wgrant> That's tests.
[07:11] <wgrant> Ahem
[07:11]  * jtv stands back and admires wgrant's genius :)
[07:11] <jtv> But
[07:11] <wgrant> Hm.
[07:11] <wgrant> But that could be it.
[07:11] <jtv> I did change something in the test.
[07:11] <wgrant> It is those tests that are spewing crap to stderr.
[07:11] <jtv> Yes.  It's because publish-distro is now a LaunchpadCronScript.
[07:11] <wgrant> It previously redirected stdout/stderr to null pipes.
[07:11] <jtv> Where that test instantiates the object, it should inject a DevNullLogger.
[07:12] <wgrant> But now runs PublishDistro directly.
[07:12] <wgrant> Yeah.
[07:12] <jtv> I can do that.
[07:12] <wgrant> Thanks.
[07:13] <stub> I wanna QA my db update script, which will make qastaging die for a few seconds.
[07:13] <wgrant> Feel free.
[07:13] <wgrant> We are bad and a while away from buildbot completion.
[07:14]  * wallyworld goes out to buy food
[07:26] <lifeless> stub: \o/
[07:27] <lifeless> stub: we need a catchup call too
[07:27] <lifeless> I couldn't last night - family thing, and am eating now; can we make a time later today?
[07:32] <stub> lifeless: sure
[07:33] <stub> I might grab some fud too
[07:42] <lifeless> shall we say in one hours time then ?
[07:44] <stub> k
[07:49] <adeuring> good morning
[08:04] <mrevell> Howdy
[08:06] <bigjools> morning everyone
[08:06] <poolie> hi bigjools, mrevell
[08:06] <poolie> lifeless: still here?
[08:06] <bigjools> o/
[08:06] <lifeless> kindof :>
[08:06] <poolie> the U3011 is amazing
[08:06] <poolie> you should totally get one
[08:06] <poolie> imax-mode
[08:08] <lifeless> \o/
[08:11] <bigjools> woo!
[08:13] <lifeless> poolie: photo ?
[08:15] <poolie> lifeless: https://plus.google.com/112646476239496153808/posts/ApTZ7GyWAdo
[08:15] <poolie> looks like a big glowing thing
[08:15] <poolie> heh, that laptop looks like a netbook
[08:35] <lifeless> stub: now ok ?
[08:40] <bigjools> jtv: Contents is not updated yet it seems
[08:40] <jtv> oh
[08:40] <bigjools> http://archive.ubuntu.com/ubuntu/dists/oneiric/ for example
[08:41] <bigjools> jtv: http://launchpadlibrarian.net/75734346/2TgWVd4UTg0dWE5ieBiCMVPmNBE.txt
[08:41] <jtv> grrr
[08:41] <bigjools> jtv: need to set up script monitoring for this :)
[08:41] <jtv> We don't have that?
[08:42] <bigjools> jtv: you need to tell losas to do so
[08:42] <bigjools> and this is a new LPS
[08:42] <lifeless> LPS? [not LaunchpadProductionStatus I assume]
[08:42] <jtv> Local Processor Status?
[08:42] <jtv> Hi lifeless :)
[08:42] <lifeless> hola jtv
[08:43] <StevenK> LaunchpadScript
[08:43] <StevenK> I guess
[08:43] <jtv> Ah yes :)
[08:47] <stub> lifeless: I'm going to try skype on my desktop again
[08:48] <lifeless> ok
[08:48] <bigjools> ARGH
[08:48] <lifeless> call me  :)
[08:48] <bigjools> FeatureFixture cancels all other feature flags.  I've been burned.
[09:22] <jtv> bigjools: generate-contents-files cron fix has deployed, so we'll see.
[09:22] <bigjools> jtv: oh, cowboy?
[09:22] <jtv> cron change — no code change.
[09:22] <bigjools> ah cron, sorry
[09:29] <jtv> bigjools: another thing: we should be able to scratch steps 12 & 14 off https://wiki.ubuntu.com/NewReleaseCycleProcess now, shouldn't we?
[09:30] <bigjools> yup
[09:31] <jtv> cjwatson: I realize we discussed this already, but I'd like to check up: if we do ^^^ then step 13 could go as well because you watch these files like a hawk anyway, right?
[09:35] <stub> Anyone running Aurora ?
[11:24] <henninge> adeuring: hey!
[11:24] <henninge> adeuring: Moin ;)
[11:24] <henninge> adeuring: Wenn du so nett wärst ...
[11:24] <henninge> bitte
[11:24] <henninge> ;)
[11:24] <henninge> file:///home/henning/canonical/lp-branches/devel-work/lib/lp/code/javascript/tests/test_branchdiff.html
[11:24] <henninge> crap
[11:24] <henninge> mist
[11:24] <henninge> adeuring: https://code.launchpad.net/~henninge/launchpad/bug-813627-preview-diff-overlay/+merge/68820
[11:42] <adeuring> henninge: sure, I'll look
[11:47] <henninge> adeuring: thank you!
[11:52] <jml> I'm writing a launchpadlib script, running it against staging for now.
[11:52] <jml> am using login_with,
[11:52] <jml> get this error: http://paste.ubuntu.com/649908/
[11:52] <jml> what am I supposed to do with that?
[11:54] <jml> why am I unauthorized? how do I become authorized? do my users need to know about access tokens?
[11:55]  * jml ducking out to get some food. please don't let that stop you answering in the mean time.
[11:56] <bigjools> jml: I wonder if it's anything to do with the cache bug I filed the other day
[12:02] <adeuring> henninge: r=me
[12:03] <henninge> adeuring: thanks again ;-)
[12:09] <jml> bigjools: which one is that?
[12:10] <bigjools> jml: mine was to do with cached wadl not updating but I wonder if the auth tokens sometimes get the same problem
[12:10] <StevenK> I seem to recall something like that.
[12:10] <StevenK> It usually happens when we blow up the session database.
[12:11] <jml> bigjools: https://bugs.launchpad.net/launchpadlib/+bug/812799 ?
[12:11] <_mup_> Bug #812799: Local cache not updated when it should be <launchpadlib :Triaged> < https://launchpad.net/bugs/812799 >
[12:11] <bigjools> well I've always usually been directed to re-auth
[12:11] <bigjools> jml: yes
[12:17] <jml> bigjools: I moved .launchpadlib out of the way and still get the same problem
[12:18] <jml> which is consistent with my discoveries from strace.
[12:18] <bigjools> jml: it should offer to re-auth :/
[12:20] <jml> bigjools: I guess it's using some kind of system keyring
[12:21] <bigjools> yeah it throws the token in the password storage that your desktop uses
[12:22] <jml> I can't find it in Passwords & Encryption Keys
[12:27] <james_w> it's called something odd IIRC
[12:33] <jml> james_w: the code says it's called 'launchpadlib'
[12:33] <jml> at least, that's what is passed to keyring.get_password
[12:34] <james_w> hmm, ok
[12:34] <jml> but that doesn't exist in Passwords & Encryption Keys
[12:34] <jml> so I'm trying to figure out where the hell it's looking
[12:34]  * jml busts out set_trace, since google is failing.
[12:34] <bigjools> woo ajaxy mid-review diffs working
[12:35] <bigjools> the link should be green though
[12:35] <james_w> it's called "network password" here
[12:35] <james_w> jml, ^
[12:36] <LPCIBot> Project devel build #911: FAILURE in 5 hr 44 min: https://lpci.wedontsleep.org/job/devel/911/
[12:36] <jml> harumph
[12:36] <jml> ahh...
[12:36] <jml> 'launchpadlib' is the domain. or something.
[12:37] <jml> which doesn't show up in P&EK
[12:45] <jml> https://bugs.launchpad.net/launchpadlib/+bug/814595
[12:45] <_mup_> Bug #814595: Unrecoverable error when authorization fails <launchpadlib :New> < https://launchpad.net/bugs/814595 >
[12:47] <jml> sorry if it's a little grumpy. it's a pretty serious bug & I lost a fair bit of time to it.
[12:47] <jml> james_w: how did you figure out that it was called "network password"?
[12:48] <james_w> jml, just by looking at everything that didn't have a clear non-launchpad purpose
[12:48] <jml> james_w: heh, ok. thanks.
[12:49] <benji> unfortunately the string "network password" isn't under our control; the Gnome keyring calls that class of entries "network password"
[12:52] <bac> wow, adeuring, no backlog
[12:52] <jml> benji: that is a shame.
[12:53] <adeuring> bac: well, I did only two reviews this morning.
[12:53] <bac> two more than me today!
[12:53] <adeuring> seems that people are in holidays
[12:54] <jml> benji: luckily, the bug can be fixed without that, since the ideal is never to be compelled to look for keys in the keyring
[12:54] <benji> jml: indeed; in fact, I /thought/ that invalid auth tokens were silently thrown away
[12:56] <jml> :\
[12:59] <james_w> http://shnatsel.blogspot.com/2011/07/weve-just-revolutionized-alpha-testing.html <- a Launchpad success story
[13:08] <jml> nice
[13:11] <jml> today is obviously a 'file lots of bugs' day
[13:12] <jml> almost makes me want to file bugs on Launchpad about improving my person-oriented bugs views.
[13:14] <spiv> jml: in happy news my inline diffs on merge proposals patch landed on production (for ~launchpad)
[13:14]  * spiv -> bed
[13:16] <henninge> dpm: ping
[13:28] <dpm> henninge, pong
[13:32] <deryck> henninge, ping for standup
[13:33] <henninge> deryck: argh, already
[13:34] <jml> can I delete a PPA over the API?
[13:35] <bigjools> no
[13:36] <jml> bigjools: why not?
[13:36] <henninge> deryck: mumble dead, try again
[13:36] <bigjools> jml: because nobody write the code to do it
[13:36] <deryck> henninge, ah ok
[13:36] <bigjools> wrote*
[13:36] <jml> bigjools: fair enough.
[13:36] <bigjools> jml: are you grumpy today? :)
[13:37] <jml> bigjools: not really. just while debugging the login error.
[13:47] <StevenK> Should be fairly easy to add, just the decorator.
[13:47] <wgrant> We should perhaps not do it until PPA deletion does something useful.
[13:47] <wgrant> Which is also very easy.
[13:48] <bigjools> wgrant: you criticise with no suggestion of what would be useful.  Many people already find it useful.
[13:48] <StevenK> Right
[13:48] <wgrant> bigjools: It doesn't free up the name or disappear.
[13:48] <wgrant> It is useful for the purpose for which it was implemented.
[13:49] <bigjools> there's a bug about those IIRC
[13:49] <wgrant> But an API for that purpose is not particularly useful.
[13:49] <wgrant> I don't think.
[13:49] <bigjools> make it disappear was rather hard
[13:49] <wgrant> Yeah.
[13:49] <wgrant> Rename it is one line of code plus tests :)
[13:49] <wgrant> And it fixes most issues that I know of.
[13:49] <StevenK> Clean up job that removes the row from Archive after a day?
[13:49] <bigjools> one line?
[13:50] <StevenK> But that then means you need to delete the publications too
[13:50] <bigjools> StevenK: that would be the naive approach :)
[13:50] <wgrant> StevenK: With all the BPRs and SPRs that have been copied into other archives?
[13:50] <StevenK> Tis messy
[13:55] <jml> why not delete in real-time?
[13:56] <wgrant> We cannot remove the DB stuff.
[13:56] <wgrant> And there is stuff on disk to be removed.
[13:57] <jml> ok, so that just means we use long poll, right?
[13:57] <wgrant> Hah
[14:00] <bigjools> we'll work on deploying long poll when Red goes to maintenance
[14:02] <jml> oh, interesting.
[14:03] <bigjools> wgrant, StevenK: BTW, I am very concerned about never being able to derive from distros with a) active builds b) items in the queue
[14:03] <jml> well, it's not like deleting PPAs is going to be attempted before then.
[14:03] <bigjools> I think relaxing b) is easy
[14:03] <bigjools> I am not sure of ramifications for a)
[14:03] <wgrant> It is pretty messy.
[14:03] <wgrant> This goes back into the copying partial subsets of binaries thing.
[14:03] <bigjools> indeed
[14:04] <wgrant> Another dupe of which was filed yesterday.
[14:05] <StevenK> That we should allow copying binaries only?
[14:05] <wgrant> That if something built in karmic, you can only copy it from karmic, not anything later.
[14:07] <jtv> Do we have a way for tests to query the log level that LaunchpadScript sets?  Apparently it gets set on a handler, not the logger, but I'm not seeing the handler.
[14:14] <bac> hi sinzui
[14:17] <stub> jtv: You would have to poke the internals. Why would it matter what level the script sets?
[14:18] <jtv> stub: for some reason LaunchpadScript setup changes log levels.
[14:18] <stub> You probably have to invoke a script and look for DEBUG, INFO etc.
[14:19] <jtv> That'd be very costly.  :(
[14:19] <stub> It adds log levels, and configures the various handlers to what level they emit by default.
[14:20] <stub> logging.DEBUG isn't changes to a new number or anything like that.
[14:20] <jtv> We have several cases where scripts instantiate and run other script objects, which seems to change the log level no matter what you do (and never change it back)
[14:20] <stub> c/changes/changed
[14:20] <jtv> Well no, that'd be very weird.
[14:20] <stub> Yer, have no idea what happens if you try to do that.
[14:21] <jtv> Point is, logger.getEffectiveLevel returns NOTSET.
[14:21] <stub> LaunchpadScript seems pretty difficult to invoke except as a standalone script.
[14:22] <bigjools> awesome, ec2 sent me an email saying "Test Runner FAILED"
[14:23] <stub> logging.getLogger('').getEffectiveLevel() you mean?
[14:23] <stub> (the root logger?)
[14:23] <jtv> Would that work?
[14:23] <jtv> I just tried getEffectiveLevel on the logger that LaunchpadScript created.
[14:24] <stub> NOTSET just means inherit from somewhere I think
[14:24] <jtv> Although it does seem to do something global, because when script A instantiates script B, that's enough to change A's logging as well.
[14:24] <stub> so the logger the script just uses its parents or something like that.
[14:25] <jtv> So suddenly from the moment B is instantiated, A continues without the log level you specified on the command line.
[14:25] <stub> There are a number of loggers, and we only want to bother maintaining one, so we just configure that stuff on the root logger IIRC.
[14:25] <jtv> That would explain.
[14:26] <stub> Yer. Cause we can't force scripts to use the logger instantiated just for them, or we could, but legacy code would need to be waded through.
[14:27] <stub> (and we would have to pass it around everywhere and use it whenever some code elsewhere wanted to log a message)
[14:27] <stub> So yeah, it is global state and LaunchpadScript or somewhere in that mess sets it up so we see the messages per -v, -q etc. with the nice formatting and timestamps.
[14:28] <stub> Maybe some flag is needed to create a LaunchpadScript without doing that setup?
[14:28] <jtv> I was thinking maybe we should skip it if test_flags is given.
[14:28] <stub> That sounds sane
[14:28] <jtv> Except it makes for damned ugly tests.
[14:28] <jtv> Because how do you test this without passing test_args?
[14:29] <stub> I think you have to pass test_flags in, or it will use argv anyway, and make the test runner explode.
[14:29] <jtv> Exactly.
[14:29] <stub> yer.
[14:29] <stub> so new flag.
[14:29] <jtv> Or maybe one test could just sabotage options parsing.
[14:30] <jtv> No, no, I don't think it'd help much.  :(
[14:30] <stub> if you like monkey patches over explicit arguments and the probability of you forgetting to unsabotage it leak your breakage to later tests...
[14:30] <jtv> Ah yes, the joy of global variables.
[14:31] <bigjools> wgrant: were you talking about bug 813749 ?
[14:31] <_mup_> Bug #813749: copying package that have been copied from another series doesn't work if you do not use the "original" package <Launchpad itself:Incomplete> < https://launchpad.net/bugs/813749 >
[14:31] <stub> Feel free to refactor the entire LaunchpadScript API. It it horrible and difficult to extend.
[14:31] <jtv> Anyway, I think it's probably reasonable to skip the logger setup if test_args is given.  The script simply own't have -v and -q.
[14:31] <danilos> whoa, I just learned about https://launchpad.net/launchpad/+documentation ;)
[14:31] <jtv> *won't
[14:32] <bigjools> wgrant: and what is the dupe?
[14:32] <bigjools> can't find it
[14:32] <wgrant> bigjools: Oh, apparently I saw it and forgot to triage it.
[14:32] <wgrant> Probably because I couldn't find the dupe.
[14:32] <bigjools> heh
[14:32] <stub> jtv: It might break some tests, but I think it unlikely enough to give it a go.
[14:32] <wgrant> It was like 6am, so meh.
[14:32] <jtv> stub: right ho, I'll try that.
[14:32] <wgrant> But you know the general idea of the bug, right?
[14:33] <bigjools> wgrant: vaguely
[14:33] <bigjools> 2nd copy copies already copied binaries or something
[14:33] <wgrant> karmic has lpia, while >= lucid don't.
[14:33] <wgrant> So if you copy something from karmic to lucid, lucid only gets two of the three binaries.
[14:33] <wgrant> So you can't copy from, say, lucid to maverick.
[14:33] <wgrant> Because the copy doesn't have a superset of the archive's binaries.
[14:34] <bigjools> wgrant: I think we can alter the +initseries job so that it checks the packages you're copying to see if any of them are building
[14:35] <bigjools> rather than a blanket "something is building, argh"
[14:35] <wgrant> Even that is probably too strict.
[14:35] <bigjools> even if copying with binaries?
[14:35] <wgrant> But making it more lenient than that is more than probably extremely painful and difficult.
[14:36] <bigjools> wgrant: actually I'm still struggling to understand this issue
[14:36] <bigjools> it's been a long week and my brain was shredded the last 2 days by derived distros problems
[14:38] <bigjools> wgrant: I guess the problem is, why do we check the superset
[14:38] <bigjools> or is that the bug?
[14:38] <gary_poster> bac, https://code.launchpad.net/~gary/launchpad/bug812335/+merge/68762 when you have a mo
[14:38] <wgrant> bigjools: See line 399 onwards in packagecopier.py
[14:39]  * bigjools looks
[14:39] <wgrant> bigjools: I'm not sure the rationale remains valid, but we need something like that.
[14:39] <bac> gary_poster: will do it now
[14:39] <gary_poster> ty
[14:39] <bigjools> wgrant: I don;t undserstand the rationale
[14:39] <bigjools> my typing has gone to hell
[14:40] <wgrant> bigjools: The rationale doesn't explain the superset check.
[14:40] <bigjools> and what is the problem it's trying to check
[14:40] <bigjools> right :)
[14:40] <wgrant> It's simply providing reasoning that all BPRs have unique files.
[14:41] <bigjools> unique across what set?
[14:41] <wgrant> All their files have different contents, that is.
[14:41] <wgrant> Ah.
[14:42] <wgrant> The superset check is, I suspect, to prevent different sets of builds being copied in together.
[14:42]  * bigjools tries to find the original bug
[14:42] <wgrant> eg. if I have an i386 binary for that source already in this archive, and I try to copy a different i386 one in.
[14:42] <wgrant> Then the source will have two different i386 binaries.
[14:42] <wgrant> In one archive.
[14:43] <wgrant> Or something.
[14:43] <bigjools> bug #387613
[14:43] <_mup_> Bug #387613: CheckALL - CopyALL approach does not work well for multiple copies <api> <lp-soyuz> <ppa> <Launchpad itself:Fix Released by cprov> < https://launchpad.net/bugs/387613 >
[14:44] <wgrant> Where'd you get that? Annotate?
[14:44] <bigjools> "conflicting versions to be copied in the same batch"
[14:44] <bigjools> annotate, then bzr log
[14:47] <bigjools> it's classic Portuglish in the bug description
[14:51] <bac> gary_poster: what is happening at line 134 of the main diff?
[14:51] <bac> gary_poster: er, nm
[14:51] <gary_poster> bac, cool
[14:53] <bac> gary_poster: any reason not to used named values and do it in a single interpolation?
[14:53] <gary_poster> bac, sqlvalues is what I was thinking
[15:05] <bac> gary_poster: done
[15:05] <gary_poster> thank you bac
[15:24] <jtv> cjwatson: archive index generation should (knock on wood) work normally again on the next run.  It's a big change though, so needs watching.
[15:30] <jcsackett> bac: could i add https://code.launchpad.net/~jcsackett/launchpad/form-picker-macros-also-irritate-me/+merge/68862 to your queue?
[15:30] <bac> jcsackett: sure
[15:44] <mtaylor> why is my launchpadlib script asking this question:
[15:44] <mtaylor> Please set a password for your new keyring
[15:44] <bac> benji: ^^
[15:44] <mtaylor> is there a magic flag I can pass which tells somehting I'm trying to run a script which is not going to be run interactively for most of it's life?
[15:45] <bac> jcsackett: is the only difference between this MP and the previously approved one the unrolling of the bad merge conflicts?
[15:45] <jcsackett> bac: yup, it just undoes the rollback and fixes the one bit of bad conflict resolution.
[15:46] <benji> mtaylor: there is a mechanism for non-interactive authentication; I'll have to remember what it is.  The basics are that you authenticate once interactively and then refer to that authentication token after that
[15:46] <bac> jcsackett: ok
[15:46] <mtaylor> benji: ok. I'll look in to it...
[15:46] <mtaylor> thanks
[15:47] <bac> jcsackett: did the test suite catch the bad merge issues?
[15:51] <benji> mtaylor: take a look at the credentials_file argument to login_with
[15:53] <sinzui> bac: no. That could have been caught by windmill if it ever worked
[15:54] <sinzui> bac: yui-app tests could be written to verify that the ajax widget was activated for the field.
[15:54] <sinzui> bac: The popup widget is from 2005. It never had ajax tests
[15:56] <mtaylor> bac: hey there! you don't have the powers to remove unused users, do you?
[15:56] <sinzui> mtaylor, we can rename unused users. Admins can merge users for other users
[15:57] <mtaylor> sinzui: so, https://launchpad.net/~keystone seems to be a ghost person
[15:57] <mtaylor> and it's in the way of me making a team to manage https://launchpad.net/keystone (well, someone made https://launchpad.net/~keystone-tem - but that doesn't match the rest of our naming scheme, and I'm anal)
[15:58] <sinzui> No, he is real, but has not done anything substantial
[15:58] <mtaylor> well poo
[15:58] <sinzui> He did not choose his user name, which is what I think you care about
[15:59] <mtaylor> yes. I don't mind that he's a real person - I'm sure he's lovely :)
[16:00] <sinzui> I can change hi Lp-id since Lp decided it. He has never done anything in lp to related his Lp-Id to his name
[16:02] <cr3> hi folks, I'd appreciate advice about handling anonymous information in a launchpad'esque way even though I realize that anonymous is mostly frowned upon in launchpad: I'm handling submissions in the launchpad hwdb and some don't have an owner, so if I'm linking the results in a testrun table for example, should the person_id be allowed to be null for anonymous submissions or should I have an anonymous placeholder person entry and its corresponding celebrity
[16:03] <jcsackett> bac: sorry, didn't catch your earlier comment, but sinzui is right.
[16:04] <sinzui> mtaylor, ~keystone was created by shipit. He is on the list of people to remove from Lp.
[16:06] <mtaylor> whee!
[16:07] <mtaylor> shipit is the thing that created a bunch of user accounts back in the day, yeah?
[16:13] <sinzui> bunch is an understatement. we have 2.5 million shipit accounts. only a small percent used Lp.
[16:14] <sinzui> mtaylor, ~keystone is free
[16:14] <mtaylor> sinzui: thank you!
[16:32] <jml> is there an API to get a launchpadlib archive object given a string like 'ppa:person/ppa_name'?
[16:36] <maxb> I think lp.people['person'].getPPAByName(name='ppa_name') is the best you'll get
[16:36] <maxb> The other syntax is private to "dput" AFAIK
[16:37] <bigjools> what he said
[16:41] <jml> ok. so I'll parse it myself
[16:41] <jml> well, it's not private to dput per se, because apt-add-repository uses it
[16:41] <jml> thanks maxb & bigjools
[17:31] <jml> g'night all
[18:35] <LPCIBot> Project devel build #912: STILL FAILING in 5 hr 59 min: https://lpci.wedontsleep.org/job/devel/912/
[19:38] <cr3> are products and product serieses accessed controlled, ie is there any product for which I couldn't access /name/+series in the web interface?


[00:00] <Centaur5> Would anybody in here be able to tell me if Adaptec has decent raid monitoring software for their cards in Ubuntu?
[00:47] <Zylogue> hello, all...I used Ubuntu server 5.x a while back.  I recall in it was a web fronted mp3 player.  This app would be great for a multimedia server I'm looking at building.  Does anyone recall the name of this app, or similar app?  I would like the music to play locally to that machine, out the soundcard audio jack and into the stereo.  Thanks
[01:42] <m1r> i am trying to follow this tutorial https://help.ubuntu.com/community/PXEInstallServer , but dhcp server dont start after install, what could i do about it ?
[03:36] <warchief_ryan> does anyone know what is required to use squid?
[03:38] <warchief_ryan> if anything
[04:01] <owh> Salutations. I'm in need of some peer comment. I have a server running rsync. A cron job checks every minute for the existence of a directory called 'current' and if it exists, it moves it into a time-stamped tree, yyyy/mm/dd/hh:mm. When a client connects, it syncs to a directory called 'current'. This works well.
[04:01] <owh> The client's sync continues into the correct (now moved) directory.
[04:01] <owh> All good. Now I want to add --link-dest to the client's sync command.
[04:03] <owh> On the server I can add a sym-link to an appropriate directory and name it "previous". If I don't touch the sym-link, all is well. What I don't know is when and how and if the --link-desk=../previous is actually used. rsync with verbose doesn't mention the previous directory and strace does not reveal any further detail.
[04:04] <owh> I've tested the above both locally and across a network. No difference in the strace results that I can determine.
[04:05] <owh> So, I could create a cron-job that changes "previous" to the second-last backup, but it's far from a "known" state. I doubt that I can link-dest into the whole dated tree - the rsync server/client will likely run out of memory.
[04:05] <owh> Any comments/suggestions/insights?
[04:06] <owh> BTW, I'm doing this so that the client can just run a simple rsync command across any OS without the need for other applications etc.
[09:11] <owh> Was my question that obtuse?
[09:15] <dthacker-work> I don't know, I wasn't here when you asked it.
[09:19] <owh> Fair enough :-) - rather than repeat it, I'll link to the log: http://irclogs.ubuntu.com/2008/04/12/%23ubuntu-server.html
[09:19] <owh> (It's the last question :)
[09:42] <dthacker-work> owh:  sorry, doing database restart.  I haven't even bent rysnc like that. sorry.
[09:43] <owh> dthacker-work: Fair enough.
[10:22] <AlexC_> hey
[10:22] <AlexC_> My Postfix is throwing up errors such as ' warning: cannot get private key from file' however the file does it, what could be causing this?
[10:24] <dthacker-work> AlexC: what was the last thing you changed?
[10:25] <AlexC_> dthacker-work, that's the weird thing, I haven't touched anything at all =\
[10:25] <AlexC_> the only thing that has changed is the VPS has migrated to a different datacenter last night, since then it has not been working
[10:25] <dthacker-work> VPS?
[10:26] <AlexC_> virtual private server
[10:27] <dthacker-work> hmm.  Are you sure all your keys migrated with your virtual server?
[10:27] <dthacker-work> that's where I'd look first
[10:27]  * dthacker-work sees sleep on the horizon....
[10:28] <AlexC_> they should have, it was just the physical location of the server that changed, the data has stayed on the same machine
[10:30] <dthacker-work> did the hostname change at all?
[10:33] <AlexC_> no, everything is the same
[10:33] <AlexC_> anyway, thanks dthacker-work however I must be off, I'll pop back in later
[17:06] <symtab> hello
[17:06] <symtab> any ideas how i can fix this problem:
[17:06] <symtab> Ignoring unknown interface lo=lo.
[17:06] <symtab> /etc/init.d/loopback start
[17:20] <robc4> Did anyone do the 2.6.24-16 kernel upgrade for Hardy Server?
[17:32] <AlexC_> hey all
[17:35] <AlexC_> I've got an issue with the SSL certificate for Postfix, getting this error when sending email:  "warning: cannot get private key from file"
[17:35] <AlexC_> the cerficate does exist, and everything is in place. This issue only occured after my VPS host was migrated (the physical master server moved to another datacenter)
[17:49] <AlexC_> a ha .... I have fixed that issue, however there is one left
[17:50] <AlexC_> it seams ClamAV is playing up, here are the errors:http://paste2.org/p/20160
[18:35] <MatthewMetzger> kirkland: regarding my memory cache problem, is it safe for me to run this command as root to clear the cache: "sync; echo 3 > /proc/sys/vm/drop_caches"?
[18:37] <cjsstables> hello all.  I have been following rrcoumputerconsulting's howto for setting up ubuntu server as an samba-ldap server, but I always hang on reboot at the very last step.  Is there a know bug with ubuntu server?
[18:43] <MatthewMetzger> cjsstables: I'm new here, so I don't know. But you could check https://bugs.launchpad.net/ubuntu
[22:30] <balzac> hello
[22:30] <balzac> anyone using ebox?
[23:18] <hubuntu> hei everybody! I'm writing a presentation for the FLISOL (http://www.flisol.net/ LatinAmerican Installation Festival by april 26th) to be used by all spanish speaking LoCo teams around the continent. Anyone has a preentation laying somewhere which shows the advantages of Ubuntu in the server room?
[23:19] <hubuntu> I'm specially interested in Hardy features
[23:20] <hubuntu> so if anyone has something lying down or want to chat about what i should include right now, please do


[08:37] <henninge> !
[09:00] <eyfour> Hi, everyone. I am trying to fix a bug that causes Ubuntu One (https://bugs.launchpad.net/ubuntu-translations/+bug/1244314) from running on systems with Norwegian (nb) locale. This was caused by an erroneous translation (now corrected and approved in Launchpad). Is there any way to get this new translation into Saucy as a bug fix, so that Norwegian users may use Ubuntu One? Thanks.
[09:01] <eyfour> correction: a bug that causes Ubuntu One **not** to run
[10:06] <ypwong> eyfour, that needs someone to coordinate a stable update for language packs, which I don't see there's such a plan for saucy...
[10:10] <eyfour> I see.
[10:12] <eyfour> ypwong: could this be considered as a patch, though? Like the ones that are pushed every ~3 weeks? After all, it does break Ubuntu One completely for anyone using the mentioned locale.
[10:15] <eyfour> ypwong: never mind, you answered it already.
[11:25] <dpm> eyfour, I'll try to schedule a langpack update for next week
[11:35] <eyfour> dpm: That would be excellent. Many thanks for your help! :)
[11:38] <dpm> eyfour, no worries, see https://lists.ubuntu.com/archives/ubuntu-translators/2013-December/006361.html