[12:16] <BluesKaj> Hi folks
[16:29] <dscassel> Morning, BluesKaj
[16:29] <dscassel> Er, afternoon.
[16:29] <dscassel> It's Sunday. :P
[16:32] <BluesKaj> hi dscassel


[05:00] <darkxst> jbicha, gnome-shell http://pastebin.com/mxmu5LMH
[05:00] <darkxst> and mutter incase you missed it earlier http://pastebin.com/UEatwuvt
[07:42] <sgo11> hi, is that possible to download ubuntu gnome remix 13.04 beta now? if so, where is the download link? thanks.
[08:34] <darkxst> sgo11, not quite yet
[08:36] <sgo11> darkxst, ok. thanks for your reply.
[08:36] <darkxst> sgo11, you can build your own with this script, https://code.launchpad.net/~ubuntu-gnome-dev/+junk/iso-build-script/
[08:37] <sgo11> darkxst, got it. thanks.
[08:37] <darkxst> or install raring beta and follow the upgrade steps in https://wiki.ubuntu.com/UbuntuGNOME/ReleaseNotes/12.10
[08:39] <sgo11> ok. :)
[08:42] <darkxst> we should have daily images, at some point, now that things are official, but no idea how long they will take to get set up
[16:16] <gonyere> jbicha: I've read some conflicting things about 13.04 - is it going to have 3.6 or 3.8 included by default?
[16:19] <jbicha> gonyere: 13.04 will have 3.6, we updated games and calculator but almost everything else is 3.6
[16:19] <gonyere> k, is/will there be an easy way to get 3.8?
[16:21] <jbicha> https://launchpad.net/~gnome3-team/+archive/gnome3
[16:29] <gonyere> cool :) any thoughts on the current stability of 13.04 ? good, decent, awful?
[16:59] <jbicha> gonyere: I think 13.04 is more stable than 12.10 but there's 3 caveats:
[17:00] <jbicha> 1. It's still Alpha 2. Tomorrow is Feature Freeze which means there's a tendency for developers to push not-quite-finished stuff so that they don't have to wait 6 more months
[17:01] <jbicha> 3. There's a proposal to turn Raring into a daily release and currently there's little protection against one bad upload breaking things
[17:02] <jbicha> not too big of a deal if you're the kind of a person that already runs Ubuntu alphas but otherwise it's unclear yet
[22:43] <darkxst> jbicha, is there some reason why we dont have an updated GOA in the PPA?
[22:46] <jbicha> darkxst: I don't think so, I'm guessing we want it staging though
[22:47] <darkxst> jbicha, ok, I will update it


