[02:36] <Guest10015> Hi
[02:36] <Guest10015> I would like to appeal my ban from #ubuntu-offtopic
[02:49] <Pici> Guest10015: why?
[02:49] <Guest10015> Pici, why what?
[02:49] <Pici> Guest10015: Why do you want to be unbanned?
[02:49] <Guest10015> I was told to take a cooling off period and come back when I felt like I could follow the rules
[02:50] <Guest10015> I think I can do that now
[02:52] <Guest10015> Pici,
[02:52] <Guest10015> ?
[02:52] <Pici> I don't feel comfortable unbanning you at this time.
[02:52] <Guest10015> why
[02:52] <Pici> Your history speaks volumes.
[02:52] <Guest10015> I've changed and I would like a chance to demonstrate that
[02:53] <Guest10015> Pici,
[02:53] <Pici> yes?
[02:54] <Guest10015> I would like a chance to demonstrate that I've changed
[02:54] <Pici> I don't think you have. You've demonstrated the inability to follow simple channel guidelines on a number of occasions, and I have no reason to believe that you will follow through this time.
[02:55] <Guest10015> so at what point do you decide that I will be able to follow the channel guidelines?
[02:55] <Guest10015> How can you know if you don't give me anymore chances
[02:55] <Guest10015> Pici,
[02:56] <Pici> I can infer from your behavior in other non-ubuntu channels that you can't follow their rules.
[02:56] <Guest10015> which channels?
[02:56] <Guest10015> I was behaving just fine in #ubuntu today
[02:58] <Pici> Not really.
[02:58] <Pici> I think we're done here.
[03:00] <Guest10015> how long until i can be unbanned
[03:00] <Guest10015> i miss my irc friends
[03:00] <Guest10015> and the sense of community
[03:11] <Guest10015> Pici,
[03:13] <Guest10015> Pici,
[03:13] <Guest10015> please respond
[03:15] <Guest10015> LjL,
[03:15] <Guest10015> hi
[03:15] <Guest10015> how do i get voice like you?
[15:32] <IdleOne> !nomir is <reply> for more information about why Mir will not be included as default in ubuntu 13.10 see http://fridge.ubuntu.com/2013/10/01/xmir-update-for-ubuntu-13-10/ and https://wiki.ubuntu.com/Mir/13.10/NoDefaultQ%26A
[15:33] <genii> Hm.
[15:33] <genii> So they're staying with xorg right now, or wayland, or what?
[15:33] <IdleOne> with X yeah
[15:34] <Pici> k1l_: heh
[15:34] <k1l_> i think its sad. mir/xmir could need some testing before 14.04 gets lts
[15:35] <IdleOne> you can test it, it just won't be default
[15:35] <k1l_> im not talking about the devs testing it. i mean that the bright usergroup could test it
[15:36] <IdleOne> they can
[15:36] <IdleOne> it is already in the 13.10 repos
[15:37] <IdleOne> should try reading those links :)
[15:37] <IdleOne> the second link specifically
[15:38] <k1l_> IdleOne: i know
[15:38] <IdleOne> ok so I don't understand what you mean then
[15:38] <k1l_> but i mean that not only the few voluntary testers help with bug reports but all the users.
[15:39] <k1l_> there are alot of different setups and usecases that get not tested if its not default, imho
[15:39] <IdleOne> testing should be done by users who are aware of the possible lack of features and shiny. Not by all the users who then yell and scream how Ubuntu and Canonical suck because they shipped something that wasn't near ready for primetime
[15:40] <IdleOne> I see this is one of the first responsible moves Canonical has done in a while.
[15:40] <k1l_> im talking about making it from stable to rocksolid
[15:40] <genii> Heh
[15:40] <k1l_> i dont want to spread alpha software as default
[15:41]  * k1l_ afk
[15:46] <Myrtti> so tempted to say "so is Dumbledore"
 i must enter my password 20 times
[21:20] <bazhang> troll detected
[21:24] <genii> bazhang: I got to go do some work, so won't be around to boot if required
[21:25] <bazhang> :)
[21:34] <IdleOne> I don't like the answer you gave me so I will ignore it and repeat my question
[21:37] <bazhang> we need 3D blinking ascii in such cases
[21:40]  * genii ponders no, list is <reply> Ciao! This is not a file sharing channel (or network); read the channel topic. If you need information about me, type « /msg ubottu !bot ». If searching for a channel, see « /msg ubottu !alis ». Per l'italiano, fare riferimento al !it
[21:41] <IdleOne> That idea has been suggested before and refused
[21:42] <IdleOne> in +1 did waldenista join twice with the same nick. I did not see them leave befoee the second join
[21:42] <genii> IdleOne: I guess it makes it look like we're picking on the Italians :-/
[21:42] <IdleOne> now my client says he left the channel but he is still there
[21:43] <IdleOne> genii: it does
[21:43] <IdleOne> oh, nevermind diff. nicks
[21:44] <LjL> genii: well are you? yes i'm asking you, are you?
[21:44] <genii> Hehehe
[21:44] <genii> LjL: It's only ever really the Italians that are using the !list so.... probably, yes
[21:46] <LjL> genii: still, whatever these people are interested in, it's not Ubuntu support, be it in English or Italian, so !it doesn't really help a whole lot
[21:46] <LjL> and the -it folks wouldn't really be happy at us redirecting those people there, at all
[21:47] <genii> Ah, good point.
[22:00] <Unit193> IdleOne: I don't think it's considered "picking on" if they're pretty much the only ones that *ever* call it.  Just a more proper target.  It's not picking on when you do !es is it? ;)
[22:02] <genii> We might as well just alias !hola to !es .... <runs away>
[22:30] <IdleOne> the point is that people who egt sent the !warez trigger are not looking for ubuntu support and targeting Italians because the majority happen to be Italian is not right
[22:31] <IdleOne> get*
[22:31] <IdleOne> dinner
[22:32] <genii> We, guess I should get headed home, face-off is like 40 minutes from now


[08:36] <rbasak> sil2100: o/ I have a request to review qemu from the SRU queue so I'll look at that now.
[08:37] <rbasak> (unless you're already on it which seems unlikely given the current size of the queue :-/
[08:39] <Unit193> rbasak: BTW, any news?
[08:39] <rbasak> Unit193: on?
[08:41] <sil2100> rbasak: hey! Thanks for the heads up, I'm on the release sprint today so I essentially had no time for SRU queue reviews
[08:41] <sil2100> s/today/this week/
[08:51] <Unit193> PM.
[08:52] <Laney> AM
[08:55] <Unit193> Laney: Fixed the factoid, as requested.
[08:55] <Laney> thx
[12:08] <coreycb> doko: i imagine that if 20.04 were to have python 3.8 it would be in 19.10 as well to help stabalize things. is that correct?
[12:12] <coreycb> doko: there's a lot of brainstorming going on with upstream openstack to figure out how to catch up and test better. they currently only test on the latest LTS but i'd like to propose that they test on the latest release (LTS or interim). not a release under development as that's not realistic for a voting gate.
[12:16] <doko> coreycb: I doubt about 19.10, because it's not yet released at this time. So maybe an alpha or a beta
[12:18] <coreycb> doko: ok, that'll be harder to get any testing upstream then unfortunately until after 20.04 releases
[12:18] <coreycb> doko: maybe some non-voting tests but those will likely just get ignored
[12:19] <doko> coreycb: https://www.python.org/dev/peps/pep-0569/
[12:20] <doko> so probably a 3.8 release candidate in 19.10
[12:20] <doko> and updating that later
[12:22] <coreycb> doko: if we could make a statement like that it would be great. ie. we'll release 19.10 with a beta or rc based on what's available at the time, and update it to the final version after release (reference pep 0569 for schedule)
[12:23] <coreycb> doko: seem reasonable for me to say that?
[12:33] <doko> coreycb: sure, but this will be as in 18.04 an "unsupported" version, no extensions built for it yet
[12:34] <coreycb> doko: i think that's fine. tests are run in a venv. thanks!
[20:49] <tsimonq2> infinity, vorlon: That's sane, right? &
[20:49] <tsimonq2> s/&/^/
[20:50] <vorlon> tsimonq2: lgtm
[20:51] <tsimonq2> Cool.
[22:06] <mwhudson> should i be surprised that libhttp-parser-dev doesn't install a .pc file?
[22:09] <sarnold> I'm certainly surprised
[22:09] <sarnold> it's 2018 right? :)
[22:13] <mwhudson> good i am glad someone else is surprised


[12:23] <blacking> hello all..
[12:24] <blacking> please does anyone can help me how install ubuntu under usb drive??


[00:40] <nigelb> nhandler, its meant to show list of QA packages where we have a delta from debian
[00:41] <nhandler> What do you mean by QA packages nigelb ?
[00:41] <nigelb> err.. packages maintained by debian QA team... the orphaned packages
 I prepared a list of orphaned packages with Ubuntu changes: http://merkel.debian.org/~dktrkranz/ubuntu_QA   It could be interesting uploading such changes to Debian as QA uploads if feasible, thoughts?
 It's a good idea.  I've been doing that as I run across such packages.
 some packages could be candidate for removal as well, but at least there's a chance to reduce deltas a bit. Any idea how to spread it?
[00:42] <nigelb> nhandler, ^
[00:42] <nhandler> nigelb: Ah ,ok
[00:43] <nigelb> nhandler, some of those changes need not be sent back.. hence I put it onto a wiki
[01:21] <nigelb> nhandler, will you be around at 1630 UTC ?
[01:21] <nigelb> persia, well, in case you're swamped by mail, brian and jcastro are +1 for 1630 :)
[03:01] <nhandler> Darn, missed him.
[03:10] <persia> He'll be back :)
[08:17] <dholbach> good morning
[14:31] <nigelb> persia, um.. can you chair the meeting?
[14:31] <persia> meeting?
[14:31] <persia> I thought it was a semi-informal chat
[14:32] <nigelb> yeah.. someone has to semiformally lead it :)
[14:32] <persia> Oh, I can do that.  Do we have some list of decisions we need made?
[14:33] <nigelb> I'll make an etherpad
[14:33] <persia> Sounds like a plan :)
 http://etherpad.com/aryJjRUeik
 anyone wants to contribute to things to be discussed, feel free to add ^
