[11:55] <duanedesign> morning all
[14:02] <mahen> jdobrien: hi :) It seems there is a fix regarding my bug report :) Please tell me if you want me to check whether it works or not (if that's available in a ppa or proposed repo maybe ? :)
[14:03] <jdobrien> mahen, what do you mean a fix?
[14:04] <jdobrien> mahen, I started a branch which will fix it when it's finished
[14:04] <mahen> well I don't know, I just saw this "** Branch linked: lp:~jdobrien/ubuntuone-client/fix-666942 " added to my bugreport, I assumed it was one fix :)
[14:04] <mahen> aah :)
[14:04] <mahen> Okay !
[14:04] <mahen> Sorry :)
[14:04] <mahen> Well, thanks for your work then :)
[14:04] <jdobrien> mahen, we found the issue..it's going to take longer for me to write tests for it than to fix it...as usual :)
[14:07] <mahen> jdobrien: okay :) Sorry for giving you work fixing stuff that will, if I understood correctly, be dropped anyway for 11.04
[14:07] <jdobrien> mahen, what will be dropped 11.04?
[14:08] <jdobrien> mahen, this is a real bug in the code actually :)
[14:08] <mahen> I thought the whole sync daemon was being rewritten in a completely different way to allow things like resume, better reliability/performance etc.
[14:08] <mahen> But I just caught some words here & there :)
[14:13] <rye> mahen, from performance point of view I can say that since it is highly modular the bits can be changed w/o rewriting all other code.
[14:14] <mahen> rye : good to know
[14:14] <duanedesign> hello all
[14:14] <rye> duanedesign, morning!
[14:15] <duanedesign> good day rye. Hope you had a nice weekend
[14:18] <mahen> thanks everyone & see you
[14:19] <rye> duanedesign, yes, pretty much! I can now be contacted about music store issues too :-). Played with moovida, ushare, gmediacenter and mediatomb, set up the network properly... well, a normal weekend you know :)
[14:19] <duanedesign> rye: do you know if their is an existing bug report about the Emblems in Lucid not refreshing automagically.
[14:20] <rye> duanedesign, in lucid?... let me have a look at the code
[14:20] <duanedesign> rye: the user is using the stable/PPA
[14:21] <duanedesign> bug 671380
[14:21] <ubot4> Launchpad bug 671380 in ubuntuone-client "Nautilus checkmarks not refreshing automatically (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/671380
[14:26] <rye> duanedesign, uh-huh, i understand the issue now...
[14:27] <rye> duanedesign, need to check how nautilus reacts when we .. hmmm
[14:29] <duanedesign> yeah i did not have a VM of lucid haandy to confirm it...
[14:29] <duanedesign> probably need to get one set-up
[14:30] <rye> duanedesign, confirming in maverick, moved file does not get any emblem (well, it just bears the same set of emblems it used to)
[14:32] <rye> duanedesign, it's like it does not have the info about this file :-/, ok, getting the source of ubuntuone-cilent-gnome and a hammer
[14:33] <duanedesign> :)
[16:05] <hallyn> jinkeys, my first:  next_actions.otl.u1conflict
[16:07] <duanedesign> ruh roh
[16:08] <hallyn> well one thing i finally accidentally confirmed:  ecryptfs won't write out the lower files until you umount - so i left for coffee shop with netbook, and ubuntuone had my old files :)
[19:18] <jdobrien> mahen, ping
[19:44] <mahen> jdobrien: yep ?
[19:45] <jdobrien> mahen, did you cancel your subscription?
[19:45] <jdobrien> mahen, I just noticed that it wasn't active
[19:46] <mahen> jdobrien: hm ? I thought I just downgraded it to 20 GB temporarily actually
[19:46] <jdobrien> mahen, let me check
[19:46] <mahen> as soon as it works properly I'll upgrade again of course :)
[19:46] <jdobrien> mahen, did someone do that for you?
[19:47] <mahen> jdobrien: no. Hmm, something definitely changed since last time I visited the one.ubuntu.com/account page
[19:47] <mahen> indeed it seems to be cancelled now
[19:47] <mahen> it wans't last time I tried the sync daemon
[19:47] <mahen> wasn't
[19:47] <jdobrien> when is the last time you checked?
[19:48] <jdobrien> mahen, ok im going to fix it...don't worry you won't get charged, but you'll get a silly welcome email
[19:48] <mahen> I'm not sure, maybe it was last wednesday (date of my latest debug log)
[19:48] <jdobrien> oh ok
[19:49] <mahen> jdobrien: no problem :)
[19:49] <mahen> thanks
[19:50] <jdobrien> mahen, ok...you should work now
[19:50] <tfi> Hi everybody ;-) . Don't know if this is the right place.. I'm a new Ubuntu One user and trying to create an account there.. I'm waiting for 10 minutes now for the confirmation code but no one arrives yet.. Is there a problem or should i simply wait?
[19:51] <jdobrien> mahen, I would like to find out what's going on with that Move retry thing
[19:51] <jdobrien> mahen, it's bewildering
[19:51] <mahen> jdobrien: OK, I have some spare time :)
[19:51] <mahen> please tell me what to do :)
[19:52] <jdobrien> mahen, is your client connected?
[19:52] <mahen> not yet
[19:52] <mahen> shall I ?
[19:52] <jdobrien> yeah
[19:52] <mahen> ok, it'll take a couple of minute (drive spinning)
[19:52] <mahen> +s
[19:52] <jdobrien> ok
[19:53] <mahen> (which is another issue I have btw, but I'll bother you later about this ;)
[19:55] <mahen> jdobrien: online
[19:55] <jdobrien> mahen, are you seeing exceptions?
[19:56] <mahen> yes (I have debug enabled also)
[19:57] <jdobrien> mahen, can you paste the exceptions?
[19:58] <jdobrien> mahen, hello?
[19:59] <mahen> yep
[19:59] <mahen> http://paste.ubuntu.com/528324/
[20:50] <toml_> echo
[20:50] <toml_> honk
[20:51] <rye> toml_, hi
[20:51] <toml_> hey rye
[20:51] <toml_> got a q that's not covered in the FAQ
[20:51] <rye> toml_, okay, i am listening
[20:51] <toml_> cool
[20:52] <toml_> two folders synced into Ubuntu One
[20:52] <toml_> across two computers
[20:52] <toml_> folders A and B
[20:52] <toml_> both are synced
[20:52] <toml_> let's add a third computer
[20:52] <toml_> can I just sync folder A to the third computer, and not folder B?
[20:53] <toml_> ie. so folder A synced across 3 computers, folder B synced across only two
[20:53] <rye> toml_, yes, but by default it will subscribe the folder so that it will start syncing
[20:53] <toml_> so how to override the default behaviour?
[20:53] <rye> toml_, config file
[20:53] <toml_> path?
[20:53] <rye> udf_autosubscribe = False in [__main__] section of ~/.config/ubuntuone/syncdaemon.conf
[20:54] <toml_> on the third computer?
[20:54] <rye> toml_, all available options are listed in /etc/xdg/ubuntuone/syncdaemon.conf
[20:54] <toml_> rye, k let me have a skinnt at it
[20:55] <toml_> rye, thanks
[20:55] <rye> toml_, yes, on the third computer will be not synchronizing anything (but ~/Ubuntu One/ folder) by default. To force subscription - u1sdtool --subscribe=$folder_uuid, which can be found by u1sdtool --list-folders
[20:56] <toml_> rye, so unset the default subscription, then on the third computer force sub to the folder with the uuid you want
[20:57] <rye> toml_, yes, by the way, what version of Ubuntu are you runnign?
[20:58] <toml_> rye, 10.04 netbook remix on 2 x boxes, and 10.10 on a third
[20:59] <rye> toml_, 10.10 has this option, while i am not sure about 10.04, but if third machine won't subscribe then it won't sync to it for sure
[20:59] <toml_> rye checking it now
[21:01] <toml_> rye, 10.4 Netbook has this option
[21:07] <rye> toml_, ok, then it should be ok
[21:07] <toml_> rye just checking it out now; thanks loads for the help with this.
[21:08] <rye> toml_, you are very welcome!
[21:27] <toml_> rye, slight problem
[21:27] <rye> toml_, yup?
[21:28] <toml_> rye, okay, on 10.4 possible to edit syncdaemon.conf and disable automatic subscription; however, after adding computer to my account
[21:28] <toml_> rye, it still automatically subscribes
[21:29] <toml_> rye, when i run the --unsubscribe-folder option, it ignores it
[21:29] <rye> toml_, run u1sdtool --disconnect
[21:29] <rye> toml_, in order for it to stop syncing
[21:29] <toml_> rye, -same as -d ?
[21:29] <rye> toml_, hm, let me double-check
[21:29] <rye> toml_, yes
[21:29] <toml_> rye, thanks
[21:31] <rye> toml_, wow, there's even a dbus method to disable udf autosubscribe in 10.10
[21:32] <toml_> rye, sounds... scary
[21:33] <toml_> rye,  ahaha I fecked up ... changed the wrong option in syncdaemon.conf
[21:34] <toml_> rye, will go back over it again ... think it may have been an error existing between brain and computer
[21:35] <rye> toml_, in order to prevent syncing of everything - just restart syncdaemon - u1sdtool --quit; u1sdtool --start, verify that udf is not subscribed and then --connect
[21:35] <toml_> rye, right
[21:36] <toml_> rye, hmm still subscribed to the folder
[21:36] <rye> toml_, before connecting - unsubscribe it
[21:39] <toml_> rye, nah,... -folder-unsubscribe=<id> isn't responding
[21:39] <toml_> rye, so I quit, start, list folders, try to unsub from the ID I want to. then quit, start, list... and it's still there
[21:39] <rye> toml_, u1sdtool --unsubscribe-folder=aaabbbccc... ?
[21:40] <toml_> rye, yup
[21:40] <rye> toml_, is u1stool --list-folders shows subscribed=False ?
[21:40] <toml_> rye, standby
[21:40] <rye> toml_, for the folder which you don't want to be sync locally
[21:41] <toml_> rye, no, actually it doesn't have a flag: it's id=asdsadafafas subscribed= path=/home/etcetcetec
[21:41] <toml_> rye, but it doesn't say =true
[21:41] <rye> toml_, ok, that's 10.04, False was not properly printed then
[21:42] <toml_> rye, okay, so I can safely delete the initial file structure that it laid down on the local machine before I told it not to sync?
[21:42] <rye> toml_, yes, to test - you can try keeping sd disconnected, remove the files/folders and then run u1sdtool --waiting-meta
[21:43] <toml_> rye, and that will then tell me whether it is will try to affect changes to that folder when i reconnect to the cloud?
[21:43] <rye> toml_, yes
[21:44] <toml_> rye, testing
[21:44] <toml_> rye, --waiting-meta ... nothing reported
[21:45] <rye> toml_, u1sdtool --status = ?
[21:46] <toml_> rye, connection: Not User With Network \ decription: ready to connect \ is_connected: false \ is_error: false \ is_online: false \ queues: IDLE
[21:47] <rye> toml_, awesome!, feel free to connect
[21:47] <toml_> rye, ta for walking me through it rye ... really appreciate the support
[21:47] <mahen> good night everyone ! thanks again jdobrien !
[21:47] <toml_> rye, also a good crash course in the tool ;)
[21:49] <rye> toml_, you are welcome!
[21:49] <toml_> rye, are you a dev for this tool, or just volunteering here?
[21:49] <rye> toml_, I am more like customer support
[21:49] <toml_> rye, aha, for canonical?
[21:50] <rye> toml_, canonical/ubuntuone-specific
[21:50] <jdobrien> rye, don't give away all our secrets on one day
[21:50] <toml_> rye, well, good on you man - clear instructions, really observant of what I was doing.  I am all ears!!!!
[21:51] <jdobrien> rye, :)
[21:51] <rye> well
[21:51] <rye> eyes
[21:51] <jdobrien> rye, well...of you disconnect the client
[21:52] <jdobrien> rye, then mv <oldname> <newname> && mv <newname> <oldname>
[21:52] <jdobrien> rye, on a huge directory...
[21:52] <jdobrien> rye, the stupid server tries to do it
[21:52] <jdobrien> rye, more specifically...my stupid code
[21:52] <jdobrien> rye, or...stupid me :)
[21:53] <rye> jdobrien, erm, okay, mv oldname newname - Move() oldname -> newname... and another Move() to bring newname into oldname... that's only one dir level change... right? node id is kept...
[21:54] <jdobrien> rye, bascially it results in a move that does nothing
[21:54] <jdobrien> rye, do it with the client disconnected to a large directory
[21:54] <jdobrien> rye, then reconnect the client and you're stuck
[21:55] <rye> jdobrien, but why large directory is a must?
[21:57] <jdobrien> rye, because the server tries to do a lot of work on moves... we're going to work on fixing that this cycle as well
[21:58] <jdobrien> rye, when you move a large directory structure, there are path renames and we need to check for shares etc....it's huge
[21:58] <rye> jdobrien, so TRY_AGAIN comes from db layer?
[21:58] <jdobrien> rye, usually yes
[21:59] <rye> jdobrien, so the query times out, then TRY_AGAIN is issued to the client which calls the server to perform the same operation which is locked which calls TRY_AGAIN and so on?
[21:59] <jdobrien> rye, it's not a locking issue as I once thought
[21:59] <jdobrien> rye, but you're close
[22:01] <rye> jdobrien, wow