[05:04] <|Giskard|> hi :)
[05:05] <|Giskard|> somebody here?
[05:05] <|Giskard|> hallo?
[07:47] <kraut> moin
[13:55] <kwwii> hi all
[13:57] <pitti> hi
[13:57] <seb128> hey pitti
[13:58] <Hobbsee> argh, it's a scary people meeting!
[13:58] <Keybuk> scary people?
[13:58]  * Hobbsee points at Keybuk. yes.
[13:58] <Hobbsee> don't you count as scary?
[13:58] <kwwii> Hobbsee: stop being sKary
[13:58]  * mvo waves
[13:59]  * Hobbsee trouts kwwii
[13:59] <kwwii> *ouch*
[13:59]  * Mithrandir gives Hobbsee some fresh salmon
[14:00] <Hobbsee> kwwii: would now be an appropriate tiem to mention that i'm not running kubuntu?
[14:00]  * Hobbsee smacks Keybuk with the salmon, then
[14:00] <kwwii> Hobbsee: don't tell me, tell Riddell
[14:00]  * seb128 hugs Hobbsee
[14:00] <Hobbsee> (thanks. that's useful)
[14:00]  * Hobbsee hugs seb128
[14:00] <seb128> ;-)
[14:00] <Mithrandir> Hobbsee: welcome to the dark^Wbrown side.
[14:00] <Hobbsee> Mithrandir: it's not brown anymore :)
[14:00] <kwwii> lol, black and orange!
[14:00] <Hobbsee> Mithrandir: bar the panels, looks remarkably like kubuntu.
[14:01] <Hobbsee> nah.  bluey-purple.  :)
[14:01] <Mithrandir> orangish, then
[14:01] <Keybuk> Riddell: ping
[14:01] <Mithrandir> kwwii: incidentially, the default openbox theme is quite a good match for our default look.
[14:02] <kwwii> Mithrandir: cool, i will check it out
[14:03] <MacSlow> Greetings everybody
[14:03] <Keybuk> Welcome back everybody
[14:03] <Keybuk> How's everyone settling back into their own timezones?
[14:03] <pitti> ~ sweet ~
[14:03]  * kwwii actually slept through the whole night
[14:04] <{ted}> Pretty good.
[14:04] <pitti> surprisingly easy, due to not being able to sleep on planes I could actually sleep Sunda ynight
[14:04] <{ted}> I had the easy one though.
[14:04] <MacSlow> Keybuk, sunday and monday felt a bit odd
[14:04]  * mvo is mostly good as well
[14:04] <Keybuk> Better than me then!  I slept most of Sunday daytime and thus am still vaguely unsure what day it is
[14:04] <MacSlow> but since tuesday everything feels solid again
[14:05] <pitti> {ted}: how have your first 'remote' days been? grinded through all the NewStaffTasks?
[14:05] <seb128> I was sleepy on sunday afternoon and I'm back on local time since monday ;-)
[14:05] <Keybuk> First thing on the agenda, Welcome Aboard to {ted}!
[14:06] <MacSlow> {ted}, official greetings!
[14:06] <{ted}> pitti: I've done a bunch of them, I need to ensure that I've done them all.
[14:06] <pitti> {ted}: can you consider using [ted] instead, for no-shift-love? :)
[14:06] <{ted}> I'm pretty thrilled that my simple package finally built.
[14:06] <mvo> {ted}: welcome!
[14:06] <{ted}> Hmm, yeah, I thought for some reason the nickserv wouldnt' let me have that one.
[14:06] <MacSlow> {ted}, took me a few days to make sure I did all needed pieces
[14:06] <seb128> {ted}: could you use a nickname without special chat at the start? it hurts my hand to use the modifier
[14:06]  * ogra would guess "ted" is taken
[14:07] <seb128> [ also needs a modifier on french layout :(
[14:07] <MacSlow> indeed... AltGr-7 is ugly
[14:07] <{ted}> Hmm, I might have to come up with something clever ;)
[14:07] <MacSlow> seb128, we should switch to US-layout
[14:07] <kwwii> he is just making sure you really want to chat with him ;-)
[14:07] <seb128> MacSlow: I like to give non-english testing to Ubuntu because we have non-english users apparently
[14:07] <MacSlow> {ted}, what about TheTed?
[14:07] <pitti> MacSlow: US layout is *so* much better for programming, vim, etc.
[14:07] <pitti> tgould?
[14:08] <MacSlow> pitti, hell yeah
[14:08] <pitti> anyway, OT for meeting
[14:08] <Keybuk> And since {ted} has joined, and is in the balmy US/Pacific timezone, this brings us onto the second agenda item ... the meeting time
[14:08] <Keybuk> thanks for all not shouting at the sudden move of an hour
[14:08] <MacSlow> Keybuk, afternoon for me so... no issues there
[14:08] <Keybuk> {ted}: are you happy with this time?  or would you prefer a little later in the day?
[14:08] <Keybuk> (obviously we now have to balance the fact the team spans nine timezones)
[14:09] <MacSlow> {ted}, must be just after getting up for you over there, right?
[14:09] <{ted}> This is good for me, it's when I normally wake up.
[14:09] <MacSlow> oh... I though all except for Ted are located in Europe
[14:09] <{ted}> It just means that i don't get to shower first.
[14:09] <{ted}> But, you guys can't smell me through IRC.
[14:09] <pitti> MacSlow: right, nothing in between the TZ span edges :)
[14:10] <pitti> {ted}: apt-get install irc-smell-plugin is not until 8.10
[14:10] <{ted}> pitti: Heh, the way things are going, I wouldn't be surprised.
[14:10] <MacSlow> pitti, some specs just should not be considered at all
[14:11] <{ted}> But, in IRC, it'll all be encoded into your nick...  just like state.
[14:11] <pitti> so, 1400 UTC then?
[14:11] <Keybuk> any objections to 1400 UTC? :p
[14:11] <MacSlow> nope
[14:11] <Hobbsee> i object!  :P
[14:11]  * Hobbsee shuts up again
[14:12] <pitti> Hobbsee: you are awake 24 hours a day, what do you care? :)
[14:12] <MacSlow> Hobbsee, can you be bribed with a cookie?
[14:12] <{ted}> nope
[14:12] <Hobbsee> pitti: not quite :)
[14:12] <Hobbsee> MacSlow: depends how much chocolate it contains.
[14:12] <Keybuk> mvo, kwwii, Riddell?
[14:12] <MacSlow> hm... 34%
[14:12] <pitti> (OT: these American cookies were sooooo yummy)
[14:12] <mvo> that is fine with me
[14:12]  * MacSlow misses the muffins
[14:12] <ogra> s/yummy/heavy/
[14:13] <Keybuk> ok, next agenda item
[14:13] <Keybuk> Spec Approval
[14:13]  * MacSlow is still working on them
[14:13] <pitti> when can a spec go from review to pendingreview?
[14:13] <pitti> erm, pendingapproval?
[14:13] <pitti> when we got one or two positive feedbacks from our fellows?
[14:13] <Keybuk> pitti: in theory, when a "reviewer" reads it
[14:14] <Keybuk> in practice, I'll read anything >= review
[14:14] <Keybuk> spec approval basically involves nagging me all of next week to read your specs
[14:14] <pitti> after Sevilla we used peer review for that
[14:14] <Keybuk> please feel free to message me on IRC with a list of those you want me to read
[14:14] <Keybuk> and keep on doing it until I do it :)
[14:14] <pitti> which worked very well IME
[14:14] <MacSlow> Keybuk, I thought we still have time  until 22nd to bring them into shape before review/approval
[14:14] <Keybuk> that's another good option
[14:14] <Keybuk> MacSlow: indeed, which is Thursday next week
[14:15] <pitti> especially feedback from upstream is helpful
[14:15] <MacSlow> Keybuk, I should have done them before the weekend
[14:15] <Keybuk> in practice, if you're mostly at review by Thursday, I'll be more than happy
[14:15] <pitti> MacSlow: NB, bring to state review != get them approved
[14:15] <MacSlow> Keybuk, the gdm dude, Jon, is pretty fast with replies... David Reveman is certainly slower with replies
[14:16] <MacSlow> pitti, indeed... I was oversimplifiying
[14:16] <MacSlow> the process
[14:16] <Keybuk> please don't let me block you - nag and shout at me if you need me to review something
[14:17] <{ted}> MacSlow: Did you ask the GDM guy about some of the power management stuff we were talking about with the logout?  Not sure that it's going to be Hardy, but I was curious what he's thinking there.
[14:17] <MacSlow> {ted}, not yet
[14:17] <MacSlow> but on my list
[14:17] <Keybuk> does anyone have any questions about the spec process?
[14:18] <pitti> I would like to defer filling out the release notes part until a beta is available
[14:18] <MacSlow> I am a bit unsure about the difference between "Design" and "Implementation"
[14:18] <Keybuk> MacSlow: sometimes it's often the same bit
[14:18] <MacSlow> ok
[14:19] <pitti> ^ I usually describe the high-level "what?" bits in design, and the actual implementation details ("how?") in implementation
[14:19] <pitti> but often, the implementation is clear from reading the design, so I think it can sometimes be skipped
[14:19] <MacSlow> pitti, changing that a bit as things go on is possible I would guess... as long as only one part "Release Notes" changes, or?
[14:20] <Keybuk> specs can change as much as you like ;)
[14:20] <Keybuk> cjwatson is a great fan of rewriting a spec after implementation so that it actually matches
[14:20] <MacSlow> well :)
[14:20] <Keybuk> since it can then serve as documentation
[14:20] <MacSlow> ah... ok... I'll remember that one
[14:21] <Keybuk> ok
[14:21] <Keybuk> pitti: PolicyKit adoption strategy?
[14:21] <pitti> right; I'm a bit nervous about this
[14:21] <Riddell> MacSlow: often my specs don't have a design at all (since if it's a port from ubuntu it has already been designed)
[14:21] <pitti> since it's basically an on/off thing (main or not at all)
[14:22] <pitti> so my current gut feeling is to do enable it in hal and put it into main, but not necessarily use it for all the things in the admin menu
[14:22] <MacSlow> Riddell, you're lucky then
[14:22] <pitti> but only for some small applications and new usage cases like g-p-m and network-manager access control for the current console, etc.
[14:23] <pitti> for hardy I'd like to keep using gksu for gnome-system-tools, for example
[14:23] <Keybuk> that sounds very reasonable
[14:23] <pitti> at least until we disable ptrace() by default in the kernel
[14:23] <seb128> I discussed that with pitti during allhand and I'm happy with doing it this way
[14:23] <pitti> it's not so much my inconfidence in the PK implementation itself
[14:24] <pitti> but more the fact that then all the admin UI will run with just user privileges
[14:24] <mvo> what about the package tools (synaptic and friends)?
[14:24] <pitti> and thus there is no security boundary any more to other user processes
[14:24] <pitti> mvo: same argument
[14:24] <mvo> gksu then
[14:24] <Keybuk> what's the ptrace issue?
[14:24] <pitti> I wouldn't like firefox plugins to install packages without notice
[14:24] <mvo> we have no tools that install without a question
[14:25] <pitti> Keybuk: e. g. if a firefox plugin ptraces users-admin or the synaptic frontend, it can use the PK privileges granted to users-admin
[14:25] <pitti> if those programs run as root, user processes can't ptrace them
[14:25] <pitti> I'm aware that you can still use Xevent injection, etc., but it's much harder
[14:25] <Keybuk> because it can steal the PK auth token?
[14:25] <pitti> whereas attaching gdb and calling system() is a trivial exploit
[14:25] <pitti> Keybuk: no, not steal
[14:26] <pitti> Keybuk: just execute arbitrary code in the process context of the target app
[14:26] <Keybuk> ahh
[14:26] <Keybuk> what did davidz have to say about that?
[14:26] <pitti> that's why I prefer having admin GUIs run as root
[14:26] <pitti> (a common misconception is that this is a bad thing per se)
[14:26] <pitti> Keybuk: it just came to my mind after we met, unfortunately
[14:26] <pitti> I'll ask him via email, but I had to catch up with too much so far
[14:26] <Keybuk> it'd be worth getting some thoughts on that
[14:27] <Riddell> pitti: doesn't policykit have a way to restrict which apps can run something?
[14:27] <pitti> so I think that using PK for things that already run as user, like g-p-m or the netapplet tool, PK is great
[14:27] <pitti> Riddell: sure it has, it assigns privileges based on process ID and executable path
[14:27] <pitti> Riddell: the point is, with ptrace() that does not help you *at all*
[14:27] <pitti> Kees and I talked about this, and he also would like to disable ptrace() by default
[14:28] <pitti> that's a slight inconvenience for developers, since they have to enable it to use gdb, strace, etc.
[14:28] <Keybuk> sadly I'm not helping that battle
[14:28] <pitti> but it's well worth it, IMHO
[14:28] <Keybuk> since Upstart *uses* ptrace
[14:28] <pitti> Keybuk: upstart == root, isn't it?
[14:28] <Keybuk> right
[14:28] <pitti> (it should only be disabled for normal users)
[14:28] <Keybuk> certainly user ptrace should be off by default
[14:28] <pitti> no reason to disable it for root
[14:28] <Keybuk> there should be a "I'm a developer" switch that enables ptrace and disables apport :)
[14:29] <pitti> something like that, yeah
[14:29] <seb128> and change the yelp icon to a gnome-terminal one
[14:29] <Keybuk> seb128: ?
[14:29] <mvo> devel mode
[14:29] <seb128> Keybuk: the icons you have on the default panel, I expect developer to want a command line rather than yelp there
[14:30] <pitti> once we have that, I'm fine with using PK for everything, since then it is equivalent protection like our current gksu (which is also susceptible to X event injection)
[14:30] <pitti> seb128: heh :)
[14:30] <pitti> so, any objection to this approach? we'll get PK for things that make good use of it, but continue to use gksudo for the main set of admin GUIs
[14:30] <Keybuk> seb128: if only yelp did devhelp stuff ;)
[14:30] <Keybuk> (one of my private annoyances)
[14:31]  * seb128 hugs pitti, looks a good approc
[14:31] <Keybuk> pitti: what kind of timeline can we disable ptrace for users?
[14:31] <pitti> then we can at least drop libpam-foreground and the nasty hacks in g-v-m, g-p-m, nm-applet, etc. to only work on the currently active session
[14:31] <Keybuk> pitti: absolutely no objection; it's better than pam-foreground so should immediately replace that
[14:31] <pitti> Keybuk: I don't know
[14:31]  * pitti makes a note to mail kernel team and Kees
[14:31] <pitti> the more interesting question is probably how to enable it again
[14:31] <pitti> disabling it is probably trivial
[14:32] <pitti> it would become a sysctl, but that might not be the most obvious interface
[14:32] <pitti> so we need to build something on top of it
[14:32] <pitti> (maybe patch strace and gdb to give an explanation?)
[14:32] <Keybuk> echo 1 > /proc/sys/kernel/root-me-root-me-root-me
[14:33] <Keybuk> ptrace has a CAP now, doesn't it?
[14:33] <pitti> "please uncomment kernel.user_ptrace in /etc/sysctl.conf" or so
[14:33] <pitti> Keybuk: I think it always had it
[14:33] <pitti> CAP_SYS_PTRACE
[14:33] <pitti> oh, sorry
[14:33] <pitti> that's only to trace processes which do not belong to you
[14:35] <pitti> a sysctl and useful explanation errors in strace and gdb seems like a reasonable start?
[14:35] <Keybuk> yup, very
[14:35] <Keybuk>         if (((current->uid != task->euid) ||
[14:35] <Keybuk>              (current->uid != task->suid) ||
[14:35] <Keybuk>              (current->uid != task->uid) ||
[14:35] <Keybuk>              (current->gid != task->egid) ||
[14:35] <Keybuk>              (current->gid != task->sgid) ||
[14:35] <Keybuk>              (current->gid != task->gid)) && !capable(CAP_SYS_PTRACE))
[14:35] <Keybuk>                 return -EPERM;
[14:35] <pitti> ACTION: pitti to mail kees and kernel team about disabling ptrace and re-enabling interface
[14:35] <pitti> (argh, I can't do that, can I)
[14:35] <Keybuk> can't do which?
[14:36] <Keybuk> oh, I gave up with mootbot after about the second meeting
[14:36]  * pitti adds it to his personal TODO list
[14:36] <seb128> pitti: is there any bot set for the meeting?
[14:36] <pitti> Keybuk: ACTION:
[14:36] <pitti> nevermind
[14:36] <Keybuk> the fact only the chair can do actions means I have to see, copy and paste them anyway
[14:36] <Keybuk> so s/mootbot/tomboy/ :)
[14:36] <siretart> sounds easy to fix, though
[14:36] <pitti> so, I'm done with the topic, unless someone else has questions?
[14:37] <Keybuk> ok, next topic then
[14:37] <Keybuk> Patches
[14:37] <Keybuk> send your patches upstream and to Debian whenever you can
[14:37] <Keybuk> :-)
[14:37] <pitti> ++
[14:37] <Keybuk> jcastro can help you find your upstream, and find out from them how they want patches delivered and at what threshold
[14:38] <Keybuk> (this is going to be the topic of the next six months)
[14:38] <Keybuk> {ted}: well done for stepping up to deal with g-p-m so quickly!
[14:38] <pitti> now, at merge time, this is an excellent time to do so, when we clean up our patches and adopt them to the current version
[14:38] <Keybuk> exactly
[14:38] <seb128> we will start using tags for desktop packages soon, I just need to mail the list to settle the tags list etc
[14:38] <Keybuk> this is something we're not terrible at anyway; but we can always be brilliant
[14:38] <seb128> like adding bugzilla and launchpad bug numbers and a description in the patches
[14:39] <MacSlow> Keybuk, I will see to get as much as possible from my gutsy-work to Vincent
[14:39] <{ted}> tags?
[14:39] <seb128> and we will not accepted easily patches which are not sent upstream first
[14:39] <pitti> seb128: ah, I thought you meant https://wiki.ubuntu.com/Bugs/Debian/Usertagging
[14:39] <seb128> {ted}: comments on the top of the patch
[14:39] <MacSlow> Keybuk, I talked with Vincent already at UDS and know how he expects the stuff
[14:39] <seb128> pitti: what we discussed in Sevilla
[14:39] <pitti> Fedora's policy is that they do not apply and upload a patch before it is reported upstream
[14:40] <pitti> quite rigid, but effective apparently
[14:40] <seb128> they don't respect it apparently
[14:40] <Keybuk> pitti: Fedora are upstream for almost everything in their distirbution
[14:40] <Keybuk> and the things that they aren't, they certainly bloody well don't do that
[14:40] <seb128> because I browse their viewcvs quite often and they do have some patches which are not upstream there
[14:40] <Keybuk> look at the number of patches to things like sysvinit which they have
[14:40] <Keybuk> (Debian is upstream for sysvinit)
[14:40] <pitti> well, that's what Lennart told me anyway
[14:40] <pitti> (and he does)
[14:41] <seb128> we will try to do the same for desktop packages
[14:41] <pitti> anyway, I just think it's an idea to be considered
[14:41] <seb128> would probably be nice to not limit to desktop but I can't speak for other teams ;-)
[14:41] <Keybuk> amusingly
[14:41] <Keybuk> Fedora has patches in their RPMs for packages that they are upstream for
[14:41] <jcastro> seb128: do you have it written down someplace what the desktop patch policy for gnome will be?
[14:41] <pitti> heh
[14:42] <pitti> "Bow to seb128, buy him a beer, give him a hug"
[14:42] <seb128> jcastro: no, as said I need to mail the list, it's on my TODO for this week to discuss it, then I'll write it on the wiki and let you know
[14:42] <Keybuk> but our goal here isn't to pick fault in other distributions ability to send patches back
[14:42] <Keybuk> but to make sure nobody can pick fault with us :)
[14:42] <Keybuk> I already think we do a better job than anybody else
[14:42]  * mvo is very happy about this policy!
[14:42] <Keybuk> but we can always do better
[14:42] <seb128> Keybuk: depending of the "we"
[14:43] <seb128> I think it's less than optimal in MOTU land
[14:43] <pitti> *nod*
[14:43] <Keybuk> that's possibly true
[14:43] <pitti> this should probably be incorporated into the MOTU training process
[14:43] <seb128> anyway that's OT for this meeting probably
[14:43] <Keybuk> that's the end of my list of topics
[14:43] <Keybuk> any other business?
[14:44] <Hobbsee> pitti: it already is, community side.
[14:44] <pitti> Hobbsee: it hasn't always been that way, though
[14:44] <pitti> but good to know that it is like that now
[14:45] <Hobbsee> pitti: has been emphasised in the las tcouple of releases, but perhaps not enough, making it mandatory, etc.
[14:45] <Riddell> have we considered asking QA for help with New queue and archive admin?
[14:46]  * MacSlow forgot lunch today
[14:46] <Riddell> since New queue is essentially QA
[14:46] <seb128> it should not be
[14:46] <seb128> what is uploaded should have been QA reviewed first
[14:46] <dholbach> we have a lot of MOTUs feeding back patches and in sponsoring bugs it is requested a lot, though the degree of feeding of course back varies
[14:47] <Riddell> seb128: what should it be then?
[14:47] <pitti> isn't that a classic archive-admin task?
[14:47] <Hobbsee>  Riddell motu's, etc, should be doing the job of qa
[14:47] <Hobbsee> as in, checking it.
[14:47] <Riddell> the emphasis is different from revu et al, but it's essentially just another check
[14:48] <Hobbsee> there shouldnt *be* anything in that queue that isnt fine to upload.  although i'm aware that it's not the case.
[14:48] <pitti> Hobbsee: it's not that bad, though
[14:48] <seb128> well, I would not trust all the QA people to accept packages in the archive
[14:48] <pitti> most rejections are due to licensing issues, not due to bad packaging
[14:48] <pitti> (IME anyway)
[14:48] <Keybuk> (no other business? => end of meeting, to let you continue the discussion)
[14:48] <seb128> Keybuk: thanks
[14:48] <pitti> thanks everyone
[14:48] <Keybuk> if you haven't already done so, make sure you get your performance review feedback in by tomorrow (for canonical staff except MacSlow and {ted})
[14:49] <mvo> thanks
[14:49] <Hobbsee> pitti: true, but motu's should be doing licencing too, no?
[14:49] <Riddell> seb128: indeed, I'd be unsure if there's enough packaging experience
[14:49] <pitti> Hobbsee: they should, yes
[14:49]  * Hobbsee should be in bed.  night all.
[14:49] <seb128> Riddell: not only packaging, I'm not sure QA people know or care about licenses
[14:50] <seb128> Hobbsee: 'night
[14:50] <Riddell> I include caring about licence in packaging expertese :)
[14:50] <pitti> Riddell: btw, seb128 and I thought a "do three source NEWs a day" approach for the three of us would work; WDYT?
[14:50] <seb128> pitti: works for me
[14:50] <pitti> (until the current backlog is finished)
[14:50] <seb128> should we claim the packages we review somewhere?
[14:50] <pitti> then, with so many archive days we shouldn't get a big backlog anytime soon
[14:51] <Riddell> that would take about 6 weeks to clear the backlog
[14:51] <pitti> Riddell: no, it's only 30ish Ubuntu source NEWs
[14:51] <seb128> Riddell: there is not so many source NEW, that should rather be a week
[14:51] <Riddell> right, does seem like a good idea
[14:51] <MacSlow> he's taking the shower now I bet
[14:52] <pitti> ok, seems we are done; thanks again everyone
[14:52] <seb128> thanks pitti
[14:53]  * MacSlow goes for late lunch now