[15:54] <dholbach> persia: do you know who else was invited to the meeting? is it going to be in 1h36m?
[15:56] <persia> No, yes, and I only found out it was a "meeting" about 90 minutes back: I just thought it was nigelb, bdmurray, and myself talking about the patch subscribing script.
[15:56] <dholbach> ok
[15:57] <maco> haha
[15:57] <dholbach> I'll be there too, but I think I'll go back home before the meeting starts
[15:59] <persia> OK.
[15:59] <persia> Apparently, I'm chairing, so I'm happy to wait :)
[16:13] <dholbach> see you later :)
[17:13] <nigelb> persia, anything more to add to http://etherpad.com/aryJjRUeik ?
[17:14] <persia> No.
[17:14] <persia> I have opinions about #2 and #3, but I'm really only around to talk about #1, which seems easy enough.
[17:14] <persia> Did you ever write up the behaviour you *wanted* the script to have?
[17:15] <nigelb> well, I was hoping we'd have a consensus on #2 and #3
[17:15] <persia> We may :)
[17:15] <nigelb> the script would consider bugs with patch* tags processed would be what I *wanted*
[17:15] <nigelb> i.e. not adding patch again if another patch-* tag is present
[17:16] <persia> That ought be simple enough.  HAve you found the source?
[17:16] <nigelb> um, no brian has not yet shared it
[17:16] <persia> Aha!
[17:16] <nigelb> I had asked if he could put it in bzr and sync to the box that runs it once a day
[17:16] <nigelb> that way we could request merges, etc
[17:17] <nigelb> (to the script that is), but I guess he's just a bit busy with release nearing, etc
[17:17] <persia> Probably.
[17:20] <dholbach> I forgot again... who apart from bdmurray were we waiting on? :)
[17:20] <persia> nigelb: ?
[17:20] <nigelb> jcastro
[17:20] <dholbach> ah ok
[17:21] <nigelb> and bryceh if he's around
[17:22] <dholbach> hi bdmurray
[17:22] <bdmurray> hello
[17:24] <nigelb> persia, I guess we can get started now :)
[17:25] <persia> OK.  So nigelb twisted my arm to make me chair a "meeting", but please consider his opinions strongly, as he's the instigator of all this.
[17:25] <hyperair> tsk nigelb =p
[17:25] <persia> Agenda is at http://etherpad.com/aryJjRUeik
[17:26] <persia> First topic is to look for changes to the patch subscription script.
[17:26] <persia> nigelb: I think you wanted to have it not re-add "patch" when "patch-foo" was present?
[17:26] <nigelb> yup
[17:26] <persia> bdmurray: Is there a branch somewhere that could be used to make that adjustment, or do you have concerns about doing that?
[17:27] <nigelb> bryce_ helped make the review guide (https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved) more prettier and some of his edits made sense.  But this version would require the script to be intellegent to all the tags
[17:27] <bdmurray> there is no branch that contains that script yet additionally it checks to see if the patch tag was already there so why remove the tag?
[17:27] <bdmurray> I mean I don't see a need to remove the patch tag just add patch-foo in addition to patch
[17:28] <dholbach> I'm still not sure I understand what the script should be doing. :)
[17:28] <persia> dholbach: Subscribing ubuntu-reviewers to a sensible subset of the patch bugs so we have a manageable target.
[17:28] <nigelb> dholbach, the script subscribes ubuntu-reviewers to all bugs with patches
[17:28] <nigelb> well, after a certain date
[17:29] <persia> dholbach: Also, trying to merge all the different ways that patches are identified into one format.
[17:29] <bdmurray> right so any new bugs with patches
[17:29] <nigelb> my only worry is that LP really doesn't allow negation while searching
[17:30] <persia> Which makes it hard to search for bugs that have patches but have not yet been reviewed?
[17:30] <nigelb> like searching bugs with patch tag but without patch-forwarded-upstream
[17:30] <bdmurray> I think negation is possible if not with the web interface with the api
[17:30] <persia> Definitely with the API, and definitely not with the web interface, but most of us use the web interface.
[17:30] <dholbach> I use http://people.canonical.com/~dholbach/resubscribe for a different purpose right now - maybe that can be used?
[17:30] <hyperair> launchpad should sprout support for google-like syntax for searching
[17:31] <bdmurray> its says right in the web interface that it works
[17:31] <bdmurray> #  Find bugs that don't have the test tag:  search for -test
[17:31] <persia> Ah, cool.  I never got that to work, but I haven't tried in a while.
[17:31] <persia> So that makes this moot, I think.  nigelb?
[17:32] <nigelb> yes, we can move on :)
[17:32] <nigelb> I'll edit the review guide appropriately
[17:32] <jcastro> wait!
[17:32] <persia> Great.  Item 2:  Patch Day and thoughts on current implementation.
[17:32] <persia> OK.  Back to item 1.
[17:32] <persia> jcastro: ?
[17:32] <jcastro> we already know the patches because lp figures that out for the +patches view
[17:32] <jcastro> so maybe we can ask the lp team to just sub the right team when a patch is attached?
[17:32] <persia> jcastro: No.  That fails in all sorts of ways.
[17:33] <jcastro> ok, explain that to me after then, I don't want to hold up the agenda
[17:33] <persia> I've commented at length in the various LP bugs on the subject, but essentially not every patch happens to be a text file attached with the patch flag.
[17:33] <nigelb> Its a nice feature for teams like X
[17:33] <bdmurray> jcastro: there are various exceptions for if the sponsors team is subscribed etc...
[17:33] <nigelb> but not for others
[17:33] <jcastro> ok
[17:33] <persia> jcastro: Just to confirm your thoughts, that does work about 90% of the time, it's just the rest that are tricky.
[17:34] <nigelb> release team subscribed, merges, etc
[17:34] <persia> Anyway, item 2: Patch Day and thoughts on current implementation.
[17:34] <nigelb> this is the current way we wish to implement https://wiki.ubuntu.com/PatchDay
[17:34] <persia> I presume that's described at https://wiki.ubuntu.com/PatchDay
[17:35] <nigelb> persia, would you like to summarize here? since it was originally your idea :)
[17:35] <persia> nigelb: So, what's to discuss here?
[17:36] <persia> Um, my "idea" was just that if we're going to have a patch day, we just schedule some time, have someone responsible for keeping things going in shifts, and do it.
[17:36] <bryce_> personally I think it's not the best way to achieve this
[17:36] <bryce_> I understand the objective is to make the bar low so many people can participate
[17:36] <persia> I'm open to formalisation if someone thinks it will help, but I feel we would do better to develop policies based on what we discover to be best practices.
[17:37] <bryce_> however in practice I think you find one guy that's really motivated can do more than 10 random joiners
[17:38] <bryce_> so I'd suggest instead of holding a ** Day, to focus on finding and recruiting those specific super contributors
[17:38] <persia> That makes more sense to me than having special days.
[17:38] <bryce_> anyway, just my opinion ;-)
[17:38]  * persia has the sense that special days discourage people from contributing the rest of the time
[17:39] <dholbach> I'm not sure that's true - it can be great to get together as a team, set a goal and achieve it
[17:39] <dholbach> especially if there's no team yet
[17:39] <nigelb> it makes things move and help us look back to what we've achieved
[17:39] <bryce_> dholbach, that has not been my experience with X
[17:39] <persia> Nor mine with REVU
[17:40] <nigelb> But I did see that with hugdays :)
[17:40] <bryce_> possibly we're doing it wrong ;-)
[17:40] <dholbach> well, I'm not saying we shouldn't have tuition sessions :)
[17:40] <dholbach> I think we should have them too
[17:40] <dholbach> https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved looks good already, but I guess it needs a few examples and stuff, so people know can more easily guess what we'd like them to do
[17:41] <nigelb> dholbach, I'll get to work on that. :)
[17:41] <dholbach> also having a XYZ Day helps with people who want to get involved but don't know who they can talk to
[17:42] <persia> I guess.  I'd rather have staffed channels, but that takes more commitment from everyone involved.
[17:42] <dholbach> and we can always try a few things out and see how they work
[17:42] <nigelb> dholbach, Hence, the idea of rotating staffing
[17:42] <dholbach> it's not like we need to keep tuition sessions or patch days going if we see they don't work
[17:42] <persia> Anyway, my feeling is that if some folk want to have a "Patch Day", let's have one.  If it's a huge success, let's have more.  Scheduling for every other saturday in advance seems ambitious.
[17:43] <hyperair> i think having XYZ days helps in having the channels staffed sufficiently.
[17:43] <nigelb> persia, that needs to be edited.  It was the initial edit of the bug day wiki page :)
[17:43] <dholbach> shall we move on or do we want to discuss date, time and organisation already?
[17:44] <persia> Does may 5th work spetacularly badly for anyone?
[17:44] <nigelb> Date is May 5th, jcastro and I are working on an announcement to -devel
[17:44] <dholbach> ok
[17:44] <persia> I strongly believe that time should be "all day, in your timezone", which makes it 50 hours.
[17:44] <jcastro> I agree
[17:45] <hyperair> i agree as well
[17:45] <persia> For organisation, what I suggested to nigelb was based on the very old bug days, when we had a channel contact who would keep things going and hand off to the next person.
[17:45] <persia> WHich I believe resulted in the big table.
[17:45] <persia> Does that work for an initial day for everyone?
[17:46] <dholbach> do we have enough people who know about the process and stuff?
[17:46] <hyperair> big table?
[17:46] <persia> hyperair: Under "Contacts" in https://wiki.ubuntu.com/PatchDay
[17:46] <hyperair> hmm i see
[17:47] <persia> dholbach: At the current time, I think it's semi-fluid, based on the docs written up by nigelb and bryce_ , so there's two folk who know stuff.  I'm happy to take some slots.
[17:47] <dholbach> ok
[17:47] <nigelb> We're also hoping to recruit after the announcement
[17:47]  * dholbach marks day in calendar
[17:48] <dholbach> that should also leave us enough time for reviewing docs
[17:48] <nigelb> also, please review the wiki for any additions/deletions
[17:48] <nigelb> if some thing needs to be added, add to the TODO page
[17:48] <nigelb> https://wiki.ubuntu.com/ReviewersTeam/TODO
[17:48] <persia> Or just do it :)
[17:49] <nigelb> yeah, that works too :)
[17:49] <persia> OK.  Anything else about PatchDay?
[17:50] <bdrung> nigelb: https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved -> Workflow -> first entry should have a LP link
[17:50] <persia> RIght then.  Moving on: Item 3: Policy for new members to join
[17:50] <dholbach> I think it'd be good if they could mention a couple of bugs they already worked on
[17:51] <nigelb> bdrung, the LP subscribed bugs?
[17:51] <dholbach> so they demonstrate that they know when to forward stuff to upstream and debian and how to do it, etc
[17:51] <persia> My personal thought is that until we develop enough popularity that we end up being unsure, we let anyone already on the team endorse anyone else, and that lets them on the team.
[17:51] <bdrung> nigelb: yes
[17:51] <dholbach>  + people we know who do good work
[17:52] <persia> dholbach: I don't want to add anyone to the team unless they ask.  I know folk who don't like to be on too many teams.
[17:52] <dholbach> sure, that's not what I meant
[17:53] <persia> Oh, yeah.  I completely agree that "people we know do good work" is the right criterion.
[17:53] <dholbach> endorsements-for-people-who-asked + people-who-can-show-they-did-good-work-for-people-who-asked
[17:53] <bryce_> how many people are you expecting will want to join?
[17:53] <dholbach> bryce_: there's already a bunch that tried to join :)
[17:53] <bryce_> dholbach, oh, how many?
[17:54] <persia> bryce_: I think ~50 members would be a good target.
[17:54] <dholbach> bryce_: I think 10 in the last month (and that with the little publicity the team got)
[17:54] <persia> Trick being that lots of folks try to join teams like this to get their stuff reviewed, rather than review other people's stuff.
[17:55] <nigelb> sorry, got disconnected
[17:55] <bryce_> persia, ah, so are you assuming 50 active contributors, or 50 of which a subset is contributing?
[17:56] <dholbach> so process-wise, I think we should ask people to apply for membership through LP, if we know they do good work, approve them, if not, they should come to #ubuntu-reviewers show a few bugs they worked on (regarding the review team process), then make the decision
[17:56] <persia> bryce_: I'd be happy with 30 (rotating) active of 50 as a target.  I expect that's going to take > 6 months to reach.
[17:56] <dholbach> so it doesn't get to heavy-weight
[17:57] <persia> dholbach: Sure, but I'd like the process here to involve some *current* member (maybe an admin, maybe not) endorsing them (over IRC is fine).
[17:57] <dholbach> persia: yes, sure
[17:57] <dholbach> persia: who else would?
[17:57] <persia> Something like "I want to join", "I know you, yeah" OR "I want to join", "what have you done?" "this" "that looks good, sure".
[17:58] <persia> I'm just worried about formalisation, councils, etc.  I think we're not mature enough to need that yet, and I think it creates false barriers to entry due to individuals internal perceptions.
[17:58] <dholbach> sure, that wasn't my plan
[17:58] <nigelb> I agree
[17:58] <nigelb> something simple but something agreed upon
[17:58] <dholbach> the good thing is that nobody is blocked because of lacking team membership
[17:58] <dholbach> they can still do good work
[17:59] <persia> RIght.
[17:59] <dholbach> ok great
[17:59] <nigelb> only they can't unsubsribe, its only a matter of asking here :)
[17:59] <persia> Alright then.  Anything else anyone wants to raise whilst we're all here?
[17:59] <dholbach> not from me
[17:59] <bryce_> I have an anecdote
[17:59] <bdrung> are there any plans to create scripts?
[18:00] <bdmurray> I had one question too
[18:00] <bryce_> yesterday I looked through the 'audacious' bugs (a music player I use which has been quite buggy)
[18:00] <bdrung> bryce_: i saw that
[18:00] <bryce_> I saw half a dozen patches posted, and thought, "Wow, someone's been active, I should sponsor these!"
[18:00] <bryce_> then I looked and saw they were all patches I had made and posted 1.5 yrs ago hoping someone would sponsor them :-/
[18:01] <nigelb> lol
[18:01] <bryce_> so... there's definitely a need for this ubuntu-reviewers team :-)
[18:01] <persia> Yeah.  It's been about 1.5 years since we identified the need, but until nigelb started pushing, everyone was busy with something else.
[18:01] <bryce_> on the topic of scripting...  you know I definitely am more of a fan of automation over crowd-surfing to solve problems like these
[18:02] <nigelb> bryce_, if anyone can help with scripts, I'd be really happy :)
[18:02] <bryce_> recruiting one guy to hack together some scripts that do the work of 10 men might be easier than finding 10 men.  But I could be wrong.  ;-)
[18:03] <nigelb> bdrung, you have thoughts of a few snippets that could help?
[18:03] <bryce_> I'm willing to wait and see how the crowd-sourcing works.  Certainly humans tend to be a lot better than scripts in general, so if the manpower can be had, go for it
[18:03] <persia> I think we want a mix.
[18:03] <bdrung> i was thinking about a python script that does following: 1. grab the patch from the lp bug 2. detect the type debdiff vs normal patch 3. apply debdiff or add patch (directly, quilt, dpatch) 4. build 5. maybe upload to ppa
[18:04] <persia> As we formalise process, we can script it, but I think lots of stuff ends up being semi-dependent on a large number of variables, and we haven't identified enough of those yet.
[18:04] <nigelb> bdrung, some of the patches are badly formated which needs to be manually corrected
[18:04] <nigelb> I've come across a few so far
[18:04] <bdmurray> How can we as a group track these variables and issues persia?
[18:04] <bryce_> nigelb, right but who does that fixup?
[18:05] <nigelb> I do it manually when I see that the patch doesn't apply cleanly
[18:05] <bdrung> nigelb: yes, human investigation is still required.
[18:05] <bryce_> nigelb, I had a similar idea as bdrung... cases where the patch is invalid, the scripts would kick back to the reporter to fix (which I'd argue is probably all the human reviewers would do anyway, but the scripts would turn things around a lot faster)
[18:06] <nigelb> bryce_, most things are small enough for us to fix ourselves :)
[18:06] <persia> bdmurray: What do you think about having an "automation cases log", where we document cases that seem like they didn't require thought, and add a count.  When enough folk hit a case (e.g. >15 occurances), we use a script to find and resolve the rest?
[18:06] <bryce_> nigelb, fair enough
[18:07] <bdrung> bryce_: and as maximum of automation: we may push all patched packages to an ppa. so the submitter can test it directly.
[18:07] <bdmurray> persia: yes, something like that would be fantastic
[18:07] <nigelb> bryce_, I'm for automation but probably after a little bit of human intervention...like a human okaying for auto-testing patch
[18:07] <persia> nigelb: Could you organise such a wiki page?
[18:07] <bryce_> nigelb, fwiw most of the time I've needed to fix patches is because the code changed while the patch waited in the queue, so if the process can be made more immediate it would make it less necessary to fiddle patches.
[18:07] <nigelb> persia, yes.  definitely
[18:07] <persia> Thanks.
[18:07] <bdmurray> bryce_: did you do something similar for automating X bugs?
[18:08] <bryce_> bdmurray, yep
[18:08] <nigelb> bryce_, do you folks triage the X bugs with patches on your own? i.e. can we exclude X and kernel?
[18:09] <bdrung> maybe we can take some bits from the ack-sync script
[18:09] <bryce_> nigelb, don't exclude X
[18:09] <bdmurray> nigelb: kernel is excluded in the script too - they go to Jeremy Foshee
[18:09] <nigelb> JFO right?
[18:09] <bdmurray> yeah
[18:09] <bryce_> nigelb, while I have tended to the X patches I won't be doing X.org next release
[18:10] <nigelb> bryce_, but would we folks know what we're doing?  I'm lost with X
[18:10] <persia> I'd like to exclude the kernel, just because it's so big and so different, but most of X is just standard libraries, services, and applications.
[18:10] <bryce_> nigelb, plus I'm curious to see how this process works with something like X.org
[18:10] <nigelb> http://pastebin.ubuntu.com/408255/ this is an intersting pastebin of top packages with patches that the LP guys generated
[18:11] <nigelb> bryce_, the X package there was a special case that you mentioned the other day?
[18:11] <nigelb> where the upstream posts patches for users to test, so can we exclude them from the scope of this review?
[18:11] <bryce_> nigelb, consider it a proof-test of the process then.  ;-)  But honestly X really isn't *that* different from other things.  Most of the patches we get are against easier bits like keyboard config xml fiddles or so on
[18:12] <bryce_> nigelb, right that's xserver-xorg-video-openchrome
[18:12] <nigelb> bryce_, I'd be happy to help with the smaller bits, but this xserver-xorg-video-openchrome can be excluded...yes?
[18:12] <bryce_> nigelb, yes
[18:13] <persia> I don't think we should exclude patches from upsteam.
[18:13] <persia> They just get the "patch-approved-upstream" tag extra-fast.
[18:15] <persia> bdmurray: You had a question at :00 ?
[18:15] <nigelb> hm
[18:15] <bryce_> persia, well in this case the patches aren't "approved from upstream" but rather are patches upstream is asking bug reporters to test - e.g. they add debugging stuff
[18:15] <persia> Oh, I misunderstood then.  Hrm.
[18:15] <bryce_> iow, patches that aren't appropriate to be sponsored
[18:15] <nigelb> yeah, I saw some heated arguments on one of those bugs
[18:16] <nigelb> where the reporter wanted to know how to patch, why he should do it, and if the said patch writer was an ubuntu contributor..
[18:16] <bryce_> heh, yeah.  They seem to have things in hand so I just try not to interfere.  They seem to not like if we carry patches in ubuntu on top of what they provide, so we can just leave that package alone.
[18:16] <bdmurray> Is anybody using the ubuntu-patch-reviews mailing list?  The only posts getting through at the moment are mine so the list just gets notified when a new bug is added to the queue and not all bug comments are making it there.
[18:17] <nigelb> I'm not subscribed since it was only a bug list.  mostly the patch tag getting added
[18:17]  * persia doesn't use that list
[18:17] <nigelb> ah, bdmurray ... question
[18:18] <nigelb> is it possible for your script to use a different username? (so that we know its the script)
[18:19] <bdmurray> probably but why?
[18:19] <persia> That gets all sorts of complicated in terms of LP permissions and stuff.  I'd rather run scripts as real people, unless they are LP-internal.
[18:19] <nigelb> ah.
[18:19] <nigelb> forget then.
[18:21] <nigelb> bdmurray, you had a question earlier?
[18:22] <thekorn> but maybe it would be nice if this script could also add a comment, like "this tag was added by a script following the process on the wiki page"
[18:22] <thekorn> just my 50cent ;)
[18:22] <persia> I really prefer when scripts don't add such comments: it tends to send me lots of unwanted bugmail.
[18:23] <bdmurray> well its already sending e-mail due to adding the tag
[18:23] <nigelb> yeah, as such the patch tag addition is a bit of unwanted mail :D
[18:23] <bdmurray> so what's a few characters more ;-)
[18:24] <bdmurray> nigelb: I asked it earlier about the mailing list
[18:25] <persia> Somehow it seems like I don't get email for tags / status changes, but mostly just for comments.
[18:25] <persia> Maybe it's just me (or my memory)
[18:25] <nigelb> bdmurray, I'm undecided whether to join or not
[18:25] <persia> OK.  If everything has been asked, I think we're done.  Thanks everyone!
[18:26] <nigelb> just a momment
[18:26] <nigelb> https://wiki.ubuntu.com/ReviewersTeam/KnowledgeBase
[18:26] <bryce_> I wonder if there's a special codeword or flag or something we can put in with emails from automated processing, to clue in procmail or whatever to ignore the email?
[18:26] <nigelb> If anyone feels something needed to be added to the knowledge base please add or let me know what is to be added :)
[18:26] <persia> bryce_: We'd have to teach LP about it first, but after that it's easy.
[18:27] <bryce_> hmm
[18:27] <bryce_> kind of a "minor edit" type flag
[18:27] <bdmurray> a new X-Launchpd header?
[18:27] <nigelb> thank you folks for the time.. :)
[18:27] <bryce_> thanks
[18:27] <persia> Basically have some API-settable flag that indicates automated processing, and then have mailed updates based on changes with that flag have another header.
[18:27] <persia> bdmurray: Precisely.
[18:28] <persia> I don't think it should be for every API change though, because of tools like groundcontrol and bughugger
[18:29] <bryce_> persia, there's really two flags, one for "minor automated bug changes" like adding tags, and one for "major automated changes" like marking your bug report invalid since you didn't respond in N days
[18:29] <bryce_> or maybe the latter wouldn't need a flag
[18:31] <persia> I think the latter wouldn't get the flag, because you *want* to notify the user
[18:34] <bryce_> persia, yeah so just a "minor automatic edit" type flag is needed.
[18:34] <nigelb> persia, that was truly *awesome*. Now, we have some sort of coordination and agreement to things )
[18:35] <persia> That would be my preference.
[18:35] <bryce_> such could be handy for apport-collect too, when it does a separate email for each attachment
[18:35] <persia> nigelb: And next time, you get to chair the meeting :p
[18:35] <persia> apport would be a huge user.
[18:35] <nigelb> persia, no thanks.  :D
[18:35] <nigelb> jcastro, if you've got time we'll finish off the work on the mail now :)
[18:39] <jcastro> yeah
[18:39] <jcastro> basically I think just adding some spice in there would help.
[18:39] <nigelb> I'll toss it into an etherpad, so we can all edit
[18:39] <jcastro> yeah
[18:40] <jcastro> hey, ubuntu-uk has an etherpad btw
[18:40] <nigelb> it does? linky?
[18:41] <jcastro> http://pad.ubuntu-uk.org
[18:42] <nigelb> http://pad.ubuntu-uk.org/aSZVcm7UE9
[18:42] <jcastro> on it
[18:42] <jcastro> nigelb: link me to your blog pls
[18:43] <nigelb> yes
[18:43] <nigelb> jcastro, http://justanothertriager.wordpress.com/2010/03/16/1801-bugs/
[18:43] <nigelb> jcastro, I think we can use bryce's anecdote too
[18:44] <jcastro> nigelb: paste it in there and I'll work it in
[18:44] <nigelb> okay :)
[18:44] <thekorn> If upstreams comments on a bug like "I'll take care of this patch, and apply it to the next release", does this qualify as "patch-forwarded-upstream" ?
[18:45] <nigelb> thekorn, generally upstream commits to svn or git immediately
[18:46] <nigelb> but yes, that counts too :)
[18:46] <persia> I'd call that patch-accepted-upstream even.
[18:46] <nigelb> yep I second ^
[18:46] <persia> I consider patch-forwarded-upstream an intermediate state, indicating we're waiting for an upstream accept/reject still.
[18:47] <thekorn> right , forwarding and accepting are two different things,
[18:47] <thekorn> now the question is: what do we want to indicate in the review workflow
[18:47] <persia> To me the important things are:
[18:47] <persia> 1) I'm on it.
[18:48] <jcastro> nigelb: ok how's that?
[18:48] <persia> 2) Someone qualified is looking at it
[18:48] <nigelb> jcastro, its awesome :)
[18:48] <persia> 3) It's good/bad
[18:49] <nigelb> persia, anything to add/edit to http://pad.ubuntu-uk.org/aSZVcm7UE9 ?
[18:50] <persia> I thought it was May 5th, not May 6th.
[18:50] <nigelb> corrected
[18:51] <thekorn> ok, I think I got it now. 1) and 2) is -forwarded-upstream, 3) AND good is -accepted-upstream, 3) AND bad is -needswork or even -rejected-upstream
[18:51] <persia> I don't think we can commit to "we  will get the patch applied in Ubuntu immediately" unless we first ensure we have sufficient quorum of uploaders to be around.
[18:51] <jcastro> "we will try"
[18:51] <jcastro> :p
[18:51] <persia> thekorn: Something like that.  nigelb and I went through about 20 use cases to establish the tag set, but I forget all the details.
[18:51] <persia> "try" works :)
[18:52] <persia> "We'd like your help to get these submissions reviewed and if necessary sent upstream so that they don't bitrot and to encourage people to continue helping us improve open source software. " Feels run-on.
[18:52] <nigelb> thekorn, I'll add use cases over this week
[18:52] <persia> How about "We'd like your help to get these submissions reviewed and if necessary sent upstream so that they don't bitrot.  We believe this helps to encourage people to continue helping us improve open source software. "
[18:53] <nigelb> thekorn, what parts are most confusing?
[18:53] <nigelb> thekorn, I'll add more details to those.
[18:53] <persia> Last bits edited inline.
[18:54] <thekorn> nigelb, for me there are so many bold bits in the workflow section
[18:54] <thekorn> nigelb, but otherwise it is looking great
[18:54] <thekorn> and I think concrete examples will help alot
[18:54] <nigelb> thekorn, all tags are bolded to mark them as tags
[19:02] <nigelb> looks like I'll need to make some changes to the wiki first
[19:03] <thekorn> for me this sentence is also a bit confusing """When a review of the patch is done, unsubscribe ubuntu-reviewers from the bug. The tags will help us catch the bug for clean up later."""
[19:04] <thekorn> what exactly does """review """ mean here? does review envolve upstream action, or is it just the review process described in the first two items
[19:05] <thekorn> s/envolve/involve
[19:05] <nigelb> ok, its like this.  a bug is in review queue
[19:05] <persia> The entirety of the process.  "This patch has been handled".
[19:05] <persia> Rejected upstream/debian/ubuntu or accepted upstream, etc.
[19:05] <nigelb> yeah.. the simple explanation :)
[19:10] <nigelb> persia, I think reviewers can be unsubscribed when patch-needswork.  can be resubscribed once work done?
[19:10] <nigelb> also... um, how to do negative searches again?
[19:10] <bryce_> nigelb, prepend a -
[19:10] <bryce_> so like "foo bar -baz"
[19:10] <bryce_> also make sure to set the tag combinator thingee to 'All' rather than 'Any'
[19:11] <persia> nigelb: Works for me.
[19:11] <nigelb> brian also suggested the same for forwarded upstream
[19:12] <persia> I don't think we want to unsubscribe for forwarded-upstream.  Maybe accepted-upstream or accepted-debian.
[19:12] <persia> TO me, forwarded-upstream implies we're still responsible for the patch.
[19:12] <nigelb> then I need to do the negation
[19:12] <nigelb> https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-reviewers&field.tag=patch&field.tag=-patch-forwarded-upstream&field.tags_combinator=ALL
[19:13] <nigelb> This is supposed to work ^
[19:13] <persia> Launchpad doesn't understand the form data submitted in this request.
[19:13] <nigelb> yeah
[19:14] <nigelb> ah, figured it out
[19:20] <nigelb> so joining is apply and prove work you've done or apply and get an ack from current member
[19:23] <persia> or come hang out here and do stuff until someone gets annoyed and bugs an admin to add you.
[19:24] <nigelb> yes, that is indeed needed :D
[19:31] <nigelb> tweaked a bit https://wiki.ubuntu.com/ReviewersTeam
[20:43] <vish> jcastro: damn you are fast! , i just about to warn you about the typo and got your second mail :)
[20:43] <jcastro> it happens every time. :D
[20:44] <vish> hehe..