[12:00] <littlegreenman> i know where it is
[12:00] <littlegreenman> but that whole svn is chinese to me
[12:01] <sivang> I know we have administrators for each language group, can't find that darn page though.
[12:01] <littlegreenman> i know you guys were having some kind of meeting today... i was busy doing other stuff
[12:02] <littlegreenman> but i will talk to falco and we can work on the portuguese translation side of things
[12:04] <sivang> littlegreenman : it was nothing formal, read the post on the ML :)
[12:05] <sivang> littlegreenman : http://www.ubuntulinux.org/wiki/SubVersion
[12:05] <sivang> use the part for repository users.
[12:06] <littlegreenman> sivang: sorry if i am asking things you guys have covered. but how is the whole ubuntu manual hornbeck was working on.... at what stage is this?
[12:06] <littlegreenman> is this being worked at?
[12:08] <sivang> we are integrating the hornbeck table of contents with the already available FAQ,
[12:08] <sivang> it already looks great :)
[12:08] <littlegreenman> :)
[12:08] <sivang> and even works great under the gnome help broswer
[12:08] <littlegreenman> yeah, the thing we were talking about... on the mailing list....
[12:09] <sivang> No, proble for questions :) However, I will say good night for now :) unless you have anything urget :)
[12:09] <littlegreenman> and this is in the svn thingy, the hornbeck http:// ip address he gives?
[12:09] <littlegreenman> just that last q :D
[12:09] <littlegreenman> gotta go too... tomorrow is monday, gotta work
[12:11] <sivang> yes
[12:11] <sivang> It is,
[12:11] <sivang> it's available there for checkout
[12:12] <littlegreenman> okidoki
[12:12] <littlegreenman> bye bye
[12:13] <littlegreenman> take care
[12:14] <sivang> night!
[12:49] <falco> well
[12:49] <falco> I'm leaving
[12:50] <falco> hasta people
[01:30] <robertj_afk> hornbeck, you here?
[01:32] <hornbeck> yes
[01:33] <robertj_afk> Whew, busy weekend, having a birthday is such a pain
[01:34] <hornbeck> I just got done replacing brakes on my wifes car
[01:34] <hornbeck> fun stuff
[01:34] <hornbeck> I am about to eat but I will be back in about 30
[01:36] <robertj> see you then
[01:41] <ggi> hi
[01:42] <ggi> I'm finally finished all the essays I've been bogged down with, and I'm wondering what I should start working on.
[01:47] <robertj> hornbeck: what are you using to build the docs?
[01:56] <robertj> ggi: Common Tasks listen to music is a good one
[01:58] <ggi> robertj: I'll take a look.
[02:09] <robertj> hornbeck: let me know when yo uget back
[02:12] <hornbeck> robertj: my wife wants me to go to the store with her
[02:12] <hornbeck> I am sorry
[02:12] <hornbeck> why not email me
[02:12] <hornbeck> hornbeck at freeshell dot org
[02:12] <hornbeck> that way we can work that way
[02:12] <robertj> wanted to just chat with you in person ;)
[02:13] <robertj> anyway, is there an yeasy way to build it as a single doc
[02:13] <hornbeck> have you heard all the stuff going on latly?
[02:13] <hornbeck> the book has been merged with the faq
[02:13] <hornbeck> it is all located at http://<IP_ADDRESS>/faq
[02:13] <robertj> so is edigint being done on the wiki?
[02:14] <hornbeck> it is all being done in docbook I think
[02:14] <hornbeck> I am really not sure
[02:14] <robertj> so is the stuff in svn deprecated?
[02:15] <hornbeck> it is in the faq svn repository
[02:15] <hornbeck> the book stuff from /book is no longer
[02:15] <hornbeck> do you read the mailing list?
[02:16] <hornbeck> it is all in a mail from plovs called usersguide.xml
[02:20] <hornbeck> gotta go
[02:20] <hornbeck> be back later
[02:22] <robertj> much better, the lack of a margin is bad though ;)
[03:59] <Hoodster> ChrisH: I have a question...
[04:34] <hornbeck> ChrisH: you here?
[04:36] <sivang> hi hornbeck, I'm here
[04:36] <hornbeck> hey
[04:36] <sivang> having trouble sleeping lately ...
[04:36] <sivang> :)
[04:37] <hornbeck> we are working toward Hoary with this new guide right?
[04:38] <sivang> yes :)
[04:38] <sivang> Finally we agreed , if I'm not mistaken.
[04:39] <hornbeck> ok, under system configuration in the new guide, do you think it should match up with the system configuration menu under computer?
[04:40] <sivang> lemme see.
[04:40] <hornbeck> it would make since, since we are calling it system configuration
[04:41] <sivang> I Know ChrisH has told me he wants to work on this section also
[04:41] <hornbeck> yeah I know he does
[04:41] <sivang> maybe you should be mailing him wait for his response on the morning?
[04:42] <sivang> or , UTC+2 morning :)
[04:42] <hornbeck> but in my old TOC it was identical to the Hoary System Configuration menu
[04:42] <hornbeck> thats why I was looking for him in here :-)
[04:42] <sivang> he's never here around these hours.
[04:42] <sivang> try maybe,
[04:43] <sivang> in about 5 more?
[04:43] <sivang> :)
[04:43] <sivang> is that reasonable for your timezone?
[04:43] <hornbeck> five more and I will be in bed
[04:43] <sivang> then 4? :)
[04:43] <hornbeck> it is about 10 at night here?
[04:43] <sivang> you mean, for me?
[04:43] <hornbeck> sorry did not mean the ?
[04:43] <hornbeck> it is 10 at night here
[04:43] <sivang> ah I see.
[04:43] <sivang> it's 5:43am here :)
[04:44] <sivang> didn't sleep at all in the night..
[04:44] <sivang> but sun hasn't come yet,
[04:44] <hornbeck> well it is really 9:43pm here
[04:44] <hornbeck> Sunday
[04:44] <sivang> You know what, mail me and him , I'll talk to him about it when I See him
[04:44] <sivang> what do you say?
[04:44] <hornbeck> well, I will start working on the Common Tasks section
[04:44] <hornbeck> see you tomorrow
[04:44] <sivang> have you mailed the list about it?
[04:45] <hornbeck> yeah, I just did
[04:45] <sivang> we all mailed the list with our intention on what to work.
[04:45] <sivang> ah ok
[04:45] <sivang> hreat!
[04:45] <sivang> great!
[04:45] <sivang> (damn the kbd)
[04:45] <hornbeck> of course for some reason the mail is not showing up
[04:45] <hornbeck> :-(
[04:45] <sivang> hmm lemme check
[04:45] <sivang> I think I got yours:
[04:45] <sivang> I will work on the Common Tasks.  Also some sections was left out of
[04:45] <sivang> System Configuration, if we are working towards Hoary.  I will add these
[04:45] <sivang> if that is alright.
[04:45] <sivang> John
[04:45] <hornbeck> I guess it did show up
[04:45] <sivang> yes I got it
[04:46] <hornbeck> kinda slow here I guess
[04:46] <sivang> maybe your getting lagged because of too many relay systems.
[04:46] <hornbeck> no one else took that did they?
[04:46] <hornbeck> maybe
[04:46] <sivang> I don't think so,
[04:46] <sivang> lemme check the list
[04:46] <hornbeck> my server is running slow
[04:46] <hornbeck> I may have missed some mail
[04:47] <sivang> Chris - I'll do the "System Configuration" part.
[04:47] <hornbeck> got that one
[04:47] <hornbeck> just you, plovs, and chris had posted about it right?
[04:47] <sivang> AP : I for one would like to start with: Part IV  Software
[04:47] <sivang> yes
[04:47] <hornbeck> ok
[04:47] <sivang> and me,
[04:47] <hornbeck> than I have them all
[04:47] <sivang> the about and the background info
[04:47] <sivang> :)
[04:48] <hornbeck> is it all going to be one file?
[04:48] <sivang> Was great looking the TOC In yelp btw:)
[04:48] <sivang> the toc you worked, together with the more work AP and chris put into it - supreb
[04:48] <hornbeck> I had that running like three days ago :-)
[04:48] <sivang> now we just need to put content into it
[04:48] <sivang> :)
[04:48] <sivang> who was that guy you worked with on the toc?
[04:48] <sivang> we should get him here and help on the content part
[04:48] <hornbeck> robertj
[04:49] <hornbeck> he was here earlier but I had to run
[04:49] <hornbeck> he is not filled in, on this change I do not thing
[04:49] <hornbeck> think
[04:49] <sivang> I don't reckon it would be much of a problem, after all nothing hard was done :)
[04:49] <sivang> only good IMHO
[04:50] <hornbeck> I feel kinda bad though because he worked alot on that with me
[04:50] <sivang> we need to focus on lowered earth, trimmed down goals for haory, this is the major one,
[04:50] <sivang> and the 2 others are following,
[04:50] <sivang> so guess it looks good.
[04:50] <hornbeck> and we had plans to work on the wiki and the docbook at the same time and keep them both up to date with the same info
[04:51] <hornbeck> well, I am going to start working on this.  Hopefully I will have a good amount of content in it this week
[04:51] <hornbeck> talk to you later
[04:52] <hornbeck> I like how he broke it all down into chapters
[04:55] <sivang> I see, well, the current suggestion is to use the wiki as an errata
[04:55] <sivang> which seems reasonable, what do you think?
[04:56] <sivang> It's too much work updating both the wiki and the dobook
[04:56] <sivang> and we have it doc book, we could always publish "unstable" braches to the website
[04:56] <sivang> exported is plain HTML.
[04:56] <sivang> Is this acceptable?
[05:09] <hornbeck> yes, that is good
[05:09] <hornbeck> him and I had talked about that before all the talk of the wiki only being used for errata had been discussed
[05:11] <sivang> I meant unstable=stable
[05:21] <hornbeck> right
[05:21] <hornbeck> what does gnome-common do?
[05:24] <sivang> did you apt-cache gnome-common?
[05:24] <sivang> sorry,
[05:24] <sivang>  apt-cache show gnome-common
[05:24] <hornbeck> nope?
[05:24] <hornbeck> that is neat
[05:25] <hornbeck> do you think it would hurt if I installed gnome-common from cvs so I can use yelp from cvs?
[05:26] <hornbeck> nevermind
[05:26] <hornbeck> using gnome-common from hoary let me build the new yelp
[05:29] <sivang> hornbeck : are you using jhbuild?
[05:29] <hornbeck> nope
[05:29] <hornbeck> I build all my own cvs stuff
[05:29] <hornbeck> I run alot of cvs
[05:29] <hornbeck> going to build evolution tonight
[05:30] <hornbeck> since the hoary evo does not work
[05:30] <sivang> you should use jhbuild
[05:30] <sivang> it is THE way to CVS :)
[05:30] <hornbeck> I don't like it
[05:30] <sivang> google for it,
[05:30] <hornbeck> I have used it before
[05:30] <sivang> what was wrong with it?
[05:30] <hornbeck> I used to use jhbuild and garnome
[05:30] <hornbeck> I just do things my way now
[05:30] <hornbeck> I have my own way of building
[05:31] <sivang> ./make install
[05:31] <sivang> ./mak
[05:31] <sivang> ?
[05:31] <sivang> what didn;t you like in it?
[05:31] <hornbeck> it always died on my
[05:31] <hornbeck> me
[05:31] <sivang> ah
[05:31] <hornbeck> I have not tried it for awhile though
[05:32] <hornbeck> maybe I will try it tonight
[05:32] <hornbeck> do you use it?
[05:32] <sivang> I used it to install yelp from cvs,
[05:32] <sivang> it just rulezed for this sole purpose
[05:32] <hornbeck> so you don't do a complete install with it?
[05:32] <sivang> I am trying,
[05:32] <hornbeck> nice
[05:32] <sivang> fd.o has been taken down to maintainance
[05:32] <sivang> after some compromise,
[05:32] <sivang> so it oculdn't install the whole gnome
[05:33] <sivang> but it's still working !
[05:33] <hornbeck> does it install to /opt still
[05:33] <sivang> no,
[05:33] <sivang> you set up a prefix
[05:33] <sivang> and everything goes there,
[05:33] <hornbeck> that is cool
[05:33] <sivang> keeping your system intouched
[05:33] <sivang> untouched
[05:33] <sivang> yes
[05:33] <sivang> very much
[05:33] <sivang> I'm getting acquinted with the ways of the GNOME :)
[05:33] <hornbeck> I like to break my stuff to much
[05:33] <hornbeck> I have always ran the whole GNOME from cvs till Ubuntu
[05:34] <hornbeck> I ran gentoo with my own ebuilds
[05:34] <plovs> morning guys
[05:34] <hornbeck> morning
[05:35] <sivang> hey plovs!
[05:35] <hornbeck> man beagle is rocking once again :-)
[05:35] <sivang> is it back in univesre?
[05:35] <plovs> hornbeck, good!
[05:35] <hornbeck> it never was in universe
[05:35] <plovs> sivang, i just too little
[05:36] <hornbeck> I need to make some beagle builds
[05:36] <hornbeck> but it is multiple binaries
[05:38] <plovs> hornbeck, how's evo?
[05:38] <hornbeck> broken
[05:39] <hornbeck> I am downloading the source from Ubuntu and the cvs so I can just roll my own binary
[05:39] <sivang> hornbeck : are you going to diff between the two and patch one?
[05:39] <hornbeck> yeah
[05:40] <hornbeck> is there a simple way to build debian packages?
[05:40] <sivang> I don't get it , could you please explain? how would that help you get a working evo?
[05:40] <hornbeck> like one command?
[05:40] <sivang> not exactly..
[05:40] <sivang> the build command at the end if you require no special setups is ttrue one command,
[05:40] <sivang> but you must make some preperations for it.
[05:40] <sivang> read the NM's guide
[05:41] <sivang> it is a very nice intro to this,.
[05:41] <hornbeck> I have read it
[05:41] <hornbeck> I was just wondering if there was something easier
[05:43] <sivang> I this this is as easier as it gets..
[05:46] <hornbeck> I did not know if some other method had come along
[05:47] <plovs> hornbeck, still need to rebuild the kernel for beagle?
[05:48] <hornbeck> yes
[05:48] <hornbeck> I have a prebuild on my server
[05:48] <hornbeck> if you want to try it, it is a stock kernel with inotify
[05:49] <hornbeck> stock ubuntu kernel with inotify
[05:49] <plovs> it's all the difference between rebuilding or not rebuilding
[05:49] <plovs> i liked it quite much without
[05:49] <plovs> why is inotify not yet in the kernel?
[05:50] <hornbeck> it will be in 2.6.10 from what I heard
[05:50] <hornbeck> I don't mind redoing the kernel, I have other stuff built in anyways
[05:51] <hornbeck> my laptop looks like crap with out the radion driver built in
[05:51] <plovs> i would like reiser4 and inotify
[05:51] <hornbeck> I am thinking of building Ubuntu Kernels with alot of patches and hosting them
[05:51] <plovs> for the rest i'm happy
[05:51] <hornbeck> alot of people want all the bells and whistles
[05:52] <plovs> hornbeck, well, if i can order, i need athlon with inotify as minimum, to go, please :-)
[05:52] <hornbeck> you want me to build you a kernel tonight?
[05:53] <plovs> hornbeck, if you've got the time sure, great (if not no prob)
[05:53] <plovs> ok, i'm of to make and have breakfast, bbl
[05:53] <sivang> hornbeck : take a look here also https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS
[05:54] <hornbeck> plovs I will build it while I am sleeping
[05:54] <hornbeck> all I have to do is change the arch
[05:54] <hornbeck> sivang thanks
[05:55] <hornbeck> check http://<IP_ADDRESS>/download in about 8 hours plovs
[05:55] <hornbeck> under athlon
[06:04] <hornbeck> you will be able to use download.opensoftdesign.org in about five hours
[06:04] <hornbeck> dns has to reset
[06:47] <plovs> hornbeck, great!
[07:05] <hornbeck> plovs: your kernel is building right now :-), and I am going to bed
[07:07] (plovs_work/#ubuntu-doc) hornbeck, thanks, and good night
[07:25] <hornbeck> plovs_work: you around?
[07:27] <hornbeck> your kernel is done :-)
[07:27] <hornbeck> ready when you need it
[09:20] <ChrisH> Moin, guys.  But this way I have more time writing the docs while sitting on the couch with a laptop on the lap.
[12:49] <lulu> ChrisH: Hi Chris :o)
[12:50] <plovs_work> ChrisH, that's the plus of being sick
[12:50] <plovs_work> lulu, hi!
[12:52] <ChrisH> Yet another tonsillitis... :(
[12:52] <cenerentola> hi ya there..
[12:53] <cenerentola> someone here knows how the wiki works?
[12:53] <cenerentola> and how is it being worked?
[12:54] <cenerentola> i "need" to know where i can find the exact dates of the conference
[12:56] <plovs_work> cenerentola, #ubuntu is for those kind of questions
[12:56] <cenerentola> sorry
[12:56] <lulu> cenerentola: on the front page of the website and where you put your name down for sponsorship - please read the website and search the wiki first......
[01:33] <falco> hi people
[01:35] <ChrisH> hi, falco
[01:35] <lulu> falco:hiya!
[01:56] <sivang> Hi All
[01:56] <Hoodster> Hi sivang
[01:56] <Hoodster> I can't stay, but I just want to wish everyone a great day!
[01:58] <falco> tanks, to you too
[01:59] <ChrisH> When do we apply for the "Friendliest Ubuntu Channel Award"? :)
[01:59] <sivang> I am setting up the competition as we speak...:)
[02:04] <sivang> Hey Lulu
[02:17] <lulu> sivang: hiya :o)
[02:18] <sivang> lulu : What do you think of our reorganization streamlined to several main doc feature goals? :)
[02:20] <hornbeck> morning
[02:22] <ChrisH> hornbeck: hey :)
[02:22] <lulu> sivang: great to have the focus - sorry - have all the doc tea emails still to catch up on.
[02:22] <lulu> hornbeck: hiya!
[02:23] <hornbeck> hows it going guys
[02:40] <lulu> guys - do we have docs for Windows users who want to convert to linux? and need some info/persuation?
[02:41] <lulu> persuasion....!
[02:42] <hornbeck> not that I know of
[02:42] <hornbeck> I think that is something being worked on
[02:42] <lulu> aah - just discovered - http://www.ubuntulinux.org/wiki/LinuxIntro which  is a start...
[02:43] <lulu> hornbeck: thanks.....this would be worth expanding on...
[02:43] <ChrisH> Probably hard to convert Windows users when Ubuntu comes neither with a virus scanner nor a firewall. ;)
[02:43] <ChrisH> sivang: Aren't you preparing an introduction chapter in the handbook? Could be something to include there.
 Probably hard to convert Windows users when Ubuntu comes neither with a virus scanner nor a firewall. ;) <[02:54] <sivang> lulu : I am working on this, it's a basis for the ntro section of the guide.