[22:24] <bcurtiswx> #help
[22:25] <bcurtiswx> meeting help
[22:25] <meeting> bcurtiswx: (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
[22:25] <bcurtiswx> meeting help #startmeeting
[22:25] <meeting> bcurtiswx: Error: There is no command "#startmeeting".
[22:25] <bcurtiswx> meeting help startmeeting
[22:25] <meeting> bcurtiswx: Error: There is no command "startmeeting".
[22:27] <bcurtiswx> #startmeeting
[22:27] <meeting> Meeting started Mon Oct 15 22:27:47 2012 UTC. The chair is bcurtiswx. Information about MeetBot at http://wiki.debian.org/MeetBot.
[22:27] <meeting> Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting
[22:28] <bcurtiswx> #topic Testing meeting bot
[22:28] <bcurtiswx> #idea seems to work OK
[22:28] <bcurtiswx> #action use meeting bot
[22:29] <bcurtiswx> #endmeeting
[22:29] <meeting> Meeting ended Mon Oct 15 22:28:59 2012 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4)
[22:29] <meeting> Minutes: http://meeting.sugarlabs.org/ubuntu-us-dc/meetings/2012-10-15T22:27:47.html
[22:29] <meeting> Log:     http://meeting.sugarlabs.org/ubuntu-us-dc/meetings/2012-10-15T22:27:47
[23:00] <bcurtiswx> OK, Who is present for meeting?
[23:01] <kjcole> Shhhhhowtime!
[23:01] <bcurtiswx> #startmeeting
[23:01] <meeting> Meeting started Mon Oct 15 23:01:53 2012 UTC. The chair is bcurtiswx. Information about MeetBot at http://wiki.debian.org/MeetBot.
[23:01] <meeting> Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting
[23:02] <bcurtiswx> #topic Attendance
[23:02] <kjcole> Shhhowtime!
[23:02]  * kjcole is here
[23:02]  * bcurtiswx is here
[23:02]  * kjcole is perusing the email regarding topics of discussion
[23:03] <bcurtiswx> OK, two in attendance.
[23:04] <bcurtiswx> #idea Move meeting to tuesday to gauge availability
[23:04] <bcurtiswx> We will take a vote, to pass it must receive 2 out of 2 votes.
[23:05] <bcurtiswx> Voting FOR postponing until tomorrow Tuesday
[23:05]  * bcurtiswx raises hand
[23:05] <kjcole> #agreed
[23:05]  * kjcole raises hand
[23:05] <bcurtiswx> Vote has passed
[23:06] <bcurtiswx> #help Meeting postponed until tomorrow Tuesday
[23:06] <Sugi> what??
[23:06] <bcurtiswx> Sugi, it was just KJCole and I and we already voted to postpone
[23:06] <bcurtiswx> #endmeeting
[23:06] <meeting> Meeting ended Mon Oct 15 23:06:46 2012 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4)
[23:06] <meeting> Minutes: http://meeting.sugarlabs.org/ubuntu-us-dc/meetings/2012-10-15T23:01:53.html
[23:06] <meeting> Log:     http://meeting.sugarlabs.org/ubuntu-us-dc/meetings/2012-10-15T23:01:53
[23:07] <bcurtiswx> kjcole, Sugi, I will get e-mail out. See ya'll tomorrow
[23:07] <kjcole> So... Same bat time tomorrow, presumably.
[23:07] <bcurtiswx> kjcole, correct
[23:08] <kjcole> Hokay.
[23:08] <Sugi> ohhk
[23:08] <kjcole> Though unlike Sunday mornings, we did get (briefly) up to 3. ;-)
[23:08] <bcurtiswx> lol
[23:09] <Sugi> haha
[23:09] <Sugi> I always preferred weekdays. :)
[23:10] <kjcole> Sugi OK good to know.
[23:15] <bcurtiswx> OK, the wife needs to do some stats HW. Giving her the dual monitor setup :) see ya'll tomorrow
[23:16] <kjcole> See ya.