[02:23] <yuriy> i added a new patch with quilt, but it doesn't show up in the debdiff
[02:24] <yuriy> I think it might be because there was no debian/patches before?
[02:24] <yuriy> I used quilt as it says in the packaging guide
[02:25] <yuriy> do I need to modify something else?
[04:41] <nixternal> hola
[04:43] <yuriy> heya nixternal
[04:44] <yuriy> nixternal: think you could help me with that ^^
[05:04]  * nixternal looks
[05:05] <nixternal> yuriy: I still do my patches the old school way..haven't used the quilt patching stuff, nor the cdbs patching stuff
[05:39] <yuriy> nixternal: well, is there something that needs to be added somewhere when creating the first patch?
[05:41] <nixternal> oh
[05:41] <nixternal> derr, ya, add the patch name to debian/patches/serial
[05:41] <nixternal> that didn't even cross my mind at first
[05:41] <DaSkreech> What did I miss today?
[05:42] <nixternal> the same thing I missed
[05:42] <nixternal> EVERYTHING!
[05:42] <DaSkreech> that's all?
[05:43] <DaSkreech> ah well same thing every day I guess
[05:46]  * nixternal beds - g'nite
[05:47] <DaSkreech> gday mate!
[05:47] <yuriy> nixternal: that's already done, quilt did it
[05:48] <yuriy> assuming you mean debian/patches/series
[05:48] <yuriy> nixternal: night
[07:57] <Serega> yaw... good morning!
[07:57] <DaSkreech> :-)
[07:58] <Serega> DaSkreech: hey!
[07:58] <DaSkreech> Hey! Serega
[07:58] <Serega> did anobody noticed some strange behavior of editboxes in konqi4?
[07:59] <Serega> *anybody
[08:02] <DaSkreech> Qt 4.4 bug
[08:02] <Nightrose> Serega: yea - i am working on a fixed package
[08:02] <Nightrose> if you have time to do it feel free to jump in
[08:02] <Serega> ah, thank you
[08:02] <Nightrose> as i will leave soon and not be back until sunday
[08:02] <Serega> just interesting
[08:03] <Nightrose> ;-)
[08:10] <DaSkreech> Ah damn it
[08:10] <DaSkreech>  I need to get amarok working
[08:11] <\sh> Nightrose, when do we meet in KA?
[08:17] <Nightrose> \sh: sorry - busy doing last minute stuff ;-)     meet for what?
[08:28] <\sh> Nightrose, openexpo... :) or just give me a ring when you are back from praque
[08:28] <Nightrose> ok
[08:34] <peer_> I made a copy of a directory with rsync to a mobile disk. diffed it - everything is fine. but with "Properties" on the two directories, I get different total file sizes. This should not be like that.
[08:35] <peer_> I think that if i put a file on the disk with x bytes, it should tell me that it has x bytes and retrieve x bytes. not y bytes, even if it takes y bytes on the disk.
[08:36] <peer_> this is with hardy, kde3 and latest updates. with dolphin and with konqueror.
[08:39] <peer_> I sometimes use the total file size serves as a rough estimation that the whole copy thing went well. but if a good copy still gives different total file size values, i need to investigate further even if everything was copied fine. it makes things more complicated.
[08:39] <\sh> peer_, same FS on both disks?
[08:40] <peer_> probably not...  but both are ext3.  but i'm not even sure how to check for details.
[08:41] <\sh> peer_, that's a problem...different inode sizes could give different fsizes...therefore estimation on the filesize (or the total sum of it) is not good...md5sums are better for this
[08:41] <peer_> it's for a backup. but with this kind of not being sure, it really doesn't make me trust the tools.
[08:41] <peer_> and i know that windows displays two values in this kind of situation: the total file size, and the total file size on disk. you always get a clear picture.
[08:42] <awen_> peer_: the files are written in blocks to the disk ... if the block-size is different the size on disk might also differ
[08:43] <peer_> the difference is if you look at the bytes of your data, or if the bytes from a purely technical perspective (which is less important since it's an artifact).
[08:44] <awen_> peer_: the difference is also which is the faster to calculate ... calculating actual sizes might take a serious longer amount of time
[08:44] <peer_> so the properties boxes add up the artifacted file sizes, and not the file sizes of the data i put there.
[08:44] <hads> So if you diff the files and they are the same then what are you worried about?
[08:45] <peer_> well, yes, it might take longer to calculate, but as it is, it makes me take MUCH more time to diff the files, since it SEEMS that something was wrong when I copied them.
[08:45] <awen_> peer_: if it is recursively it uses "estimate file space usage"
[08:46] <peer_> it's kind of unexpected und counter-intuitive behavior.
[08:46] <peer_> what is "estimate file space usage" ? and yes, it's a directory tree.
[08:47] <peer_> it calculates to the byte. if it's only an estimation, maybe it should not give all the digits.
[08:48] <awen_> peer_: look at the "du" command ... i'm almost certain that dolphin/konqueror uses mostly the same method
[08:48] <peer_> it also doesn't say "estimation" in the dialog box
[08:48] <peer_> yes, du also gives different values. :-/
[08:49] <awen_> peer_: "du -bcs" gives you the same as konqueror at least
[08:49] <peer_> so i have to write my own tool?
[08:50] <peer_> yes. so i get<PHONE_NUMBER>5 and<PHONE_NUMBER>1 bytes for the original and the backup, respectively. what would you conclude from that? something went wrong with the backup. and from this point on you loose time.
[08:51] <awen_> peer_: might exist another tool ... but i'm not sure
[08:51] <awen_> peer_: I would do an rsync from one to the other ... rsync uses checksums for all the data
[08:52] <peer_> yes, that's exactly what I did. but since I never uses rsync before, I wanted to verify it's operation. and got this :-)
[08:53] <hads> rsync works well.
[08:53] <awen_> peer_: then i can tell you that rsync actually outperforms the verification :)
[08:54] <peer_> how can I know the inode sizes etc.? maybe they are the same, so then there'd by another problem uncovered.
[08:54] <hads> Probably best discussed in a user channel anyway
[09:00] <peer_> I just checked with tune2fs, the "Inode size" is the same for both file systems. This makes it somewhat stranger. What else could be different?
[09:01] <peer_> Block size and fragment size also are identical.
[09:02] <peer_> So does this mean that the added file sizes depend on some random factor?
[09:03] <peer_> If so, then for what would it be useful anyway?
[09:03] <awen_> peer_: you could try asking in #ubuntu ... there is a little better chance to hit an expert in the "underlying layers"
[09:04] <peer_> well, i thought in -devel the people are expertier :-)
[09:06] <awen_> peer_: in kubuntu specific kubuntu stuff ... but the channel is mostly used for coordinating the making of kubuntu, and most of the people in here is also in the user channels
[09:07] <awen_> peer_: so in general you might as well ask in the user channel ... then even more people can learn from the findings :)
[09:07] <peer_> ok
[11:46] <mornfall> yuriy: I'll look at Adept during FOSScamp (and your patches, too)...
[15:32] <\sh> hmmm...any idea how to add a second panel in kde4 ? I wonder where the option in the panel submenu is ;)
[15:33] <Jucato> dunno if it's there in 4.0.4 already, but right-click on the desktop  -> Add Panel
[15:36] <\sh> Jucato, not in kde 4.0.3  (kubuntu hardy) ;
[15:36] <Jucato> oh.. must be a trunk thing :/
[15:37] <\sh> do we have somehow trunk packages for kde4 somewhere? ppa or whatever?
[15:37] <\sh> ah we have 4.0.4 in backports
[15:38] <nixternal> \sh: 4.1 alphas are going to be making their way into intrepid soon as well
[15:39] <nixternal> wth, jjesse uses trillian, eww
[15:39] <nixternal> wth, jjesse uses trillian, eww  <-- requote from after you quit :p
[15:40] <nixternal> I thought Trillian died many years ago
[15:41] <Jucato> nixternal!!!!!!!!!!!!!!
[15:41] <jjesse> nope trillian is still being used
[15:41] <nixternal> I have to go pick up a friend from the train station, and I don't feel like doing it...I should make him walk
[15:42] <jjesse> haha
[15:42] <\sh> nixternal, you are not ubuntu today ,-)
[15:42] <jjesse> call him lazy cause he isn't walking
[15:42] <nixternal> \sh: to early to be Ubuntu I guess :)
[15:43] <nixternal> actually, I am being Ubuntu, because if I don't drive to pick him up, I will not be polluting mother earth :)
[15:43] <\sh> nixternal, hell, I'm already far behind being "Ubuntu"...it's too hot...
[15:43] <Jucato> nixternal: nah, you're just being Foresight :)
[15:43] <nixternal> heh, I haven't done any Foresight stuff in a while now...been way to busy
[15:44] <nixternal> anywho, bbiaf...gonna go pick him up really quick
[15:44] <jjesse> nixternal: idid i hear correctly you have a job?
[16:11] <\sh> guys, I installed kde4.0.4 from backports..but every app is telling me "I'm kde 4.0.3"
[16:12] <\sh> this is not the truth, right?
[16:13] <ScottK> IIRC someone else commented on the same thing.
[16:14] <\sh> ScottK, well, konsole --version just results in qt4.4.0 and kde 4.0.3
[16:14] <ScottK> I'm pretty sure it's a bug and you have 4.0.4, but maybe someone else recalls for sure.
[16:16] <\sh> nixternal, should know
[16:25] <Hobbsee> when does 4.1 come out?
[16:27] <Jucato> end of July or early Aug
[16:29] <Hobbsee> rught
[16:29] <Hobbsee> er, right
[16:29] <Hobbsee> an intrepid candidate then
[16:32] <Jucato> yep. centipede candidate
[16:54] <ScottK> Riddell: Do we need a Kubuntu spec on proper Xrandr support?  It's something I think we are really missing just now.
[16:55] <DaSkReEcH> manchicken: ping
[16:55] <manchicken> pong
[16:56] <DaSkReEcH> manchicken: Saw the brainstorm on upadtes being visaully respresented?
[16:56] <DaSkReEcH> updates
[16:57] <manchicken> Naw
[16:57] <DaSkReEcH> Interesting
[16:57] <Jucato> wow manchicken!!!! :)
[16:57] <manchicken> Jucato: Wuddup?
[16:57] <Jucato> how are you?! LTNS
[16:58] <DaSkReEcH> The update notifier would visually show how severe an update is available and there would be an option for the list of updates to show how severe they are as well
[16:58] <Riddell> ScottK: I'm kindae hoping upstream will do that for us, but it's something to look at
[16:58] <manchicken> Seriously.
[16:58] <manchicken> I'm doing well.  Just working a lot, volunteering a lot, parenting, fun stuff.
[16:58] <Jucato> how's the babychicken? :)
[16:59] <ScottK> Riddell: I hope so too, but we need to keep track of it.  I see no sign Guidance is up for that, so we need to make sure we pick the right tool.  This will be particularly problematic if we keep a KDE3 desktop.
[16:59] <yuriy> DaSkReEcH: link? like colorizing based on priority or section?
[16:59] <DaSkReEcH> yuriy: Section ?
[16:59] <yuriy> security/backports/...
[17:00] <DaSkReEcH> Ah right. Something like that
[17:00] <DaSkReEcH>  the mockup had a very oxygen looking bug which gets coloured from green to red
[17:00] <DaSkReEcH> normal bumpd version updates get no bug at all
[17:01] <DaSkReEcH> so if it's slight security risk you get green bug beside the update if it's critical and urget you get a erd bug
[17:01] <ScottK> I'd suggest that would confuse the average user who doesn't care and the non-average user already knows enough to figure it out.
[17:01] <DaSkReEcH> the highest colour bug becomes the icon on systray showing there are updates
[17:01] <manchicken> Jucato: Big.
[17:01] <yuriy> what does the urgency= thing in the changelog do?
[17:01] <Jucato> manchicken: oooh :)
[17:01] <ScottK> We really don't want users picking and choosing updates.
[17:01] <ScottK> yuriy: Nothing in Ubuntu.
[17:01] <DaSkReEcH> ScottK: probably off by default then?
[17:02] <DaSkReEcH> seele: ping
[17:02] <ScottK> yuriy: In Debian it's how fast it can transition from Unstable to Testing.
[17:02] <ScottK> DaSkReEcH: I was thinking neat idea but probably not worth the trouble to implement.
[17:03] <yuriy> DaSkReEcH: i don't think there's anyway to get that kind of information
[17:03] <yuriy> beyond just security update or not
[17:03] <ScottK> DaSkReEcH: Also potentially actively dangerous since it promotes the idea that users should decide what updates to take.
[17:03] <DaSkReEcH> ScottK: To be honest I didn't care too much about the bug beside individual updates
[17:03] <DaSkReEcH>  I did like the idea of the systray indicating that this is a crtical update
[17:03] <yuriy> but colorizing all security updates the same doesn't sound like a bad idea
[17:04] <DaSkReEcH> ScottK: users shouldn't decode what updates to take? :)
[17:04] <ScottK> As a rule we don't put out non-important updates.
[17:04] <DaSkReEcH> I guess if you don't have backports on
[17:04] <yuriy> ScottK: backports
[17:05] <ScottK> yuriy: I think a special pinning solution for backports is useful.  Only take updates from backports if you've explicitly installed that package from backports.
[17:05] <ScottK> But generally I don't think picking/choosing is useful end user behaviour
[17:05] <smarter> but security updates are automatically installed by unattended-upgrades ayway
[17:05] <DaSkReEcH> Lord knows that's how Windows works
[17:06] <DaSkReEcH> drives me crazy
[17:06] <DaSkReEcH> of course they enforce that by never telling you waht any updates do
[17:06] <ScottK> We want users to have the package configuration we've tested.  If they update some stuff and not others, then who knows what happens.
[17:07] <yuriy> anyways, can somebody help me with this, i'm working on bug 214577
[17:07] <jdavies> yuriy: http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog explains the urgency= field
[17:08] <yuriy> there was no debian/patches previously and I added it and created a new patch with quilt as it says in the packaging guide
[17:08] <yuriy> but the patch doesn't show up in the debdiff
[17:08] <ScottK> The current tools are sufficient for experts.  Non-experts have no proper basis to make such decisions anyway.
[17:34] <seele> DaSkReEcH: pong
[17:40] <DaSkReEcH> seele: didn't see the conversation on highlighting security bugs for the Update notifier?
[17:43] <DaSkReEcH> seele: Just wanted to know if it would be a good idea for the user to see the severity of the update
[17:47] <seele> DaSkReEcH: i dunno.. do we have stats on if users tend to install all updates right away or only some updates or never update?  if they are always updating anything then it wouldnt matter
[17:47] <seele> DaSkReEcH: if they are picking and choosing updates or not updating all the time, then it might matter
[17:49] <DaSkReEcH> seele: hmm I guess popcon doesn't cover that :)
[17:49] <DaSkReEcH> Might track the downloads from the servers so those stats should be around somewhere
[17:51] <Tm_M> hi kids
[17:52] <apachelogger> hey mom
[17:52]  * ryanakca waves to Tm_M
[17:53] <ScottK> seele: My concern would be if we start to show them a distinction between updates they will be encouraged to pick and choose when in reality virtually none of them would know enough to make an intelligent choice.  It'd be some kind of attractive nuisance.
[17:54] <seele> ScottK: yeah.. and if people are alredy installing all or none of the updates, adding some kind of severity wont necessarily make it better and it might change the behavior of people already installing all the updates
[17:55] <seele> those who don't update probably wont care or even notice.  they might have adept notifier turned off
[17:55] <ScottK> I think those that know enough to decide are probably using apt anyway.
[17:56] <seele> was there a bug report or something? i missed the beginning of the discussion
[17:56] <ScottK> It's an idea on brainstorm.
[17:57] <seele> ah
[17:57] <ScottK> I don't see a link in my scrollback.
[17:57] <DaSkReEcH> I'll find it
[17:58] <smarter> I think we shouldn't care, security updates are automatically installed by unattended-upgrades anyway
[17:58] <DaSkReEcH> but as I was saying the description seemed to me to be for the notifier where they were more interested in actaul individual ones being marked which I wasn't so hot on
[18:00] <DaSkReEcH> http://brainstorm.ubuntu.com/idea/8492/
[18:00] <DaSkReEcH> Probably
[18:37] <Artemis_Fowl> seele: ping
[18:38] <seele> Artemis_Fowl: pong
[18:41] <Artemis_Fowl> seele: [20:08:12] <jpwhiting|workpc> Artemis_Fowl: hello
[18:41] <Artemis_Fowl> seele: [20:08:43] <jpwhiting|workpc> did seele send you a note?
[18:41] <Artemis_Fowl> seele: [20:09:53] <jpwhiting|workpc> about adept-like lists
[18:41] <Artemis_Fowl> seele: [20:10:13] <Artemis_Fowl> jpwhiting|workpc: no
[18:41] <Artemis_Fowl> [20:10:35] <jpwhiting|workpc> ah, I spoke with her the other day about your brainstorming, and she had some suggestions iirc
 I thought she was going to send you an e-mail