[02:55] <sivang> anyway, I have to arrange some stuff, be back in an hour or so
[02:56] <lulu> sivang: great - I am adding a link suggestion..
[02:57] <sivang_away> lulu : I'll talk to you in an hour or so :) this is only a very start part of it, this is a comprehensive background guide :)
[02:58] <lulu> ok!
[05:09] <ggi> hornbeck: Are you around?
[06:24] <ChrisH> What happened to the screenshot tool in Hoary? I don't see it. And it's not part of gnome-panel either.
[06:54] <ChrisH> Ah, seems to be bug 3556. :(
[07:00] <ggi> ChrisH: I remember seeing this on Planet GNOME. I think it's being rewritten: http://webwynk.net/jrb/#1100912296
[07:34] <sivang> Hi all again, back for a while.
[07:36] <ggi> Hello. Who do I ask for SVN commit access? hornbeck doesn't seem to be around.
[07:39] <sivang> Let's see what with ChrisH,
[07:39] <sivang> maybe he can help with it
[07:39] <sivang> :)
[07:40] <sivang> ChrisH : how do we give svn accesses to our devoted contributors ? :)
[07:44] <ChrisH> sivang, ggi: Hornbeck must create the account. I can't help here.
[07:44] <sivang> ChrisH : ah ok.
[07:44] <ChrisH> sivang: It's a file in his local file system (/etc/subversion/passwd). Unless I hack his system there is no way. And he will probably not like that. :)
[07:45] <ggi> Grr. When is he usually active here?
[07:47] <sivang> ggi : he popps now and the,
[07:47] <sivang> you can always mail him on the list and see where that gets you
[07:47] <sivang> :)
[07:47] <sivang> I reckon it wouldn't take too long before you get acceess .
[07:48] <ggi> I suppose. I'll go mail him.
[07:48] <ChrisH> ggi: Every once in a while. :)
[08:02] <lulu> night guys - see you tomorrow :o)


[01:19] <studio-bouzzi> I'm installing Ubuntu Studio on my computer right now...
[01:19] <studio-bouzzi> Is there somthing I should know?
[01:21] <studio-bouzzi> What is the best advise you would give about ubuntu Studio?
[07:53] <studio-user798> HELP
[07:54] <cfhowlett> !help
[13:24] <tj_>
[20:51] <studio-user843> greetings.   trying to install ubuntu studio 15.  live cd runs ok.  install seems to hang after "creating ext4 filesystem for /"
[20:51] <studio-user843> any hints how to tell what is going on?


[15:50] <shadeslayer> MOTU meeting in 10 minutes right?
[15:58] <tumbleweed> right
[15:59] <dholbach> yes :)
[16:00] <dholbach> I can chair if somebody else does minutes :)
[16:02] <dholbach> hum, that puts us in a bit of a deadlock situation :)
[16:02] <dholbach> ok, let's start anyway
[16:02] <dholbach> #startmeeting
[16:02] <meetingology> Meeting started Thu Aug 23 16:02:45 2012 UTC.  The chair is dholbach. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:02] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[16:02] <dholbach> agenda page is up at https://wiki.ubuntu.com/MOTU/Meetings
[16:03] <dholbach> micahg, around?
[16:03] <dholbach> or anyone else who'd like to talk about sqlite?
[16:03] <dholbach> #topic Killing off sqlite 2 (src:sqlite)
[16:04] <dholbach> Personally I haven't checked quantal-changes too closely, so I don't know how much progress we made in this regard.
[16:04] <tumbleweed> http://people.canonical.com/~ubuntu-archive/transitions/sqlite.html
[16:04] <tumbleweed> not much progress, no
[16:04]  * tumbleweed is also a little out of touch atm
[16:04] <dholbach> I mentioned it in the minutes of the last meeting and on the bug fixing initiatives page, but maybe we need to launch another call for help with this
[16:05] <dholbach> Ok, maybe somebody can send an email to the lists about this.
[16:06] <shadeslayer> I could try and help a bit, if someone could explain what needs doing ;)
[16:06] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative#Moving_away_from_sqlite
[16:06] <dholbach> Ah, it's not too much text - I can paste it:
[16:06] <dholbach> We would like to get away from moving sqlite in favour of sqlite3. http://paste.ubuntu.com/1138024/ has a list of packages which need to be built with sqlite3, sometimes some porting work will be involved in making the switch. Be sure to check for new versions upstream which already moved over. Also are there around 10 packages which depend on python-sqlite and will need to be moved over as well.
[16:06] <shadeslayer> alright
[16:07]  * shadeslayer can give one of the packages a try tonight
[16:07] <dholbach> when UDW is over I will start doing some more regular blog posts about specific bugs or specific targets - maybe this will help as well
[16:08] <dholbach> thanks shadeslayer
[16:08] <dholbach> #topic Update from DeveloperAdvisoryTeam.
[16:08] <shadeslayer> right, it helps if you have a set of smaller packaging bugs that people can get started with
[16:08] <dholbach> yes
[16:08] <shadeslayer> oh look, kraft, I've worked on that before, so I can start with that
[16:08] <dholbach> cool
[16:08] <dholbach> In the advisory team we just recruited 2 new members, jokerdino and vibhavp who have been doing a great job until now.
[16:09] <dholbach> And we're still reaching out to new contributors and get a lot of good feedback.
[16:09] <dholbach> Closer to the release we'll release the feedback again.
[16:09] <dholbach> That's all from your DAT.
[16:09] <dholbach> #topic Review https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
[16:10] <dholbach> shadeslayer, if you look at the wiki page - do you have any smaller packaging bugs we should put on there?
[16:10] <shadeslayer> nothing off the top of my head, no
[16:10] <dholbach> we should probably advertise this page even better - as it will likely help getting things done :)
[16:10] <shadeslayer> I can try and compile a list of small packaging bugs in Kubuntu
[16:10] <dholbach> great
[16:11] <dholbach> that'd be awesome
[16:11] <dholbach> if anybody else would have a look at the page and update it if necessary, that would be great - after UDW next week I'll have a look at it myself again
[16:12]  * shadeslayer adds to TODO
[16:12] <dholbach> excellent
[16:12] <dholbach> #topic Any other business?
[16:13] <shadeslayer> well ... question ...
[16:13] <dholbach> sure
[16:13] <shadeslayer> when considerign a new developer for a MOTU position
[16:13] <shadeslayer> do you focus on universe work that person has done
[16:13] <shadeslayer> or the ability to do packaging work
[16:14] <shadeslayer> *considering
[16:14] <dholbach> I'm not on the DMB, so I personally could just say what I /would/ do. :-)
[16:14] <shadeslayer> sure
[16:15]  * tumbleweed is on the DMB
[16:15] <micahg> dholbach: no, no progress yet on sqlite, will try to get to it after feature freeze
[16:15] <dholbach> but I assume that apart from a general demonstration of packaging skills and a track record of good work in Ubuntu, it will be interesting to see why MOTU upload rights would be relevant to them
[16:15] <dholbach> micahg, ok cool
[16:15] <shadeslayer> hm
[16:15] <tumbleweed> it's about work done and ability and trust
[16:16] <shadeslayer> tumbleweed: ^ your opinion?
[16:16] <tumbleweed> ability being less important than trust that the person won't go beyond their abilities
[16:16] <shadeslayer> right
[16:16] <tumbleweed> we do expect a certain level of skill, though
[16:17] <shadeslayer> *nod*
[16:17] <tumbleweed> motus are generalists, so they should already have a fairly wide packaging skillset
[16:17] <shadeslayer> yeah, I want to expand my packaging skillset, which is why I plan on contributing more to Universe
[16:17]  * dholbach hugs shadeslayer
[16:17] <shadeslayer> that, and now that Kubuntu is in Universe ;)
[16:18] <dholbach> :-)
[16:18] <dholbach> ok cool - any more topics for us? :)
[16:19] <shadeslayer> that's it from me :D
[16:19] <dholbach> #topic Updating the wiki for next meeting / minutes
[16:19] <dholbach> Is there anyone who could update the Wiki? :)
[16:20] <tumbleweed> I'm fairly tied up right now, I'm afraid. But I could tomorrow
[16:20] <dholbach> that'd be perfect
[16:21] <dholbach> thanks a lot tumbleweed
[16:21] <dholbach> thanks a lot everyone
[16:21] <dholbach> that was a quick meeting :)
[16:21] <dholbach> #endmeeting
[16:21] <meetingology> Meeting ended Thu Aug 23 16:21:13 2012 UTC.
[16:21] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-08-23-16.02.moin.txt
[16:21] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-08-23-16.02.html