[00:00] <zetheroo> auto browse?
[00:00] <seb128>  /apps/nautilus/preferences/exit_with_last_window
[00:00] <seb128> in gconf-editor
[00:00] <zetheroo> Open nautilus on removeable media insert.
[00:00] <zetheroo> ok
[00:01] <zetheroo> ah ok
[00:01] <zetheroo> it's set to true atm
[00:01] <seb128> right
[00:01] <seb128> it's false in lucid
[00:01] <zetheroo> cool
[00:01] <seb128> which is what you want for your case
[00:02] <zetheroo> so i should be able to turn desktop off again and have nautilus running nevertheless
[00:02] <seb128> yes
[00:02] <seb128> that's what the key is about
[00:02] <seb128> for those like you who don't want their desktop to be useful ;-)
[00:02] <zetheroo> haha
[00:02] <zetheroo> I use a screenlet for that ;)
[00:03] <zetheroo> all my "Desktop" folders and files are accessible from a widget-like screenlet ...
[00:03] <zetheroo> hmmm
[00:03] <zetheroo> maybe I have to reboot to make that change take effect!?
[00:04] <seb128> you have to run nautilus
[00:04] <seb128> it's probably not running right now
[00:04] <mtx_init> im trying to sign the conduct, but when I do gpg --fingerprint, I get nothing, any ideas?
[00:05] <zetheroo> oh so I still have to have another nautilus window open ...
[00:05] <zetheroo> hmm ... I thought that option I changed meant I didn't have to have a browser window open all the time ..
[00:06] <persia> mtx_init: This isn't the right channel, but https://help.ubuntu.com/community/GnuPrivacyGuardHowto probably has the documentation you need.  Ask in #ubuntu if you get stuck.
[00:07] <seb128> zetheroo, nautilus is being run on session start and did exit because you didn't have the key set
[00:07] <mtx_init> I was told to ask here, but ok
[00:07] <seb128> zetheroo, it will not exit next login
[00:07] <persia> mtx_init: By whom?
[00:07] <persia> mtx_init: And where?
[00:07] <mtx_init> bdmurray:
[00:07] <seb128> zetheroo, you can run it manually too for this time though
[00:07] <zetheroo> ah i see
[00:07] <zetheroo> ok
[00:07] <zetheroo> thanks a million
[00:07] <seb128> np
[00:07] <hggdh> mtx_init: OK
[00:07] <mtx_init> But il ask in #ubuntu, thanks for your help
[00:07] <ddecator> mtx_init, i can find you the wiki page a sec...
[00:08] <hggdh> mtx_init: did you create a GPG key for you?
[00:08] <persia> mtx_init: Well, given some context, here might not be wrong, but really the wiki page I linked should contain wverything you need.
[00:09] <mtx_init> well I was just following the instructions on the code of conduct page.   Which seemed to omply the fingerprint was the first step
[00:09] <bdmurray> He is trying to sign the CoC to join the Bug Squad so it seemed reasonable to me that someone here could help.
[00:09] <hggdh> yes
[00:09] <hggdh> mtx_init: again: do you have a GPG key?
[00:09] <mtx_init> nope, but im reading the linked page now
[00:10] <Hillshum> If lucid hangs on me as it logs in, what package should I report a bug against?
[00:10] <persia> Hillshum: That's tricky: you'd want to try to identify where it hangs.
[00:10] <Hillshum> persia: How might I go about that?
[00:11] <persia> Hillshum: After an unsuccessful boot, try booting a liveCD and see if you can mount the unsuccessful boot and recover anything from /var/log/syslog or similar.
[00:11] <persia> bdmurray: Indeed: it the point of signing the CoC is to join bugsquad, this is the right place :)
[00:16] <mtx_init> It claims it cannot import the OpenPGP key
[00:18] <ddecator> mtx_init, at what step?
[00:18] <mtx_init> after I copy the fingerprint and add it in
[00:18] <mtx_init> to the website
[00:19] <hggdh> mtx_init: did you send your public key to the Ubuntu keyserver?
[00:20] <mtx_init> i guess not.
[00:20] <hggdh> mtx_init: heh. So do I ;-)
[00:21] <mtx_init> No offence but this seems overly burdensome and the documentation is severally fragmented.
[00:22] <hggdh> perhaps we should clarify it -- I am starting to agree
[00:22] <crimsun> plars: RE: #528524, speaker-test accepts an -f parameter. That should help narrow the scope of affected apps.
[00:23] <crimsun> plars: (sorry, would have responded sooner, but $dayjob blocks access)
[00:23] <ddecator> hggdh, maybe have basic instructions included on the bugsquad wiki where it says that you have to sign the CoC? that way people won't have to hunt down the complicated directions
[00:24] <LimCore> or make a screencast
[00:24] <hggdh> ddecator: this is one place, yes. But the best would be at LP itself
[00:24] <ddecator> hggdh, true
[00:25] <mtx_init> thanks guys for your help.
[00:25] <ddecator> mtx_init, no problem =)
[00:25] <ddecator> we're always happy to help anyone interested in helping with bugs ;)
[00:29] <Hillshum> persia: syslog shows  nothing I can recognize
[00:29] <hggdh> LimCore: I am be an exception, but I never watch screencasts ;-)
[00:29] <ddecator> hm, speaking of bugs, anyone willing to give me information on how to handle a "failed to install" bug? (such as bug 529136 )
[00:29] <ubot4> Launchpad bug 529136 in firefox (Ubuntu) "package firefox 3.6.2~hg20100226r33622+nobinonly-0ubuntu1~umd1~karmic failed to install/upgrade: subprocess installed post-installation script returned error exit status 2 (affects: 1)" [Undecided,New] https://launchpad.net/bugs/529136
[00:30] <crimsun> plars: another test (for GSt) would be: gst-launch playbin uri=file:////usr/share/sounds/ubuntu/stereo/service-login.ogg
[00:31] <LimCore> interesting talk at #ubuntu-hardened
[00:31] <LimCore> is it possible to own your ubuntu desktop, even if you try really hard to protect self
[00:32] <LimCore> so far I would say that yes
[00:32] <LimCore> if you will find a window where an unpatched exploit in common app exists, even extra security might not help
[00:33] <crimsun> that's trivial, really. You have physical access to your machine, at which point everything is game over.
[00:34] <LimCore> hmm? no phisical access
[00:35] <mtx_init> Is it possible to delete submitted bugs?
[00:35] <crimsun> no, but you can mark the status Invalid
[00:35] <mtx_init> But they will see be in public view?
[00:36] <crimsun> yes, unless you mark [them] private
[00:36] <mtx_init> can you do that after I have submited them.  because they were real bugs but nobody responsed to them, making me look like an idiot.
[00:36] <crimsun> hmm? Which bugs?
[00:37] <mtx_init> sent you a pm
[00:37] <ddecator> mtx_init, just because nobody responds doesn't mean you did something wrong. unfortunately, there are way more reports than we can handle, so some of the slip by
[00:38] <mtx_init> well can I get rid of it then?
[00:38] <mtx_init> Because they make the submitter look like an incompetent.
[00:40] <plars> crimsun: I'll try that, thanks
[00:40] <ddecator> you could mark your own bugs as invalid, but if they are real bugs then we would like it if they stayed open so we can hopefully look at them at some point. and trust us, people from all different specialties submit bugs, and we never see any of them as incompetent =)
[00:40] <crimsun> mtx_init: your comment implies that the symptom is caused by a dependency, so I could mark it invalid
[00:40] <mtx_init> well I just dont want then tied to my name anymore
[00:41] <mtx_init> It was a mistake to submit it
[00:41] <crimsun> more useful, I could triage it to affect the other dependency
[00:41] <crimsun> mtx_init: no one's perfect
[00:41] <ddecator> mtx_init, if you're unsure, then submitting is better than leaving a bug unknown, so never hesitate
[00:41] <mtx_init> crimsun: yeah that excuse doesnt get people jobs.
[00:42] <LimCore> hggdh: I can probalby eventually take over your box
[00:42] <jcastro> I file dumb bugs all the time!
[00:42] <crimsun> mtx_init: I don't know of an instance where it has prevented a competent person from being hired.
[00:42] <BUGabundo> I don't even understand half the bugs I file .S
[00:43] <LimCore> hggdh: we have a way to stop many vectors of such an attack, and all what is needed is some information for the end users to use such countermesure. Does it sound like something that could be swiftly done?for Ubuntu? All actuall software is in place, only some GUI/info/docs
[00:43] <mtx_init> crimsun: the internet is filled with people who have been denied jobs due to their foss submissions
[00:43] <mtx_init> ive read tons of stories on it
[00:43] <mtx_init> over the years
[00:43] <crimsun> mtx_init: FUD?
[00:43] <mtx_init> I dont know what that means
[00:44] <crimsun> would you really want to work for a place that would deny you employment based on FOSS submissions?
[00:44] <mtx_init> I live in ny, thats how the games played here
[00:44] <mtx_init> we arent as lax as the west coast.
[00:44] <hggdh> LimCore: what are you talking about?
[00:44] <ddecator> i've never heard of that in chicago though...
[00:45] <LimCore> hggdh: attacke based on getting an exploited desktop application to emulate for example gsudo window or something - can be stoped by making sure that instead of trusing gsudo users would do alt+ctrl+f1 and alt+sysrq+k
[00:45] <mtx_init> Ny firms are very high strung.  Ive seen people fired for making common spelling mistakes in comments.
[00:46] <hggdh> LimCore: and how would one get an exploited appl in?
[00:46] <crimsun> mtx_init: you're free to mark that bug private and invalid
[00:46] <LimCore> hggdh: just wait untill some arbitrary code execution is discovered. Happened before, will eventually happen again. In example in some jpeg viewer or some lib to process XML or stuff
[00:47] <persia> Can we get back to bug discussions?
[00:47] <ddecator> yes please...
[00:54] <Hillshum> Can I use apport-collect offline somehow?
[00:55] <persia> Hillshum: Not trivially, no.  You can use apport-retrace offline though.
[00:56] <crimsun> hmm? Doesn't --save (or apport-cli) accomplish that??
[00:56] <Hillshum> How should I gather information for my bug then? The system in question won't let me log in to gnome
[00:57] <persia> crimsun: Oh, excellent point.  apport-cli is the tool to use for this (apport-collect requires access to LP)
[01:15] <Hillshum> So how do I get apport to upload a given apport file to a given bug?
[03:46] <nigelb> cjohnston: you around?
[03:58] <cjohnston> ?
[03:58] <nigelb> cjohnston: got lucid working?
[03:59] <cjohnston> ya
[03:59] <nigelb> cjohnston: can you test something for me? (i can close a bug if it works)
[03:59] <cjohnston> k
[04:00] <nigelb> cjohnston: open rhythmbox and add this as podcast http://noagenda.podshow.com/feed
[04:00] <nigelb> see if it works :)
[04:01] <cjohnston> it added and is downloading
[04:01] <nigelb> well, then it works :)
[04:01] <nigelb> thank you cjohnston :)
[04:01]  * nigelb hands cjohnston a toffee
[04:25] <ddecator> alright, so i checked the wikis and didn't see anything, but is there a specific procedure for "failed to install/upgrade" bugs?
[04:26] <persia> ddecator: I usually verify locally on the target release, then verify on up-to-date development release as a first stage.
[04:26] <persia> I then sometimes try using aptitude instead of apt-get (or vice-versa) to differentiate between resolver bugs and package bugs.
[04:27] <ddecator> persia, ok. and if it cannot be reproduced locally?
[04:27] <micahg> ddecator: you need to check the log to see what failed
[04:28] <ddecator> micahg, which log? (for example, i'm looking at bug 529136 )
[04:28] <ubot4> Launchpad bug 529136 in firefox (Ubuntu) "package firefox 3.6.2~hg20100226r33622+nobinonly-0ubuntu1~umd1~karmic failed to install/upgrade: subprocess installed post-installation script returned error exit status 2 (affects: 1)" [Undecided,New] https://launchpad.net/bugs/529136
[04:28] <persia> If you can't reproduce it locally, even with a system that matches the submitters system to the best of your ability (including locale, etc.) you get to dig through the logs.  Almost invariably if it can't be reproduced it comes from either 1) the submitter's system having a local change or non-repo package, or 2) The submitter7s system having leftover cruft from being continuously upgraded rather than havign a recent clean install.
[04:29] <persia> In the former case, identify the issue, and mark invalid.  In the latter case, identify the upgrade path, and use that to help replicate locally.
[04:32] <ddecator> is it the dpkgterminallog.txt file i should look into?
[04:32] <micahg> yes
[04:32]  * micahg guesses it was a bad download
[04:32] <ddecator> ok. and i'm assuming it's important to test on the same architecture as the reporter as well?
[04:35] <ddecator> why do you think that micahg ? i'm trying to make sense of the log...all i see is the error with the profiles for ff 3.5
[04:39] <nigelb> ugh, I'm so tired of closing old reports.  But I guess thats the easiest way to get to the new reports.
[04:39] <ddecator> it looks like the firefox package couldn't install because of "update-alternatives: error: alternative path /usr/bin/firefox doesn't exist." which caused dependencies to not be met?
[04:39] <ddecator> nigelb, i've been working on some of the old firefox ones, most of them aren't even responding..
[04:40] <nigelb> ddecator: its good they dont respond, you get to close them ;)
[04:40] <micahg> ddecator: not sure...I guess grabbing the 0223 daily of 3.6 in a karmic vm and try installing the 0226 packages
[04:40] <micahg> I agree with persia on this one...
[04:40] <micahg> oh wait...why is firefox an alternative
[04:41] <ddecator> it looks like they are using the daily ppa if that makes a difference
[04:41] <persia> ddecator: That's a bug in the firefox maintainer scripts: at some point in history handling changed, and there isn't an old snippet to deal with it.
[04:41] <persia> Or a third party repo
[04:41]  * persia wishes PPAs would just go away
[04:42] <micahg> persia: we don't offer it through alternatives
[04:42] <ddecator> idk about that, i like being able to use ff 3.7 ;)
[04:42] <ddecator> so possibly an usupported ppa?
[04:42] <ddecator> unsupported*
[04:42] <persia> micahg: Not now, but was it *ever* offered that way?  It may be that you need a snippet to handle the very old case.
[04:43] <micahg> persia: if you remember where that was so I have a reference, I'd be happy to look into it
[04:43] <micahg> ddecator: I enabled submission from the PPAs so we can catch more bugs in the dailies
[04:43] <ddecator> micahg, bug submission?
[04:43] <micahg> ddecator: yes
[04:44] <ddecator> micahg, oh, that'll be nice
[04:44] <micahg> for firefox 3.6 pecifically
[04:44] <micahg> so we can fix stuff for lucid
[04:44] <ddecator> good call. is there a package that a bug should be assigned to if it's a daily build?
[04:44] <nigelb> can someone who can read stack traces teach me how to read bug 458660
[04:44] <ubot4> Launchpad bug 458660 in rhythmbox (Ubuntu) "rhythmbox crashed with SIGSEGV in PyObject_ClearWeakRefs() (affects: 1)" [Medium,New] https://launchpad.net/bugs/458660
[04:44] <micahg> ddecator: no, it's already tagged
[04:45] <ddecator> micahg, good deal
[04:45] <micahg> ddecator: you should see the PPA tag on those bugs
[04:45] <persia> micahg: I have no memory of it, and haven't used firefox since feisty.  You'd have to check revision history, etc.
[04:45] <micahg> persia: I'll ask asac in teh morning
[04:45] <ddecator> micahg, yah i saw those, i just didn't realize you could use them for that
[04:45] <persia> May predate his coordination of it also, but sure :)
[04:47] <ddecator> oh fun, this log is in spanish...
[04:48] <persia> dpkg logs shouldn't be that language-specific.
[04:48] <ddecator> i can still find it, just looks odd to me, haha
[04:48] <persia> Most of the strings will be repeats, so you can just look them up in the .po files with grep.
[04:49] <ddecator> micahg, this one has the same -alternatives error
[04:50] <ddecator> lets go for the trifecta...
[04:51] <ddecator> and we're 3/3
[04:52] <ddecator> 2 of which are daily, 1 is not...
[04:54] <micahg> ddecator: I add the tag in the apport hook
[04:54] <persia> micahg: Maybe just the daily-builds uses alternatives?
[04:54] <micahg> persia: they don
[04:54] <ddecator> persia, one isn't daily
[04:54] <micahg> t'
[04:55] <micahg> what's the one that isn't
[04:55] <ddecator> let me find it..
[04:55] <ddecator> bug 524947
[04:55] <ubot4> Launchpad bug 524947 in firefox (Ubuntu) "tried installing firefox-3.6 after adding mozillateam/firefox-stable PPA :: package firefox 3.6+nobinonly-0ubuntu4~mfs~karmic1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2 (affects: 2)" [Undecided,New] https://launchpad.net/bugs/524947
[04:55] <persia> Were it one bug about alternatives, I'd call it local.  Three makes me suspicious that something more complicated is involved.
[04:56] <ddecator> that's why i asked, i wanted to check all three, but i didn't think they'd all be related...
[04:57] <persia> Looking at the logs, that's clearly a bug in the maintainer scripts for the PPA firefox.
[04:57] <micahg> persia: my guess is they installed some third party firefox at some point like ubuntuzilla
[04:57] <ddecator> then switched to the mozilla team ppa?
[04:57] <micahg> ddecator: yes
[04:58] <ddecator> micahg, want me to ask the reporters?
[04:58] <micahg> ddecator: ask 1
[04:58] <ddecator> i'll ask that one since he says specifically that the used the mozilla team ppa...
[04:58] <micahg> ddecator: or better see if you can find someone who uses ubuntuzilla
[04:58] <persia> micahg: I'd agree except that the error is coming from `firefox.postinst configure 3.6+nobinonly-0ubuntu4~mfs~karmic1`
[04:59] <ddecator> micahg, ah, i can refer back to that person from that other bug...
[04:59] <ddecator> unless persia is on to something
[04:59] <micahg> persia: right, but if they removed ubuntuzilla and the only firefox was the one from our package, that error would make sense
[04:59] <persia> micahg: Do you know if the daily PPA maintainer scripts are available somewhere without downloading the package?
[04:59]  * micahg check ubuntuzilla
[04:59] <micahg> persia: it's from the .head repo
[05:00]  * persia needs a URL
[05:00]  * micahg knows there's nothing in there
[05:00] <micahg> persia: lp:firefox/3.6
[05:00]  * persia didn't want to download it that way either, and tries other things
[05:00] <micahg> persia: http://sourceforge.net/apps/mediawiki/ubuntuzilla/index.php?title=Main_Page#Repository_contents_and_package_behavior
[05:00] <micahg> it does install and alernative
[05:01]  * persia checks the maintainer scripts documentation again
[05:01] <persia> Aha!  So it's firefox.prerm upgrade ... that's failing.
[05:02]  * micahg wonders how that got in tehre...
[05:03] <persia> micahg: So if you want to fix this with Ubuntu packages, just have firefox.prerm failed-upgrade attempt to remove alternatives if they exist.
[05:03] <persia> micahg: From the ubuntuzilla alternatives handling.
[05:03] <persia> http://women.debian.org/wiki/English/MaintainerScripts
[05:03] <persia> see "Upgrading"
[05:04] <micahg> I guess we still install the alternative...
[05:05] <persia> heh.
[05:06] <persia> Anyway, by using the docs at the Debian/women wiki, and checking the arguments, the issue can be solved.
[05:06] <persia> In the specific case of 524947, they seem to be upgrading from "3.6_3.6+karmic" which doesn't look like your version strings at all.
[05:07] <micahg> persia: that was a special package that asac made
[05:08] <micahg> oh, maybe not
[05:08] <persia> Oh.  Then the user in 524947 doesn't appear to have used out-of-repo sources aside from the PPA, based on the logs.
[05:08] <persia> Well, check the logs.  The upgrade path for the past 3-4 updates of firefox is listed there.
[05:09]  * ddecator wishes he had a better idea of what is going on
[05:09]  * micahg check the 3.5 prerm
[05:09] <persia> ddecator: So, when a package installs, it goes through several steps.  There are scripts in the package that can run before or after either install or removal, and take various arguments (see the page I linked).
[05:10] <micahg> there is none...
[05:10] <persia> ddecator: When a package fails to install or upgrade, this is usually a bug in the maintainer scripts, although it can also be file conflicts with other pacakges, etc.
[05:10] <persia> micahg: You checked the binary, not just the source?
[05:10] <persia> CDBS can stuff a lot of things in maintainer scripts.
[05:10]  * micahg checks
[05:11] <ddecator> ok, that makes sense...
[05:11] <persia> ddecator: So the trick is to try to replicate the issue, and figure out why it's failing (the update-alternative call has to be somewhere, for instance).
[05:12] <ddecator> ok
[05:12] <micahg> no
[05:12] <persia> Then track down which package needs to be tweaked.  Luckily, all the maintainer scripts take a version argument, so developers can clean up when there is an issue.
[05:12] <ddecator> ok, i get the general idea =)
[05:13] <persia> micahg: Based on that, the alternatives implementation may come from somewhere else.  You might test to see if an alternative is defined, and if so, remove it, and if not, ignore it.
[05:13] <micahg> it's there...I was looking at the wrong file :/
[05:14] <ddecator> if there is a place where install logs are temporarily stored, i can check mine from my daily updates
[05:15] <micahg> ah, the binary was firefox-3.5 before, so if the prerm for 3.6 is tried, it'll fail
[05:15] <persia> micahg: Excellent.  It's always easier when the bug can be found, rather than trying to work around random 3rd party packages.
[05:15] <persia> micahg: So, based on the docs, just add a prerm for 3.6 that cleans up from a failed 3.5 prerm if needed.
[05:17]  * micahg is confused
[05:18] <micahg> it says the postinst script is failing on some
[05:19] <micahg> something has got to be wrong
[05:20] <ddecator> any testing you want me to do or questions we need answered by the reporters?
[05:21] <persia> ddecator: When a developer (e.g. micahg) gets all excited about a bug, it's usually better to just hand off to them, and go find a new bug.  Acting as a proxy for contacting the reporters usually loses information (through no fault of the proxy, but due to the nature of language processing in human brains).
[05:22] <ddecator> persia, fair enough, i'll just do my homework then and stick around in case i can help with anything, but i'll plan on letting micahg take care of it from here
[05:23]  * micahg is very confused
[05:23] <persia> ddecator: When acting in the bugsquad role, the key is to make sure the developer has enough information to begin debugging.  I think we reached that point :)
[05:24] <ddecator> persia, very true. i'll leave them alone rather than mark them as dupes and triage them or anything
[05:25] <micahg> it would seem a simple file check is necessary, but that doesn't seem right either
[05:26] <micahg> ddecator: remember bug 526966
[05:26] <ubot4> Launchpad bug 526966 in firefox (Ubuntu) "Firefox start page not into English? (affects: 1)" [Undecided,Incomplete] https://launchpad.net/bugs/526966
[05:26] <ddecator> micahg, yah, i saw his response...
[05:27] <ddecator> do you think xp was his only os?
[05:30] <phantomgraph> Allow persia, remember me? =)
[05:31] <persia> It has been a while.
[05:31] <phantomgraph> *nods
[05:31] <phantomgraph> Well I figured it out all on my own.. sort of...
[05:32] <phantomgraph> if you recall the latest cups update nuked all my windows printers from my share on 9.1
[05:33] <persia> Right.
[05:35] <phantomgraph> turns out it was some windows problem. I got one of those invisible updates that Micky soft likes to do and poof, they started to see the printer on the my Ubuntu box again. Of course I had to set up a new printer link, but that's easy enough...
[05:36] <persia> Oh, excellent!
[05:36] <persia> That was a very mysterious bug, and I feared it wouldn't get solved.
[05:36] <phantomgraph> (The new link had to be set up on the windows machines)
[05:36] <persia> Knowing that MS already identified it and sent out a patch makes it easier.
[05:37] <persia> Could you update your bug with your findings (please reference the MS fix that makes it work for others who cherrypick hotfixes), and set it to "Invalid"?
[05:37] <phantomgraph> I think it was just a bug in one of the patches MS sent out.
[05:37] <ddecator> micahg, want me to close that report?
[05:38] <phantomgraph> I'm not sure how to do that as I was still working on opening a bug report when MS fixed it.
[05:38] <micahg> ddecator: sure
[05:39] <persia> phantomgraph: So the bug never got filed in LP?
[05:39] <phantomgraph> As far as I can tell the solution is this. On the MS machine delete the old link to the Ubuntu printer,  give it a couple of minutes, then go and add the printer again after the update.  Simple as pie.
[05:40] <phantomgraph> Nope persia, I was still gathering data and testing to see if it was something I did to the systems...
[05:43] <phantomgraph> One thing I can say for certain, the only update on the Ubuntu box since the 'break' was Open Office, and I doubt highly that OO would fix a printer share problem... ;>
[05:43] <persia> phantomgraph: OK.  In that case, there's nothing to do with LP.  No point filing a bug we already know to both 1) not be valid for Ubuntu and 2) be already fixed by MS.
[05:43] <persia> phantomgraph: Thanks for coming back to share your success.
[05:45] <phantomgraph> No problem persia, just wanted to drop back in and let you know what I've found out.
[05:45] <phantomgraph> Thanks much for all your suggestions!
[07:05] <kermiac> can anyone confirm bug 529852 is default/ expected behaviour? I can confirm ALT + "t" does open a terminal window in lucid
[07:06] <ubot4> Launchpad bug 529852 in ubuntu "[Lucid] <Alt>T opens up terminal, even though I haven't assigned it anywhere (affects: 1)" [Undecided,New] https://launchpad.net/bugs/529852
[07:11] <persia> It just makes a terminal flash for me (and not even the default terminal, but just a terminal window in another program I have open)
[07:12] <kermiac> hmm... interesting
[07:12] <persia> In a VM I recently booted with ubuntu netbook (last week's image), it doesn't do anythig at all.
[07:13] <kermiac> on a fully up-to-date lucid (alpha 3) I can reproduce it on 2 different machines
[07:13] <kermiac> I thought in metacity it's supposed to be CTRL+ALT+T
[07:14] <kermiac> I should be able to find out more info in the metacity changelogs?
[07:15] <kermiac> hmmm.... someone else in ubuntu+1 confirmed it does the same thing
[07:22] <persia> I suspect it's highly flavour-dependent, and I don't have Ubuntu Desktop handy (well, my base install was hacked from Ubuntu Desktop at one point, kinda, but still)
[07:22] <kermiac> http://changelogs.ubuntu.com/changelogs/pool/main/m/metacity/metacity_2.28.1-0ubuntu2/changelog says CTRL+ALT+T
[07:22] <kermiac> but someone in +1 says compiz is the same for them
[07:33] <kermiac> does xorg handle shortcut keys or something else?
[07:33] <kermiac> ^^ default shortcut keys
[07:33] <vish> kermiac: same here , alt + t opens terminal
[07:35] <kermiac> hey vish... can you please check that it is set in system --> Preferences --> keyboard shortcuts --> Desktop --> Run a terminal
[07:35] <vish> kermiac: hehe , was just replying that in +1 ;)
[07:36] <vish> it is mapped as ctrl+alt+t , but that does nothing
[07:36] <vish> using compiz, btw
[07:36] <kermiac> lol, guess that's what happens when I'm asking the same thing in 2 chans
[07:37] <kermiac> ok, so that's yet another diff behaviour
[07:37] <kermiac> being mapped to CTRL+ALT+T
[07:37] <vish> kermiac: any idea , what the old shortcut was?
[07:38]  * kermiac looks on the karmic box
[07:38] <kermiac> looks like it is set to diabled by default in karmic
[07:39] <vish> kermiac: probably the patch wasnt good? [but i doubt that , noting pitti has cherry-picked it]
[07:41]  * vish brb , testing a different nautilus bug
[07:58] <Zus> any one use irc on pidgin?
[08:05] <AtomicSpark> test
[08:05] <AtomicSpark> wonderful
[08:06] <Zus1> test
[08:06] <Zus1> I can't see the main window is too big
[08:06] <micahg> Zus1: yes
[08:07] <Zus1> the other irc channel im in with pidgin is fine
[08:08] <micahg> Zus1: you can drag the bar between the nicks and the channel
[08:08] <Zus1> in fact the other 2 windows are displayed correctly   except thihe irc channels
[08:09] <Zus1> micahg:  I can drag the vertical bar yes, not the horizontal one  between where I type  and where I read ...
[08:10] <micahg> Zus1: close the channel and rejoin
[08:11] <Zus1> same results
[08:12] <Zus1> lol now all my irc chats are all the same.. well
[08:12] <Zus1> no biggie I will use x chat...
[08:12] <micahg> Zus1: screenshot?
[08:13] <Zus1> yep I got  one of each window , h
[08:13] <Zus1> how can I send it to you?
[08:13] <micahg> Zus1: my nick at ubuntu dot com
[08:16] <Zus1> micahg:  I sent it
[08:41] <BUGabundo_remote> bom d|a
[08:57] <kermiac> vish, you still around?
[08:57] <vish> yup
[08:58] <kermiac> can you please check to see if you think bug 529852 needs anything further?
[08:58] <ubot4> Launchpad bug 529852 in compiz (Ubuntu) "<Alt>T opens up terminal, even though I haven't assigned it anywhere (affects: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/529852
[08:58] <kermiac> else I will set to triaged
[08:59] <seb128> can you tell pitti about this one?
[08:59] <seb128> he's on #u-d
[08:59] <kermiac> seb128: yes, we were discussing it earlier
[09:00] <kermiac> in #u-d
[09:00] <seb128> hum, and he didn't manage to help you with that?
[09:00] <seb128> I would think it's due to a change he did
[09:01] <kermiac> we worked through a few gconf settings (as outlined in the bug report) but they wouldn't stick after session restart
[09:01] <kermiac> yes, that's why I went looking to check with pitti as I noticed it was his change
[09:02] <seb128> hum and he didn't want to look at it?
[09:02] <seb128> not sure why you need other people to help you triage it now
[09:02] <seb128> it's obvious enough that pitti should be able to look at it no?
[09:02] <kermiac> just making sure I didn't miss anything. I think it's triaged... just simply double-checking I didn't miss anything
[09:03] <seb128> I don't think there is too much detail needed
[09:03] <seb128> the change is clear and the bug title too
[09:03] <seb128> did you ask pitti if the bug should be assigned to him too?
[09:03] <kermiac> no, I can ask him now though
[09:04] <seb128> would be useful
[09:04] <seb128> thanks
[09:04] <kermiac> np seb128 :)
[13:06]  * cjohnston is tired of all this membership spam
[13:07] <persia> hrm?
[13:07] <cjohnston> all the people sending the ML, I want to join or I want to renew
[13:08] <nigelb> cjohnston: its only fair
[13:08] <persia> OH.
[13:08] <cjohnston> nigelb: shaddup
[13:08] <persia> The renewals stuff should go away soon.
[13:08] <nigelb> (after you spamming classroom team with all the classbot spam)
[13:09] <cjohnston> thats not my fault
[13:09] <persia> And the way to deal with the add requests is to review some of them.
[13:09] <persia> Also be nice to folks :)
[13:09] <cjohnston> I told nhandler...
[13:09] <nigelb> cjohnston: well, we bit our tongues then.  so just hold on.
[13:09] <nigelb> its nice to see how many people are actually interested :)
[13:10] <cjohnston> nigelb: classroom spam should be fixed
[13:10] <nigelb> nah
[13:10] <cjohnston> i hope
[13:10] <nigelb> I still get, I dont complain though
[13:10]  * nigelb is looking for some bugs to fix to ease his bruised confidence
[13:10] <cjohnston> tell nhandler
[13:10] <cjohnston> uh oh
[13:10] <cjohnston> what happened?
[13:11] <cjohnston> you can fix some clasbot bugs
[13:11] <nigelb> no thanks.
[13:19] <bhuvi> i cannot file bugs in launchpad anyone please help me out i get launchpad time out error when ever i press the submit bug report button
[13:26] <hggdh> BTW, for what is worth, I *have* been revieweing the renewal requests.
[13:26] <nigelb> morning hggdh :)
[13:26] <hggdh> morning nigelb
[13:26] <hggdh> morning/afternoon/evening all
[13:26] <nigelb> its kinda evening ;)
[13:27] <hggdh> there you go. It is kinda morning here
[15:20] <easy> does anybody deal with 10.04 bugs in here?
[15:20] <nigelb> easy: yes, we deal with all bugs
[15:21] <easy> ahhh, (first time user here) I have a login bug, but don't know where to report or how
[15:22] <nigelb> can you describe your problem?
[15:23] <easy> it's where i type in my user name and password, and when i hit enter, it drops back to the login window.  But if I use the mouse to click, it works
[15:24] <greg-g> easy: I would report the bug against "gdm" right now (you're using Ubuntu, not Kubuntu, right?). You can do so here: https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+filebug
[15:24] <seb128> easy, try uninstalling plymouth
[15:24] <easy> yes, ubuntu
[15:24] <seb128> there is a zillion bugs about vt conflict making xorg crash on enter
[15:24] <seb128> due to it
[15:24] <seb128> no need to open a new one if that fixes your issue
[15:25] <greg-g> heh
[15:26] <nigelb> hehe
[15:27] <easy> alright, many thanks everybody
[15:30] <BUGabundo_remote> removing a package isn't a fix, it's a workaround
[15:31] <nigelb> but it narrows down the bug
[15:31] <nigelb> (and there is already an open bug for this issue)
[15:32] <greg-g> BUGabundo_remote: no one said it was a fix, just that it confirms what the issue is.
[15:32] <BUGabundo_remote> (2010-03-02 15:24:53) seb128: no need to open a new one if that *fixes* your issue
[15:32] <greg-g> right, but that fixes the issue, not that the bug is fixed
[15:33] <greg-g> he is saying that it confirms what the issue is, and it is being worked on
[15:36] <seb128> BUGabundo_remote, right, that fixes the issue means it's the plymouth bug
[15:36] <seb128> which is known
[15:44] <BUGabundo_remote> I know
[15:44] <BUGabundo_remote> I was prob one of the 1st to mention it in #+1
[15:45] <BUGabundo_remote> one of the dupes is even mine :\
[15:52] <m0ar> I'm vrey new to triaging, and I'm trying to set a bug to "Triaged". It contains all information needed, it's simple and very obvious. Even tho, "Triaged" isn't aviable in the status field. What am i missing?
[15:52] <nigelb> m0ar: only bug control can set bugs to triaged
[15:52] <m0ar> Ah
[15:52] <nigelb> mentioned the bug number here and ask that it be set to triaged
[15:52] <nigelb> someone who has the rights will do it for you
[15:52] <m0ar> 528962
[15:53] <m0ar> It's pretty much done, right?
[15:53] <m0ar> My report btw
[15:53] <nigelb> bug 528962
[15:53] <ubot4> Launchpad bug 528962 in shutter (Ubuntu) "Shutter doesn't fill certain dependencies (affects: 1)" [Undecided,Confirmed] https://launchpad.net/bugs/528962
[15:53] <m0ar> What's the diffrence between bugcontrol and buqsquad then?
[15:54] <nigelb> m0ar: bug control has more rights, like setting bugs triaged, wont fix AND set importance of bugs
[15:54] <m0ar> Ah
[15:55] <m0ar> So the goal for the buqsquad is to refine the reports?
[15:55] <nigelb> the goal for bug squad is to triage the bug report
[16:00] <vish> m0ar: usually one doesnt confirm their own bug reports ;)  confirmation has to be done by a different person
[16:00] <vish> rather not supposed to even
[16:00] <m0ar> vish: Well, I guess that one was pretyt obvious?
[16:00] <vish> m0ar: still nope :)
[16:01] <m0ar> Okay, thanks for telling!
[16:02] <nigelb> vish: set to triaged please.  I'll try to fix it.
[16:02] <vish> m0ar: usually the bugs where you see the OP confirming is it either the package maintainer..
[16:03] <vish> nigelb: sure.. can you comment on the bug first?
[16:03] <nigelb> yup.
[16:05] <vish> nigelb: importance?
[16:05] <nigelb> vish: medium or high if you wish
[16:05] <m0ar> I'm new, but what hsould decide if that's normal or high? :)
[16:05] <vish> nigelb: what do you think? ;)
[16:06] <m0ar> I'd guess normal
[16:06] <nigelb> vish: its a blocker, I'd say high.  but I'm not sure of the usage pattern of the bug
[16:06] <vish> m0ar: https://wiki.ubuntu.com/Bugs/Importance
[16:06] <m0ar> "A bug that has severe impact on a non-core app"
[16:07] <m0ar> High demands a "severe impact on users" which I'd guess is more.. hardcore bug?
[16:07] <nigelb> It affects every user wanting to install the package
[16:07] <m0ar> True
[16:07] <vish> nigelb: but its a non core app
[16:07] <nigelb> bah, true
[16:08]  * nigelb should sleep
[16:08] <nigelb> its been 24 hours
[16:08] <vish> ;)
[16:08] <m0ar> But "severe impact" I'd iterpret as more of a big problem
[16:08] <m0ar> nigelb: I went to sleep 07 this morning, sucked
[16:08] <nigelb> I got up yday around same time
[16:09] <nigelb> oh wait, its been 25 hours
[16:09] <m0ar> Keep counting!
[16:10] <m0ar> Is thos possible to set as confirmed?
[16:10] <m0ar> bug 495947
[16:10] <ubot4> Launchpad bug 495947 in debian (and 1 other project) "[need-packaging] lxdm (affects: 1)" [Unknown,New] https://launchpad.net/bugs/495947
[16:10] <nigelb> its a workflow bug
[16:10] <m0ar> Meaning? :)
[16:10] <persia> But I thought it was done?
[16:10] <persia> What does rmadison say?
[16:11] <m0ar> rmadison?
[16:11] <nigelb> persia: he's not commented
[16:11] <nigelb> m0ar: its a development workflow bug, you can safely skip it.
[16:11] <persia> `rmadison` is a tool that tells you which versions of a package are in which releases.
[16:11] <nigelb> bah
[16:11] <m0ar> nigelb: It's hard to find bugs that I actually can triage in some way D:
[16:11] <persia> Running `rmadison lxdm` will tell you if and when lxdm was packaged and uplaoded.
[16:12] <nigelb> in a lucid cache?
[16:12]  * ogra saw plenty of uploads of lxdm on the lucid-changes list ...
[16:12] <ogra> likely an oversight that the bug wasnt closed yet
[16:12] <persia> nigelb: rmadison doesn't care where it's run.  The results are the same whether you run on dapper or lucid.
[16:12]  * persia expects so, but wants to teach how to check that
[16:13] <ogra> lxdm (0.1.0-0ubuntu1) lucid; urgency=low
[16:13] <ogra>   * Intial release (LP: #495947)
[16:13] <ogra> hmm, intresting
[16:13] <nigelb> already second revision in lucid
[16:13] <nigelb> but its a git snapshot
[16:13] <nigelb> probably the bug was for a new debian sync
[16:13] <ogra> its packaged
[16:13] <persia> Still, bug #495947 needs closing.
[16:13] <ubot4> Launchpad bug 495947 in debian (and 1 other project) "[need-packaging] lxdm (affects: 1)" [Unknown,New] https://launchpad.net/bugs/495947
[16:13] <persia> Generally speaking, and needs-packaging bug can be closed if it's packaged.
[16:13] <ogra> yeah
[16:14] <nigelb> go ahead and close it?
[16:14] <persia> And no developers will ever complain if it's closed correctly.
[16:14] <ogra> i dont get why the janitor didnt do it
[16:14] <persia> Just don't close them just because it's in a PPA somewhere.
[16:14] <ogra> the bug is mentioned properly in the changelog
[16:14] <persia> ogra: Janitor only closes bugs against packages, and nobody assigned the bug to the package before the changelog was parsed.
[16:14] <ogra> aha !
[16:16] <persia> ogra: The issue is that it can only work if this is done between upload and source NEW, so there's a narrow window.
[16:16] <ogra> yeah
[16:16] <vish> m0ar: nigelb: set the bug to "confirmed" , needs to be sent upstream
[16:16] <m0ar> vish: What bug?
[16:16] <nigelb> vish: its just a dep issue.
[16:16] <vish> m0ar: the shutter bug
[16:17] <m0ar> Isn't it just an issu with apt?
[16:17] <vish> nigelb: dep was changed here or upstream?
[16:17] <nigelb> vish: It was set upstream.  I'm looking to find why.  There should be a reason
[16:17] <m0ar> It's already set as confirmed?
[16:18] <m0ar> So, how can I send that upstream? :)
[16:18] <m0ar> If I'm supposed to?
[16:18] <vish> m0ar: i have added a comment about how to send upstream ;)
[16:19] <m0ar> I realized
[16:19] <m0ar> But still, isn't this just an issue with the ubuntu packing? Do explain!
[16:19] <nigelb> m0ar: its an issue with debian packaging, we just sync'd the package
[16:20] <m0ar> Oh, so what has to be done is?
[16:21] <nigelb> you may have to report it to debian, but I'm still checking why they downgraded the particular depends to suggesets
[16:22] <nigelb> well, only one way to test.  I have to change the build dep, build and test. hmf
[16:26] <nigelb> m0ar: could you install the missing package and see if it works fine?
[16:26] <nigelb> (if so, we can fix this very soon)
[16:26] <m0ar> nigelb: If it works with imagemagick installed?
[16:26] <nigelb> yup
[16:26] <m0ar> It does, already tried
[16:26] <m0ar> Installing shutter gives the error
[16:26] <nigelb> ah, this looks easy.  Now all I need to do is why upstream tinkered with the deps
[16:26] <m0ar> installing imagemagick and trying to start shutter = works
[16:28] <m0ar> nigelb: Can you tell me how this works? WHY isn't imagemagick installed and what decides the dependencies?
[16:28] <nigelb> well, there is a debian/control file in every package that lists the depends for every package
[16:28] <nigelb> if a package is listed under depends, that package wont work unless that depends is installed
[16:29] <nigelb> then there is recommends, these packages wont be installed automatically.
[16:29] <nigelb> someone changed the imagemagick package to recommends from depends, which caused this issue
[16:30] <nigelb> well, not someone, the debian maintainer
[16:30] <m0ar> Ah
[16:30] <m0ar> That's kinda wierd right?
[16:31] <nigelb> they should have a reason.
[16:31] <m0ar> Oh darn, I'm in a rush
[16:31] <m0ar> Thanks for the lession
[16:31] <m0ar> Bai
[22:49] <bibinou> how does apport set the importance of a bug ?
[22:49] <bibinou> *how can
[22:49] <persia> bibinou: The launchpad API.
[22:50] <bibinou> yeah, but how can it decide if it's medium, high, etc
[22:51] <bibinou> how can it judge if a bug is important or not ?
[22:51] <bibinou> maybe, given the error type
[22:51] <bibinou> crash / signature, etc
[22:52] <persia> bibinou: I believe it sets all the crashes to "Medium" (which is usually correct for a crash).
[22:52] <persia> I think it doesn't set it for other cases.
[22:52] <bibinou> ok thanks