[18:42] <Artemis_Fowl> is this old news?
[18:42] <Artemis_Fowl> didn't we turn to the Preview pane?
[18:42] <seele> yeah, it's old news
[18:42] <Artemis_Fowl> ok
[18:42] <Artemis_Fowl> one min to show you new screenshots then
[18:44] <Artemis_Fowl> seele: http://www.hotlinkfiles.com/files/1324937_zjrtj/KGRUBEditor45.png
[18:45] <seele> Artemis_Fowl: the default needs to be a radio button, not checkbox
[18:45] <Artemis_Fowl> I centered the separator's text and used a different Default  system
[18:46] <seele> and can you take the default selection off of the menu item?
[18:46] <Artemis_Fowl> seele: I used checkboxes so that the user is able to deselect default
[18:46] <Artemis_Fowl> seele: with radio buttons there would always be a default
[18:47] <seele> can't use checkboxes
[18:48] <Artemis_Fowl> with radio buttons how could someone deselect an entry from default?
[18:48] <seele> if a default isn't selected, do it just wait for the use to make a selection or is the first in the list the default?
[18:50] <Artemis_Fowl> it is the default
[18:50] <seele> so there is a default regardless?  then we don't need a "no default" option
[18:51] <seele> by default it will be at the first entry, then the user can change it to whatever they want
[18:51] <seele> if they click the system settings reset or generate a new grub config file, it'll just get reset to the first one again
[18:51] <Artemis_Fowl> seele: no, a default is not mandatory
[18:51] <Artemis_Fowl> seele: it is in my configuration that the first one is set as default
[18:51] <seele> so if there is no default, grub just sits at the menu?
[18:51] <Artemis_Fowl> yes
[18:52] <Artemis_Fowl> no
[18:52] <Artemis_Fowl> if there is no timeout, then this is when grub just sits
[18:53] <seele> can you have a timeout without a default or do you have to have a default to set a timeout?
[18:54] <Artemis_Fowl> nothing is mandatory. if you have a timeout but don't have a default then the first entry is booted by default
[18:54] <Artemis_Fowl> let me check this out
[18:54] <Artemis_Fowl> I don't remember exactly
[18:55] <seele> ok
[18:55] <Artemis_Fowl> Quote: "Set a timeout, in sec seconds, before automatically booting the default entry (normally the first entry defined)."
[18:56] <Artemis_Fowl> it is not 100% clear
[18:56] <Artemis_Fowl> what this means
[18:56] <Artemis_Fowl> but I suppose it means what I told you
[18:56] <seele> so the first entry is the default default?
[18:56] <seele> and there is always a default, it just doesnt' always have to be defined?
[18:57] <Artemis_Fowl> if a default is not defined, then the first entry is assumed to be default
[18:57] <seele> ok.. then i dont see why we cant use the radio button
[18:57] <seele> because there is always a default
[18:58] <Artemis_Fowl> hmm...it could confuse users
[18:59] <seele> why?
[18:59] <seele> i think the unmarked default is the confusing part
[18:59] <Artemis_Fowl> if they know they have no default and see that the first entry is marked as default, they would thing it's a malfunction
[18:59] <seele> but they do have a default.. you just said the first entry is the default if no default is selected
[18:59] <Artemis_Fowl> GRUB is confusing in general
[18:59] <Artemis_Fowl> yes but they don't know it :)
[19:00] <seele> yes!  which is the confusing part!
[19:00] <Artemis_Fowl> lol
[19:00] <seele> marking the default andhaving them explicitly select it will make it simpler
[19:00] <Artemis_Fowl> anyway, most users won't even notice it
[19:00] <Artemis_Fowl> advanced users edit the file manually
[19:01] <seele> exactly
[19:01] <seele> the other editors probably had the same reasoning, because they didnt implement all possible grub functionality either
[19:02] <Artemis_Fowl> btw I removed fallback
[19:02] <Artemis_Fowl> it's no use to the target group
[19:02] <Artemis_Fowl> even advanced users don't use it
[19:02] <Artemis_Fowl> that's fine, right?
[19:02] <seele> yep, that's fine
[19:03] <Artemis_Fowl> ok then
[19:03] <Artemis_Fowl> screenshot #2
[19:03] <Artemis_Fowl> http://www.hotlinkfiles.com/files/1324938_awru1/KGRUBEditor46.png
[19:03] <Artemis_Fowl> simply shows the preview
[19:03] <Artemis_Fowl> any comments?
[19:03] <seele> can the background be white?
[19:04] <seele> like a text box so the text looks selectable?
[19:04] <seele> right now as the system background, it doesnt look like you could select the text.  just like you cant hgihlight and select a label that is in a window
[19:05] <seele> but the purpose of doing it this way was so that people could select and copy text, correct?  versus the tooltip or whatever
[19:05] <Artemis_Fowl> seele: this is how Qt paints read only text editors
[19:05] <seele> oh
[19:05] <seele> hmm
[19:05] <Artemis_Fowl> and it could be just y theme...
[19:05] <Artemis_Fowl> my*
[19:05] <seele> lemme ping a troll really quick
[19:07] <seele> Artemis_Fowl: the text is selectable in the disabled mode, correct?
[19:08] <Artemis_Fowl> yes
[19:08] <ScottK> I find it very interesting how subcultures have unique jargon.  I understood "lemme ping a troll", but not so many would.
[19:09] <seele> lol, yeah.. i guess i meant a trolltech troll and not an irc troll :)
[19:09] <jussi01> hehe, I totally missed that one
[19:11] <seele> Artemis_Fowl: are you using QTextEdit?
[19:11] <Artemis_Fowl> seele: yes
[19:11] <Artemis_Fowl> uhm
[19:11] <Artemis_Fowl> maybe KTextEdit
[19:11] <Artemis_Fowl> let me check
[19:11] <DaSkReEcH> Yeah someone came into #kde looking for a troll and I was highly confused for a moment
[19:12] <Artemis_Fowl> seele: it's a KTextEdit
[19:12] <uga> Riddell: I found today that the live CD from kubuntu using kde4 doesn't seem to use proxies even if manually configured
[19:12] <seele> 14:10 < TZander> seele: what you want is to use a QTextEdit widget.
[19:12] <seele> 14:11 < TZander> seele: the class has a set of 'textInteractionFlags'. One of them is to allow editing of text.
[19:12] <seele> 14:11 < TZander> seele: a separate one is selecting.
[19:12] <seele> 14:12 < TZander> seele: just using a QTextEdit will give him a white background, unless he did something weird (like using a broken QStyle)
[19:13] <uga> Riddell: the proxy was working fine (I manually telnetted), but konqueror(4) seemed to be unable to use it
[19:13] <seele> Artemis_Fowl: i dont know if that helps or not
[19:14] <Artemis_Fowl> seele: it does
[19:14] <seele> ok cool
[19:14]  * Artemis_Fowl is checking out
[19:19] <Artemis_Fowl> seele: in the meantime take a look at the last screenshot: http://www.hotlinkfiles.com/files/1324936_1a4lk/KGRUBEditor47.png
[19:19] <Artemis_Fowl> seele: it illustrates the Quick/Full Editor
[19:19] <Artemis_Fowl> popup*
[19:20] <seele> do you have the different editors implemented yet?  i'm still not sure what the differences would be and if there need to be two
[19:20] <Artemis_Fowl> not yet
[19:21] <Artemis_Fowl> seele: the Maps+Password+Kernel attributes cannot be quick-edited
[19:21] <seele> what are the types of things that are?
[19:22] <Artemis_Fowl> strings. but it's kind of complex
[19:23] <seele> are they things that users normally need to edit quickly?  and when they edit those thigns, do they typically not need to edit the maps, passwords, or kernel?
[19:23] <seele> if the non-quick-edits and quick-edits are linked in tasks, then the quick edit mode doesnt make sense because the user will have to go to full edit mode to edit the rest of the options anyway
[19:25] <Artemis_Fowl> in the Quick Edit the most common attrbutes should be listed such as title, root etc
[19:26] <Artemis_Fowl> kernel and the other stuff are edited from time to time but quickly would make no sense
[19:26] <seele> hmm
[19:27] <seele> well.. how about this
[19:27] <seele> just do it however you want and we'll get it out the door
[19:27] <seele> then we have some people use it and figure out if it's working out or not
[19:27] <Artemis_Fowl> seele: fine by me
[19:27] <seele> we have very little data on how normal users might use this thing because the existing grub UIs suck
[19:27] <Artemis_Fowl> and someone is spamming my inbox....
[19:28] <Artemis_Fowl> totally irrelevant but annoying
[19:28] <seele> with the way the button is implemented.. it wont hurt if we change the UIs or workflow a little as long as we still use an edit button
[19:29] <Artemis_Fowl> so for now all I have to do is change the checkboxes to radio buttons?
[19:30] <Artemis_Fowl> the white background is no issue
[19:30] <Artemis_Fowl> it seems that QTextEdit uses always a white background
[19:30] <ryanakca> Has anybody started merging kdetoys, or can I attempt to? *doesn't see a bug on LP*
[19:31] <seele> Artemis_Fowl: yes, and if possible, no radio button in the "menu" entry
[19:31] <Artemis_Fowl> seele: not possible
[19:32] <Artemis_Fowl> imagine what would happen if the user has such an entry and has this entry as default
[19:32] <Artemis_Fowl> weird but possible
[19:34] <seele> hmm.. so you can reformat the text, but you can't take the radio button off the list item?
[19:35] <seele> selecting that as default wont break anything will it?
[19:35] <Artemis_Fowl> hmm
[19:35] <Artemis_Fowl> let me think about it
[19:37] <Artemis_Fowl> seele: ok. I could hide the checkbox but consider this:
[19:38] <Artemis_Fowl> if this entry is marked as default since there will be no radio button, the user won't know that this is default
[19:38] <seele> so you mean if they mark it as default by hand in the config file but then open it in the UI?
[19:38] <ryanakca> Am I safe to assume that all Kubuntu changes to KDE Toys are stored in debian/patches ?
[19:38] <Artemis_Fowl> yes
[19:39] <seele> ok.. only advanced users will do something like that (and for what reason i dont know) so i wouldnt worry about it until we get someone with a reason why they would do it
[19:39] <Artemis_Fowl> as I said it's ackward but possible. I have to consider all possibilities
[19:39] <Artemis_Fowl> ok
[20:47] <mhb> Riddell: I apologize, but I cannot make it to the FossCamp.
[20:48] <mhb> Riddell: I have so much learning to do during the weekend... I have 2 exams the following week, and I cant learn during UDS, so I have to skip FOSSCamp.
[20:48] <mhb> hope you dont mind
[21:00] <seele> mhb: are your exams next week or is it a study week?
[21:00] <seele> oh, i misread your message
[21:01] <seele> does this mean there will be an end of exams happy hour? :)
[21:12] <mhb> seele: next week.
[21:13] <mhb> seele: tuesday and wednesday.
[21:13] <mhb> which is also bad, but what can I do?
[21:13] <mhb> tuesday late afternoon, that's okay.
[21:26] <yuriy> seele: what do you think of bug 226430?
[21:30] <seele> yuriy: yeah.. the entire logging out process is a problem.  they chose that word because leave is more ambiguous than logout, so the other actions could fit in there together
[21:30] <seele> but at the same time, you confirm you want to get out three times: choose leave, select logout, and then again logout from the plasma-looking menu
[21:32] <yuriy> seele: but you wouldn't agree that the choice of word "leave" is a bug?
[21:32] <yuriy> i don't really see the problem with it. or at least can't think of a better way to put it
[21:32] <Tm_M> we need 'are you sure?' menu too :p
[21:32] <yuriy> we have one :P
[21:32] <seele> yuriy: yeah, and i can't imagine it translates well.  but that's why they chose that word instead of logout
[21:33] <seele> because logout, switch user, shut down, sleept, etc. can all fit under it semantically
[21:33] <yuriy> seele: sorry, yeah it is a bug or yeah it isn't?
[21:33] <Tm_M> menu/dialog
[21:34] <seele> yes it is but i doubt it will get fixed upstream anytime soon
[21:34] <seele> 1) because there is more than just the label that is a problem with the work flow and 2) i dont know of a better word and i dont think the powers to be will accept a regression to Log Out
[21:35] <yuriy> seele: could you post a commment to that effect since you know about what's going on with that? and change to won't fix
[21:35] <seele> hmm.. ok..
[21:39] <Tm_M> hmm, I wonder if we can patch it to not ask things twice
[21:40] <seele> that was talked about back when 4.0 was released.  i dont remember why it was decided to stay the same
[21:41] <seele> i think the argument is that there is an option to turn off the confirmation, but it wasn't made default
[21:41] <Tm_M> also, can that menu be named as session?
[21:42] <Tm_M> maybe too technical
[21:42] <stdin> when the Application Launcher Menu is in use the plasma logout menu is needed
[21:43] <Tm_M> yes, that should be 'sensed'
[21:43] <Tm_M> perhaps
[21:47] <Tm_M> can that plasma menu be launched by some command? if application launcher menu just calls it directly
[21:47] <Tm_M> or so
[21:50] <seele> yuriy: i dont have a WONTFIX status option, should i use INVALID instead?
[21:52] <Tm_M> any sense in that idea?
[21:58] <DaSkReEcH> Makes sense to me
[21:59] <yuriy> seele: hmm i guess you have to be in bug control. i think won't fix would be better, i'll change the status
[22:00] <seele> ok
[22:43] <awen_> yuriy: while you are at it, can you mark bug 228568 as wishlist
[22:43] <santiago-ve> guys... big question here... i want to become in a ubuntu-member... but more like a kubuntu-member... is the process the same?~ or do i need other steps (others that wiki.kubuntu.com/Membership
[22:47] <awen_> santiago-ve: welcome :)
[22:48]  * awen_ is not a member, so isn't really sure of the process
[22:48] <yuriy> phew, done with bug backlog
[22:49] <awen_> yuriy: cool :) ... and thanks
[22:50] <yuriy> santiago-ve: same as on that page, except you need to come to a kubuntu meeting instead of a community council meeting, and you need to have something specific to kubuntu
[22:51] <yuriy> s/something/have done stuff/
[22:52] <santiago-ve> yuriy, besides some advocacy~ and having the whole company where i work using Kubuntu... nothing else >.<
[23:44] <Riddell> mhb: no problem, we don't want kubuntu as a reason for people failing exams
[23:45] <ryanakca> Riddell: I forget, are you a DD?
[23:46] <Riddell> ryanakca: nope
[23:47] <ryanakca> thanks anyways :)
[23:47] <DaSkReEcH> D&D ?
[23:48]  * ryanakca is trying to get a fixed version of kmplayer into Debian, but the people in #debian-qt-kde seem to be more preoccupied trying to figure out how to put a SUSE like logo on the titlebar of a window :)