[12:14] <tabu> hello! the mouse pointer disappears when I boot with two monitors connected VGA+DVI, booting with only one monitor and then plugging the other solved it, but is there other workaround?
[12:18] <tabu> my card is a Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
[12:29] <tabu> hello! the mouse pointer disappears when I boot with two monitors connected VGA+DVI, booting with only one monitor and then plugging the other solved it, but is there other workaround? I'm using a Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
[12:29] <cfhowlett> tabu, ask this in #ubuntu
[12:29] <tabu> logging in, then out and then in again solved it as well
[12:29] <tabu> ok
[12:29] <tabu> thank you!
[15:35] <sancho_panza> hi everybody
[15:35] <sancho_panza> can i ask for help to someone?
[15:36] <sancho_panza> i just need to be directed to the right direction :D
[16:49] <aluisio> how to play encrypted DVD on ubuntustudio?
[19:59] <studio-sheadtree> my install has not moved from "Creating ext4 file system / in partition #1 of LVM VG ubuntu-studio-vg, LV root..." for 15 minutes and suggestions?


[05:02] <mup> PR snapd#8854 closed: sysconfig/cloudinit: make callers of DisableCloudInit use WritableDefaultsDir <Simple 😃> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8854>
[05:12] <mup> PR snapd#8850 closed: dirs: delete unused Cloud var, fix typo <Cleanup :broom:> <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8850>
[05:24] <mborzecki> morning
[05:25] <mvo> hey mborzecki
[05:26] <mborzecki> mvo: hey
[05:36] <mborzecki> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1858636 is interesting
[05:36] <mup> Bug #1858636: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium <apport-collected> <eoan> <focal> <rls-ff-incoming> <snap> <wayland-session> <chromium-browser (Ubuntu):Confirmed> <snapd (Ubuntu):Confirmed for anonymouse67> <https://launchpad.net/bugs/1858636>
[05:42] <mup> PR snapd#8837 closed: snap: add an activates-on property to apps for D-Bus activation <Needs Samuele review> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8837>
[06:25] <zyga> Hey guys
[06:25] <zyga> Unclear if I will work today, depending on ability
[06:27] <mborzecki> zyga: hey
[06:28] <zyga> Hey :-)
[06:32] <mvo> zyga: good morning
[06:43] <zyga> Hey mvo
[06:44] <zyga> I will file time of for Friday
[06:48] <mvo> zyga: yeah, please do
[07:02] <pstolowski> morning
[07:03] <mborzecki> pstolowski:hey
[07:17] <mborzecki> heh, even without font cache, spotify snap still segfaults on my host
[07:21] <pedronis> hello
[07:24] <pedronis> pstolowski: hi, I left some comments/questions in #8812
[07:24] <mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services ⚙> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
[07:25] <pedronis> pstolowski: on a different note: is/can be #8532 useful or should we just close it?
[07:25] <mup> PR #8532: tests: install new snapd deb into preseed image <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8532>
[07:26] <pstolowski> pedronis: saw your comments, thanks for looking at it!
[07:27] <pstolowski> pedronis: 8532 might be useful, i need to think
[07:28] <pedronis> pstolowski: ok, on a 3rd note: do you want to look at #8823 more ?
[07:28] <mup> PR #8823: asserts/internal: limit Grouping size switching to a bitset representation <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8823>
[07:29] <pstolowski> pedronis: yes, i'll conclude this review today
[07:30] <pedronis> mvo: mborzecki: hi, we were having issues with centos on Fri, are we looking into it?
[07:30] <mborzecki> pedronis: what kind of issues?
[07:31] <mborzecki> let me check the most recent prs
[07:31] <pedronis> mborzecki: https://github.com/snapcore/snapd/pull/8855/checks?check_run_id=766170841 selinux/package related
[07:31] <mup> PR #8855: cmd,many: move Version and bits related to snapd tools to snapdtool, merge cmdutil <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8855>
[07:32] <mborzecki> pedronis: yeah, it's the same as https://forum.snapcraft.io/t/snapd-updates-in-fedora-epel-for-enterprise-linux/8310/28?u=mborzecki
[07:33] <pedronis> mborzecki: do we need to mark them unstable?
[07:34] <pedronis> 7 is also failing and marked required
[07:34] <mborzecki> pedronis: maybe, i need to poke around a bit more, had some trouble refreshing rhel vms in the morning
[07:38] <mup> PR snapd#8858 opened: asserts,daemon: add support for "serials" field in system-user assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/8858>
[07:49] <mborzecki> heh, so centos is lagging behind again
[07:50] <mborzecki> and snapd 2.45 installs fine on rhel8
[08:01] <mborzecki> hm a build of selinux-policy for centos in a sufficient version was done a couple of days ago https://koji.mbox.centos.org/koji/buildinfo?buildID=11412 but no clue where to find it
[08:08] <mup> PR snapd#8859 opened: tests: enable snap-auto-mount test on core20 <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8859>
[08:19] <mborzecki> pedronis: mvo: yeah, so with some info from folks in #centos it is lagging behind, 8.2 is in the oven so no updates are being pushed, and in general there is no clear solution for the latency of updates from rhel (which is used for epel builds) appearing in centos
[08:20] <pedronis> mborzecki: mvo: so short term we shoul mark both centos unstable?
[08:20] <mborzecki> perhaps we should make that test smarter, rather than dumping whole centos to unstable
[08:21] <pedronis> mborzecki: that sounds ok, but if is not trivial we should first unblock landings
[08:22] <pedronis> mborzecki: also it's a bit unclear is a good use of time, I don't know. I agree that the fact that we have fully unsable systems, instead of unstable tests is a bit of a problem
[08:23] <mborzecki> otoh, how do we mark the system unstable right now?
[08:26] <mvo> mborzecki: I can mark it unstable (I uncheck "required test" in the settings box for this)
[08:26] <mborzecki> mvo: please do
[08:30] <mvo> mborzecki: done, centos-7 is no longer required
[08:30] <mborzecki> mvo: centos-8 :)
[08:31] <mvo> mborzecki: that is already not-required
[08:31] <mvo> mborzecki: should I make -7 required again?
[08:31] <mborzecki> mvo: yeah, sorry, centos-7 is good, only 8 needs to be non-mandatory
[08:32] <mvo> mborzecki: updated again, thank you :)
[08:45] <mborzecki> sil2100: hey, can you take a look at https://github.com/CanonicalLtd/ubuntu-image/pull/189 ?
[08:45] <mup> PR CanonicalLtd/ubuntu-image#189: ubuntu_image: do not overwrite the files that snap prepare-image has created <Created by bboozzoo> <https://github.com/CanonicalLtd/ubuntu-image/pull/189>
[08:48] <mup> PR snapd#8823 closed: asserts/internal: limit Grouping size switching to a bitset representation <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8823>
[08:53] <mup> PR snapd#8860 opened: overlord: refuse to install snaps whose activatable D-Bus services conflict with installed snaps <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8860>
[08:59] <mborzecki> quick errand
[08:59] <zyga> starting work
[09:01] <zyga> pedronis: thank you for the changes to https://github.com/snapcore/snapd/pull/8829 - they look good
[09:01] <mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
[09:01] <zyga> pedronis: I will prepare the next chunk in a moment
[09:02] <zyga> mborzecki: what is up with centos-8?
[09:02] <zyga>  Problem: package snapd-2.45-1.el8.x86_64 requires snapd-selinux = 2.45-1.el8, but none of the providers can be installed
[09:04]  * zyga reads backlog
[09:15] <pedronis> pstolowski: thanks, I expanded a bit my considerations: https://github.com/snapcore/snapd/pull/8812#discussion_r440038759
[09:15] <mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services ⚙> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
[09:17] <pstolowski> pedronis: thank you
[09:21] <zyga> mborzecki: do you think you could do a 2nd review for 8829?
[09:21] <zyga> it's the same code, just split out and polished a little
[09:35] <mborzecki> re
[09:36] <mborzecki> pstolowski: which snap did you try to debug with --gdbserver?
[09:36] <pstolowski> mborzecki: hello-world
[09:37] <mborzecki> ok, let me try that
[09:38] <mborzecki> meh, python 3.5 vs 3.8
[09:38] <mup> PR snapd#8861 opened: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>
[09:40] <mborzecki> zyga: centos-8 should be marked as unstable, even if it fails it should be possible to merge a PR
[09:40] <zyga> I see
[09:40] <zyga> are we waiting for something to migrate?
[09:40] <mborzecki> zyga: and i'll be adding some details about centos-8 and epel to the standup docs
[09:40] <zyga> ok
[09:44] <pedronis> mborzecki: hi, I updated https://github.com/snapcore/snapd/pull/8844 to keep only the benchmarks as we discussed previously
[09:44] <mup> PR #8844: asserts/internal: add some iteration benchmarks <Created by pedronis> <https://github.com/snapcore/snapd/pull/8844>
[09:48] <mborzecki> pedronis: thanks!
[09:54] <pedronis> mvo: I reviewed #8858, missing some bits (format is a bit complicated)
[09:54] <mup> PR #8858: asserts,daemon: add support for "serials" field in system-user assertion <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8858>
[09:55] <mvo> pedronis: thank you, looking
[10:00] <pstolowski> mborzecki: are you checking my remark about seond 'continue'?
[10:01] <mborzecki> pstolowski: yeah, that was my intention, but got into a fight with py35 in ubuntu-image :/
[10:01] <pstolowski> haha
[10:44] <mup> PR snapd#8784 closed: snap: add new `snap run --experimental-gdbserver` option <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8784>
[10:55] <jamesh> mborzecki: would you have any idea of what sort of changes I'd need to fix this error? https://github.com/snapcore/snapd/pull/8861#issuecomment-644048833
[10:55] <mup> PR #8861: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>
[10:55] <mborzecki> jamesh: looking
[10:56] <jamesh> mborzecki: in short, I need to make a couple of directories under /var/lib/snapd readable by dbus-daemon
[10:56] <jamesh> while being writable by snapd
[10:57] <mborzecki> jamesh: should be fairly simple, i can push a patch there
[10:58] <jamesh> mborzecki: thanks.  That seemed like the only legitimate failure in the logs so far.
[10:58] <jamesh> good thing you added that regression test :-)
[10:59] <mborzecki> jamesh: mhm, yeah we need to updae the policy, system_dbusd_t (used dbus-daemon) does not have read access to /var/lib/snapd
[11:00] <jamesh> mborzecki: I suppose we can't just label /var/lib/snapd/dbus in a way to give it access if it can't read /var/lib/snapd :(
[11:00] <jamesh> or traverse it at least
[11:01] <popey> I have updated a snap (atom) which now complains that "- Mount snap "atom" (256) (cannot find required base "core")" - but i have core installed. https://paste.ubuntu.com/p/kMNzw3Jj8v/   any ideas?
[11:01] <popey> you can "snap install atom --edge --classic" to try for yourself.
[11:02] <mborzecki> jamesh: we could use the same label as /usr/share/dbus/services.d but then quite likely we'd need to update the snapd policy to allow snapd write access there
[11:02] <mborzecki> jamesh: either way, a change is needed
[11:02] <mborzecki> i wonder why there was no error on fedora though
[11:04] <zyga> jamesh: hi
[11:04] <zyga> sorrym I'm not around during the calls much
[11:04] <zyga> not the best moment in my life
[11:04] <jamesh> mborzecki: it should be similar label to /usr/share/dbus-1/{services,system-services} -- not sure if that differs to session.d/system.d
[11:04] <zyga> I left a pair of small comments on https://github.com/snapcore/snapd/pull/8861
[11:04] <mup> PR #8861: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>
[11:04] <jamesh> zyga: no problem
[11:05] <zyga> jamesh: sorry to nickpick about the name but I really wonder why we use "services" and not "session-services"
[11:06] <jamesh> zyga: I followed the naming scheme that D-Bus uses, as mentioned in the comment.  I'm not sure it is worth being different
[11:07] <zyga> I see, I missed that when jumping through the diff
[11:11] <jamesh> zyga: and as always, thanks for the review feedback :-)
[11:15] <mborzecki> jamesh: do we need to reload dbus-daemon to have it pick up those extra conf files?
[11:15] <mborzecki> i would guess that system dbus got reloaded/restarted on centos 7 and that triggered the denial
[11:17] <zyga> Interesting, I recall a bug where it would only work if a directory was present to start with
[11:17] <zyga> as otherwise dbus would not establish some inotify watch
[11:17] <zyga> I don't recall the details
[11:18] <jamesh> mborzecki: there is a restart method you can send, but I think it generally picks things up via inotify these days
[11:19] <jamesh> mborzecki: we don't currently do it when adding/removing system bus policy, but probably should.
[11:19] <jamesh> perhaps that should be a new PR
[11:19] <mborzecki> jamesh: isn't inotify only for service.d system.d directories?
[11:22] <jamesh> mborzecki: once it reads the new config file from /usr/share/dbus-1/system.d or session.d, it should start monitoring the new directory for service activation files
[11:34] <zyga> core20 prepare fails, has anyone looked at that?
[11:44] <pedronis> that's recent
[11:56] <mborzecki> jamesh: heh, the test is fine in isolation as suspected
[12:09] <clmsy> hi everyone, quick question, were there any known changes to gadget structure for core20 builds?  my ubuntu-image cli fails on the last step of building a core20 based image with "cant find boot config".
[12:09] <clmsy> in the gadget's stage folder i can see all the grub related files
[12:16] <clmsy> ooh one sec i realized something... snapcraft clean actually never removes gadget and parts folder somehow, i manually deleted them, did another build and the gadget snap is created but there is no stage or parts folder hmm
[12:18] <zyga> mborzecki: o/
[12:18] <zyga> mborzecki: I opened a small tweak and another chunk carved out of the refresh tracking logic
[12:19] <zyga> mborzecki: the tweak is https://github.com/snapcore/snapd/pull/8862 and is really small apart from mv'ing some code around - I did this to allow the diff in cgroup.go (in subsequent branches) to be readable
[12:19] <mborzecki> zyga: trading PR for PR https://github.com/snapcore/snapd/pull/8864 :)
[12:19] <mup> PR #8862: sandbox/cgroup: improve pid parsing code <Created by zyga> <https://github.com/snapcore/snapd/pull/8862>
[12:19] <mup> PR #8864: cmd/snap: do not show $PATH warning when executing under sudo on a known distro <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8864>
[12:19] <zyga> mborzecki: and to make sure I didn't break anything in conflict resolution
[12:19] <mup> PR snapd#8862 opened: sandbox/cgroup: improve pid parsing code <Created by zyga> <https://github.com/snapcore/snapd/pull/8862>
[12:19] <mup> PR snapd#8863 opened: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
[12:19] <zyga> mborzecki: gladly :)
[12:19] <mup> PR snapd#8864 opened: cmd/snap: do not show $PATH warning when executing under sudo on a known distro <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8864>
[12:19] <zyga> mborzecki: the only new change is that I simplified PidsInGroup
[12:20] <zyga> compare https://github.com/snapcore/snapd/pull/8862/files#diff-a44752c174bd4af51ccc892ed5bc15b4L212 and https://github.com/snapcore/snapd/pull/8862/files#diff-a5c0640204de19f988a6d5446e6108e6R32
[12:20] <zyga> it was a simple code reuse as everything was exactly the same
[12:20] <zyga> the https://github.com/snapcore/snapd/pull/8863 is a bigger PR that involves one main new function in the form taken verbatim out of refresh app awareness v2 branch - again split to a new file for readability
[12:20] <mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
[12:21] <mborzecki> mhm
[12:21] <zyga> comments there probably need tweaking but the logic is what I wanted it to be
[12:21] <zyga> the comment on the PR is more accurate than than the comments inside
[12:21] <zyga> ok, that's that
[12:21] <zyga> going to look at your PR :)
[12:23] <zyga> mborzecki: is there a spread test that shows this warning?
[12:24] <mborzecki> zyga: afaik there isn't one
[12:25] <zyga> ok
[12:25] <zyga> btw, I found one thing over weekend
[12:25] <zyga> grep -x
[12:25] <zyga> very useful for line matches
[12:25] <zyga> especially as grep -qFx
[12:25] <zyga> quiet, literal, whole line matches
[12:25] <zyga> it's essentially a line in open("fname").splitlines() in shell
[12:26] <zyga> mborzecki: could you add a test, I think it's going to be useful to let us know the list is stale
[12:26] <zyga> apart from that and the nitpick inline +1
[12:47]  * zyga reviews services changes from pawel
[12:50] <mup> PR snapcraft#3170 closed: repo: decouple fetch and unpack stage-packages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3170>
[12:55] <pedronis> clmsy: yes, gadget look different/have different details in UC20 (and some details are still in flux), I recommend ATM looking at the 20 branches of https://github.com/snapcore/pi-gadget and https://github.com/snapcore/pc-amd64-gadget for an idea
[13:28]  * zyga lunch break (ha ha, in bed :()
[13:35] <roadmr> zyga!!! hope you get better! I'm too far to help but let me know if I can in any way
[13:39] <zyga> thanks Daniel, being here and working keeps me sane
[13:41] <roadmr> 👍
[13:41] <roadmr> just don't work too much :)
[13:41] <Saviq> ijohnson: confirmed the classic → strict refresh issue https://bugs.launchpad.net/snapd/+bug/1883538
[13:41] <mup> Bug #1883538: Classic to strict refresh requires manual intervention <snapd:New> <https://launchpad.net/bugs/1883538>
[13:42] <Saviq> almost looks like staged refresh…
[13:43] <Saviq> we only have about 10% of the people tracking stable on the most recent revision (that's out for a week now)
[13:43] <Saviq> mvo: FYI ↑
[13:45] <mvo> Saviq: oh, interessting. thank you, will look after my current meeting
[14:00] <ijohnson> thanks Saviq
[14:00] <ijohnson> we will look in a bit, I too have a meeting now :-)
[14:02] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8812#pullrequestreview-430673354
[14:02] <mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services ⚙> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
[14:02] <pstolowski> zyga: thank you
[14:06]  * zyga debugs the core 20 prepare failure
[14:12] <abeato> has anybody tried running UC20 on kvm + TPM (simulated or passthrough) for disk encryption?
[14:12] <ijohnson> abeato: yes not passthrough, but simulated
[14:12] <abeato> ijohnson, cool - any special issue with that or things just work?
[14:13] <ijohnson> abeato: yes it should just work, what issues are you running into?
[14:13] <abeato> ijohnson, none, just double checking before I enter a rabbit hole :)
[14:13] <ijohnson> abeato: for now, I use the swtpm-mvo snap + socket to provide to qemu
[14:13] <abeato> ijohnson, will try that, thanks
[14:14] <ijohnson> abeato: this is my qemu cmdline I use with a copy of the OVMF_VARS.ms.fd from the ovmf package:
[14:14] <ijohnson> https://www.irccloud.com/pastebin/I4HPR8u9/
[14:53] <mborzecki> zyga: should probbaly land https://github.com/snapcore/snapd/pull/8863 first
[14:53] <mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
[14:54] <mborzecki> zyga: w8, not this one, this one: #8862
[14:54] <mup> PR #8862: sandbox/cgroup: improve pid parsing code <Created by zyga> <https://github.com/snapcore/snapd/pull/8862>
[14:55] <zyga> looking
[14:55] <zyga> yeah
[14:55] <zyga> with one review?
[14:55] <zyga> maybe pawel can do a quick one
[14:55] <zyga> it's just moving a few lines around
[14:55] <zyga> mborzecki: thanks for this!
[14:56] <mborzecki> zyga: or ijohnson/cmatsuoka maybe?
[14:56] <zyga> yeah
[14:56] <zyga> anyone who's around
[14:56] <zyga> sorry, I'm kind of out of touch
[14:56] <zyga> ah I see ijohnson is around
[14:56] <ijohnson> whats up
[14:56] <cmatsuoka> which PR?
[14:56] <zyga> https://github.com/snapcore/snapd/pull/8862
[14:56] <mup> PR #8862: sandbox/cgroup: improve pid parsing code <Created by zyga> <https://github.com/snapcore/snapd/pull/8862>
[14:57] <zyga> 2nd review, just moving code around _and_ simplifying the main function since it had a common implementation with a private function already present
[14:57] <zyga> it's good to chat to you guys btw
[14:57] <zyga> I'm sorry for not joining the standups now
[14:57] <zyga> I really want to get over this part of my life
[14:57] <mborzecki> ijohnson: zyga: if https://github.com/snapcore/snapd/pull/8864 is green, i'll merge it and add a test in a follow up
[14:57] <mup> PR #8864: cmd/snap: do not show $PATH warning when executing under sudo on a known distro <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8864>
[14:58] <ijohnson> k, sounds good to me
[14:58] <zyga> mborzecki: that's okay
[14:58] <zyga> mborzecki: the test is mainly to see it break over time
[14:58] <zyga> :)
[14:58] <zyga> kind of distro-sensors
[15:00] <pedronis> is spread on core 20 working now?
[15:00] <ijohnson> pedronis: it seems that preparing it intermittently fails because there are snaps in the classic 20.04 image we use to prepare it
[15:00] <zyga> yeah
[15:00] <ijohnson> I saw some reds preparing on Friday, some greens preapring on Friday
[15:00] <zyga> I'm running a loop to get a shell and look around
[15:01] <pedronis> is this the issue that we seem not to get the same image all the time?
[15:01] <ijohnson> I think it's really the problem that mvo described is that we don't get the same image all the time
[15:01] <ijohnson> pedronis: yes
[15:01] <ijohnson> at least afaict
[15:01] <pedronis> :/
[15:01] <ijohnson> maybe it's something else too
[15:02] <zyga> woah
[15:02] <zyga> interesting
[15:03] <zyga> do we have hard proof that this happens?
[15:03] <zyga> (!same image)
[15:03] <ijohnson> zyga: the hard proof is that we sometimes get an image with snaps installed in it, and sometimes we get an image without snaps installed in it
[15:04] <zyga> hmm
[15:04] <zyga> maybe we always get an image with a seed inside
[15:04] <ijohnson> iirc mvo added a check to make preparing fail if it detects snaps installed in the image
[15:04] <zyga> and we sometimes manage to seed
[15:04] <zyga> and sometimes dont
[15:05] <ijohnson> zyga: you approved the PR :-)
[15:05] <ijohnson> https://github.com/snapcore/snapd/pull/8849
[15:05] <mup> PR #8849: tests: fail in setup_reflash_magic() if there is snapd state left <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8849>
[15:05] <zyga> yeah but I didn't know it turned something up
[15:07] <cmatsuoka> zyga: so from what I see 8862 is just reorganization, without any feature changes?
[15:07] <zyga> cmatsuoka: yes
[15:07] <zyga> cmatsuoka: one tiny code change, if you look at the public function
[15:07] <zyga> but it's 100% identical after, just calls a helper that happens to do the common tail
[15:08] <cmatsuoka> zyga: yes, I noticed that, and it looks better this way
[15:08] <zyga> yeah, it's easy to follow top to bottom
[15:10] <zyga> thanks guys!
[15:12] <cmatsuoka> zyga: how are you feeling? getting better?
[15:12] <zyga> cmatsuoka: not actually
[15:12] <zyga> cmatsuoka: more news on Wednesday after doc visit
[15:16] <cmatsuoka> zyga: I hope you get well soon
[15:16] <zyga> thanks, I really want to
[15:50] <mup> PR snapd#8865 opened: workflow <missing-colon> test PR title as part of the static checks again <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8865>
[16:10] <zyga> https://github.com/snapcore/snapd/pull/8863 is now ready for review
[16:10] <mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
[16:10] <zyga> broken out of the refresh-app-awareness-v2 branch
[16:10] <mup> PR snapd#8862 closed: sandbox/cgroup: improve pid parsing code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8862>
[16:59] <ijohnson> hey folks, could I get reviews on https://github.com/snapcore/snapd/pull/8519, it is green now after I debugged it more and fixed the test
[16:59] <mup> PR #8519: tests/special-home-can-run-classic-snaps: re-enable <Test Robustness> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8519>
[18:31] <mup> PR snapd#8844 closed: asserts/internal: add some iteration benchmarks <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8844>
[19:01] <mup> PR snapd#8864 closed: cmd/snap: do not show $PATH warning when executing under sudo on a known distro <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8864>
[19:06] <mup> PR snapd#8866 opened: tests/main: add spread test for running svc from install hook <Services ⚙> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8866>
[19:41] <mup> PR snapd#8867 opened: interfaces: add uinput interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8867>
[20:06] <mup> PR snapd#8868 opened: interfaces: add system-source-code for access to /usr/src <Needs Samuele review> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8868>
[20:46] <mup> PR snapd#8869 opened: asserts/internal: expand errors about invalid serialized grouping labels <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8869>
[20:51] <mup> PR snapd#8317 closed: many: make sure ephemeral failover snapd does not open sockets <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8317>
[21:27] <mup> PR snapd#8870 opened: interfaces: add gconf interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8870>
[21:32] <mup> PR snapd#8871 opened: tests/prepare-restore.sh: reset-failed systemd-journald before restarting <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8871>
[21:42] <mup> PR snapd#8872 opened: tests/lib/prepare-restore.sh: if we failed to purge snapd deb, ls /var/lib/snapd <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8872>
[22:02] <mup> PR snapd#8873 opened: interfaces: misc small interface updates <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8873>