[04:32] <mup> Bug #1858766 changed: Machine can't be redeployed using zfsroot <curtin:Expired> <MAAS:Expired> <https://launchpad.net/bugs/1858766>
[04:32] <mup> Bug #1863791 changed: apt-install of maas-rack-controller fails trying to connect to maas-internal hostname <cdo-qa> <foundations-engine> <MAAS:Expired> <https://launchpad.net/bugs/1863791>
[04:35] <mup> Bug #1858766 opened: Machine can't be redeployed using zfsroot <curtin:Expired> <MAAS:Expired> <https://launchpad.net/bugs/1858766>
[04:35] <mup> Bug #1863791 opened: apt-install of maas-rack-controller fails trying to connect to maas-internal hostname <cdo-qa> <foundations-engine> <MAAS:Expired> <https://launchpad.net/bugs/1863791>
[04:41] <mup> Bug #1858766 changed: Machine can't be redeployed using zfsroot <curtin:Expired> <MAAS:Expired> <https://launchpad.net/bugs/1858766>
[04:41] <mup> Bug #1863791 changed: apt-install of maas-rack-controller fails trying to connect to maas-internal hostname <cdo-qa> <foundations-engine> <MAAS:Expired> <https://launchpad.net/bugs/1863791>
[13:54] <mup> Bug #1872021 changed: [Ubuntu][Bionic] systemd caused kernel to hang on fsnotify wait-on-completion <MAAS:Invalid> <linux (Ubuntu):New> <linux (Ubuntu Bionic):Triaged> <linux (Ubuntu Eoan):New> <linux (Ubuntu Focal):New> <https://launchpad.net/bugs/1872021>


