[08:28] <karthik_>  hey i need to switch netween workspaces.. how does it happen internally in the code
[08:28] <karthik_> ?
[08:32] <laga> can you define "workspaces"?
[08:36] <karthik_> i do not know the def of  workspace
[08:37] <karthik_> but in the right hand side bottom we have two symbols
[08:37] <laga> ah.
[08:37] <karthik_> there we can shift from one to other
[08:37] <laga> that's not a kernel thing. well, it does involve multitasking, but that's pretty much low level functionality.
[08:37] <laga> you need to ask the desktop people
[08:37] <karthik_> or using ctrl+alt+right arrow/left arrow
[08:38] <karthik_> ok
[17:31] <crazybyte> hi
[17:31] <crazybyte> perhaps somebody could help me and explain what the nosmp parameter is?
[17:32] <crazybyte> i know that switches the smp kernel in single procesor or up mode
[17:32] <crazybyte> and disables apic
[17:32] <crazybyte> but beside that what it does?
[17:32] <crazybyte> i mean is it possible even if the operation system and programs see only one core that both cores are working?
[17:32] <crazybyte> thank you!
[17:33] <Kano> crazybyte: what do you think the other core should do?
[17:34] <crazybyte> Kano, i'm asking because i have a very nasty bug/behaviour on my laptop
[17:34] <crazybyte> this laptop is new
[17:35] <crazybyte> and it doesn't want to work only with nosmp
[17:35] <Kano> funny
[17:35] <crazybyte> when i try to use smp i end up blocking the system at boot
[17:35] <crazybyte> it doesn't work in any other distro
[17:35] <crazybyte> except slackware (boot cd)
[17:35] <Kano> what system
[17:35] <crazybyte> but it works fine in windows and freebsd
[17:35] <wilstone> hi, I was pointed in this direction with this question, hope someone can help
[17:36] <crazybyte> so it's something that si configurated in the kernle
[17:36] <wilstone> i'm trying to update my dell bios, but when I run "wget -q -O - http://linux.dell.com/repo/firmware/bootstrap.cgi | bash" as root I get an untrusted packages warning, a "Do you want to continue" message, but no chance to respond so "unrecognised input", and the process aborts....is there an easy way round this?
[17:36] <wilstone> thanks
[17:36] <crazybyte> Kano, intel core 2 duo with 2gb memory usb based wifi and sata hdd
[17:37] <Kano> wilstone: dont use wget |bash, but download it
[17:38] <Kano> crazybyte: amd board? or why usb based wifi?
[17:38] <crazybyte> and that is why i was wondering if it is possible that both cores are working the only thing that when threading is used there is no explicit management on which core the thread goes in the case of nosmp
[17:38] <crazybyte> Kano, it's Intel
[17:38] <crazybyte> ah
[17:38] <crazybyte> sorry it has Sis chipset
[17:38] <Kano> the worst chipset you can buy
[17:38] <crazybyte> i mean but usb based wifi that the wifi that is integrated is connecting through usb
[17:39] <Kano> i would return it and get something with centrino logo
[17:39] <crazybyte> i can't return it
[17:40] <crazybyte> Kano, but it is possible that both cores are working even if they aren't visible by using nospm
[17:40] <crazybyte> ?
[17:40] <wilstone> Kano: thanks. i know this is a very stupid question, but I only started on ubuntu yesterday.....how?
[17:41] <crazybyte> wilstone, try using a browser perhaps
[17:41] <wilstone> yeah thanks for that.....
[17:41] <Kano> crazybyte: nope
[17:41] <crazybyte> ok
[17:42] <crazybyte> thx for the info Kano :)
[17:42] <crazybyte> btw Happy New Year!
[17:42] <crazybyte> wilstone: go to that url that you gave
[17:42] <wilstone> what I mean is where do I put it
[17:42] <crazybyte> download the file it there is one there
[17:42] <crazybyte> and or save it
[17:43] <crazybyte> in a file if you get a contents
[17:43] <crazybyte> and run it manually
[17:43] <crazybyte> you can save it anywhere imho
[17:43] <Kano> wget -O firmware-update.sh  http://linux.dell.com/repo/firmware/bootstrap.cgi
[17:43] <Kano> chmod +x firmware-update.sh
[17:43] <Kano> sudo ./firmware-update.sh
[17:44] <Kano> in case of problems try
[17:44] <Kano> sudo bash firmware-update.sh
[17:44] <wilstone> great
[17:44] <wilstone> thanks Kano
[17:44] <wilstone> for your patience