[00:01] <StevenK> wgrant: http://pastebin.ubuntu.com/1199747/
[00:03] <wgrant> StevenK: Have you confirmed that it now fails with the diff reverted?
[00:04] <StevenK> wgrant: Just did.
[00:05] <StevenK> IllegalTarget: Product-name-100217 doesn't allow Private bugs.
[00:05] <wgrant> Sounds good, then
[00:10] <wgrant> StevenK: Hm, why are you using multiple products?
[00:36] <StevenK> wgrant: Sorry, was noming. Yeah, let me remove that bit.
[00:42] <StevenK> wgrant: http://pastebin.ubuntu.com/1199798/
[00:43] <wgrant> StevenK: You could also remove the makeCommercialSubscription bit if you use makeProduct(bug_sharing_policy=BugSharingPolicy.PUBLIC_OR_PROPRIETARY)
[00:43] <StevenK> Does that also allow USERDATA?
[00:44] <wgrant> Yes
[00:44] <StevenK> Which invalidates the test, does it not?
[00:44] <wgrant> You'd still have to transition it to BugSharingPolicy.PROPRIETARY after creating the bug
[00:44] <wgrant> It just saves you from having to manually create the commercialsubscription
[00:45] <StevenK> I think it's moot, it would be the same amount of lines
[00:45] <StevenK> But I can if you want
[00:46] <wgrant> Perhaps
[00:46] <wgrant> Anyway, it looks fine now
[00:50] <StevenK> wgrant: The diff is updated if you want to +1
[00:51] <wgrant> You can actually kill of two more lines by not setting the product or bug owners, but I think you might kill me too
[00:53] <StevenK> wgrant: And use login_celebrity, I guess
[00:54] <wgrant> StevenK: person_logged_in(product.owner)
[00:54] <wgrant> Due to the APG it'll even have access to the bug
[00:56] <StevenK> wgrant: owner killed
[00:56] <wgrant> That sounds painful
[00:56] <StevenK> Haha
[00:58] <StevenK> wgrant: Thanks, tossing at ec2.
[01:00] <StevenK> Bloody hell, buildbot, finish already
[01:04] <StevenK> wallyworld, wgrant: Some cards can probably move out of QA-Landing
[01:04] <wallyworld> probably
[01:07] <wgrant> buildbot only finished 30 seconds ago
[01:08] <StevenK> wgrant: Heh, it was saying 56 minutes when I looked 10 minutes ago.
[01:08] <wgrant> 6 seconds after you mentioned QA-Landing, in fact...
[01:32] <lifeless> bigjools:<PHONE_NUMBER>
[01:32] <lifeless> bigjools: 1.9B
[01:32] <bigjools> lifeless:<PHONE_NUMBER>58798
[01:33] <lifeless> bigjools: rows.
[01:33] <bigjools> sweet
[01:33] <lifeless> can we scale? Yes we can!
[01:33] <lifeless> of course, it is 68GB on disk.
[01:34] <wgrant> + indices
[01:34] <wgrant> If we're talking about branchrevision, there's like 100GB of indices
[01:35] <wgrant> Ah, no, only about 70GB now.  Does that sound like a good design to you?"
[01:39] <lifeless> bigjools: "If that's what they need to do to get those kickass benchmarks, then it's a great design."
[01:39] <bigjools> lifeless: "Does /dev/null support sharding?"
[01:39] <bigjools> I can't continue, laughing too hard
[01:40] <lifeless> bigjools: you hadn't seen this ?
[01:40] <bigjools> I have
[01:40] <bigjools> but it remains hilarious
[01:42] <lifeless> indeed!
[01:43] <lifeless> bigjools: http://www.xtranormal.com/watch/11762072/native-html5
[01:45] <wgrant> ORDER BY Branch.date_last_modified DESC, Branch.target_suffix ASC, Branch.lifecycle_status DESC, Branch.owner_name ASC, Branch.name ASC
[01:45] <wgrant> would you like some tie-breakers?
[01:55] <wgrant> lifeless: Have you thought about getting eg. bug search totals from bugsummary?
[01:56] <lifeless> I think that would rock
[01:56] <lifeless> only works for some cases though
[01:56] <lifeless> could be used to set upper bounds on bad estimates.
[01:56] <lifeless> (can't be used to set lower bounds with our search algebra)
[01:57] <wgrant> Yeah
[01:57] <wgrant> Most of the common searches should work
[01:57] <lifeless> personally I just want to nuke all the counts
[01:57] <wgrant> Obviously not fti
[01:57] <lifeless> or make them round - 10's 100's 1000's
[01:58] <lifeless> put that behind a FF for a bit
[01:58] <lifeless> see what the reaction is
[01:58] <lifeless> if its good, change the code base to estimate everywhere.
[02:00] <lifeless> bigjools: this is hilarious - http://www.xtranormal.com/watch/7023615/watch_movie
[02:00] <bigjools> must...resist....
[02:00] <bigjools> too much to do
[02:01] <mwhudson> lifeless: i didn't think the native-html5 one was very funny
[02:01] <mwhudson> it was quite odd, though, so that's something i guess
[02:01] <wgrant> lifeless: Well, EXPLAIN-based estimates will often be waaaaaaay off
[02:01] <lifeless> mwhudson: the html5 one was not as good as I thought it would be
[02:02] <lifeless> mwhudson: the one I just linked is a follow on from the mongodb one
[02:02] <lifeless> wgrant: shrug :>
[02:02] <mwhudson> ahh
[02:02] <lifeless> wgrant: I guess we need some care
[02:02] <wgrant> It should be better now that we have bugtaskflat, I guess
[02:02] <wgrant> But before bugtaskflat it would have been hopeless
[02:04] <mwhudson> lifeless: ok, watch_movie is pretty good
[02:04] <mwhudson> 3 mins in
[02:06] <wgrant> OOPS report is pretty today :)
[02:06] <lifeless> much better
[02:06] <lifeless> not sure I'd call it pretty
[02:07] <wgrant> Well
[02:07] <wgrant> Prettier than it's been for a while
[02:07] <lifeless> yes
[02:07] <lifeless> massive improvement
[02:07] <lifeless> just there is more to do
[03:42] <StevenK> wgrant: https://dogfood.launchpad.net/ubuntu/+source/unity/+changelog
[03:53] <lifeless> grah
[03:53] <lifeless> Non-sql time: 5595 ms
[03:53] <lifeless> if you're fixing timeouts
[03:53] <lifeless> https://bugs.launchpad.net/~lifeless/?advanced=1
[03:55] <lifeless> bug 1049452 if anyone wants to have a poke
[03:55] <_mup_> Bug #1049452: Person:+bugs timeout on advanced search form  <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1049452 >
[03:56] <lifeless> wgrant: StevenK: How do we release launchpad-buildd ?
[03:57] <wgrant> lifeless: dch -i
[03:57] <wgrant> lifeless: Then wait for IS to get us builders back
[03:57] <lifeless> also, annoying - why is https://bugs.launchpad.net/python/+bug/96878 not FR for python, upstream has it as such.
[03:57] <wgrant> Then RT
[03:57] <_mup_> Bug #96878: Launchpad session cookie is accessible from Javascript <bugjam2010> <infrastructure> <lp-foundations> <qa-ok> <Launchpad itself:Fix Released by wgrant> <Python:Fix Committed> < https://launchpad.net/bugs/96878 >
[03:58] <wgrant> lifeless: Resolution: accepted
[04:02] <wgrant> lifeless: tsk tsk, duping your own timeout bugs
[04:04] <lifeless> well, blame my short memory
[04:09] <wgrant> lifeless: I was hoping the timeout was on +reportedbugs..
[04:09] <lifeless> wgrant: the search works fine...
[04:09] <lifeless> wgrant:
[04:09] <lifeless> 57 queries/external actions issued in 1.68 seconds
[04:09] <lifeless> AJAX Log ↓
[04:09] <lifeless> not the fastest thing under the sun, but working >> not working.
[04:09] <lifeless> Can't /setup/ the query though.
[04:09] <lifeless> The form DIAF.
[04:10] <lifeless> I bet its listing milestones for every project on Launchpad, more or less.
[04:10] <wgrant> I made that pretty fast in most cases
[04:10] <wgrant> But maybe you're terrible :(
[04:10] <lifeless> and doing so super inefficiently. Probably a list of storm objects
[04:10] <lifeless> with in
[04:11] <lifeless> milestone in milestones: <- trigger the sqlbase __eq__ which is dog slow.
[04:11] <lifeless> + quadratic in a list.
[04:11] <wgrant> Not that slow
[04:11] <lifeless> -bet you-
[04:11] <lifeless> yes that slow
[04:11] <lifeless> we've had 20s timeouts from that before.
[04:11] <lifeless> shortly after new bug subscriptions, if you recall
[04:12] <wgrant> Perhaps
[04:34] <StevenK> wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/dsp-changelog-timeout/+merge/123880
[04:35] <wgrant> StevenK: Have you recowboyed that to check that the query count is now sanE?
[04:37] <StevenK> No, let me that do
[04:39] <StevenK> My dyslexia seems strong today
[04:39] <StevenK> At least I didn't run make start stop
[04:41] <wgrant> Heh
[04:41] <wgrant> Huh
[04:42] <StevenK> wgrant: 198 -> 51
[04:42] <wgrant>  Limit  (cost=10000003268.61..10000003269.44 rows=1 width=0) (actual time=122.637..122.637 rows=0 loops=1)
[04:42] <wgrant> The main +specworkload query apparently doesn't please postgres very much
[04:43] <wgrant> enable_seqscan=0 applies a 10 billion cost penalty
[04:43] <wgrant> But that plan still wins
[04:44] <StevenK> wgrant: No review?
[04:45] <wgrant> StevenK: That wasn't the only extract_bug_numbers callsite?
[04:46] <wgrant> (it was)
[04:46] <wgrant> Ah
[04:46] <wgrant> There's one in stringformatter.py itself
[04:46] <StevenK> It's called in stringformatter itself
[04:46] <StevenK> Yeah
[04:46] <StevenK> I can inline it and stop exporting it if you wish
[04:46] <wgrant> Nah
[04:46] <StevenK> Probably not worth it
[04:47] <wgrant> r=me, thanks
[04:47] <wgrant> We still have a few VPC queries, but that's possibly just removedby so I don't really care
[04:48] <StevenK> Yeah, we could make the pre-loading smarter by including some of the data from spph
[04:49] <wgrant> Not as big an issue as the bugs :)
[04:49] <StevenK> Indeed, so it's fine for now
[04:49] <wgrant> The page is still slow on DF, but a fair bit of it is probably template time
[04:50] <StevenK> And Unity has a TON of SPRs
[04:50] <StevenK> Tell me when you're done and I'll revert DF
[04:50] <wgrant> I'm done
[04:55] <StevenK> Tempted to close 1000257
[04:55] <wgrant> bug #1000257
[04:55] <_mup_> Bug #1000257: OOPS sending email notification for bug watch <bugwatch> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1000257 >
[04:56] <wgrant> Indeed
[04:56] <StevenK> I can't see how it happened, but it did
[04:59] <wgrant> StevenK: ndt
[04:59] <wgrant> Probably
[05:24] <StevenK> wgrant: http://pastebin.ubuntu.com/1199974/
[05:59] <lifeless> StevenK: https://devpad.canonical.com/~lpqateam/ppr/lpnet/
[06:21] <StevenK> wallyworld: Nice easy one for you: https://code.launchpad.net/~stevenk/launchpad/destroy-plus-daily-builds/+merge/123888
[06:31] <StevenK> wallyworld seems to be missing.
[07:25] <stub> Been butting my head against pgbouncer.
[07:26] <lifeless> stub: oh?
[07:26] <stub> Unfortunately, root cause of my problems seems to be that KILL and RESUME just affect if opening new outgoing connections work or not.
[07:26] <lifeless> stub: btw your part line is ... fun
[07:26] <lifeless> '18:52 -!- stub [~stub@canonical/launchpad/stub] has left #launchpad-dev ["PART #launchpad :PART #postgresql :PART #slony :PART #storm :PART #zope3-dev :ISON cr3 jkakar daniels intellectronica daf czajkowski static SteveA fabbione Ng
[07:26] <lifeless>           thumper bigjools debonzi BradB bac sinzui_is_awake jdub allenap Znarl chrism andrewv elmo lifeless `a"]
[07:26] <lifeless> '
[07:26] <stub> So the timouts for how long until I check if a backend is up, how long I wait for a backend connection, how long a client connection keeps retrying for a backend, all kick in
[07:27] <stub> I have no idea what an ISON is
[07:27] <lifeless> me neither
[07:29] <stub> Anyway, unless I or someone wade into the C code, we might need two pgbouncers to do the updated fdt and actually lower downtime rather than increase it
[07:29] <lifeless> stub: sure; how would that work ?
[07:30] <stub> I can reduce the timeouts during the window, but to a minimum of 1 second. And that makes a huge difference if we are aiming at <5s
[07:31] <stub> lifeless: Instead of KILL and RESUME on individual databases, we have separate pgbouncer instances for master and slave connections and shut them down/start them up
[07:31] <stub> But it means a lot more bespoke production crap
[07:31] <stub> init scripts etc.
[07:32] <stub> And certainly not generalizable for outside of canonical.
[07:36] <wgrant> Oh
[07:36] <wgrant> I thought we had an alternative to pause that rejected new connections
[07:36] <wgrant> But indeed, such a thing does not exist
[07:37] <stub> wgrant: We have KILL and PAUSE, and we need KILL in current launchpad because we are running in session mode, not transactional mode
[07:37] <wgrant> Right, but we have nothing like PAUSE that doesn't hang
[07:37] <wgrant> WHich is what we really need
[07:37] <stub> If we were running in transactional mode, yeah.
[07:38] <wgrant> Even in session mode
[07:38] <stub> But for current LP, the existing connections would never die unless we signalled all the clients 'oi, go reconnect now'
[07:38] <wgrant> Right, but KILL serves that purpose already
[07:38] <wgrant> We can kill all existing connections easily
[07:38] <stub> Yes, so for now KILL does what we need
[07:38] <wgrant> We just can't reject new ones claenly
[07:39] <stub> KILL rejects new connections
[07:40] <wgrant> If we run it constantly, yes
[07:40] <stub> The documentation is fuzzy there
[07:40] <wgrant> But it's a momentary thing
[07:40] <wgrant> It drops all current and pending clients at the moment it's run
[07:40] <wgrant> If we PAUSEd and ran kill every 10ms, it would work
[07:41] <stub> On my system, KILL keeps it dead until RESUMEd
[07:41] <stub> which is why I say the docs are wrong
[07:41] <wgrant> I can still connect, it just hangs
[07:42] <wgrant> On 1.5.1
[07:42] <wgrant> If I then KILL again, the hung connection drops, as expected
[07:42] <stub> $ psql -p 6432 launchpad_dev_master
[07:42] <stub> psql: ERROR:  pgbouncer cannot connect to server
[07:43] <wgrant> That's very interesting
[07:43] <wgrant> Do you have a tiny bouncer->server timeout or something?
[07:43] <stub> 2012-09-12 14:43:01.020 5838 LOG C-0x1e0d518: launchpad_dev_master/stub@unix:6432 login failed: db=launchpad_dev_master user=stub
[07:43] <stub> 2012-09-12 14:43:01.020 5838 LOG S-0x1e2aec8: launchpad_dev_master/stub@unix:5432 closing because: pause mode (age=0)
[07:44] <stub> wgrant: oh, you are experiencing the same problem my test case picked up
[07:44] <stub> wgrant: After a KILL, the pools don't know that the db is down so keep trying to open connections, and failing because the db is down
[07:44] <stub> wgrant: So it keeps retrying for 15 seconds until the 'db is down' flag is set
[07:45] <stub> wgrant: And then, after a RESUME, that pool is still stuffed as it only tries to reconnect to a dead db every N seconds.
[07:46] <wgrant> Ah, there we go, it does eventually time out
[07:46] <wgrant> And now it is dead properly
[07:46] <wgrant> So what we really need is a way to force it to poll and time out quickly
[08:00] <adeuring> good morning
[08:01] <lifeless> transactional mode still woudn't be fast enough, would it ?
[08:02] <wgrant> I don't think so
[08:11] <wgrant> Ah
[08:11] <wgrant> It's pretty easy to make it to do what we want
[08:11] <wgrant> Like
[08:11] <wgrant> Really easy
[08:13] <lifeless> share
[08:13] <wgrant> Will have patch in a sec
[08:15] <wgrant> Particularly if I don't try to run an amd64 binary on i386
[08:30] <stub> wgrant: I can reduce the timeouts, but it still can add about 2 seconds to the time according to my test case
[08:31] <stub> wgrant: Patch welcome though, I hate relearning C everytime I need to do this.
[08:32] <wgrant> It all works, except that changing the size of the PgDatabase struct makes it segfault
[08:32] <wgrant> Just adding the new unused flag
[08:32] <wgrant> Segfault
[08:32] <wgrant> But if I reuse one of the existing flags it all works
[08:32] <wgrant> Will look further after dinner
[08:33] <wgrant> I can't see a hardcoded size anywhere obvious
[08:34] <czajkowski> jelmer: when you get a chance can you follow on the Question you were on https://answers.launchpad.net/launchpad/+question/206501  so I can see if it can be closed.
[08:34] <czajkowski> cheers
[09:02] <wgrant> (it turns out their makefile deps suck, so a make clean fixed it)
[09:04] <wgrant> stub: http://pastebin.ubuntu.com/1200173/
[09:04] <wgrant> You currently need a DISABLE/KILL/RESUME then ENABLE sequence
[09:05] <wgrant> As disable doesn't actually kill, and kill implicitly pauses
[09:07] <lifeless> nice
[09:09] <stub> Cool
[09:10] <stub> That on github?
[09:10] <wgrant> I hate tracking down the official repo on GitHub
[09:10] <wgrant> Maybe there's a link somewhere...
[09:10]  * wgrant googles
[09:11] <stub> I could argue that KILL should imply DISABLE
[09:11] <wgrant> Indeed
[09:11] <wgrant> Alternatively KILL could just kill
[09:11] <wgrant> and you're expected to PAUSE first
[09:12] <stub> yeah, I can take the patch to the mailing list
[09:12] <wgrant> https://github.com/markokr/pgbouncer-dev looks like it
[09:12] <stub> Unless they use git://git.postgresql.org/git/pgbouncer.git directly
[09:13] <wgrant> They do, but the github account is owned by the primary committer
[09:13] <wgrant> So it seems relevant
[09:13]  * wgrant has forked it
[09:19] <wgrant> I always forget how obtuse git is
[10:58] <wgrant> stub: I've revised it a bit, so it now rejects only at client connect time and is not so terrible. https://github.com/wgrant/pgbouncer-dev/compare/disable
[10:58] <wgrant> I'll create a pull request if you don't object soon
[11:00] <stub> wgrant: Cool. I was going to build a package here to test my test case
[11:00] <wgrant> Great
[11:00] <stub> (running through the full process before I go and hack up full-update.py)
[11:00] <wgrant> You still need the DISABLE/KILL/RESUME, do stuff, ENABLE sequence, but I'll mention improving that on the MP
[11:01] <wgrant> If you leave it paused too long it'll still lose the backend connections and hang once you reenable
[11:01] <wgrant> But if you resume immediately after killing you can keep it disabled forever
[11:03] <wgrant> Also note that DISABLE only forbids new client connections. An existing client connection can still grab a server connection if it hasn't already. I could forbid in find_server as well, but I'm not sure if it's worth it
[11:03] <wgrant> Given you need to KILL anyway
[11:19] <stub> So htf do I convert https://github.com/wgrant/pgbouncer-dev/compare/disable to a diff?
[11:21] <wgrant> stub: You're beyond my GitHub knowledge at this point, I'm afraid
[11:21] <wgrant> Let me poke around
[11:22] <stub> I guess I'm locked in ;)
[11:23] <wgrant> http://pastebin.ubuntu.com/1200362/
[11:26] <Laney> stick ".patch" on the end of that URL
[11:26] <wgrant> Ah
[11:26] <wgrant> I tried .diff
[11:26] <wgrant> But not .patch
[11:27] <wgrant> Hm
[11:27] <wgrant> .diff works now too
[11:27] <wgrant> I must have been on a different URL
[11:27] <stub> Because hacking urls is discoverable UI
[11:27] <tumbleweed> on commits, .diff and .patch give you different things
[11:27] <wgrant> Yeah, .patch gives headers and commit message and stuff
[11:29] <stub> Still seems noise to strip
[11:29] <stub> oh, guess diff ignores it
[11:30] <stub> no, noise to strip.
[11:31] <stub> oh no, I'm on 1.5.2, patch is trunk
[11:31] <wgrant> There shouldn't be conflicts outside NEWS
[11:32] <stub> yeah
[11:32] <stub> I just need more coffee
[11:42] <stub> built the package, manual tests look good
[11:48] <stub> And my updated tests like it too.
[11:48] <stub> wgrant: Looks good.
[11:48] <wgrant> Great
[11:49] <wgrant> My only significant concern is that an evil client could connect but not cause a server connection to be established.
[11:49] <wgrant> Then you DISABLE, and wait for connections to disappear from the backend server
[11:49] <wgrant> But if you don't KILL, there could still be someone lurking in pgbouncer
[11:49] <wgrant> waiting to strike and ruin your day
[11:50] <wgrant> (to reproduce, open up a psql session but don't do anything. Call DISABLE in another session, and see that you can still talk in your original session)
[12:07] <wgrant> stub: Hopefully this will be a little less messy (and faster!) than sudoing around multiple instances
[12:07] <stub> Oh, much.
[12:08] <stub> We will need to KILL anyway after a timeout
[12:08] <stub> To catch evil transactions.
[12:08] <wgrant> Yeah
[12:09] <wgrant> Definitely
[12:09] <wgrant> But for the master we will just want to DISABLE and then KILL immediately
[12:09] <stub> http://paste.ubuntu.com/1200439/ is the test case for the always-slave process, and it is passing with the new pgbouncer
[12:10] <wgrant> Oh, an actual LP test case
[12:10] <wgrant> Fancy
[12:13] <StevenK> stub: https://code.launchpad.net/~stevenk/launchpad/buildfarmjob-index-redux/+merge/123854 would love a review
[12:13] <wgrant> stub: Looks good
[12:15] <stub> got the failwhale
[12:15] <stub> not even an oops
[12:15] <wgrant> 502?
[12:15] <wgrant> Huh
[12:15] <wgrant> Haven't seen many of those since we switched back to the rightful DB servers
[12:16] <stub> StevenK: Didn't we do this already?
[12:17] <StevenK> stub: Almost. The previous index did not have status, this one does. The two of them will work in concert for Builder:+history
[12:18] <stub> yer
[12:18] <StevenK> stub: Builder:+history with the index we added to prod makes it really fast. Builder:+history also allows filtering by status, which is slow.
[12:18] <wgrant> Well, slow for uncommon statuses
[12:19] <StevenK> Right.
[12:19] <StevenK> It's noticibly slower. Like 4 seconds versus 0.4
[12:21] <stub> It it ready for prod or just qastaging?
[12:21] <stub> Oh, I'm building this pgbouncer package for precise. I can just copy it to lucid and it will be fine, right?
[12:22] <StevenK> I think it should be fine, but I admit to not actually testing it.
[12:22] <StevenK> stub: I'm happy to play around on DF tomorrow if you're more comfortable with me having tested it.
[12:23] <stub> Just removing it requires a FDT update. Apart from that no real worries applying it to prod.
[12:23] <wgrant> stub: I'm not sure if the same binary will work
[12:23] <wgrant> We have a ~lucid1 for 1.5.1 atm...
[12:24] <stub> So reupload for lucid or make a recipe to work around the limitation
[12:24] <wgrant> Exactly
[12:25] <stub> StevenK: Its on qastaging
[12:25] <StevenK> Let's have a look
[12:25] <StevenK> 0.8 hot for main
[12:26] <StevenK> 1.3 for FTBFS hot
[12:26] <wgrant> SUPERSEDED is more interesting
[12:26] <StevenK> 0.9 for depwait hot
[12:27] <StevenK> superseded is 2.2 cold, 0.29 hot
[12:27] <wgrant> Excellent.
[12:27] <wgrant> To production we go.
[12:28] <StevenK> How about I land it first?
[12:28] <StevenK> :-)
[12:31] <StevenK> stub: It's landed as r15944, you can add it to prod at your leisure
[13:19] <abentley> deryck: I'm the OCR.  Could you please review https://code.launchpad.net/~abentley/launchpad/spec-creation-info-type/+merge/123821 ?
[13:19] <deryck> abentley, sure
[13:19] <abentley> deryck: Thanks.
[13:19] <deryck> np!
[14:27] <abentley> rick_h_: btw, my enum is lp.registry.enums.PUBLIC_PROPRIETARY_INFORMATION_TYPES
[14:28] <rick_h_> abentley: cool, thanks. Will look at updating that today.
[14:41] <sinzui> adeuring, can you comment on bug 839779 and bug 450480 about how to fix them?
[14:41] <_mup_> Bug #839779: HWDB doesn't create HWDeviceClass anymore <hwdb> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/839779 >
[14:41] <_mup_> Bug #450480: Get PCI and USB vendor/product names from the "PCI ID Repository" project and from linux-usb.org respectively <hwdb> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/450480 >
[14:42]  * adeuring is looking
[14:50] <adeuring> sinzui: I am a bit lost ATM regarding
[14:50] <adeuring> #839779
[14:50] <_mup_> Bug #839779: HWDB doesn't create HWDeviceClass anymore <hwdb> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/839779 >
[14:50] <adeuring> I guess that newer HWDB reports do not contain any data about devices classes anymore.
[14:51] <adeuring> but I need to check
[14:52] <adeuring> sinzui: regarding bug 450480: WHat do you miss in the bug report?
[14:52] <_mup_> Bug #450480: Get PCI and USB vendor/product names from the "PCI ID Repository" project and from linux-usb.org respectively <hwdb> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/450480 >
[14:52] <sinzui> adeuring, why a cronscript? Shouldn't the data be processed correctly when it is uploaded?
[14:53] <sinzui> or put another way? I do not understand why hal has that data, but udev does not?
[14:54] <adeuring> sinzui: ask the udev developers ;) The data is probably not important enough
[14:55] <sinzui> okay. So want a process that gathers the secondary data to provide consistent, historic reporting?
[14:55] <adeuring> sinzui: the script that processed the HWDB report can of course also read the two URLs directly
[14:55] <adeuring> and use the data.
[14:55] <adeuring> but we should also update existing "bad" records.
[14:56] <sinzui> okay. and calling out to external site is blocked for most servers
[14:57] <adeuring> sinzui: that's a problem indeed... But we might be able to read the data manually form time to time
[14:57] <sinzui> understood. The data does not change often, which is why you want to pull it daily or weekly
[14:58] <adeuring> sinzui: right.
[14:58] <sinzui> okay. I think I know enough to fix this
[14:58] <deryck> abentley, your code looks great.  well tested and solid.  r=me.
[14:58] <abentley> deryck: Thanks.
[14:58] <adeuring> sinzui: BTW, we wil always have the situation that a report contains a devcie where vendor/product names are yet knwon, even in the two databases mentioned in the bug report.
[14:59] <adeuring> I don't know how often these DBs are updated, but we must always expect some lag
[14:59] <adeuring> when for example some small vendor sells a new USB mouse
[14:59]  * sinzui nods
[15:00] <sinzui> adeuring, what do you need to know about HWDeviceClass in staging's db?
[15:01] <sinzui> is there a query I can run?
[15:01] <adeuring> sinzui: the existing data itself is not a problem. Just need to check why no nbewer data exists
[15:13] <adeuring> sinzui: after looking a bit more at the output of "udevadm info --export-db" I still have no idea why HWDeviceClass is not updated. Could be a bug in the processing the reports. On the other hand, it would make sense to check if the data from recent submissions really has no links to HWDeviceClass records. After all, the set of device _classes_ is rather small compared with the number of different device models: A USB mouse is is a USB mou
[15:13] <adeuring> so it might even be a "non-bug"
[15:14] <sinzui> okay. I will look into this.
[15:14] <sinzui> adeuring, who uses the the hwdb now?
[15:15] <adeuring> sinzui: I have no idea... ask cr3
[15:15] <sinzui> oh, I did
[15:15] <adeuring> or flacoste
[15:15] <sinzui> he uses the XML only
[15:15] <cr3> adeuring: ogasawara still uses the hardware db
[15:15] <adeuring> ah, right
[15:20] <rick_h_> abentley: quick ok on the change over to your enum please? https://code.launchpad.net/~rharding/launchpad/updated_product_allowed_types/+merge/123987
[15:21] <abentley> rick_h_: r=me.
[15:22] <rick_h_> abentley: thanks
[17:03] <sinzui> jcsackett, do you have a few moments to discuss Bug #810664
[17:03] <_mup_> Bug #810664: Specification:+index asserts -  (from_node, to_node) not in self.edges <oops> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/810664 >
[17:17] <jcsackett> sinzui: sure.
[17:21] <sinzui> jcsackett, http://pastebin.ubuntu.com/1200924/
[17:37] <sinzui> jcsackett, I just got my replacement router. I am going to drop off the net for a bit
[18:54] <deryck> abentley, I have two branches related to specification_sharing_policy if you have the bandwidth to review them.
[18:54] <abentley> deryck: Sure.
[18:55] <deryck> abentley, thanks.  see....
[18:55] <deryck> https://code.launchpad.net/~deryck/launchpad/specification-sharing-policy-unused/+merge/124021
[18:55] <deryck> and
[18:55] <deryck> https://code.launchpad.net/~deryck/launchpad/specification-sharing-policy-garbo/+merge/124026
[19:02] <abentley> deryck: The allowed types for SpecificationSharingPolicy.PUBLIC, SpecificationSharingPolicy.PUBLIC_OR_PROPRIETARY, SpecificationSharingPolicy.PROPRIETARY_OR_PUBLIC look incorrect because they include InformationType.PRIVATESECURITY, InformationType.USERDATA, InformationType.PUBLICSECURITY
[19:05] <abentley> deryck: In the definition of setSpecificationSharingPolicy, can we use IProductPublic.specification_sharing_policy directly instead of copying it?
[19:17] <deryck>  abentley, sorry was on call with flacoste
[19:18] <deryck> abentley, so to the first question, sorry about that.  copied from branch which I thought would be the same. I'll take another pass at that.
[19:18] <abentley> deryck: Cool.
[19:18] <deryck> abentley, as for the copy, I did this exactly like bug and branch sharing policy.  both of those copied.  So I didn't question it.
[19:19] <deryck> I don't know if there's some reason it needs the copy honestly.  and I was just playing it safe.
[19:20] <abentley> deryck: I had a grovel through copy_field recently, and it seems like its only purpose is to let you change attributes (like readonly).  So give it a try without the copy and I bet it will work.
[19:20] <deryck> abentley, ok, will do.  I can change the other places too and try them.
[19:22] <abentley> deryck: Should your branch also be defining default values for the policies?  I don't see that.
[19:23] <abentley> deryck: Bugs has lp.bugs.interfaces.bugtarget.BUG_POLICY_DEFAULT_TYPES for example.
[19:23] <deryck> abentley, right.
[19:23] <deryck> abentley, so I didn't realize those were needed until the two methods coming in the final branch.
[19:23] <deryck> abentley, I have them in that, but can bring them up to this branch if it makes more sense.
[19:24] <abentley> deryck: No, that's fine as long as it's in the plan.
[19:24] <deryck> abentley, ok, cool.
[19:47] <abentley> deryck: Do you think there should be a policy that permits PUBLIC, PROPRIETARY and EMBARGOED?
[19:50] <deryck> abentley, on TL call, just a minute and I'll consider that.
[19:58] <jcsackett> quit
[20:02] <deryck> don't do it jcsackett!  it will be better tomorrow, I'm sure. ;) :)
[20:02] <deryck> abentley, ok, thinking on that now....
[20:02] <jcsackett> deryck: :-P
[20:03] <lifeless> sinzui: do you need a link to the zconfig bug ?
[20:04] <sinzui> I saw it yesterday in my browser
[20:04] <sinzui> lifeless, it affect lp and zope right, and I think fred was the reviewer?
[20:04] <deryck> abentley, so what use case are you thinking of?  Starting public, but shifting to either of the other two later?  or something else?
[20:05] <lifeless> sinzui: yes
[20:05] <lifeless> sinzui: that sounds right
[20:06] <sinzui> lifeless, send me the bug, as my history does not want to reveal it
[20:06] <abentley> deryck: No, I guess I was just thinking that we wouldn't want to prevent people using Embargoed from doing everything else that people using Proprietary can do.
[20:06] <lifeless> sinzui: abel took a stab at it, but sadly only ended up moving the issue around, we didn't understand quite what was going on.
[20:06] <lifeless> bug 481512
[20:06] <_mup_> Bug #481512: race condition when rotating logs <canonical-losa-lp> <lp-foundations> <qa-untestable> <Launchpad itself:Triaged> <ZConfig:Fix Released by fdrake> < https://launchpad.net/bugs/481512 >
[20:06] <abentley> deryck: I don't have a use case really, unless people other than PES use Embargoed.
[20:09] <sinzui> yes, I saw the branch apparently. thank you lifeless
[20:09] <lifeless> sinzui: de nada
[20:09] <lifeless> sinzui: thank *you*
[20:12] <abentley> deryck: We are famous now: http://feedproxy.google.com/~r/d0od/~3/3xNeugsEvpU/ubuntu-12-10-login-screen-adds-remote-desktop-access
[20:14] <deryck> abentley, nice!
[20:14] <deryck> abentley, I hope they have that server beefed up more than we did. ;)
[20:14] <abentley> :-)
[20:33] <abentley> deryck: Could you please review https://code.launchpad.net/~abentley/launchpad/fix-banner/+merge/124052 ?
[20:33] <deryck> abentley, absolutely.
[20:39] <deryck> abentley, should you be a bit more specific in the test?  to make sure that the phrase is actually in the banner, and not somewhere else in browser.contents.
[20:39] <abentley> deryck: I can do that.
[20:39] <deryck> abentley, ok, cool.  other that that, looks great.  I like the IInformationType approach.
[20:40] <abentley> deryck: Great.  I considered extending IPrivacy, but I saw that there are circumstances where we know whether it's private, but not what the information_type is.
[20:41] <deryck> abentley, right.  and r=me officially now on the mp.
[20:41] <abentley> deryck: Thanks.
[20:41] <deryck> np!
[20:59] <abentley> deryck: r=me on the first one.
[21:02] <deryck> abentley, thanks!
[21:12] <lifeless> sinzui: can I hand that branch off entirely ?
[21:12] <sinzui> okay
[21:12] <sinzui> It is now mine
[21:12] <lifeless> sinzui: thanks, much appreciated.
[23:13] <wgrant> StevenK: OOPS-2bf590b755c7e5cd89893f05cfb1eb91