[14:32] <natefinch> anyone here have suggestions on the best way to use juju on a mac?  I miss lxd on ubuntu.  Is there anything similar on mac?  Will lxd work in an ubuntu vm on mac?
[14:37] <natefinch> marcoceppi rick_h ^
[14:37] <rick_h> natefinch: so if juju is on the VM then yes. I think that's how most folks use juju on a mac
[14:37] <rick_h> natefinch: personally, I use maas/jaas on a mac and don't lxd much on there
[14:38] <rick_h> natefinch: let me know if you hit any issues with the client on the mac. I try to do most of my juju-ing from my mac to test it out and keep the brew packages up to date
[14:38] <primeribz> natefinch: I as well curently have a setup running ubunutu in a vm with juju installed thhere.
[14:38] <rick_h> natefinch: another thing to test out is something that hit the email list on friday https://launchpad.net/multipass
[14:39] <rick_h> natefinch: I've not tried it out yet, but might be a nicer way to get the VM going to use juju/lxd on there. Not sure
[14:40] <natefinch> rick_h: that link 404's
[14:40] <rick_h> natefinch: oh sorry, it's internal testing I guess my bad
[14:40] <natefinch> heh :) . s'ok
[14:41] <rahworkx> natefinch: have a look at this. https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-containers-to-virtualbox-vms-on-os-x-a06a8046756a
[14:43] <natefinch> rahworkx: that sounds awesome
[14:44] <rahworkx> natefinch: thanks to bdx :)
[17:41] <natefinch> gah, the default lxd init parameters don't work with juju :/
[17:42] <natefinch> lxd-bridge has IPv6 enabled. Juju doesn't support IPv6
[17:43] <natefinch> at least it gives me instructions on how to fix lxd.  But geez.  Also, that lxd init wizard is insanely long.
[19:07] <zeestrat> rahworkx: Regarding the reusing username issue, there's an old issue on it. Feel free to add some fire to it :) https://bugs.launchpad.net/juju/+bug/1668335
[19:07] <mup> Bug #1668335: `delete-user` doesn't fully delete user <juju:Triaged> <https://launchpad.net/bugs/1668335>
[19:08] <rahworkx> zeestrat: ok will do.
[21:27] <hallyn> stupid question.  i did a conjure-up to try kubernetes-core onto localhost.  i ctrl-c'd it when it was mostly installed.  now i see stuff is still running, but juju status no longer shows anything other than
[21:27] <hallyn> conjure-kubernetes-core-59c  conjure-up-localhost-267  localhost/localhost  2.2.1    unsupported
[21:27] <hallyn> how do i 'reconnect' to that?
[21:28] <rick_h> hallyn: juju status shows that? what does `juju controllers` show?
[21:29] <rick_h> hallyn: I'd expect you to be able to `juju switch conjure-kubernetes-core-59c && juju models` and see a model listed there. From there you can destroy the controller and such if you wanted to cleanup.
[21:31] <hallyn> rick_h: indeed i see models there,
[21:31] <hallyn> i don't want to destroy it, i want to investigate :)
[21:31] <hallyn> thanks rick_h
[21:32] <rick_h> hallyn: and so you can juju switch into those models, run juju status, etc
[21:32] <hallyn> now to remember how to connect to its apparently private lxd socket
[21:32] <rick_h> hallyn: hmm, lxc list and such should show the containers. I'm not sure about the private socket
[21:33] <hallyn> hm lxc list shows nothing and lsof -U shows a private socket...
[21:33] <hallyn> but yay i can attach to the model, that's a start.  this controller/model thing is confusing to me stil :)
[21:34] <hallyn> thanks
[21:35] <hallyn> imma start over :)
[21:35] <hallyn> my fault for exiting early
[21:35] <rick_h> hallyn: sec, let me get you a walk through.
[21:36] <rick_h> hallyn: https://youtu.be/FqPjO0NZ8z0?t=363 walks through it a bit from a talk I gave
[21:37] <hallyn> rick_h: thanks i'll look at that too.  was looking at https://insights.ubuntu.com/2017/01/27/deploying-the-canonical-distribution-of-kubernetes-onto-aws/ and mainly https://kubernetes.io/docs/getting-started-guides/ubuntu/
[21:37] <rick_h> hallyn: and I think there's a blog post and such somewhere. the docs have an intro as well here: https://jujucharms.com/docs/stable/controllers
[21:37] <hallyn> bbl
[21:37] <rick_h> let me know if there's confusion
[21:37] <rick_h> hallyn: k, good luck!
[21:37] <hallyn> rick_h: will do thanks!