[06:04] <mborzecki> morning
[06:05] <mup> PR snapd#6274 closed: cmd, dirs, interfaces/apparmor: update distro identification to support ID="archlinux" (2.36) <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6274>
[06:09] <mup> PR snapd#6277 opened: centos: enable SELinux support on CentOS 7 (2.36) <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6277>
[07:59] <pstolowski> morning!
[08:00] <mborzecki> pstolowski: hey
[08:00] <mborzecki> mvo: welcome back!
[08:01] <mvo> hey pstolowski and mborzecki ! thanks, glad to be back :)
[08:02] <mup> PR snapd#6272 closed: overlord/snapstate: run 'remove' hook before 'auto-disconnect' <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6272>
[08:03] <pstolowski> hey mvo o/, not resting today after travel?
[08:04] <mvo> pstolowski: I pushed that to the end of the week, I feel I need to take care of things first and see what happend while we were away and all that
[08:05] <mvo> zyga: also good morning to you :)
[08:08] <zyga> Good morning :-)
[08:09] <jamesh> mvo: hi.  I tried pushing an update to test-snapd-dbus-service last week that seems to have got stuck.  Launchpad built it okay, but it never published.  Is it waiting for "request manual review" by any chance?
[08:10] <zyga> mvo: how are you feeling? I though you planned on taking a swap day today
[08:10] <mborzecki> zyga: hey
[08:10] <zyga> o/
[08:11] <mvo> jamesh: good morning (evening in your case I guess) - let me check what is going on there
[08:11] <mvo> zyga: I feel better, I will swap end-of-week-ish I want to see what I missed and if there is anything I can help unblocking today
[08:12] <jamesh> mvo: by the way, your original PR was very helpful in putting together mine
[08:12] <mvo> jamesh: \o/ happy to hear that
[08:13] <mvo> jamesh: thanks for working on this feature!
[08:13] <jamesh> mvo: although I've been running into some problems with my current design for activating system services not through systemd units
[08:14] <zyga> what kind of problems?
[08:15] <jamesh> zyga: when doing non-systemd activation, the dbus-daemon-launch-helper program is spawned to start the daemon
[08:15] <jamesh> zyga: it uses a simplified version of the config file parser that ignores the <include> directive.  That means it doesn't know about the extra servicedir I configure
[08:16] <jamesh> everything works fine for session services and systemd activated services (both system and session)
[08:16] <jamesh> in particular, this is a problem for 14.04 where we can't do systemd activated system services
[08:16] <mvo> jamesh: can you give me the url to the snap that was build but is not published please? I will investigate, I don't see anything in the need-review queue right now
[08:17] <jamesh> mvo: the builds were done with this recipe: https://launchpad.net/~mvo/+snap/test-snapd-dbus-service
[08:17] <jamesh> which says it should publish to edge
[08:18] <mvo> jamesh: thank you
[08:19] <jamesh> zyga: one option would be to refactor the branch to comingle the service files in /usr/share/dbus-1/system-services with the rest of the ones from the system -- that might be a bit messier on core systems though
[08:20] <zyga> mborzecki: shall we merge https://github.com/snapcore/snapd/pull/6111 ?
[08:20] <zyga> neal didn't comment further
[08:20] <mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
[08:20] <zyga> mvo: proposal, could we do a 2.36.3 or 2.37 end of this week
[08:21] <mborzecki> zyga: works for me, you can try and ping him one last time today
[08:21] <zyga> it could go to non-stable snap channel and non-ubuntu distributions
[08:21] <zyga> mborzecki: I'm really happy to iterate on top, just not feel like postpoing helps
[08:21] <mborzecki> zyga: ok, so let's land it
[08:21] <mborzecki> zyga: maybe ask pstolowski to take a look too
[08:21] <zyga> that works :)
[08:22] <zyga> pstolowski: would you mind having a look at the PR above, last one before landing, it refactors the build system around opensuse
[08:22] <zyga> and adds a shared element that can be easily reused for arch and fedora
[08:22] <mvo> jamesh: might be something silly like a expired macaroon that prevents the published, the last upload of this snap was >1y ago. anyway, I re-authed and triggered a new build that should do an upload then
[08:23] <pstolowski> zyga: sure
[08:23] <mvo> jamesh: I keep you updated
[08:23] <mvo> zyga: yeah, 2.37++
[08:23] <mvo> zyga: thanks for raising it
[08:23] <zyga> mvo: it would be lower risk
[08:23] <mvo> zyga: unless master is for some reason unfit for this
[08:23] <zyga> since not stable
[08:23] <zyga> mvo: yeah
[08:23] <zyga> mvo: but we could get some casual testing over xmas period
[08:23] <zyga> mvo: and a better feel of what 2.37.1 might look like
[08:24] <jamesh> mvo: awesome.  I've been running spread tests locally modified to use a local copy of the package, but that's only covering a couple of distros.  It'll be good to see results on the others.
[08:24] <mvo> zyga: yeah, having 2.37 in candidate for christmas would be great
[08:24] <mvo> jamesh: yeah
[08:24] <mvo> jamesh: you can always mail/tg me btw in such case, I was at a sprint last week so couldn't be on irc
[08:28] <jamesh> mvo: do you know how important 14.04 compatibility is for new features?
[08:28] <zyga> (on topic): mvo we should ask JamieBennett  or other stakeholders if 14.04 support extends over the extended paid support period
[08:29] <mvo> jamesh: "Store upload failed:
[08:29] <mvo>     Cannot upload new revisions for name=test-snapd-dbus-service
[08:29] <mvo> " (<- not very helpful, I will ask in the store channel)
[08:30] <mvo> jamesh: 14.04 we still need to support until it is EOL if we want support certain desktopish things that is unfortunate but not too terrible, our 14.04 work was always more server/cloud oriented
[08:30] <mvo> zyga: yeah, we were talking about ESM for snapd
[08:31] <jamesh> mvo: on the desktop side, my branch is fine.  However I thought it would be worth generalising it to system services too, and that's where the problems are
[08:31] <jamesh> so that's something that might be interesting to server/cloud
[08:31] <mvo> zyga: its not clear yet, I am personally not a huge fan because of the support burden (I think if we do it we need another push at systemd and update it to at least 205 there). I think it comes down to how many esm users are interessted in snaps
[08:31] <mvo> jamesh: oh, ok
[08:32] <zyga> mvo: I'm in agreement
[08:32] <mvo> jamesh: thats interessting, what is 14.04 missing here? is systemd too old or something else?
[08:32] <jamesh> but at the same time it is a new feature: it's not going to break any existing snaps
[08:32] <mvo> jamesh: thats good
[08:33] <jamesh> mvo: as my branch is currently designed, services directly activated by the system bus fail due to not being able to find the .service files
[08:33] <jamesh> mvo: on 14.04 systems, this means "all system services"
[08:34] <jamesh> on other distros where the system bus is launched by systemd, we could just tell people to make the service a daemon and be done with it
[08:34] <mvo> jamesh: aha, I see. so on 14.04 it is a fundamental problem because the system dbus is launched via upstart?
[08:35] <jamesh> mvo: yes.
[08:35]  * mvo nods
[08:35] <jamesh> mvo: the other option is to refactor the branch to put service files in /usr/share/dbus-1
[08:35] <jamesh> that means we can't assume the directory is entirely under our control
[08:36] <jamesh> and I'm not sure whether that's desirable on an ubuntu core system
[08:37] <mvo> jamesh: yeah, /usr is not writable on ubuntu-core systems
[08:37] <mvo> jamesh: does dbus look at any other dirs for this? /etc or /run ?
[08:40] <jamesh> mvo: the man page seems to indicate <standard_system_servicedirs/> will include /usr/local/share/dbus-1/system-services and /lib/dbus-1/system-services too
[08:41] <jamesh> although both of those could contain other files
[08:41] <mvo> jamesh: the other files I'm less concerned about but all of those will be read-only on core :/
[08:42] <jamesh> mvo: my current approach was to configure an extra <servicedir> through a config file in /usr/share/dbus-1/system.d, but the simplified config parser dbus-daemon-launch-helper uses ignores the include directive so doesn't see it
[08:43] <jamesh> mvo: we're fine for systemd activated services because they don't use launch-helper
[08:46] <mborzecki> anyone up for a 2nd review on https://github.com/snapcore/snapd/pull/6277 ? it's a backport to 2.36
[08:46] <mup> PR #6277: centos: enable SELinux support on CentOS 7 (2.36) <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6277>
[08:46] <zyga> perhaps mvo?
[08:46] <zyga> since it's a stable backport
[08:46] <mborzecki> mvo: ^^ pretty please
[08:47] <mvo> jamesh: aha, I see. hm, I need to look at the PR I think, I don't have enough state loaded right now about the details
[08:47] <mvo> zyga: yeah, will do, let me open it
[08:56] <mvo> jamesh: i386/amd64 of the snap should be available now
[08:57] <jamesh> mvo: thanks.
[08:58] <mup> PR snapd#6277 closed: centos: enable SELinux support on CentOS 7 (2.36) <SELinux> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6277>
[09:12] <Chipaca> moin moin moin
[09:12] <zyga> hello sir
[09:12] <Chipaca> how tings?
[09:12] <zyga> splendid
[09:12] <Chipaca> woo!
[09:12]  * Chipaca runs to the bank with that
[09:31] <mvo> hey Chipaca ! great to "see" you :)
[09:32] <Chipaca> mvo: I'd say the same, except you shouldn't be here :-)
[09:34] <mvo> Chipaca: nah, its fine, I will bugger off at the end of this week instead :)
[10:14] <zyga> Chipaca: idea, on a small terminal, snap list doesn't show revision and doesn't wrap
[10:14] <zyga> revision is really least useful part we show
[10:29] <Chipaca> zyga: I had adaptive output for things and it got -1'ed
[10:30] <zyga> boooo
[10:30] <zyga> I'm making a quick PR to look at
[10:30] <zyga> very dumb
[10:30] <zyga> but maybe enough :)
[10:30] <Chipaca> zyga: I tried to write it up in the forum, to explore finding a way out of it
[10:36] <cachio> mvo, hey
[10:36] <mvo> cachio: hey, great to see you - how are things?
[10:36] <cachio> 2.36.2 is ready to stable
[10:37] <mvo> cachio: \o/ if all is green and the store is happy I would say: lets do it :)
[10:37] <mvo> cachio: did we get some feedback from the desktop team, did they had a chance to try it as well?
[10:37] <cachio> mvo, nice, I'll ping store people
[10:37] <mvo> cachio: I know we got some +1 from advocay
[10:37] <mup> PR snapd#6278 opened: cmd/snap: modularize snap list processing <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6278>
[10:38] <cachio> mvo, I didn't get any feedback
[11:08] <mvo> cachio: ok, thanks, should be fine, they should run beta anyway :)
[11:09] <mvo> zyga: do you think you could look at 5845 again? iirc I addressed a lot (most?) of your comments
[11:09] <cachio> mvo, I was trying to reproduce the error installing the failing.snap in the failover test
[11:10] <cachio> mvo, https://paste.ubuntu.com/p/RF3SSzgNG8/
[11:10] <cachio> mvo, it is failing and the test exits
[11:11] <mvo> cachio: thanks, looking
[11:11] <cachio> mvo, no extra info, then the system reboots
[11:12] <mvo> cachio: hm, this is interessting: "Dec 08 23:42:33 dec082230-921432 snapd[1773]: daemon.go:670: Waiting for system reboot" and then "Dec 08 23:45:07 dec082230-921432 systemd[1]: snapd.service: Watchdog timeout (limit 5min)!"
[11:13] <mvo> cachio: what is the name of the test again? and does it always fail or is this sometihng new?
[11:14] <cachio> failover
[11:14] <cachio> mvo, it was failing since some weeks
[11:15] <cachio> sporadically
[11:15] <mup> PR snapd#6279 opened: interfaces: tweak deny-auto-connect policy tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/6279>
[11:16] <cachio> mvo, 2.36.2 is stable
[11:17] <cachio> running smoke test now
[11:18] <pstolowski> mvo: hey, will you find some time for review 1 or 2 of my hotplug PRs?
[11:21] <mvo> pstolowski: I hope so
[11:21] <mvo> pstolowski: there is some more going on (some core18 work and prepareing 2.37) but I will put this on my list
[11:30] <pstolowski> mvo: thanks
[11:30] <mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
[11:31] <mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
[11:31] <zyga> brb
[11:31] <pstolowski> mvo: fyi, it's #6100 and #6114
[11:31] <mup> PR #6100: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100>
[11:31] <mup> PR #6114: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>
[11:32] <zyga> mvo: https://github.com/snapcore/snapd/pull/6279/files is broken
[11:32] <mup> PR #6279: interfaces: tweak deny-auto-connect policy tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/6279>
[11:32] <mvo> zyga: uh, sorry, looking
[11:33] <zyga> does it pass for you locally
[11:33] <zyga> unit tests
[11:40] <Wimpress> mvo Chipaca We had an adhoc update from zyga last week about the status of the fontconfg cache fixes. What is the ETA for that landing in stable?
[11:42] <mvo> zyga: silly me, I will fix the issue
[11:43] <mvo> Wimpress: all validations are done and core is ready, cachio  will do the release once he gets green light from the store
[11:43] <cachio> mvo, I already did the release
[11:44] <mvo> cachio: \o/
[11:44] <mvo> Wimpress: ^- here is your answer :)
[11:44] <popey> did 2.36.2 *just* hit stable?
[11:45] <cachio> popey, yes
[11:46] <popey> ok, I was confused. just updated and looked at wikipedia which said it was released last week
[11:48] <zyga> mvo: ah, FYI we learned that the fixes don't work on fedora
[11:48] <zyga> mvo: mborzecki has the details
[11:48] <cachio> 12:48, 29 November 2018 Herakleitoszefesu (talk | contribs) m . . (6,865 bytes) +316 . . (Version 2.36.2; infobox formatting improvement) (undo | thank) Tag: 2017 wikitext editor
[11:49] <cachio> popey, I updated the release 2.36.1, then on 11/29 there was another update
[11:49] <popey> \o/ I love me some fresh updates
[11:50] <cachio> popey, I don't know who did it
[11:50] <popey> I usually do, glad someone else is :)
[11:50] <mvo> zyga: uh, that is sad
[11:50] <mvo> mborzecki: can you fill me in with the details what is missing on fedora?
[11:51] <zyga> mvo: fedora has cache in /usr/share/something
[11:51] <zyga> but I'll let you draw your own conclusions
[11:51] <mborzecki> mvo: aah yes, fedora has fc cache in different location, /usr/lib/fontconfig/cache iirc
[11:51] <mvo> mborzecki: woah, that is a strange location for a cache. very unfortunate as well :(
[11:51] <mborzecki> mvo: heh :P
[11:52] <zyga> mvo: note that the impact on strict and classic snaps is different
[11:52] <zyga> and some classic snaps also differ in impact
[11:53] <zyga> depending on how they are made
[11:53] <mborzecki> mvo: yeah, it's unfortunate, afaik it's only fedora (and rhel probably), arch uses /var/cache, zyga can tell something aboue opensuse, but iirc it's /var/cache too
[11:53] <zyga> tnere
[11:54] <zyga> there's no /usr/lib/fontconfig on opensuse for sure
[11:57] <zyga> pstolowski: replied to your questions on opensuse PR
[11:57] <pstolowski> thx
[12:00] <zyga> pstolowski: with the binary options we can also estimate the number of configurations that we need to support
[12:00] <mvo> zyga, mborzecki: I wonder what we can do, could we play tricks in snap-confine  ? i guess that won't help with clasic confned snaps
[12:00] <zyga> mvo: my opinion is as follows:
[12:00] <mvo> zyga, mborzecki or will a relocatable format v7+uuid help?
[12:00] <zyga> mvo: the issue affects graphical snaps made on top of fedora29 base, our fc cache work doesn't help there
[12:00] <zyga> mvo: strict snaps based on core and core18 are not affected
[12:01] <mvo> zyga: aha, good point
[12:01] <zyga> mvo: but our extra cache may be seen as undesired, we could look at hiding it
[12:01] <zyga> mvo: the issue also affects some classic snaps
[12:01] <zyga> mvo: classic snaps that link with host fontconfig will not be affected by negative performance as cache will be populated by the host mechanism, they will also use the right cache, wherever that might may be
[12:02] <zyga> mvo: we MAY consider a system where where the native package with snapd has the equivalent of your cache mechanism
[12:02] <zyga> that always links to the native libraries
[12:02] <zyga> for the purpose of triggering that cache refresh
[12:02] <zyga> mvo: classic snaps that link to core snap will remain affected
[12:02] <zyga> mvo: but they will benefit from your mechanism
[12:02] <zyga> mvo: to make sure we fully improve the situation I would do the following:
[12:03] <zyga> (some of which are probably optional)
[12:03] <zyga> mvo: 1) we should run different cache mechanism for classic snaps and different for strict snaps
[12:03] <zyga> mvo: 2) for classic snaps we should run the host provided cache and the snapd provided cache
[12:03] <zyga> mvo: 3) the snapd provided cache *should* move to the base snap instead
[12:04] <zyga> mvo: and we should run the one matching the base snap of the classic snap being operated on
[12:04] <zyga> mvo: this would fix all the issues
[12:04] <zyga> mvo: let me know what you think
[12:04] <mvo> zyga: yeah, that sounds sensible
[12:04] <mborzecki> zyga: sgtm
[12:04] <zyga> I especially think 3 is important
[12:04] <zyga> since it means we can deprecate old cache and grow new ones
[12:05] <zyga> and solve the hypothetical f29 based apps in the same go
[12:05] <zyga> I would say that we may make it generic enough that snapd doesn't know it's fonts
[12:05] <zyga> maybe /meta/hooks/snap-installed
[12:05] <zyga> and then that does whatever is needed
[12:05] <zyga> it would be special because base snap hooks may run unconfined
[12:05] <zyga> but base snaps are privileged already
[12:06] <zyga> so I think this is reasonable, it is the same mechanism you implemented but associated with the correct entity
[12:25] <mup> PR snapd#6280 opened: cmd/snap: make 'snap warnings' output yamlish <Created by chipaca> <https://github.com/snapcore/snapd/pull/6280>
[12:41] <Son_Goku> zyga, I felt like garbage all weekend (and Simon Peter did not help...) but I did manage to look over your yak-shaving PR
[12:43] <zyga> and?
[12:46] <zyga> hmm
[12:46] <zyga> prepare error on opensuse https://www.irccloud.com/pastebin/crnFHL37/
[12:47] <zyga> some SNAFU
[12:54] <mup> PR core18#94 closed: hooks: add cloud-init <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/94>
[13:10] <mborzecki> ehh import cycles
[13:10] <mborzecki> refactoring selinux package, got a cycle snap -> dirs -> release -> selinux -> osutil -> dirs
[13:11] <mborzecki> off to pick up the kids
[13:49] <Son_Goku> zyga, I left feedback
[13:49] <zyga> thanks, I will chec
[13:49] <zyga> check*
[13:49] <Son_Goku> zyga, also, wtf is up with the opensuse golang compiler?
[13:49] <zyga> no idea
[13:49] <Son_Goku> isn't -std a normal flag?
[13:49] <zyga> not broken on opensuse
[13:50] <zyga> er
[13:50] <zyga> on tumbleweed
[13:50] <zyga> at least since I updated this morning
[14:17] <mup> PR snapcraft#2419 closed: project: state file path change <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2419>
[14:25] <ackk> hi, I'm having an issue with multipass on xenial: https://paste.ubuntu.com/p/7HrZTvBh3k/
[14:25] <ackk> it mentions incompatible openssl version
[14:29] <sergiusens> ackk: I pinged someone who can help you with that
[14:29] <sergiusens> mvo: we need to discuss the `.snapcraft` thing. Can you add the reasons for needing it to https://bugs.launchpad.net/snapcraft/+bug/1805219 ?
[14:29] <mup> Bug #1805219: .snapcraft <19.04> <19.04-external> <Snapcraft:Triaged> <https://launchpad.net/bugs/1805219>
[14:30] <sergiusens> mvo: I think I want to go with `snapcraft.yaml` at the root of the project and allowing a `.snapcraft` as the root for assets likes hooks, gui and such
[14:40] <ackk> sergiusens, thanks
[14:49] <Saviq> ackk: hey, while our snap is confined "classic" we might stumble upon such problems, but we're moving towards strict confinement very soon so those should go away
[14:50] <ackk> Saviq, does multipass currently only work on bionic?
[14:50] <ackk> (this is a xenial host)
[14:50] <Saviq> ackk: in any case, it should work on xenial, can you please file an issue here https://github.com/CanonicalLtd/multipass/issues/new and we'll try and fix asap
[14:53] <ackk> Saviq, https://github.com/CanonicalLtd/multipass/issues/518
[14:53] <Saviq> ackk: thank you!
[14:53] <ackk> Saviq, np
[15:04] <mvo> sergiusens: in a meeting, I opened the bug and have a look
[15:04] <dot-tobias> Hi alan_g , short question concerning mir-Kiosk: I‘m running the chromium-mir-Kiosk snap on mir-Kiosk. After mir-Kiosk gets refreshed, the browser snap does not get restarted automatically. This leaves my device (meant to be always-on) with a black screen until I manually restart the chromium snap. Is this a problem specific to the chromium snap (Xwayland) or in general? And can I do something abo
[15:04] <dot-tobias> ut it? Thanks!
[15:09]  * zyga -> quick context switch for taxes and dinner
[15:19] <ackk> Saviq, does multipass currently pick proxy options from the hosts' /etc/environment ?
[15:20] <ackk> Saviq, from the log I see it can't access cdimage.ubuntu.com, and this host has a proxy set
[15:23] <Saviq> ackk: it's a systemd service, so no, it doesn't see that environment, you have to `snap set multipass proxy.http …` and similarly for https
[15:23] <ackk> Saviq, ah I see, thanks
[15:23] <alan_g> dot-tobias, I'd imagine that's a problem with the chromium-mir-kiosk example. You do realise that's an example to work from, not a stable, supported snap?
[15:25] <ackk> Saviq, ah, so setting the proxy the daemon runs, but those opensssl errors are stil three
[15:26] <Saviq> ackk: yeah it won't be able to access any https resources most likely
[15:27] <ackk> Saviq, fwiw I have the same errors on my cosmic machine
[15:27] <dot-tobias> alan_g : Yes, I read that in the Ubuntu forums. Sorry to keep pestering you about that, it’s just I do not have a lot of understanding about the graphics stack and thus not the faintest idea where to start improving / integrating this into my snap … and regarding my question today, wanted to make sure it’s not a known issue with mir-Kiosk before I start sinking hours into debugging the chromium sn
[15:27] <dot-tobias> ap 😊 again, sorry to keep bothering you.
[15:27] <ackk> Saviq, multipass seems to be working though
[15:32] <Saviq> ackk: as long as it (multipass itself) doesn't need to access any https resources, it should work indeed
[16:05] <mup> PR snapd#6281 opened: interfaces/builtin: add Multipass interfaces <Created by gerboland> <https://github.com/snapcore/snapd/pull/6281>
[16:28]  * Chipaca loves that unplugging the headset now disables the trackpad
[16:28]  * Chipaca does not actually love it
[16:28]  * Chipaca needs to reboot
[16:30] <cachio> mvo, hey, is it any way to set the StartLimitInterval for a snap service?
[16:30] <okamis> Hello, I installed slack and ran it as root by mistake, how do I purge the configuration files?
[16:39] <Saviq> okamis: /root/snap/slack should be everything it saved
[16:40] <Saviq> or, if ran through sudo, it might be /home/your_user/snap/slack - sudo doesn't change $HOME normally
[16:41] <cachio> mborzecki, do you kbiw if it is any way to set the StartLimitInterval for a snap service?
[16:51] <Saviq> cachio: not according to https://docs.snapcraft.io/snapcraft-app-and-service-metadata/8335
[16:52] <mvo> cachio: I think not :/
[16:52] <mborzecki> cachio: afaik there's no way currently
[16:52] <cachio> mvo, ok, so I need to make it manually
[16:53] <cachio> mvo, i SEE https://paste.ubuntu.com/p/NdFRpYHHzP/
[16:53] <cachio> on boards
[16:54] <cachio> at least on pi3
[16:54] <mvo> cachio: what does journalctl -u  test-snapd-daemon-notify.notify say?
[16:54] <mborzecki> cachio: the service shouldn't fail, provided the interface is connected at this stage
[16:55] <cachio> mvo, I am executing it again
[16:56] <cachio> mborzecki, not sure if when it fails the interface is connected
[16:56] <cachio> because part of this test is with the interface diconnected
[16:56] <mup> PR snapcraft#2422 closed: clean: user friendly message when cleaning <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2422>
[16:57] <mborzecki> cachio: yup, there should be an echo before, or maybe extend debug to show snap interfaces?
[16:57] <cachio> when the test fails the interface is disconnected
[16:58] <cachio> I already check that
[16:58] <cachio> mborzecki, could that be affecting?
[16:59] <sergiusens> joc: hey, what does this mean? https://www.irccloud.com/pastebin/Nh31ajqw/
[17:01] <mborzecki> cachio: maybe, do you have a log from spread?
[17:02] <cachio> I have a debug session here
[17:02] <cachio> mborzecki, I just created it
[17:02] <cachio> mborzecki, what info could help?
[17:03] <cachio> mborzecki, this is the spread log
[17:03] <cachio> https://paste.ubuntu.com/p/dq7JgX7RmF/
[17:05] <cachio> mvo, external:ubuntu-core-16-arm-32 .../tests/main/interfaces-daemon-notify#  journalctl -u  test-snapd-daemon-notify.notify
[17:05] <cachio> -- No entries --
[17:06] <cachio> mvo, this could help
[17:06] <cachio> https://paste.ubuntu.com/p/CcmqqPsx34/
[17:06] <cachio> mvo, this shows the start-limit-hit
[17:11] <Chipaca> cachio: if a test is breaking a service and such, and it doesn't do reset-failed, it'll sometimes not start
[17:11] <Chipaca> not sure if that's what you're seeing though
[17:11] <Chipaca> cachio: but that's what i had to do with the nfs-support test
[17:12] <cachio> Chipaca, the test is disconnecting the interface and trying to start the service
[17:12] <cachio> and checking the log contains denials
[17:12] <cachio> but those denials don't appear so the test fail
[17:13] <cachio> Chipaca, and the problem is that we are hitting the start limit
[17:13] <Chipaca> cachio: right
[17:13] <cachio> and it is just happenning on core for arm
[17:14] <cachio> Chipaca, what do you mean with "breaking a service"?
[17:14] <Chipaca> cachio: what's stopping the service, in this case?
[17:16] <mborzecki> cachio: about that fedora 29 bug, i think we'll have to remote the kernels manually
[17:17] <cachio> mborzecki, ok
[17:17] <cachio> I'll do that
[17:18] <mborzecki> cachio: something like this:  `dnf autoremove -y $(rpm -qa kernel-core | sort -r | tail -1)`
[17:18] <cachio> Chipaca, the test stops the service
[17:19] <cachio> disconect -> stop -> loop with start
[17:19] <cachio> we check that snap logs contains denials
[17:19] <Chipaca> cachio: but
[17:20] <Chipaca> cachio: it seems the service is exiting with error after getting the permission denied
[17:20] <Chipaca> ah
[17:20] <Chipaca> cachio: the snap is buggy
[17:21] <Chipaca> cachio: the daemon says it's "simple", but it's not a daemon at all
[17:22] <cachio> Chipaca, this is the snap.yaml https://paste.ubuntu.com/p/NxtnkdYVjy/
[17:22] <Chipaca> yes i'm looking at it here
[17:22] <cachio> Chipaca, why it is not a daemon?
[17:22] <Chipaca> it says "daemon: simple"
[17:22] <Chipaca> cachio: because it just runs a command and exits?
[17:22] <cachio> Chipaca, ahh, ok
[17:23] <Chipaca> cachio: and
[17:23] <Chipaca> cachio: a shell script exits with the exit status of the last command it executed
[17:23] <Chipaca> cachio: which means that this thing exits with error
[17:23] <Chipaca> so systemd tries to restart it a few times, and then gives up
[17:23] <Chipaca> so the test is a race between systemd restating the thing, and spread running the test
[17:25] <Chipaca> cachio: easiest fix, probably, is to add a "true" after the systemd-notify call in the script :-), and (optionally? but probably best) set "daemon: oneshot"
[17:25] <cachio> Chipaca, so we should make sure we exit 0
[17:25] <cachio> I'll try with oneshot
[17:26] <Chipaca> k
[17:26] <cachio> Chipaca, thanks
[17:26] <Chipaca> cachio: let me know how it goes
[17:44] <cachio> Chipaca, one shot does not work
[17:44] <cachio> I think I made it work
[17:45] <cachio> oneshot fails to start
[17:45] <cachio> because the interface is not connected
[17:45] <cachio> so it exits with status 1
[17:45] <Chipaca> cachio: you made the script not exit with error first?
[17:45] <cachio> Chipaca, no
[17:45] <Chipaca> cachio: you did the optional thing, and not the non-optional thing
[17:45] <Chipaca> :-)
[17:45] <cachio> I just installed and connected to the interface
[17:46] <cachio> together
[17:46] <cachio> because between the snap is installed in prepare and the interface is connected during the execution
[17:46] <cachio> systemd is retrying the service
[17:47] <cachio> Chipaca, what do you suggest'
[17:47] <cachio> ?
[17:48] <Chipaca> cachio: add an '|| true' to the systemd-notify call, or a 'exit 0' after it or something
[17:51] <cachio> Chipaca, 0
[17:51] <cachio> ok
[17:51]  * Chipaca 1
[18:04] <cachio> Chipaca, well this also works well
[18:04] <cachio> I'll create the PR
[18:08] <roadmr> sergiusens or kyleN : what's the expected Ubuntu version to host snapcraft development? (kind of a trick question - I tried bionic but some of the deps don't exist as noted in the docs, so I went down to xenial) Is it xenial?
[18:10] <mup> PR snapd#6282 opened: tests: force test-snapd-daemon-notify exit 0 when the interface is not connected <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6282>
[18:33] <sergiusens> roadmr: it is xenial, given away by the debian/changelog still there and the lack of a base in snapcraft.yaml 😉
[18:34] <roadmr> sergiusens: nice - so how do you guys get black (which requires python 3.6) to run on xenial (which has python 3.5)?
[18:34] <roadmr> I disabled the black portion of ./runtests.sh for now, am just curious, this is not blocking me or anyting
[18:34] <sergiusens> roadmr: `snap install black --edge --devmode`
[18:35] <roadmr> sergiusens: ah, perfect :) thanks!
[18:35] <roadmr> having two ways to install stuff is confusing. Hopefully soon there'l be only one :D
[18:35] <sergiusens> I intend to make all our devtools a single snap to bootstrap faster, but haven't gotten around to it yet
[18:35] <roadmr> sergiusens: it didn't take me a long time to bootstrap in any case, just black was baffling me
[18:37] <sergiusens> roadmr: yeah, but imagine not needing to ask me which dev environment is the expected one and have a snap with the interpreter, the required dependencies and tools 😉
[18:37] <roadmr> sergiusens: \o/ I like that future heh
[22:27] <mup> PR snapcraft#2423 opened: Do not use `bash` package name in staging <Created by jdahlin> <https://github.com/snapcore/snapcraft/pull/2423>
[22:27] <jdahlin> ^ we found some issues related to the `bash` package name already being registered on staging