[05:18] <batteronizer> Hi guys, is anyone aware of any workarounds for the systemd-udevd high CPU consumption issue on Dell laptops with 18.04?
[06:33] <lordievader> Good morning
[06:33] <oerheks> turnoff bluetooth?? https://ubuntuforums.org/showthread.php?t=2389530
[06:34] <oerheks> "bluez" issue https://unix.stackexchange.com/questions/433393/systemd-udevd-high-cpu-usage
[06:34] <oerheks> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1759836
[07:19] <kubast2> Uhm so I put my pc to sleep ,and when I woke it up and logged in I was greeted with 3 failed to write some KDE config ,and the root file system was mounted as ReadOnly which I know cause I tried to restart sddm to launch firefox ,because killall firefox apparentlly didn't killed "firefox" and didn't let me to launch the browser window
[07:20] <kubast2> 4.15.0-20-generic
[07:21] <kubast2> how can I report this ,might be the first time in like 25 or 50 times I put my pc to sleep but would be nice to see it fixed
[07:21] <kubast2> what steps should I take
[07:21] <kubast2> allready rebooted so at best systemctl log and kernel message log
[07:21] <kubast2> any value in that ?
[07:23] <lordievader> kubast2: I'd check the smart values of your drive first. The rootfs mounts read only when it occurs erros.
[07:23] <lordievader> errors*
[07:23] <kubast2> it's a fairlly new hdd but okay
[07:23] <kubast2> I doubt they install failling drives in new laptops
[07:24] <kubast2> in sec
[07:25] <kubast2> self test or just atributes
[07:26] <kubast2> 0 sectors ,0 end to end error ,0 command timeout ,0 uncorrectable errors ,0 high fly writes ,30961260 seek error rate ,4516972 read error rate
[07:27] <kubast2> ok doing extended rn
[07:28] <lordievader> Those are quite  high error rates.
[07:28] <lordievader> Could be  due to a faulty sata cable though.
[07:28] <kubast2> or connector who knows
[07:30] <kubast2> IIRC it's reporting concatenation of error rate and total reads. ,well turns out someone got 2 milions
[07:30] <kubast2> *200
[07:31] <kubast2> Brand new Seagate HDD has high raw read error rate<well it might not be it?
[07:31] <kubast2> It seems it may be a count of the actual sectors read, the errors are in the upper 16bits of the 48bit word, please see
[07:32] <kubast2> 0 read errors
[07:32] <lordievader> Does `dmesg` report anything about this?
[07:32] <kubast2> lordievader: can I view past dmesg ?
[07:33] <lordievader> kubast2: If it is saved to `/var/log/dmesg` yes.
[07:34] <kubast2> running journactl -o short_precise -k -b -1 it's there
[07:35] <kubast2> nothing out of ordinary at least on last ACPI: Waking up from system sleep state S3
[07:38] <kubast2> at some point there was sefault from web content(firefox) and some apparmor stuff but that's about it; pcie timeouts happen at the beginning ,but they are corrected at boot
[07:38] <kubast2> nothing seems out of ordinary
[07:40] <batteronizer> oerheks: Thanks, that itself didn't work
[07:40] <batteronizer> In me case moving this file: /lib/udev/rules.d/97-hid2hci.rules was needed
[10:26] <user19999999> hello! guys i can't start steam games (insurgency) everything is up and running but when i click my game it wont start how can I see steam output messages?
[10:41] <hateball> oh they left quite fast
[11:06] <w0lf> hi there
[11:06] <w0lf> in my kubuntu
[11:06] <w0lf> I am having this strange issue
[11:06] <w0lf> my USB 3 port stop recharging my phone after a while
[11:07] <w0lf> even If i unplug and plug it again
[11:07] <w0lf> the only solution is reboot the machine
[11:07] <w0lf> can someone please help
[11:20] <hateball> w0lf: do you see anything in dmesg ?
[11:20] <hateball> like if the device turns off or something
[11:27] <w0lf> hateball, actually just noticed that the charging sign is not showing in iphone but its charging lols
[11:39] <hateball> w0lf: :D
[11:40] <hateball> w0lf: problem solved then? :p
[11:40] <w0lf> hateball, yeah ahaha
[11:43] <hateball> :D
[11:43] <hateball> w0lf: best type of problem
[13:12] <BluesKaj> Hi folks
[13:22] <alket_> hi BluesKaj
[13:44] <BluesKaj> hi alket_
[15:03] <R13ose> The panel I created is not hiding when the mouse is not over this.  How do I fix this?
[15:30] <hateball> R13ose: did you set it to autohide?
[15:43] <R13ose> Yes the autohide is set
[15:51] <R13ose> I figured this out.  Something was open for panel settings that I didn't see
[18:05] <acme_> #privacy
[19:12] <katnip> https://linuxconfig.org/how-to-reset-lost-root-password-on-ubuntu-18-04-bionic-beaver-linux
[19:15] <genii> There is no default root password.
[19:16] <genii> Root login on *buntu is disabled by default and the usage of sudo from an account with admin priveleges is the preferred model.
[19:40] <rohan> hello! After upgrading my laptop to Kubuntu 18.04, I feel like KDE has become very slow/sluggish.
[19:41] <rohan> for example, clicking on menus takes a long time to show up
[19:41] <rohan> Alt-f2 takes forever to load
[19:41] <rohan> can someone help me debug, please?
[20:19] <nico_> hola
[20:19] <nico_> I'm trying to compile Qt qml plugins in kubuntu
[20:19] <nico_> I've been having troubles since some time, somebody knows where could I find a good tutorial? (I'm trying to compile extended plasmoids)
[23:32] <ottod> Hello, I just installed Kubuntu and was about to install nodejs when I noticed it comes with Kubuntu
[23:32] <ottod> Why is that?
[23:33] <ottod> There is no preinstalled package requiring it
[23:47] <metalbiker> hey folks. i just installed the minimal version of kubuntu and i need to find out what the terminal commands are to install the kde packages for libreoffice to get it to look correct. it looks like windows 95 with its blocky boxes and whatnot.
[23:52] <ottod> libreoffice-kde4


[03:51] <OvenWerks> zequence: where would we expect to see the bare ISO for DL?  DL for testing to see where it is at.
[03:51] <OvenWerks> (been camping for a bit)
[04:48] <zequence> OvenWerks: No CD yet. Just the DVD
[05:41] <OvenWerks> Lots of changes happened while they were not building I guess... 50%
[08:52] <zequence> OvenWerks: Did you read about ffmpeg coming back to Debian? They are planning to have libav as default, but some applications require ffmpeg.
[08:53] <zequence> messy


[00:49] <olegfink> mythos: hi
[00:58] <mkopack> Anyone here run Ubuntu on a pandaboard?
[01:02] <infinity> Lots of people.
[01:03] <infinity> Just as your question, someone might know the answer.
[01:03] <mkopack> ok, cool. I'm working on setting up the ubuntu-server image for PandaES… Just wdonering if that already includes the drivers for the Panda's hardware (like the Wifi, bluetooth, gfx, etc.) or if I'll need to install those after the fact ?
[01:04] <infinity> mkopack: Everything but video is in the default kernel.
[01:04] <infinity> mkopack: And if you're doing a server, you really shouldn't need video?
[01:04] <infinity> mkopack: Unless by "server", you mean "set-top box" or something.
[01:05] <infinity> (Sorry, when I say "video", I mean "accelerated 3D and codec", the display works fine without 3rd party drivers)
[01:05] <mkopack> What would I have to do to get video going? I don't want a huge desktop (I tried the Ubuntu desktop image and it was HORRIBLY slow and memory intensive). I just need a simple desktop for opening a couple terminals and maybe a light browser like Midori
[01:05] <infinity> Yeah, that level of "video" is fine on the default image.
[01:06] <infinity> Though we will be getting TI's binary drivers in the archive over the next week.
[01:06] <mkopack> Nah, eventually going to use this for ROS (robot OS) but I'll need a simple desktop + terminal windows to get everything going and do some light development/testing/debugging output on
[01:06] <infinity> Bah, who needs a GUI for that? ;)
[01:06] <twb> infinity: does it struggle with animated GIFs in midori tho?  my old atom/i9xx doesn't, but my tegra2 does
[01:06] <infinity> Regular TTYs are great.
[01:06] <twb> e.g. http://www.bom.gov.au/products/IDR023.loop.shtml#skip
[01:06] <infinity> twb: I dunno, I have no issues here with heavier browsers.
[01:07] <twb> infinity: admittedly i'm still running android kernel here :-(
[01:07] <infinity> I have no accelerated video on my ac100, and it's just fine.
[01:07] <twb> okey dokey
[01:07] <infinity> (Sure would be nice if nvidia got their ducks in a row and release the armhf build they have internally...)
[01:08] <infinity> mkopack: Anyhow, the server image should "just work" out of the box for all the usecases you seem to care about.
[01:08] <infinity> mkopack: Should you later decide you need accelerated video, it'll be there.
[01:09] <infinity> mkopack: And I'd highly suggest using precise/armhf, not any of the older armel releases.
[01:10] <mkopack> how do I know the diff? (sorry, not a super experienced linux person
[01:10] <mkopack> )
[01:11] <infinity> http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/ <-- Those.
[01:11] <infinity> mkopack: Or, if you're installing to a hard drive instead of an SD card, I'd use the netinst images instead.
[01:11] <infinity> (Since the preinstalled images are meant to run from SD)
[01:12] <infinity> http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/20101020ubuntu126/images/omap4/netboot/ <-- Netboot.
[01:14] <mkopack> I'm going with the 11.10 server build for now… Once 12.04 is considered "release" then I'll consider it… Not a fan of living on the bleeding edge :)
[01:15] <infinity> mkopack: Trust me, 12.04 is better.
[01:15] <infinity> mkopack: Bleeding edge or not.
[01:15] <infinity> Both in terms of faster, and less buggy.
[01:15] <infinity> Joooooin us.
[01:16] <mkopack> Hmm… well, let me give this a try first… I just want to see that this thing can run better than it did with the 11.10 desktop I tried Monday night. That was pretty discouraging...
[01:17] <mkopack> So far this seems to be going well - configging the wifi right now
[01:17] <mkopack> except it seems to insist that it needs a WEP key, and I have WPA2 … sigh
[01:18] <mkopack> So what's the "precise" mean? I know the diff between hardfp and softfp...
[01:23] <micahg> mkopack: precise is the release codename
[01:23] <mkopack> Ah!
[01:23] <infinity> mkopack: precise is just the release codename. 12.04 = precise, 11.10 = oneiric.
[01:24] <infinity> To be fair, the desktop runs pretty well when it's backed by a USB hard drive.   Running a full desktop from SD is painful.
[01:24] <mkopack> which file do I need, the .gz or the .gz.zsync ?
[01:24] <mkopack> and I assume the instructions for imaging are the same as they were from 11.10 ?
[01:24] <infinity> For netboot?
[01:24] <mkopack> for the daily builds
[01:24] <infinity> Or for server preinstalled?
[01:24] <mkopack> server preinstall
[01:24] <infinity> .gz in both cases, mind you.
[01:24] <infinity> And yeah, imaging is the same.
[01:24] <mkopack> k
[01:25] <mkopack> figure I'll image a 2nd card with 12.04 daily while the 11.10 is installing in the panda
[02:56] <mkopack> HNmm, not having much luck with the 12.04 server daily
[02:57] <mkopack> First try, after I went and told it account info, network, etc. Picked which functions/packages I wanted, it did some work and then I got what looked like a kernel dump on the screen.
[02:58] <mkopack> Power cycled and tried again, this time it got past all that and was doing the install. Got to the "Removing Packages" stage at 50% and just hung there for over 30 minutes… No changes. The light closest to the SD slot stopped blinking, the other one would blink twice, wait, then blink twice, over and over
[02:58] <mkopack> Going back to trying the 11.10
[03:35] <lilstevie> even with softfp precise is much faster than oneiric
[03:37] <mkopack> well, I had no luck getting precise to install for me
[03:38] <mkopack> so I'm going back to oneiric for the time being
[03:38] <mkopack> I'll give precise another try this weekend when I have time
[03:38] <mkopack> thankfully I have a couple SD cards to use
[03:38] <twb> lilstevie: why much faster?
[03:38] <lilstevie> don't know why, just is
[03:39] <lilstevie> at least on the tegra3
[03:39] <lilstevie> haven't tried it on my tf101 yes
[03:39] <lilstevie> yet*
[03:41] <twb> I hear you are all about the primes these days :-)
[03:42] <lilstevie> hah
[03:42] <lilstevie> not all about the primes
[03:43] <lilstevie> just  it needs more work than the tf101 at this point in time
[03:43] <twb> k
[03:44] <lilstevie> anyway gtg
[03:44] <lilstevie> class in 15 minutes is all the way over the other side of the uni
[09:22] <janimo`> ogra_, I just saw there's a newer L4T 15alpha since March the 12th
[09:22] <ogra_> no armhf
[09:22] <janimo`> I wonder if we could/should use it for the ac100 in precise
[09:23] <janimo`> ah, I forgot that armhf was desirable as well
[09:23] <ogra_> if you feel like, feel free to update, but given we dont build armhf images anymore it will only help armel upgraders
[09:24] <xranby> ogra_: i assume you mean armel images ^
[09:25] <infinity> Indeed he did.
[09:26] <xranby> we have added jogl armhf java bindings now.. the only part missing are the gles drivers
[09:30] <xranby> ogra_: all in all cool. now gpu vendors have to ship armhf binarys :)
[09:31] <xranby> for a LTS release with server focus this are a good call
[09:32] <janimo`> ogra_, well yes, it only helps those already using nvidia-tegra drivers
[09:37] <janimo`> ogra_, infinity do you know when/if we drop the armel (as it is now - armv7) port completely ?
[09:45] <ogra_> janimo`, not in 12.04 at least ;)
[09:46] <janimo`> well obviosuly not, but what of the next cycles?
[09:46] <RoyK> any idea what's happening with bug 952909?
[09:46] <ubot2> Launchpad bug 952909 in accountsservice "Some users invisible/unusable" [High,Confirmed] https://launchpad.net/bugs/952909
[09:46] <ogra_> aqsk again at UDS i'd say ;)
[09:47] <ogra_> RoyK, as in #ubuntu-desktop
[09:48] <RoyK> ogra_: erm... it's an arm specific bug, isn't it?
[09:49] <ogra_> its a desktop package and there is no arm team anymore
[09:49] <ogra_> and iirc its also amd64
[09:55] <RoyK> ogra_: no, it's not
[09:56] <RoyK> IIRC that was me guessing that, and I was wrong
[09:56] <RoyK> what happened to the arm team?
[09:56] <ogra_> well, still it is a desktop bug, there is no arm team anymore as i said
[09:57] <ogra_> was dissolved, people were put into other teams
[09:57] <RoyK> ok... so what would be a good alternative to ubuntu, then?
[09:58] <RoyK> and why isn't https://wiki.ubuntu.com/ARMTeam updated on this?
[09:58] <ogra_> ?
[09:58] <ogra_> why would you need an alternative to ubuntu
[09:59] <Mephisto__> Hello guys! I've compiled a 3.0.26 kernel for ARCH=arm and when I emualte it through qemu, I get a black screen, any help?
[09:59] <ogra_> its not that the arm port goes away, its about having the actual teams take respionsibility
[09:59] <RoyK> because if there is no arm team, then I guess the focus on arm is rather sloppy
[09:59] <ogra_> no, the opposite is the case
[10:00] <ogra_> in the current transition phase that might not be true indeed, since not all teams have HW yet but it will get there
[10:11] <xranby> ogra_: which boards have armhf gpu drivers in ubuntu 12.04 ?
[10:12] <ogra_> omap4 will
[10:12] <xranby> i have a panda a imx53 and a ac100 here
[10:12] <xranby> OK
[10:12] <ogra_> ac100 depends on nvidia ... mx5 depends on freescale :)
[10:12] <xranby> i will install armhf on the panda then
[10:12] <xranby> and keep on testing gles armel on the mx5 and ac100
[10:13] <xranby> thank you for the info
[10:23] <mythos> hmm.... olegfink always tries to contact me, when i'm asleep...
[11:32] <mkopack> Just wanted to say thanks guys... Got my pandaboard ea working last night running the 11.10 server.  Installed lode and that's working, and installing midori right now..
[11:32] <mkopack> Lxde I mean
[11:32] <mkopack> Stupid autocorrect!
[11:33] <mkopack> Way faster and better on memory than the desktop image
[19:14] <dannf> infinity: so did fedora decide not to follow suit w/ the hardfloat linker path?
[19:14]  * dannf snagged 	hello-2.6-3.fc17.armv7hl.rpm, it uses /lib/ld-linux.so.3
[19:15] <dannf> and no compat symlinks i see in their alpha tarballs
[19:15] <infinity> They dropped the compat symlink too?
[19:16] <infinity> jcm will be in punching distance of me in 4 days, I'll get to the bottom of this. >:(
[19:17] <dannf> ok - i might poke him on irc real quick - Sledge has been poking me about submitting the linker patch upstream. i fixed the no-float-arg case, but probably should chekc w/ them first
[19:17] <infinity> Well, it should go upstream period.
[19:18] <infinity> RedHat's biggest argument was that it wasn't upstream, and they were dragging their feet about being trend-setters.
[19:44] <dannf> infinity: submitted the patch - jcm reiterated his upstream-first reqmt, said he'd look at the patch & comment when he gets time (probably not before you see him)
[23:29] <avinashhm> Hi friends , i am trying to enable wl1271 by following - http://processors.wiki.ti.com/index.php/OMAP_Wireless_Connectivity_Calibration_Proccess_NLCP .. but i get into error "wl1271: ERROR could not get firmware: -2" .. but the .bin file is proper and i have copied to correct locan .. still i get this error .. has anyone faced this .. pls let me know any pointers ...more logs @ http://paste.ubuntu.com/906407/
[23:41] <infinity> avinashhm: What's wrong with the driver that ships with Ubuntu and just works?
[23:43] <avinashhm> infinity, i am using linaro-* images .. don't find any driver .. besides we are enable on a custom machine .. so i am not sure if ubuntu supports that ..
[23:44] <infinity> Fair enough.  The wiki instructions seem straightforward enough for doing per-machine calibration.
[23:44] <infinity> It's just also generally unnecessary.
[23:45] <avinashhm> infinity, yes .. the instructions are quite simple and also i am having necessary binaries in right path .. "/lib/firmware/ti-connectivity/wl1271-[fw/nvs].bin" ..  still i get this error ..
[23:46] <infinity> avinashhm: Your pastebin doesn't show you following the HOWTO...
[23:46] <avinashhm> infinity, one thing is i have integrated the wl12xx to the kernel as inbuilt .. can this make a difference .. not a loadable module
[23:46] <infinity> avinashhm: You're not giving calibrator all the arguments it needs.
[23:47] <avinashhm> infinity, below in the page, they have an example section ..  so picking this .. i ll also give other arguments to check if it has better results
[23:48] <infinity> avinashhm: The different examples are for different types of hardware.  No idea what yours is.
[23:48] <infinity> Also, did you rmmod wl12xx_sdio before starting?
[23:48] <infinity> (Cause if that's builtin, yeah, you'll have problems)
[23:49] <infinity> Since that module needs the firmware loaded, and you're moving the firmware out of the way.
[23:49] <infinity> If you tickly the device, the module wakes up, no firmware -> boom.
[23:49] <infinity> tickle*
[23:49] <infinity> Even if your final product will ship with a monolithic kernel, you're probably going to need a modular one just to do this one firmware calibration thing.
[23:50] <infinity> Then you can ship the new firmware with your non-modular kernel.
[23:50] <avinashhm> infinity, oops .. now i understand .. i will make the module loadable and then make sure to caliberate before insmoding ..
[23:51] <avinashhm> thanks very much infinity for helping ..


[00:07] <trippeh> hah, rebuilding ubuntus openssl package - it spawned like 2000 concurrent gcc processes
[00:07] <trippeh> cpu go brrr
[00:14] <mdeslaur> molten lava flows out of my stinkpad fan port when I build openssl
[00:29] <sarnold> that'd be a more environmentally friendly alternative to the tar
[02:31] <lemoi> I'm trying to change the user password for 'ubuntu' on the 20.04.x install media via cloud-init/user-data. is there a way of doing this?
[02:32] <lemoi> I'm aware that an 'identity:' yaml stanza can setup the hostname + users + passwords on the target system but I need to reset the pwd for the live media
[02:34] <sarnold> lemoi: I'm pretty sure that's possible, but the docs are pretty thin on *how* .. the docs that I know about start with "Delivery of autoinstall" on https://ubuntu.com/server/docs/install/autoinstall
[02:36] <lemoi> I agree. I was looking at the documentation you linked but I can't find anything precise
[02:47] <lemoi> sarnold https://askubuntu.com/questions/1409337/22-04-server-auto-install-password
[02:50] <sarnold> lemoi: lol that's awesome
[02:50] <sarnold> lemoi: your feature is their plea for help
[02:50] <lemoi> I'm exhausted from this crap
[05:03] <NatSocSiD> I'm having a lot of issue with apt lately, apt update freeze and it never timeouts so if I don't kill it, it'll never end, see the following screenshot: https://m.freespeech.club/3kI.png
[05:03] <NatSocSiD> is there a way to fix this? Note that if I do a speedtest i get 1gbits/s on ipv4 and ipv6, so it's not a bandwidth issue
[05:04] <NatSocSiD> I sometime have to retry 5-6 times before the apt update finally ends without issue
[05:04] <NatSocSiD> s/ends/completes
[05:06] <NatSocSiD> Here's another screenshot from my 5th try back to back: https://m.freespeech.club/8Gs.png
[05:27] <tomreyn> NatSocSiD: side note: most of us generally prefer text to be shared as text, not images. ;)
[05:28] <tomreyn> you have a LOT of apt sources, and moreover seem to be mixing different ubuntu releases there
[05:31] <tomreyn> !ubuntu+1
[05:32] <tomreyn> ^ many of your apt sources point to "lunar*"
[05:40] <NatSocSiD> tomreyn sorry, should have copied instead of taking a screenshot. Regarding the sources, unfortunately some don't provide repositories for the 23.04 yet. I'll ask in #ubuntu-next
[05:40] <NatSocSiD> Have a good day!
[06:07] <tomreyn> you, too!


[13:54] <DJones> Pici: Re Crazymethjesus, they did the same earlier on today as well and stopped after !language, so they can't say they weren't aware of it, probably about 3-4 hours ago
[13:55] <Pici> DJones: Yeah, I saw the lastlog, thats why I banned.
[13:55] <DJones> ok
[22:53] <ubot4> In #ubuntu-bugs, trijntje said: ubot4 is wrong, bug 509595 is not private
[22:53] <ubot4> ukbot: Error: I am only a bot, please don't think I'm intelligent :)
[22:53] <ubot4> ukbot: Error: I am only a bot, please don't think I'm intelligent :)
[22:53] <ubot4> ukbot: Error: I am only a bot, please don't think I'm intelligent :)
[22:53] <ubot4> ukbot: Error: I am only a bot, please don't think I'm intelligent :)
[22:53] <ubot4> ukbot: Error: I am only a bot, please don't think I'm intelligent :)
[22:54] <ubot4> ukbot: Error: I am only a bot, please don't think I'm intelligent :)
[22:54] <ubot4> ukbot: You've given me 5 invalid commands within the last minute; I'm now ignoring you for 10 minutes.
[22:54] <m4v> uhhh
[22:55] <ikonia> DJones: can you remove your bot please
[22:55] <nalioth> or teach it some manners
[23:42] <tsimpson> DJones: /msg ukbot channel #ubuntu-irc plugins.Bugtracker.bugSnarfer False
[23:42] <tsimpson> jpds: please also disable bugtracker in here


[19:48] <locodir-user> Bryanstein: hi
[19:48] <locodir-user> Um. Is the SC Ubuntu group still active, as far as I can tell it isn't
[19:50] <locodir-user> I suppose not. Oh wel
[19:50] <locodir-user> *well