[12:35] <LeeJunFan> ugh, out of the frying pan and into the fire. I setup my piped while statement in ()'s and now it won't call the 2 functions contained within on one system, the other works fine.
[12:41] <kiko> dude, bash functions are crack
[12:41] <lifeless> good morning
[12:41] <lifeless> kiko: at 3 am wtf is wrong is hardly going to be me
[12:43] <lifeless> and I'll bet it was stub.
[12:44] <kiko> hey lifeless
[12:44] <kiko> that may be
[12:44] <kiko> it is still derailed
[12:44] <lifeless> I just enabled it 30 seconds ago
[12:45] <kiko> you are making tears come out of my eyes
[12:46] <lifeless> thats cause I just got up 35 seconds ago
[01:18] <dilys> Merge to devel/launchpad/: [r=mark]  Use sortkey instead of the dbschema value in sortkey columns for specs (r3386: kiko)
[01:19] <kiko> yes!
[01:34] <Burgwork> grumble at the bug email change
[01:48] <dilys> Merge to devel/launchpad/: [trivial]  Add 1.0.1 revision of Code of Conduct from Colin Watson. (r3387: James Troup)
[02:23] <dilys> Merge to devel/launchpad/: [r=stub]  make send-bug-notifications.py connect as a specific db user. (r3388: Bjorn Tillenius)
[02:52] <dilys> Merge to devel/launchpad/: [trivial]  Remove some mirror{content,sourcecontent} files that weren't used nor tested. (r3389: Guilherme Salgado)
[03:13] <kiko> go jamesh!
[03:30] <mpt> Gooooooooooooooooooooooooooooood afternoon Launchpadders!
[03:30] <ajmitch> hi mpt
[03:34] <dilys> Merge to devel/launchpad/: [r=bradb]  add a bug listing/search for projects (r3390: James Henstridge)
[03:53] <mpt> spiv, ping
[03:54] <spiv> mpt: pong
[03:55] <mpt> spiv, I'm about to upgrade to Dapper -- will I have to do anything to my LP development setup?
[03:55] <spiv> mpt: Heh, me too ;)
[03:55] <spiv> AFAIK, no.  You're already using postgres 8.1?
[03:55] <mpt> yes
[03:56] <mpt> (tests wouldn't pass if I wasn't)
[03:56] <spiv> Then it should be fine, I think.
[03:57] <mpt> okie dokie
[03:57] <mpt> I'm just going outside into archive.ubuntu.com, I may be some time -
[03:59] <spiv> :)
[03:59] <jamesh> mpt: the postgres/dapper upgrade problem I reported earlier has been fixed
[04:07] <lifeless> kiko-zzz: please do your reviews
[04:07] <lifeless> spiv: you have two reviews queued
[04:08] <lifeless> jamesh: theres one in your queue too that is getting old
[04:09] <jamesh> lifeless: yeah.  I'll do it today
[04:09] <lifeless> thanks
[04:09] <lifeless> I want us to keep the latency down on reviews, it will keep the queue small and managable.
[04:09] <lifeless> to that end I'm adopting kikos nag-had.
[04:09] <lifeless> s/had/hat/
[06:02] <mpt> spiv, how's it going?
[06:03] <spiv> mpt: Good, after wrestling with a broken mirror...
[06:04] <mpt> So, I appear to have two problems so far
[06:04] <mpt> (1) everything crashes on launch
[06:05] <mpt> (2) "E: /var/cache/apt/archives/pybaz_1.5pre1-1_all.deb: trying to overwrite `/usr/lib/python2.4/site-packages/pybaz/__init__.py', which is also in package python2.4-bazaar
[06:05] <mpt> "
[06:05] <spiv> I'd say that python2.4-bazaar and pybaz aren't supposed to co-exist.  Hmm.
[06:06] <mpt> which to keep?
[06:07] <mpt> (Wow, Opera launches, though Firefox and Epiphany both flame out)
[06:07] <jamesh> python2.4-bazaar is probably the right now
[06:07] <spiv> launchpad-dependencies has a suggests for python2.4-bazaar
[06:07] <spiv> And says nothing about pybaz.
[06:08] <jamesh> hmm
[06:08] <jamesh> pybaz is the one in dapper/universe though
[06:08] <mpt> So I should install launchpad-dependencies?
[06:10] <spiv> I don't actually see a python2.4-bazaar package in dapper anywhere.  Regardless, for launchpad we have pybaz in rocketfuel, so you don't need a system version.
[06:11] <mpt> ok
[06:11] <spiv> The only time you'd need pybaz on your system would be to run baz2bzr conversions, I think.
[06:12] <lifeless> spiv: python2.4-bazaar is the one we want for baz2bzr
[06:12] <jamesh> spiv: python2.4-bazaar is the name used in Keybuk's repo.  The copy in dapper is called pybaz and appears to have come from debian
[06:12] <lifeless> oh right, I forgot about that little confusion.
[06:13] <jamesh> so launchpad-dependencies suggests a package that doesn't exist in the dapper repos
[07:23] <mpt> Well, that all seems to work pretty well
[07:23] <mpt> apart from the icons and scrollbars
[08:43] <carlos> morning
[08:46] <mpt> hi carlos
[08:47] <mpt> BjornT, ping
[08:47] <BjornT> hi mpt
[08:47] <mpt> BjornT, you're awake! great
[08:49] <mpt> BjornT, I had a bug ordering failure with bugtask-search-pages.txt, and bradb proposed fixing it by adding "sorted[...] " to line 30
[08:50] <mpt> That seems odd to me -- I think maybe the underlying code should be sorting the bugs, rather than the test
[08:50] <mpt> What do you think?
[08:50] <mpt> (this is after merging severity and priority)
[08:50] <mpt> jamesh, available?
[08:50] <jamesh> mpt: yeah
[08:51] <mpt> jamesh, bugzilla-import.txt line 368 or thereabouts, the Evolution task for bug 5 has severity MEDIUM. Why is this, since the imported bug was a 'blocker'?
[08:51] <Ubugtu> Malone bug 5 in rosetta "Plone Placeless Translation Service metadata missing from po files" [Wishlist,Fix released]  http://launchpad.net/bugs/5
[08:51] <mpt> no, Ubugtu, not *that* bug
[08:52] <BjornT> mpt: yeah, i agree, the underlying code should produce a stable ordering. i even made it so once, but it seems to have regressed.
[08:53] <jamesh> mpt: because the import doesn't set the status or severity on the upstream task it creates
[08:53] <jamesh> mpt: just the "evolution (Ubuntu)" task
[08:53] <lifeless> BjornT: obviously you did not write a test ;)
[08:53] <mpt> BjornT, should I leave it as an XXX then?
[08:53] <lifeless> BjornT: therefor it is undefined.
[08:53] <mpt> lifeless, there is a test, and it's failing in my branch :-P
[08:53] <jamesh> mpt: the bug status synching code would eventually assign the correct status
[08:53] <mpt> but I don't know why
[08:53] <mpt> jamesh, should it be UNKNOWN instead then?
[08:53] <BjornT> lifeless: or someone changed the test as well ;)
[08:53] <lifeless> mpt: well, are you getting a page test failure or a system test failure ?
[08:54] <lifeless> BjornT: true enough :)
[08:54] <mpt> lifeless, both
[08:54] <BjornT> mpt: i'll have a quick look, there might be a one-line fix for it.
[08:54] <jamesh> mpt: it would be if official_malone was set to False for evolution in the sample data
[08:55] <jamesh> mpt: the default for tasks on official_malone=True products is unconfirmed/normal
[08:55] <mpt> ah
[08:55] <mpt> jamesh, so we're adding a watch despite Evolution using Malone officially in sampledata
[08:55] <mpt> That's a bugzilla-import-ism, I guess
[08:56] <jamesh> mpt: the Product.official_malone stuff didn't exist back when I wrote those tests
[08:56] <jamesh> mpt: perhaps changing the test to use a gnome-terminal bug would do?
[08:56] <BjornT> mpt: hmm, the ordering should be stable. what do you order by now? (instead of priority,severity)
[08:57] <mpt> BjornT, -importance
[08:57] <mpt> which is severity renamed, with a couple of value changes
[08:57] <BjornT> mpt: and if you look at the importance of each bugtask, does the ordering make sense?
[08:59] <lifeless> spiv: pinf
[08:59] <spiv> lifeless: pong
[09:00] <lifeless> spiv: I'm here to confirm you heard my nag on reviews
[09:00] <mpt> BjornT, on /people/name16/+reportedbugs for example, the bugs are indeed sorted by descending importance, but within each importance the ordering appears random
[09:00] <spiv> lifeless: I heard :)
[09:00] <mpt> 3, 1, 9, 10, 2
[09:00] <lifeless> spiv: ok, 'nuff said.
[09:00] <spiv> lifeless: I'm half-way through one right now.
[09:00] <lifeless> I just hadn't heard, so assumed dropped packets.
[09:02] <BjornT> mpt: what you should look at is the value of bugtask.id, since that is what provides the stable ordering. if you want to order by bug id as well, you have to specify that explicitly.
[09:03] <mpt> hmmm
[09:03] <mpt> ok
[09:03] <mpt> It would be nice if I didn't have to ;-) but ok
[09:03] <mpt> i.e. "no matter what, if everything else I'm sorting by turns out the same, resort to chronological"
[09:04] <BjornT> mpt: it is chronological, but with respect to the creation of the bugtask.
[09:04] <mpt> ohhhhhh
[09:05] <BjornT> mpt: we could look at the bug as well, but would that be in chronological or reversed chronological order? sometimes you want the former, sometimes the latter.
[09:05] <mpt> sure
[09:06] <mpt> but whichever you want, you don't want 3 1 9 10 2 :-)
[09:08] <BjornT> mpt: i guess you could insert the following in BugTaskSet.search(), right before orderby_arg.append('BugTask.id')
[09:09] <BjornT> if 'Bug.id' not in orderby_arg and '-Bug.id' not in orderby_arg:
[09:09] <BjornT>   orderby_arg.append('Bug.id')
[09:09] <BjornT> or something like that
[09:10] <BjornT> that will probably break a few tests though :)
[09:12] <lifeless> jamesh: care to do a small hack to pending reviews for me ?
[09:12] <lifeless> jamesh: I'd like two extra columns. Reviewer, and days-old
[09:13] <mpt> BjornT, why not just change the "Make sure that the result always is ordered" line?
[09:13] <mpt> from BugTask.id to Bug.id
[09:14] <BjornT> mpt: because the results might include more than one bugtask for each bug, so you have to resort to bugtask.id in order to ensure a stable ordering.
[09:14] <mpt> BjornT, I thought it was a bug whenever that happened anyway
[09:14] <mpt> i.e. returning the same bug twice in any search
[09:16] <BjornT> mpt: i wouldn't say it's a bug, but we should present it better in the UI, than simply two rows.
[09:16] <mpt> hmm, fair enough
[09:17] <mpt> we might group them together somehow
[09:23] <mpt> BjornT, that code fixes the pagetest, thanks
[09:23] <mpt> but not the doctest, curiously
[09:23] <mbp_> hi
[09:25] <jamesh> https://staging.ubuntu.com/projects/launchpad/+bugs <- yay
[09:25] <mpt> jamesh, excellent
[09:26] <lifeless> jamesh: what do you think ?
[09:26] <lifeless> mbp_: welcome to The Channel
[09:26] <jamesh> lifeless: doing the age should be trivial.  Adding a reviewer column is a little more effort
[09:26] <mpt> jamesh, if you used product displayname instead of "name", that Product column would get a lot narrower
[09:27] <lifeless> jamesh: could we reformat the pending reviews page to make that easier? I'm happy to do so
[09:27] <lifeless> but I'd -really- like it if reviewers could go to your page not the wiki page to see what of theirs is pending and old.
[09:27] <jamesh> lifeless: the age is trivial because I'm already reading the dates
[09:28] <jamesh> lifeless: I just need to add a little more to parse the page headings
[09:28] <lifeless> jamesh: yes
[09:28] <lifeless> jamesh: if when you write that parser, having the headers different for the reviewers would help, let me know, or just DoIt.
[09:29] <jamesh> mpt: are you sure?  https://staging.ubuntu.com/products/launchpad-upload-and-queue/ <- name="launchpad-upload-and-queue" while displayname="Launchpad Upload and Queue system"
[09:29] <mpt> jamesh, yes, because the latter will wrap while the former doesn't
[09:29] <jamesh> shrug
[09:30] <jamesh> mpt: I used Product.name because that's what is used on the bug pages
[09:31] <jamesh> mpt: if you want to experiment, the file to edit is lib/canonical/launchpad/templates/batchnavigator-table-view.pt
[09:31] <mpt> hmm, you have a point there
[10:24] <mpt> BjornT, could I bother you for another five minutes?
[10:25] <BjornT> sure
[10:25] <mpt> BjornT, https://chinstrap.ubuntu.com/~dsilvers/paste/file5j0KoI.html
[10:26] <mpt> Either my two tests have the same silly mistake in it, such that they're picking up the output of the previous test
[10:26] <mpt> or I don't know Python
[10:26] <mpt> probably both
[10:32] <mpt> I think it's the tests, because it keeps claiming I sent something that I actually sent 3~4 tests previously
[10:32] <mpt> (emailinterface.txt line 738)
[10:35] <lifeless> are they in separate .txt files ?
[10:36] <mpt> no, all in emailinterface.txt
[10:37] <mpt> but then there are already half a dozen tests of the same type in that file
[10:37] <mpt> so that shouldn't matter
[10:39] <BjornT> mpt: yeah it's strange. i'm not sure what the problem is. what happens if you insert '>>> stub.test_emails = [] ' right before your tests?
[10:42] <BjornT> mpt: ah. how did you change PriorityEmailCommand?
[10:43] <mpt_> BjornT, that produces "IndexError: list index out of range"
[10:44] <BjornT> mpt_: ah. how did you change PriorityEmailCommand?
[10:45] <dilys> Merge to devel/launchpad/: [r=lifeless]  Added support to guess the place where the KDE .po files should be imported. Include tests. (r3391: Carlos Perello Marin)
[10:45] <carlos> go, go, go!
[10:46] <carlos> hmm, no stub around...
[10:46] <mpt_> BjornT, deleted it
[10:46] <mpt_> ohhhh
[10:48] <BjornT> hmm, i think i need to look at your changes to mail/*.py
[10:49] <mpt_> BjornT, you're probably the most appropriate reviewer for this branch anyway
[10:49] <mpt_> are reviewers allowed to fix bugs? :-)
[10:50] <lifeless> mpt_: yes
[10:50] <lifeless> mpt_: we can always get salgado or spiv or jamesh or kiko or I or steveA to give it one more once over
[10:53] <mpt_> ok
[10:55] <carlos> lifeless: I guess I should ask you as stub is not around
[10:56] <carlos> lifeless: I'm going to force a source code update on staging to test the KDE path I just landed
[10:56] <carlos> lifeless: is that ok for you?
[10:56] <lifeless> carlos: I'm not aware of anything special being done on staging - go ahead
[10:56] <carlos> ok, thanks
[11:13] <carlos> staging is back
[11:24] <SteveA> spiv: ping
[11:24] <SteveA> jamesh: ping
[11:26] <jamesh> SteveA: pong
[11:26] <SteveA> jamesh: quick call?
[11:26] <jamesh> okay.  skype or phone?
[11:26] <SteveA> skype.  i'll get my headset
[11:26] <jamesh> or sip (although I had trouble calling lifeless earlier
[11:27] <carlos> hmm, I did the staging update too early, my patch was not yet in place
[11:27] <SteveA> i don't have a sip system set up yet
[11:27] <carlos> stub: hi, I did a staging update to test the patchset I just asked you to cherrypick
[11:27] <SteveA> i do hope the admins get asterisk set up soon
[11:27] <carlos> stub: but I will need to do it again because seems like the mirror was missing that revision
[11:28] <jamesh> we were using the ekiga.net registration service
[11:28] <carlos> stub: ok?
[11:28] <jamesh> but it had issues with us both being behind firewalls
[11:29] <SteveA> jamesh: can you try restarting skype?
[11:29] <jamesh> okay
[11:31] <stub> carlos: ok.
[11:33] <carlos> mpt: http://ds21.cc.yamaguchi-u.ac.jp/~eigo/temp/rosetta.jpg
[11:33] <carlos> mpt: have you seen that?
[11:34] <carlos> The bug report seems to be talking about workrave integrated with launchpad!! :-D
[11:35] <mpt> ow
[11:36] <mpt> carlos, I tried to install Internet Explorer today to debug those problems, but the installer crashed
[11:36] <mpt> I reported a bug on it
[11:36] <carlos> mpt: the 'funny' part is that he was able to use the translation form and after some submissions, he got that problem
[11:37] <mpt> oh, interesting
[11:37] <mpt> so normally it isn't like that?
[11:37] <carlos> https://launchpad.net/malone/bugs/37994
[11:37] <Ubugtu> Malone bug 37994 in rosetta "Centre/Left column overlap in IE6. CSS-y. Screenshot" [Normal,Unconfirmed]
[11:37] <carlos> "I translated about 5 pages and then suddenly the left coloumn overlapped the centre column"
[11:38] <jamesh> https://staging.ubuntu.com/projects/launchpad/+bugs
[11:39] <mpt> weird
[11:42] <carlos> staging is back
[11:47] <carlos> stub: please, ignore the cherry pick request, I found a bug
[11:47] <stub> ok
[11:48] <stub> Whatever updates you make though will probably depend on that patch, so if I cherry pick a later fix at some point I'll need to bring in r3391 too.
[11:48] <stub> carlos: Do you have an ETA? I haven't got any rollouts scheduled this week yet.
[11:49] <carlos> stub: well, the fix is already done
[11:49] <carlos> stub: and I'm going to add the test
[11:49] <carlos> so, I think 30 minutes + PQM + staging update
[11:49] <carlos> it's a trivial fix
[11:49] <carlos> and is easy to test too
[11:49] <stub> ok
[11:53] <lifeless> stub - did you bounce the authserver in your last rollout ?
[11:53] <stub> nope
[11:56] <lifeless> could you refresh its code and bounce it ?
[11:56] <lifeless> then I can finish the conversion of vostok to a standard setup
[11:57] <lifeless> stub: I spoke with elmo about us doing ssh from pqm@balleny to the appservers. Hes happy if we use a dedicated key that PQM has to do that
[11:57] <lifeless> also, was the email I sent you about the layout on vostok sufficiently clear that you can do it yourself from here on out ?
[11:58] <stub> yay.
[11:58] <stub> I'll still pull from jubany though
[11:58] <stub> I'll read it and let you know ;)
[11:58] <lifeless> makes sense to me
[11:58] <ddaa> hey stub
[11:58] <lifeless> jubany is != appservers
[11:59] <ddaa> stub: I would like if you could handle bzrsyncd@gandwana rollouts from now on
[11:59] <stub> Ahh... I filed it.
[11:59] <stub> ddaa: ok.
[12:00] <ddaa> I'll keep you posted if I need to make a cherrypick at some point.
[12:00] <stub> This is all getting a bit heavy weight - time to think about improving and semi-automating rollouts.
[12:00] <lifeless> stub: yes
[12:01] <lifeless> ddaa: why is bzrsyncd a different user? if it was the same user no extra rollout would be needed
[12:02] <stub> It was often running a different branch before. If that has settled down we can run it from a central launchpad tree.
[12:03] <stub> (but no reason to not keep it running as a seperate unix user - we should do more of that)
[12:03] <lifeless> just put them all in group launchpad
[12:03] <lifeless> ?
[12:03] <ddaa> I like the ability to poke it directly.
[12:04] <stub> That is what is happening on drescher, with different users all members of the lp_archive group so they can access the code (although it is world readable anyway...)
[12:04] <ddaa> It's great for fixing problems quickly.
[12:04] <lifeless> ddaa: define poke please, so stub and I dont break your poking
[12:05] <ddaa> stracing, running manually, rolling out fixes myself
[12:05] <ddaa> killing if necessay
[12:05] <ddaa> though I will inform you whenever I change the production code, so we know where the buck lies
[12:06] <lifeless> rollout is the issue, because if its a central tree, then you really need access to write to that tree
[12:06] <ddaa> yup
[12:06] <lifeless> and if its a central tree rollout affects all the services
[12:06] <stub> As long as fixes get rolled out to rocketfuel asap and we are notified to cherry pick them into the production branch we should avoid blatting the fixes. And blatting will happen more now I'm thinking of automating software pushes to some extent
[12:07] <ddaa> I'm all for automation. That would make it cheap to keep a separate tree.
[12:07] <lifeless> ddaa: when was the last time you needed to write new code to fix a branch scanner bug and roll it out asap ?
[12:08] <ddaa> quite some time ago, but "past performance is no indicator of the future"
[12:08] <ddaa> the point is that the ability to do it adds some significant robustness to the process
[12:08] <ddaa> at the expense of some exceptional communication
[12:08] <lifeless> actually, I think it is :). We have a lot of cron job daemons now. But I'll leave this to you and stub, I'm happy either way.
[12:09] <lifeless> What I'm not keen on is any non-reviewed-and-committed-to-rocketfuel code running against the production database.
[12:09] <carlos> stub: I just sent the merge request to pqm
[12:09] <ddaa> I would hope that by now my reputation for anal retention would precede me in such matters.
[12:10] <lifeless> ddaa: the thing is, I don't understand what differentiates what you are asking for from that.
[12:11] <ddaa> for example: ability to alter the frequency or the arguments of the cronjob, ability to add debugging code
[12:11] <ddaa> ability to run tests (e.g. email tests in the future) as the user the script is running as
[12:12] <ddaa> (or db access tests)
[12:13] <ddaa> I expect the branch scanner to significantly grow in size and complexity in the future. So it will likely not be always as stable as it is now.
[12:15] <stub> speaking of cronjobs, we are getting to the stage of needing to migrate to some sort of central scheduler to smooth database load and contention
[12:15] <ddaa> music to my ears :)
[12:16] <ddaa> something resembling a buildd, maybe?
[12:17] <stub> perhaps. I don't know enough about buildd to make that call.
[12:18] <ddaa> I mean in terms of overall architecture
[12:18] <stub> Thats what I mean too ;)
[12:18] <stub> 'buildd is like this daemon that builds stuff'
[12:19] <ddaa> a master service handing out jobs to any number of slaves, the master centralises the smarts about what to given to who when
[12:19] <stub> Yup
[12:19] <ddaa> the slaves being quite stupid, but doing all the processing
[12:19] <stub> Although it can be dumber, as we won't need to trigger arbitrary jobs on arbitrary hosts
[12:20] <ddaa> that's a theme that is quite recurrent in my work
[12:22] <ddaa> stub: do you need any information to handle branch-scanner rollouts?
[12:22] <lifeless> stub: is there a password for launchpad@production-server ?
[12:22] <stub> Probably - I'll need to have a poke around first
[12:22] <stub> lifeless: You mean the unix account? I have no idea.
[12:22] <lifeless> elmo: ?
[12:23] <stub> passwords suck
[12:24] <lifeless> yes
[12:24] <lifeless> but I need to bootstrap the ssh key
[12:27] <lifeless> can you ping me when the authserver has been bounced ?
[12:30] <dilys> Merge to devel/launchpad/: [trivial]  Fixed a bug raised by real world data after my KDE changes. If the IPOTemplate is not yet imported, we cannot guess the IPOFile. Includes a test (r3392: Carlos Perello Marin)
[12:31] <lifeless> and - when you've generated the tree for the rollout, can you leave it around for me ?
[12:31] <ddaa> lifeless: do you know when will the branch puller will be rolled out by DBA next?
[12:32] <lifeless> ddaa: once the authserver is bounced
[12:32] <ddaa> It appears to be dead ATM, but I could not get a sysadmin to pong me back yesterday
[12:32] <ddaa> and of course, I was unable to do anything short of seeing that the accumulated CPU does not grow...
[12:32] <lifeless> ddaa: the DBA's have access to debug it. it was failing in the weekend due to a production server misconfig
[12:33] <ddaa> wonderfish
[12:33] <ddaa> I take it DBA have the situation under control.
[12:33] <ddaa> * in control
[12:35] <lifeless> there was a deadlock or something, I've killed the hung process
[12:35] <lifeless> please try elmo, znarl, stub and I when there is a problem, not just the sysadmins.
[12:41] <ddaa> you two were in bed
[12:42] <SteveA> ????
[12:42] <SteveA> dude
[12:42] <lifeless> ddaa: stub has a split day ;0
[12:43] <stub> oops... distracted
[12:45] <stub> lifeless: Why do you need  the password to setup the ssh key? Need me to add it to authorized_keys or something?
[12:45] <lifeless> stub: ssh-copy-id is easiest way
[12:45] <lifeless> stub: no, I'm adding it now by hand
[12:45] <stub> heh... never seen that before
[12:48] <carlos> lifeless: how long takes since a merge is processed by pqm and it's available from rocketfuel-built?
[12:48] <lifeless> carlos: 30 minutes
[12:48] <SteveA> ddaa: you should say "you two were in your beds", because "you two were in bed" means something different than you intended
[12:48] <lifeless> carlos: worst case
[12:49] <ddaa> SteveA: ha... thank you.
[12:49] <lifeless> stub: its setup on gangotri
[12:49] <lifeless> stub: if you want it on other machines, you can copy it around ;)
[12:49] <lifeless> stub: I'll be copying it to vostok now. I'm wondering if we should ask the admins to put it in their userdb ?
[12:50] <stub> I don't know how that works
[12:51] <carlos> ok
[12:51] <lifeless> well when users are being authenticated it can get the key from the userldap database
[12:51] <lifeless> which means 'any machine with a launchpad user would have this key setup'
[12:54] <lifeless> ok, stub, you can ssh from balleny to launchpad@gangotri seamlessly
[12:54] <lifeless> rsync too therefore
[01:11] <lifeless> stub: when do you think I should come back  to do this ?
[01:11] <stub> eh? Oh... authserver has been done.
[01:12] <lifeless> stub: well I'm also going to rollout a new tree to vostok to get spivs sftp bugfixen
[01:12] <lifeless> stub: so if you are generating a production tree for gangotri and thingy, I'll use that
[01:13] <stub> I haven't looked at Carlos' cherry pick yet. I just rolled out the current production launchpad branch, the tree of which can be found on chinstrap in ~stub/launchpad
[01:14] <lifeless> stub: whats in ~/archives/rocketfuel/launchpad/production/1.56 on balleny?
[01:15] <stub> r3354 with cherry picks on r3358, r3362, r3373, r3382
[01:15] <lifeless> so the launchpad part of the current production tree ?
[01:15] <stub> yes
[01:15] <lifeless> cool
[01:16] <lifeless> gnarh
[01:16] <lifeless> I wanted 3364 :p
[01:16] <lifeless> when are you planning a new full drop ?
[01:17] <stub> The vostok rollout docs look file
[01:17] <lifeless> great
[01:18] <stub> I wasn't planning a full drop this week unless somebody bitched.  I can do a rollout tonight if you want
[01:21] <stub> maybe r3382 with carlos' stuff cherry picked
[01:23] <carlos> stub: r3391 and r3392 (if this one appears....)
[01:23] <stub> yup
[01:24] <carlos> I'm testing it on staging now (but applied it manually as it's not available on rocketfuel's mirror yet)
[01:25] <carlos> hmm, seems like it's working ;-)
[01:25] <carlos> jordi: https://staging.ubuntu.com/rosetta/imports?status=APPROVED&type=all
[01:30] <lifeless> that would be most excellent. I'll
[01:33] <lifeless> I've grabbed a copy of your tree to ~/production/launchpad on balleny
[01:39] <jordi> carlos: good stuff!
[01:42] <ddaa> haha, just found out branch-scanner is in need of quick fix!
[01:43] <ddaa> just a bit of db poking will do it
[01:47] <carlos> stub: ok, my fix landed on rocketfuel
[01:48] <carlos> and seems like it's working without problems on staging
[01:48] <carlos> stub: I think you can start with the cherrypick when you want
[01:51] <dilys> Merge to devel/launchpad/: [trivial]  Make production config usable by authserver instance (r3393: Stuart Bishop)
[01:55] <carlos> stub: do you need anything from me for that cherry pick?
[01:55] <stub> nope.
[01:55] <carlos> ok, see you later
[01:55] <carlos> stub: thanks
[02:00] <matsubara> good morning!
[02:00] <lifeless> spiv - around ?
[02:01] <lifeless> ddaa: rollout of the branch puller cannot happen today
[02:01] <lifeless> ddaa: will try for tomorrow
[02:01] <ddaa> thanks for telling me
[02:01] <ddaa> hopefully we won't have that much downtime in the future :(
[02:02] <lifeless> if you notice it tell someone ;). I mean, email people rather than waiting to say face 2 face
[02:02] <lifeless> that will reduce the window immediately.
[02:02] <ddaa> lifeless: I told kiko as soon as I noticed something was weird.
[02:02] <ddaa> I guess I should have emailed the DBAs
[02:04] <lifeless> if you'd like us to do something ..
[02:04] <matsubara> BjornT:
[02:04] <matsubara> BjornT: ping
[02:04] <BjornT> hi matsubara
[02:04] <matsubara> hello BjornT, would you have time to review the patch for bug 33978?
[02:04] <Ubugtu> Malone bug 33978 in malone "Advanced search page doesn't do any input validation" [Normal,Confirmed]  http://launchpad.net/bugs/33978
[02:06] <lifeless> night all
[02:07] <matsubara> night rob
[02:07] <BjornT> matsubara: yeah, i should have time to review it either today or tomorrow. add it to my queue on PendingReviews and put the diff somewhere.
[02:07] <ddaa> holy cow, revision number is full of dups!!!
[02:07] <matsubara> BjornT: ok, thanks.
[02:09] <ddaa> stub, you still around?
[02:09] <stub> yes
[02:10] <ddaa> I'm going to need a big delete on Revision number, I'll prepare the query for you to review
[02:10] <David_Mills> Hi, I'm trying to report a couple of bugs I noticed in Dapper Flight 6, but I can't find where to put them.
[02:11] <David_Mills> First off, after installing nvidia-glx, trying to enable the driver results in a md5 check error on the xorg.conf, but the nvidia-glx package doesn't accept bugs
[02:15] <David_Mills> The other bug concerns time setting, I had to reset my clock since dapper considered that it was GMT (it was actually EST), and this change made sudo stop working due to the timestamp being in the future.
[02:15] <David_Mills> Also, setting the time forward more than a minute or 2 set the screensaver off.
[02:27] <matsubara> David_Mills: I think those issues are best addressed at #ubuntu
[02:29] <David_Mills> matsubara: Thanks, I was actually looking for places to put those 2 bugs, since I couldn't find appropriate packages in launchpad
[02:31] <matsubara> David_Mills: about the first issue, did you try here: https://launchpad.net/distros/ubuntu/+source/nvidia-glx/+filebug ?
[02:32] <David_Mills> I've been looking for that for half an hour, thanks :)
[02:34] <matsubara> np
[02:44] <seb128> hi
[02:47] <seb128> is that know that the "upstream task autoupdate" has issue with duplication?
[02:47] <seb128> https://launchpad.net/distros/ubuntu/+source/sound-juicer/+bug/21998
[02:47] <Ubugtu> Malone bug 21998 in sound-juicer "Hangs when trying to overwrite a file without sufficient permissions" [Minor,Confirmed]
[02:47] <seb128> "  	 sound-juicer (upstream)   	Unconfirmed  	Unknown  	  Linked to  gnome-bugs #128074"
[02:48] <seb128> hum
[02:49] <seb128> in fact that's "REOPENED" which is considered as "Unconfirmed" maybe
[03:03] <salgado> hmmm. staging hasn't been resuscitaded yet?
[03:06] <carlos> salgado: It was
[03:06] <carlos> is it down?
[03:08] <carlos> salgado: is being updated atm
[03:09] <salgado> carlos, ah, I see. thanks
[03:19] <kiko> BjornT, do you think that moving to methods will have a better impact on the factoring of the malone backend code?
[03:22] <matsubara> carlos: ping
[03:23] <matsubara> carlos: nm, found the answers that I was looking for in the rosetta faq. :)
[03:24] <BjornT> kiko: what part of the malone code are you thinking of?
[03:24] <kiko> the different callsites that actually modify status (trigger workflow statuses) of which there are 3 that I am aware of (are there more?)
[03:25] <kiko> good work carlos!
[03:27] <elmo> umm
[03:28] <kiko> hey elmo
[03:28] <kiko> how are you man
[03:29] <elmo> kiko: throw myself off a bus happy, as always
[03:34] <BjornT> kiko: actually, for malone i think it would make sense to rely on SQLObjectModifiedEvent, and do the workflow check there in a subscriber. it adds a level of abstraction though, and it depends on how much workflow related stuff we want to do. if we only want to do things on status changes, a method setStatus probably makes more sense.
[03:34] <BjornT> kiko: as for methods vs. properties, i think it depends on how much we want to do when changing the status. i don't think it will have much impact on the factoring of the code.
[03:35] <kiko> BjornT, hey, I think I like that idea.
[03:35] <carlos> kiko: thanks ;-)
[03:35] <kiko> so what would callsites change if we used the ME instead of calling API directly?
[03:37] <BjornT> kiko: would you only set dates and other stuff, or would you have checks, so that only certain people can set the status to Confirmed and so on? In the former case, the callsites wouldn't have to be modified at all, in the latter, they would have to be modified where they fire off the event.
[03:38] <kiko> BjornT, I see -- so if you wanted to verify you'd fire off the event and then check if it worked or not.
[03:38] <SteveA> kiko: i think the workflow-based API makes the permissions make more sense
[03:38] <kiko> it does.
[03:48] <kiko> bradb: why don't you do a mockup patch of the callsites to get a feel of what the different APIs would look like?
[03:48] <kiko> maybe BjornT can assist you?
[03:53] <dilys> Merge to devel/launchpad/: [trivial]  -- but iwj requested it; include bug contacts in the main source package page; also cleans up portlets there somewhat (r3394: kiko)
[03:58] <salgado> kiko, ddaa, https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-04-03/A16 is what caused the breakage in the supermirror puller script
[03:59] <ddaa> salgado: yup, lifeless told me it was broken
[04:00] <ddaa> his idea of "simplifying" the configs keeps on backfiring, the branch puller is still offline (he killed it) and should be back online tomorrow.
[04:00] <kiko> that was being sent to launchpad-errors fwiw
[04:01] <ddaa> I am probably not subscribed to that specific topic
[04:01] <ddaa> kiko: you are my smart agent for all launchpad-errors matters :)
[04:01] <kiko> I read everything
[04:02] <kiko> carlos, ping?
[04:02] <bradb> kiko: You mean method vs. event-driven vs. properties?
[04:02] <kiko> bradb, yeah
[04:03] <bradb> (BTW, I also considered using events, but I think that's even more overengineering than using methods.)
[04:03] <kiko> that way you can tell for yourself which tradeoffs each of the designs have
[04:03] <kiko> well
[04:03] <kiko> look at the callsite and database code
[04:03] <carlos> kiko: pong
[04:03] <kiko> and see what results in the optimal factoring
[04:03] <SteveA> from considering the security angle, i think using methods is easiest to understand
[04:03] <SteveA> and easiest to explain
[04:03] <kiko> carlos, so, mark is asking me what we could do to get a visible metric of language pack quality over time
[04:04] <SteveA> as you can easily explain who can move a task to what states
[04:04] <kiko> carlos, do you have some ideas on that front? to start off with, what is a good language pack quality metric?
[04:04] <SteveA> and that is simply based on what methods a person has access to
[04:04] <carlos> kiko: quality about translations or about how well do we create them?
[04:04] <kiko> carlos, quality of our exported language packs versus the original language packs.
[04:05] <bradb> SteveA: The problem we're trying to solve here though is setting dates on tasks, not bugtask state workflow. At least, that's how it started out. :)
[04:05] <kiko> bradb, not really; mark wanted us to evaluate the backend API as we did it, and I agree it's a good idea.
[04:05] <carlos> kiko: Hmm, well, the best metric there is the amount of new translations added by Rosetta
[04:05] <kiko> carlos, what about translation exports and imports that Rosetta drops?
[04:06] <carlos> kiko: I have a list from pitti that gives me the list of translation domains that we are missing or we are adding from Rosetta
[04:06] <kiko> carlos, is that done daily?
[04:06] <kiko> and are the language packs done daily?
[04:06] <carlos> kiko: pitti is able to give you that information, I think he has a script to detect that kind of things
[04:07] <carlos> kiko: yes and yes
[04:07] <carlos> kiko: http://people.ubuntu.com/~pitti/langpacks/buildd-rosetta-domaindiff.txt
[04:07] <bradb> kiko: So the deliverable here then is something that also implements a BugTask state workflow? (i.e. with perms checking and BugTask object validation?) I just want to make sure I'm solving the right problem.
[04:07] <SteveA> bradb: XP -- regularly looking for an opportunity to refactor
[04:07] <carlos> kiko: from time to time, I'm fixing some of them
[04:08] <carlos> kiko: the most visible difference is the lack of KDE
[04:08] <kiko> bradb, we might reconsider it if we decide it's not worth it, but we haven't even explored that possibility yet, so that's why I think it's worth it.
[04:08] <bradb> SteveA: Absolutely. Always. My understanding of refactoring is that it doesn't change external behaviour though. :)
[04:08] <carlos> kiko: but, as you already know, that's mostly fixed
[04:08] <LarstiQ> bradb: just include the external bits in your refactoring effort ;)
[04:09] <SteveA> bradb: eh?
[04:09] <SteveA> bradb: we're not talking about changing external behaviour.  we're talking about improving the API and altering the client code of the API to be consistent with whatever the API changes to
[04:10] <bradb> SteveA: i.e. if the solution here is to aim for something that does BugTask state workflow/perms checking, that'd be changing external behaviour.
[04:10] <carlos> kiko: the thing is that we are not going to drop the original language packs directly, we are comparing them from time to time
[04:10] <carlos> and fix the differences, until we reach the point when Rosetta exports can be used directly
[04:10] <SteveA> bradb: would it change external behaviour?
[04:10] <carlos> and I think we are near that point now, when KDE is completely imported
[04:11] <SteveA> i don't think so.  i'm just talking about making the system easier to understand for pepole reading the code.
[04:11] <bradb> SteveA: Yes. For example, you'd get an error message trying to set "In Progress" when there's no assignee.
[04:11] <kiko> bradb, we haven't discussing /doing that/
[04:11] <kiko> just being able to do it if we decide to later
[04:12] <kiko> so for now, no, no external change.
[04:12] <bradb> oh, ok, sorry
[04:12] <kiko> s/discussing/discussed and s/sorry// because there's nothing to be sorry about!
[04:13] <bradb> :P
[04:13] <bradb> Okay, I'll see what I can come up with as a prototype API.
[04:13] <kiko> carlos, that's cool, but I think we can modify that report slightly and get the metrics we want
[04:13] <carlos> kiko: sure
[04:14] <carlos> kiko: I asked pitti that specific information because is what I'm trying to fix atm
[04:14] <kiko> carlos, for instance, just having counts of how many domains we differ
[04:14] <kiko> and having that sent to the launchpad list daily
[04:14] <kiko> how does that sound?
[04:15] <carlos> hmm, that's ok for me, but I'm not sure if other people will want to get that spam daily....
[04:16] <kiko> I do!
[04:16] <kiko> and it's great to have a larger group of people interested in rosetta's status
[04:17] <carlos> ;-)
[04:20] <kiko> stub, SteveA: why did we upgrade production again today?
[04:20] <jordi> halloi
[04:21] <stub> kiko: 'cause lifeless needed a higher patch level on the authserver for supermirror stuff (or something like that)
[04:22] <kiko> stub, okay but I would have loved to know the rationale behind the update too
[04:22] <stub> ok
[04:22] <kiko> (so I don't have to distract you on IRC for it)
[04:32] <carlos> mpt_: hi
[04:32] <carlos> did you changed the way we show statistics in Rosetta?
[04:32] <carlos> https://launchpad.net/distros/ubuntu/dapper/+source/kdebase/+pots/kcmtaskbar/
[04:33] <SteveA> carlos: you really expect mpt to be around at this hour?
[04:33] <carlos> is a bit hard to understand the number that we are adding with the graphics
[04:33] <carlos> SteveA: well.. if he's online....
[04:33] <kiko> carlos?
[04:33] <carlos> ;-)
[04:33] <carlos> kiko: see the URL I pasted
[04:33] <kiko> carlos, wait up
[04:33] <SteveA> http://www.timeanddate.com/worldclock/city.html?n=264
[04:34] <kiko> carlos, what number?
[04:34] <kiko> carlos, do you need to shift-reload by any chance?
[04:34] <carlos> oh
[04:34] <carlos> ok
[04:34] <carlos> :-P
[04:34] <carlos> kiko: was it a css change?
[04:35] <kiko> yes, and stub doesn't know how to CSS invalidate
[04:35] <SteveA> i know how we can do that
[04:36] <SteveA> for CSS and such that we expect to be changing, we put it in a resourcedirectory using the directive of the same name
[04:36] <SteveA> and make the resourcedirectory called "siteuiN" where N is a number we increment
[04:36] <SteveA> then, when we rev the CSS, we need to change the directory in the main template
[04:36] <SteveA> and update that resource directory directive
[04:36] <kiko> that sounds super-complicated
[04:36] <SteveA> it's cumbersome
[04:37] <kiko> why doesn't zope just invalidate the file? is it not zope?
[04:37] <SteveA> it depends how much we want it
[04:37] <SteveA> it is nothing to do with zope
[04:37] <SteveA> we could make zope or apache send "no fucking way are you to cache this" headers
[04:37] <kiko> I'd like to just expire it correctly
[04:37] <SteveA> lifeless would be the one to say exactly what headers to send
[04:37] <kiko> I thought firefox handled this the right way
[04:38] <SteveA> the most reliable way, considering internet http caches, is to change the location / filename of the CSS
[04:38] <SteveA> we could make the CSS include parts of the main template a view
[04:38] <SteveA> and have that view class look up a setting from launchpad.conf
[04:39] <SteveA> and have a custom resource thinggie that also uses that setting
[04:39] <SteveA> so, we have css_version = 23
[04:39] <SteveA> in the launchpad.conf
[04:39] <SteveA> and that one setting says where to serve the CSS up from
[04:39] <SteveA> and also where to refer to it in the main templates
[04:41] <carlos> SteveA++
[04:41] <carlos> I like that idea
[04:42] <SteveA> kiko: if you're +1, i'll file a bug
[04:42] <kiko> I'm +1 on not requiring people to shift-reload every time we change CSS yes :)
[04:47] <SteveA> https://launchpad.net/products/launchpad/+bug/38037
[04:47] <Ubugtu> Malone bug 38037 in launchpad "Make CSS files refreshed on code updates" [Normal,Unconfirmed]
[04:49] <kiko> Znarl, yo! I have an RT request of the day today: 4532!
[04:49] <kiko> BjornT, we need to start sending out email notifications when bugwatches update
[04:49] <kiko> BjornT, how much work is that going to be?
[04:50] <Znarl> kiko : Hey kiko, will take a look.
[04:53] <kiko> BjornT, did you see corey's latest email to launchpad-users?
[04:54] <kiko> what do you think of it?
[04:54] <elmo> what's up with launchpad's team searching?
[04:54] <BjornT> kiko: it's not that much work. all that is needed is to create a new person, from which the notifications are sent from, and then make sure that an event is fired off everytime a task is changed.
[04:54] <elmo> either my expectations are unrealistically high or it's entirely SNAFU
[04:54] <elmo> https://launchpad.net/people/?name=b&searchfor=teamsonly <-- returns nothing
[04:56] <BjornT> kiko: yes, i saw the email. i'm not sure how we should improve the notifications. some people like the new format, some don't, it will be impossible to please everyone.
[04:56] <elmo> alternatively, ddaa, what's the name of the 'buttress' team in launchpad?
[04:56] <ddaa> vcs-imports
[04:57] <ddaa> buttress was deemy overly cute and potentially offensive
[04:57] <ddaa> actually, it was "buttsource"
[04:57] <ddaa> buttsource was deemy overly cute and potentially offensive
[04:57] <elmo> thanks
[04:59] <kiko> BjornT, he was writing about the inconsistency versus bugmail entered via email and via IRC?
[05:01] <dilys> Merge to devel/launchpad/: [trivial]  Add notice on two shipit pages that we're not yet taking requests of dapper CDs (r3395: Guilherme Salgado)
[05:06] <kiko> salgado, but the supermirror crash, that's now fixed in production, I believe?
[05:06] <BjornT> kiko: as i understand it, he wants the notifications to look more consistent and structured, like the old format, pleasing bugzilla users.
[05:06] <kiko> no
[05:06] <kiko> that's not what I am asking about
[05:06] <kiko> I'm asking about the inconsistency he reported
[05:10] <uws> "Fix committed" bugs still show up in the malone listing
[05:10] <uws> Is there a way to mass-change all fix-committed bugs to fix-released?
[05:11] <BjornT> kiko: are you saying that what he describes in the email (adding 'Comment Added') actually happens when you add a comment via the web? or what inconsistency are you referring to?
[05:12] <kiko> If someone changes on the web interface, it is sending out with
[05:12] <kiko> Comment Added. However, if someone uses the email interface, it is
[05:12] <kiko> merely forwarding the email on, without changes, ala debbugs.
[05:12] <kiko> he is suggesting that our bug emails have different formats depending on where they come from. but AFAIK that isn't true, is it?
[05:14] <BjornT> kiko: no, that's not true. you see no difference between a comment added via the web UI vs a commment added via email.
[05:14] <kiko> then reply to him and say he's on crack!
[05:24] <SteveA> matsubara: hello
[05:24] <matsubara> hi SteveA
[05:25] <SteveA> matsubara: in ~stevea/daf_public_html on chinstrap, there's the various reports etc. that daf was using for bug triage
[05:25] <SteveA> would you be able to take on maintaining these pages, and have them under ~matsubara on chinstrap ?
[05:26] <matsubara> SteveA: let me take a look at it.
[05:27] <carlos> jordi: ping
[05:30] <jordi> pong
[05:30] <dilys> Merge to devel/launchpad/: rs=SteveA IIRC Remove security-unaware methods from BugTaskSet and make a more obviously insecure method available for scripts that need to iterate over all items (r3396: kiko)
[05:32] <matsubara> SteveA: I copied then over to ~matsubara and as soon as time permits I'll take a look at the code.
[05:34] <SteveA> matsubara: cool, thanks
[05:49] <kiko> salgado, write to stub CC: launchpad about the missing passwords? maybe asking what happened on 2006-01-13? (gina run? but gina uses createPersonAndEmail, which is safe, right?)
[05:50] <salgado> kiko, I'm investigating it
[05:50] <kiko> ok
[05:50] <kiko> me just jumping the gun as usual
[05:50] <salgado> apparently two different scripts created these people
[05:51] <salgado> one created them because of translations and the other because they're maintainers
[05:51] <salgado> package maintainers, that is
[05:51] <kiko> the latter one seems to be soyuz before your suggested problem was fixed
[05:51] <kiko> the former might be an old rosetta problem -- carlos carlooooos?
[05:52] <salgado> but I didn't get to the ones created on 2006-01-13, which apparently were created because they have some relation to bugs
[05:52] <carlos> kiko: ?
[05:52] <kiko> bugzilla import?
[05:52] <kiko> carlos, some users in our db have preferred email addresses but no passwords
[05:52] <kiko> which means they were created the wrong way
[05:52] <kiko> do you know which part of rosetta might do that, and is that an old bug that was fixed?
[05:53] <carlos> kiko: I don't think we are setting a preferred email address..
[05:53] <carlos> let me check
[05:53] <kiko> did you use to at some point?
[05:53] <kiko> Znarl, how's that looking?
[05:53] <carlos> don't think so
[05:55] <carlos> if person is None:
[05:55] <carlos>             # We create a new user without a password.
[05:55] <carlos>             person, dummy = personset.createPersonAndEmail(
[05:55] <carlos>                                 email, displayname=name)
[05:55] <carlos> kiko: is that broken?
[05:55] <carlos> kiko: that's what we use to create new accounts
[05:56] <carlos> personset is an IPersonSet
[05:56] <salgado> carlos, that's the right way to create a person. it won't set the email address as preferred
[05:56] <carlos> salgado: I think that code has more than 6 months
[05:57] <carlos> at least, I didn't changed it this year
[05:57] <carlos> it could even have a year... so I don't think the problem was caused by Rosetta, but who knows...
[06:01] <kiko> salgado, yeah, the supermirror crash is fixed
[06:02] <kiko> BjornT, Znarl says he's nailed your RT request -- can you attempt to test it?
[06:03] <BjornT> kiko: sure
[06:07] <carlos> see you
[06:31] <BjornT> kiko: it seems that it doesn't work yet. when i try to send an email to the address i get: host fiordland.ubuntu.com[<IP_ADDRESS>]  said: 554<EMAIL_ADDRESS>Relay access denied (in reply to RCPT TO command)
[06:31] <kiko> thanks BjornT
[06:39] <SteveA> anyone up for a quick review?  https://chinstrap.ubuntu.com/~jamesh/pending-reviews/stevea/launchpad/ui//full-diff
[06:40] <SteveA> it looks big, but really it is mostly removals and svg/png/blackbox-js
[06:40] <SteveA> this is the new menus bling
[06:40] <SteveA> there's even a test
[06:45] <kiko> not me!
[06:46] <kiko> SteveA, can you approve pitti's request on the launchpad list?
[06:49] <dilys> Merge to devel/launchpad/: Fix https://launchpad.net/products/malone/+bug/38040 (+duplicate form should accept integer or bug nickname) r=kiko (r3397: Diogo Matsubara)
[06:50] <matsubara-lunch> wow
[06:50] <matsubara-lunch> that was fast.
[06:51] <kiko> yeah, pqm is ripping em up today
[06:51] <matsubara-lunch> second round?
[06:51] <kiko-fud> yes
[06:56] <bradb> Shelving to default/00: "Changes shelved on 2006-04-04 12:54:58" <-- That is a wild new shelve message.
[06:57] <kiko-fud> I like wild things
[06:57] <lakin> bradb: thanks for bug 35075  ... /me goes off in search of how to do it.
[06:57] <Ubugtu> Malone bug 35075 in malone "Bug Triagers would benifit from a way to list bugs filed without a package" [Normal,Fix released]  http://launchpad.net/bugs/35075
[06:57] <bradb> lakin: no prob
[06:58] <bradb> I gave a hint in my fix comment.
[06:58] <lakin> I found it. :)
[06:58] <bradb> coooooool
[06:59] <bradb> I've got a patch in the queue now that will add advanced searching to the one last listing that didn't have it: the package bug reports.
[06:59] <Znarl> BjornT : It should be working now.
[07:01] <lakin> bradb: way cool.
[07:40] <kiko> BjornT, ping?
[07:40] <SteveA> kiko: want to rubber-stamp my menus branch?
[07:42] <SteveA> c'mon man, you know you have a rubber fetish
[07:42] <kiko> no dude
[07:42] <kiko> I am not doing any of that rubbering
[07:42] <SteveA> burn some rubber
[07:45] <jordi> uh
[07:46] <jordi> kiko, SteveA: can you have a look at OOPS-94D267?
[07:46] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/94D267
[07:46] <kiko> yes
[07:46] <jordi> I can't modify or create new potemplatenames.
[07:46] <jordi> This is pretty critical for me right now
[07:46] <kiko> wait 5 minutes.
[07:46] <jordi> sure
[07:55] <matsubara> jordi: is the problem that you're having related to bug 37394? the oops isn't available yet.
[07:55] <Ubugtu> Malone bug 37394 in rosetta "POtemplatename needs unique name validator" [Normal,Fix released]  http://launchpad.net/bugs/37394
[07:55] <salgado> is staging still being updated?
[07:57] <matsubara> jordi: just opened the oops, that's fixed and should be working on production
[07:58] <kiko> matsubara, no, the bug is that jordi is trying to add names with underscores in them.
[07:58] <kiko> are we not checking valid_name there/
[07:58] <jordi> uh
[07:58] <jordi> ok, I'll ignore that template for now.
[07:58] <kiko> jordi, you can't add names with underscores.
[07:58] <kiko> there's no way around that
[07:59] <kiko> file a bug if you have trouble there
[07:59] <kiko> matsubara, is there a bug filed for checking a name for potemplatenames?
[07:59] <jordi> some KDE stuff use _
[07:59] <kiko> they are in trouble with us
[07:59] <kiko> or, well, does the potemplatename we use matter?
[07:59] <kiko> it's not the domain
[08:01] <kiko> jordi, file a bug on this, I suggest
[08:01] <matsubara> kiko: i'll check, but I don't think there's
[08:02] <matsubara> jordi: assign it to me and will fix it and write a test.
[08:02] <jordi> kiko: k
[08:02] <jordi> great
[08:02] <kiko> well
[08:02] <kiko> wait
[08:02] <jordi> is this against rosetta or lp?
[08:03] <kiko> jordi, by fix he means "won't crash"
[08:03] <jordi> oh
[08:03] <jordi> I cannot use an underscore, period?
[08:03] <kiko> it won't allow you to enter names with underscores.
[08:03] <kiko> period.
[08:03] <kiko> does it matter?
[08:03] <jordi> why's that? there's packages using them
[08:04] <kiko> because underscores are not allowed in launchpad URLs
[08:07] <kiko> anyone, SteveA, do we have unit tests for launchpad in our tree? where do they live?
[08:07] <SteveA> we have some unit tests
[08:07] <SteveA> they live in tests/ directories
[08:07] <SteveA> to unit test the package the tests/ package is a sub-package of
[08:07] <kiko> hmmm
[08:08] <kiko> do you recall daf's proposed selectresults.txt test that checked if security-proxied select results worked?
[08:08] <kiko> I'm going to land it
[08:08] <kiko> but I don't know where to put it
[08:08] <kiko> and whether or not to make it a unit test
[08:09] <kiko> maybe in sqlos?
[08:09] <SteveA> sure
[08:09] <SteveA> although, that should be a functional test really, i expect
[08:09] <kiko> so where do I put it?
[08:09] <kiko> ftests/ ?
[08:09] <SteveA> as it is about the integration of SelectResults and security proxies
[08:09] <SteveA> yes
[08:09] <kiko> yes, correct
[08:09] <SteveA> really it is an "integration test"
[08:10] <SteveA> but we don't make a distinction between functional and integration tests
[08:15] <matsubara> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/file9JLNMB.html
[08:21] <dilys> Merge to devel/launchpad/: [trivial]  shiny new sitemap and hierarchy navigation. with test. (r3398: Steve Alexander)
[08:28] <elmo> and the trivial abuse award goes to ...
[08:29] <kiko> SteveA is such a bulldozer
[08:29] <kiko> I should back that out
[08:36] <SteveA> oh, was that me?
[08:37] <kiko> it does have your name on it.
[08:49] <dilys> Merge to devel/launchpad/: [trivial]  fix bug 37911 (No advanced search for package bug reports) (r3399: Brad Bollenbach)
[09:02] <matsubara> jordi: did you report that bug about invalid POTemplaName?
[09:41] <dilys> Merge to devel/launchpad/: Add the name_validator constraint to IPOTemplateName.name fixing OOPS-94D267 r=kiko (r3400: Diogo Matsubara)
[09:41] <kiko> SteveA, I still haven't found out how to add an ftest for that problem.
[09:42] <kiko> the ftests we have are kinda weird
[09:55] <sabdfl> evenin' all
[09:55] <SteveA> hiya
[09:55] <sabdfl> is staging supposed to be unresponsive?
[09:56] <SteveA> no
[09:56] <SteveA> looks like it hung again
[09:57] <SteveA> i'd like to leave it hung until lifeless is around in a couple of hours
[09:57] <SteveA> he has expertise in getting stack traces out of hung python processes
[09:57] <SteveA> sabdfl: is staging being hung biting your ass greatly?
[10:01] <kiko> salgado, have you been able to test MM on mawson yet?
[10:01] <jordi> matsubara: gah
[10:01] <jordi> matsubara: no, doing now
[10:01] <kiko> jordi, already fixed, see above
[10:01] <matsubara> jordi: too late dude, already committed
[10:02] <kiko> if you want to file a bug on being able to cope with underscores in template names, cool
[10:02] <salgado> kiko, no, I'm still investigatin that data corruption
[10:02] <SteveA> kiko: just mailed lifeless asking him to look at staging when he gets up
[10:02] <salgado> kiko, can I access the web UI that uses launchpad_dogfood?
[10:02] <kiko> thanks SteveA
[10:02] <kiko> salgado, yeah, dogfood.ubuntu.com IIRC, needs certificate IIRC
[10:03] <salgado> and from mawson, can I access staging's database?
[10:03] <kiko> I can at least
[10:03] <kiko> I don't know if you can though
[10:03] <kiko> do you need staging to be working?
[10:04] <kiko> if so, you're better off waiting
[10:04] <salgado> no, if there's dogfood I can use it, I think
[10:04] <jordi> matsubara: oops, too late then.
[10:04] <salgado> need to check what revision we're running there
[10:04] <jordi> matsubara: should I close?
[10:05] <kiko> sabdfl, I admire your energy in keeping your inbox clean :)
[10:07] <matsubara> jordi: fix comitted
[10:07] <matsubara> jordi: unless you want to change it as kiko suggested above.
[10:08] <salgado> kiko, who else uses mawson?
[10:08] <salgado> I mean who else uses launchpad_dogfood
[10:12] <jordi> matsubara: suggested wherE?
[10:13] <jordi> I feel off IRC
[10:13] <matsubara> kiko if you want to file a bug on being able to cope with underscores in template names, cool
[10:13] <matsubara> jordi: ^^ that was his suggestion
[10:13] <jordi> oh right
[10:13] <jordi> I'll modify it
[10:14] <matsubara> jordi: I just closed it...
[10:15] <jordi> oops
[10:15] <jordi> ok, I'll file a new one
[10:15] <jordi> ths is a mess :)
[10:15] <jordi> but now it has a modified body/title :)
[10:15] <ddaa> *cries* buildbot is breaking my merges again *cries*
[10:16] <ddaa> *weep* *bitch* *sob*
[10:16] <ddaa> matsubara: kiko: what is the process to handle support requests in launchpad ATM?
[10:17] <kiko> ddaa, matsubara has currently been gardening them, AFAIK
[10:17] <ddaa> I see there is an insane amount of open requests, and the Launchpad QA team is restricted and only has matsubara as a member, so other LP folks cannot help.
[10:18] <kiko> it is restricted?
[10:18] <ddaa> I meant to redirect that guys with a dud productseries to the support tracker, but it looks more like the bit bucket than a place to get help from.
[10:18] <kiko> well you can probably ask to be a member
[10:19] <ddaa> kiko: I think most (all?) launchpad devs should be member of Launchpad QA.
[10:19] <kiko> mmmm
[10:19] <kiko> it's a lot of traffic, I suspect. matsubara?
[10:20] <matsubara> I created it as restricted because I took Launchpad Developers team as an example.
[10:20] <matsubara> kiko: it's not that much traffic
[10:20] <kiko> matsubara, add ddaa and me then :)
[10:20] <ddaa> Having a single authoritative person is useful, but I think it's useful for launchpad devels to be aware of what people are bitching about.
[10:21] <matsubara> but there's lots of noise in the requests, like people asking for ubuntu cds.
[10:21] <ddaa> Probably mpt too, I guess there is a lot of food for UI design though in there.
[10:21] <ddaa> matsubara: you can deal with the noise, and we can  see the signal for our personal edification.
[10:22] <ddaa> If anything, the noise is probably a signal that the path to cd requests and such is not clear enough.
[10:23] <matsubara> just added mpt, ddaa and kiko
[10:23] <ddaa> matsubara: can you email mpt so he will not be too surprised?
[10:23] <matsubara> ddaa: sure
[10:23] <matsubara> shall I add any of you as admin?
[10:24] <ddaa> I'd be happy to be admin of whatever team.
[10:24] <ddaa> If only to better better TZ coverage :)
[10:25] <ddaa> as long as people will not start expecting me to deal with all and any support request. I probably do not have enough patience to deal with stuff like that https://launchpad.net/products/launchpad/+ticket/593
[10:27] <kiko> ddaa, you don't need to care about them, IMO, but nice if you have some time for it.
[10:27] <matsubara> ddaa: at least that one is legible
[10:27] <matsubara> the great mpt_
[10:27] <matsubara> I was about to mail you
[10:27] <ddaa> mpt_ you just won the sweepstake
[10:28] <matsubara> mpt_: just added you to Launchpad QA team
[10:28] <ddaa> you will receive even more launchpam!
[10:30] <matsubara> ddaa: btw, I reported a bug 37893 which will help a bit in controlling the support spam
[10:30] <Ubugtu> Malone bug 37893 in launchpad "Launchpad support mails needs a header in the same format of bugmails." [Normal,Unconfirmed]  http://launchpad.net/bugs/37893
[10:31] <dilys> Merge to devel/launchpad/: [trivial]  offer LP_DEBUG_SQL and LP_DEBUG_SQL_EXTRA environment variables to control output of SQL and tracebacks when running application server (r3401: kiko)
[10:32] <ddaa> okay... where was I...
[10:32] <kiko> SteveA, I just went ahead and did it.
[10:32] <ddaa> ha, yes... *whine* darn buildbot *kicks* cannot merge cscvs anymore *cries*
[10:36] <SteveA> kiko: did it?
[10:39] <kiko> SteveA, as dilys reports.
[10:41] <SteveA> cool
[10:58] <sabdfl> SteveA: no, my ass just wants to gaze at a launchpad-with-top-menubar before crashing
[11:00] <kiko> sabdfl, how do I get my distribution to updateCompleteSourcePackageCache?
[11:02] <sabdfl> kiko: scripts that mess with the packages (like soyuz) should kick that now and then
[11:02] <sabdfl> though a better answer is to kick just the package you care about whenever you touch it
[11:02] <kiko> sabdfl, I need it done to get some sampledata ruffled. bummer.
[11:02] <sabdfl> because it's *expensive*
[11:02] <kiko> yeah
[11:03] <kiko> just want my data in current.sql
[11:03] <sabdfl> kiko: make sampledata; ../path/to/script/that/kicks/it; make newsampledata
[11:03] <sabdfl> script can be cd ../database; python -i ./harness.py << for d in Distribution.select(): d.updateCompleteSourcePackageCache()
[11:04] <sabdfl> ish
[11:06] <kiko>     ProgrammingError: ERROR:  permission denied for sequence distributionsourcepackagecache_id_seq
[11:06] <kiko> I'll just fuck around with the sampledata i guess
[11:10] <kiko> oh, found a way around that, whee
[11:35] <kiko> salgado, have time for a short review?
[11:35] <kiko> (say yes)
[11:35] <salgado> yes
[11:35] <salgado> where's it?
[11:36] <kiko> generating, 2m turkish
[11:42] <kiko> salgado, https://chinstrap.ubuntu.com/~dsilvers/paste/filet6d4DD.html\
[11:42] <kiko> drop the \
[11:42] <kiko> I suck
[11:48] <salgado> kiko, why's that change in the two search methods? doesn't the fti of those tables contain the 'name' column?
[11:49] <jordi> alo
[11:49] <kiko> salgado, can you ignore the distroarchrelease bit? it's not going in
[11:49] <ddaa> Good night guys.
[11:49] <kiko> salgado, the fti column does include name, but fti doesn't work well for stuff like package names -- they can be like "at" or "linux-2.6.15" both things which fti doesn't match.
[11:50] <ddaa> kiko: if you prepare me a voodoo doll at buildbot's address, I'll tell you all about it :)
[11:51] <ddaa> kiko: hint, you can do "bzr diff path/to/tree path/to/other/tree"
[11:51] <kiko> salgado, the former because it is short (and possibly a stopword) and the latter because of the dots.
[11:51] <salgado> kiko, fair enough. r=salgado, then
[11:52] <kiko> thanks salgado
[11:52] <salgado> fti sucks sometimes, but I think it would suck more without it
[11:52] <kiko> I'll add a comment
[11:52] <jordi> kiko: tomorrow there's swimming at 7AM
[11:53] <kiko> jordi, there's swimming for me in 45m
[11:54] <jordi> kiko: cool!