[00:01]  * ajmitch wonders how much of christchurch got flattened in that one
[00:03] <hads> Yeah, felt that well here.
[00:04] <ajmitch> felt it in dunedin, so it was fairly strong
[00:05] <Atamira> they had another quake?
[00:05] <Atamira> and afternoon
[00:05] <ojwb> http://www.geonet.org.nz/earthquake/drums/
[00:05] <ojwb> big smear at the RHS!
[00:07] <Atamira> dammit
[00:07] <Atamira> day after i leave chch too
[00:07] <hads> Sounds pretty big
[00:07] <hads> 6.3 just appeared on geonet
[00:08] <hads> 10km SE of CHC
[00:08] <ojwb> they often adjust the magnitude a bit from the initial though
[00:08] <Atamira> my friend in chc says hes used to them now
[00:08] <Atamira> doesnt even notice if theres a quake
[00:08] <Atamira> none of them i met the weekend did
[00:08] <ajmitch> I think they would have noticed this one
[00:09] <Atamira> ill ask them later
[00:09] <Atamira> oh scratch that
[00:09] <Atamira> ill txt him
[00:09] <hads> There's phone/elec/water broken in places.
[00:10] <ojwb> hmm, it's quite shallow too
[00:11] <ajmitch> not bad enough to cut internet connectivity through to the south
[00:16] <hads> Yeah, some CHC people in other channel have gone away but I presume that's localised.
[00:22] <ojwb> hmm, it seems to be practically on a highway through a tunnel
[00:22] <ojwb> SH74
[00:23] <ajmitch> the lyttleton tunnel? that could be messy
[00:23] <ojwb> yes, that's probably the one
[00:23] <ojwb> http://maps.google.co.nz/maps?f=q&source=s_q&hl=en&geocode=&q=http:%2F%2Fmagma.geonet.org.nz%2Fservices%2Fquake%2Fkml%2F2.2%2Fsearch%3FexternalRef%3D3468575&ie=UTF8&ll=-43.596725,172.714477&spn=0.00965,0.016673&t=h&z=16
[00:27] <hads> That tunnel is pretty sturdy.
[00:27] <ojwb> well, that's good
[00:27] <ojwb> i was thinking they wouldn't have really factored big earthquakes into the design in that area
[00:29] <hads> I had a tour through that tunnel a few years back, was very interesting.
[00:29] <ojwb> seems stuff.co.nz and nzherald.co.nz aren't happy
[00:29] <ojwb> i wonder if that's load from everyone going to read them
[00:29] <ajmitch> probably a few too many people visiting those sites
[00:30] <ajmitch> geonet probably got another big load spike, too
[00:30] <ojwb> seems more likely than having colocated in chch
[00:30] <ojwb> yeah, but they're built for that
[00:30] <ajmitch> pretty sure stuff.co.nz is in wellington
[00:30] <hads> TV3 news has interesting footage at the moment
[00:31] <chilts> yep, in Welly, and Auckland too
[00:31]  * chilts used to work on Stuff
[00:31] <hads> Catalyst isn't it?
[00:32] <chilts> yep
[01:00] <ojwb> http://static2.stuff.co.nz/1298336332/489/4688489.jpg
[01:00] <ojwb> cathedral spire is toast
[01:02] <ajmitch> the building isn't quite as destroyed as twitter rumours say
[01:02] <ibeardslee> it'll be a mission to get it back as it was
[01:05] <ajmitch> yeah
[01:06] <ojwb> john key is going to try to fly down to see what it is like on the ground
[01:07] <ojwb> I can save him the flight - it's covered in rubble
[01:07] <ajmitch> but he has to be there to show his solidarity with the people, it's election year after all
[01:07] <ibeardslee> kewl .. pity the RSA had already had rocks land on it .. could have tried to co-ordinate that a bit better
[01:08] <ojwb> hmm, stuff could do with some copy editing
[01:08] <ojwb> repeated text and "The earthquake happened at a shallow depth of five to six metres below ground."
[01:08] <ibeardslee> yeah
[01:10] <ibeardslee> Police are saying multiple fatalities have been reported at several locations in the central city
[01:11] <ojwb> having watched the tv footage, I'd be amazed if nobody had been killed this time
[01:11] <ibeardslee> http://www.police.govt.nz/news/release/27193.html
[01:12] <ojwb> though one guy was talking about having helped some people out and failed to help a guy buried up to his waist in rubble, then they panned the camera and the building was just a heap of debris
[01:12] <ojwb> so it's amazing what you can get out of uninjured
[01:16] <ojwb> hmm, the police say that chch hospital is not evacuated
[01:16] <ojwb> the news repeatedly said it had been
[01:17] <ojwb> not totally helpful
[01:47] <Atamira> i dont know whethere to be happy or sad
[01:47] <Atamira> that happened 1 1/2hrs after i left chch
[01:49] <ibeardslee> that was lucky
[01:49] <ibeardslee> our people down there are ok
[01:49] <ojwb> Atamira: I'd go for happy
[01:50] <Atamira> true
[01:50] <Atamira> ive never been in an earthquake
[01:50] <ajmitch> Atamira: well you wouldn't have been leaving any time soon
[01:50] <ojwb> if you get the choice, happy is better
[01:51] <Atamira> but it would have been a valid excuse to not have to go to work
[01:51] <ajmitch> imagine if you'd been stuck in the city for a few days because of it?
[01:52] <ajmitch> & there goes another one that we could feel in dunedin....
[01:53] <wgrant> That's not good.
[01:53] <chilts> ajmitch: you just felt another just then?
[01:53] <chilts> :(
[01:53] <ibeardslee>  All NZ airspace shut down - central air traffic control in  Christchurch hit by massive earthquake
[01:53] <ibeardslee> not much flying going on
[01:53] <ajmitch> chilts: yep
[01:54] <chilts> geonet: 6.3, 4.5, 4.4, 4.0 ... and still your one to come
[01:56] <Atamira> my friend lives close to the centre of the city
[01:56] <Atamira> but not in the city
[01:56] <Atamira> so i wouldntve been near it
[01:57] <Atamira> i was in the square last thurs tho.
[01:57] <Atamira> shame about the cathedral
[01:57] <Atamira> if they dont fix any of the other old buildings
[01:57] <Atamira> i hope they fix that one
[01:57] <Atamira> its an icon to the city
[01:59] <ojwb> my geophysicist gf is wondering if there could be an aftershock off shore
[01:59] <ojwb> some of them are pretty close to the sea
[02:01] <chilts> anyone know where http://ubuntu-nz.org and can anyone get it?
[02:01] <chilts> I know this isn't important at the moment, but am just wondering
[02:01] <ajmitch> chilts: it just points to the wiki
[02:02] <ajmitch> or at least it should
[02:02] <chilts> ok
[02:02] <chilts> I never saw it in the title until just now :)
[02:02] <ibeardslee> someone was talking about following that up .. who was that?
[02:02] <ajmitch> uh, I think I said that we should, but it was never clear who'd do it :)
[02:04] <ibeardslee> ahhh
[02:04] <ojwb> seems to be owned by canonical
[02:05] <ojwb> the domain I mean
[02:07] <ajmitch> yeah, I can probably find the right people to talk to about it
[02:07] <chilts> ajmitch: that one you felt at 2:50 was a 5.5 and another shallow one (5km), centered on Lyttleton again
[02:07] <chilts> Lyttelton
[02:07] <ojwb> the one ajmitch felt just now was 5.5
[02:07] <ojwb> snap!
[02:07] <chilts> :)
[02:08] <chilts> the GeoNet recent quakes page is mostly Chch
[02:08] <ajmitch> so all these are just a practice run for a big one in wellignton :)
[02:08] <chilts> it's on the BBC now: http://www.bbc.co.uk/news/world-asia-pacific-12533291
[02:09] <ojwb> hmm, that one was in a harbour
[02:10] <ajmitch> ojwb: is that significant?
[02:10] <ojwb> well, being offshore makes a tsunami more likely
[02:10] <ojwb> which wouldn't be good
[02:14] <ojwb> then they'd just need the banks peninsula to become an active volcano...
[02:20] <ojwb> http://www.nbr.co.nz/article/earthquake-send-kiwi-dollar-plunging-db-86655
[02:20] <ojwb> apparently 0.88 cents is a plunge
[02:23] <mcgillicutty> earthquake??
[02:24] <ibeardslee> in Christchurch
[02:24] <ajmitch> yeah, a little bit of a shake
[02:24] <mcgillicutty> just saw it on the news.  Earthquakes seem to be becoming more and more common
[02:25] <Hoggs> This one seems to have done far more damage than the last
[02:26] <ibeardslee> yes .. deaths have been reported
[02:26] <ibeardslee> more buildings collapsed
[02:27] <Hoggs> Right at lunch time.. worst time it could have happened
[02:38] <snail> did a recent update break cups for anyone else?
[02:38] <hads> snail: Yes
[02:38] <hads> cups backend failed or somesuch
[02:38] <snail> did a restart ressurect things, or was more poking needed?
[02:39] <hads> Nope, still broken
[02:39] <hads> /usr/lib/cups/backend/hp failed
[04:18] <ojwb> the canterbury ring laser is down - we're open to alien attack! http://www.geonet.org.nz/earthquake/drums/
[04:32] <hads> heh
[05:41] <ojwb> hmm, I hope the weather is better in Christchurch than Wellington
[05:42] <lifeless> raining
[05:43] <ojwb> that's not going to make life much fun for anyone having to camp out the night
[05:45] <lifeless> indeed
[08:36] <karora> lifeless: Are you in Chch?
[08:37] <lifeless> rangiora
[08:37] <karora> Ah, OK.
[08:37] <karora> Any DDs in Chch itself?
[08:38]  * karora has been fielding the traditional "Are you OK?" e-mails from folk in Europe & the US...
[09:35] <lifeless> dunno
[18:55] <ajmitch> morning
[19:04] <Bacta> Sup
[19:05] <Atamira> mornin
[19:05] <Bacta> Hi Atamira, how's things?
[19:06] <Atamira> good thanks
[19:06] <Bacta> Have any family in Christchurch?
[19:06] <Atamira> and you?
[19:07] <Bacta> I'm okayish
[19:07] <Atamira> yes, and family is fine
[19:07] <Atamira> so are friends
[19:07] <Bacta> That's good
[19:07] <Bacta> Mine are too apparently, was a bitch getting in contact with them though
[19:07] <Bacta> Was worried about one family member because she was working in a building that was red stickered after the Sept earthquake
[19:10] <Atamira> yeah. we've been watching the news all night
[19:10] <Atamira> its affecting work as well
[19:10] <Atamira> communications in chch is restricted use.
[19:11] <Bacta> You live there?
[19:15] <Atamira> no, but i was on holiday there over the weekend for 5 days
[19:15] <Atamira> flew back to akld monday
[19:15] <Bacta> I was there on Saturday and Sunday
[19:15] <Atamira> i was there from thurs to monday
[19:15] <Atamira> my friends down there are ok
[19:15] <Atamira> as are my family
[19:15] <Bacta> Wow, dodged a bullet
[19:15] <Atamira> it wouldnt have been that bad for me
[19:15] <Bacta> I'm sorry but why the hell are tomaw, ikonia and elky in here? They're not Kiwis
[19:16] <Atamira> i wasnt in the town centre. already did that friday
[19:16] <Bacta> Ah yep?
[19:16] <ikonia> my sinceer best wishesto you all in .nz, be very careful out there
[19:17] <Bacta> *sincere *wishes to
[19:17] <Bacta> You're supposed to be English
[19:17] <ikonia> yes,
[19:17] <Atamira> ty ikonia
[19:17] <ikonia>  Bacta "too" not to
[19:18]  * Bacta headdesk
[19:18] <ikonia> Bacta: so don't get smart with me
[19:18] <Bacta> I hope you're joking
[19:18] <ikonia> no
[19:19] <ajmitch> people, please just shut up & behave, we don't need the aggro here
[19:19] <ikonia> how bad is the damage at the moment ?
[19:19] <Atamira> pretty bad
[19:19] <ajmitch> bad enough, judging from the photos I've seen
[19:19] <Atamira> communications is down, power is out. water has to be boiled
[19:19] <ikonia> the news in Europe is a bit bland due to the A/P political news being headlines
[19:20] <ikonia> Atamira: ok, so pretty much the back to raw basics
[19:20] <Bacta> Look for a NZ source perhaps?
[19:20] <ikonia> Bacta: europe isn't keen on broadcasting NZ sources, it tends to pickup the mail networks and just highlight coverage from NZ rather than play it properly
[19:20] <Bacta> The mayor is on TV again
[19:20] <ikonia> the riots in the middle east are taking headlines away from this
[19:20] <Atamira> ikonia, yeah.
[19:21] <ikonia> Atamira: what's the aid situation like, it looks a little lacking from here
[19:23] <Atamira> so far, no idea
[19:23] <Atamira> right now they are just concentrating on getting ppl out of collapsed buildings
[19:23] <Atamira> the army went in last night to help as well
[19:23] <ikonia> is there any official news death toll at the moment, the european numbers seem a little scaled back
[19:24] <Atamira> officially, we have confirmed 35 deaths.
[19:24] <Atamira> but the full tally is still in the estimates
[19:24] <ajmitch> unofficially, it's looking a lot higher than that
[19:24] <ikonia> that's actually better than we are getting reported
[19:24] <ajmitch> 2-300?
[19:25] <Atamira> true
[19:25] <Atamira> cause so many are unaccountable
[19:25] <Atamira> we can only hope for the best
[19:25] <ikonia> Atamira: 200 is the european current predication
[19:26] <ikonia> to be honest if it's only 200 I think you will have done "well" due to the size of the devistation, not that it is acceptable to lose any life
[19:26] <ikonia> it just looks like there should be more
[19:27] <ajmitch> looks like my ISP's network is congested again
[19:27] <Atamira> so far, we've been told its 65
[19:27] <Atamira> but that was again an estimate
[19:27] <ikonia> keep yourselves safe,
[19:27] <ajmitch> it could well be over 200 though, hard to know for a few days, I suspect
[19:27] <Atamira> yeah
[19:27] <Atamira> they are telling ppl to stay home
[19:28] <Atamira> i wonder if my friends will go to work
[19:28] <Atamira> they moved buildings cause the other one was unsafe
[19:28] <Atamira> and this new building was single story
[19:31] <ikonia> I bet a lot of people will want to work in single story buildings after this
[19:31] <hads> Huh? Where did that agro come from? Everyone is welcome here.
[19:31] <hads> Morning all
[19:31] <ajmitch> hads: he has a history with certain people :)
[19:31] <hads> Oh, maybe everyone isn't welcome then :)
[19:32] <ajmitch> everyone's welcome if they can behave
[19:33] <ikonia> common sense
[19:34]  * ajmitch heard from a friend via facebook, he got to spend about 7 hours helping get people out of a building yesterday
[19:34] <ikonia> that's the hope that the guys who can help each other
[19:37] <ikonia> is there solid medical support at the moment ?
[19:38] <ajmitch> from what I know, there is, hospitals around the country have been cleared out to take in people from christchurch
[19:39] <ibeardslee> morning
[19:40] <hads> Yeah as far as anyone knows from outside Christchurch search and rescue + medical is going fine.
[19:42] <Atamira> latest news said that alot of the ops for this week have been postponed and chch ops are being sent up here for them
[19:43] <hads> Hospital was cleaned out of non-acute people yesterday afternoon
[19:46] <Atamira> armourguard have sent ppl down there
[19:46] <Atamira> and one of my work collegues, her flatmate was sent down for work and rescue stuff with dogs
[20:24] <mwhudson> good morning
[21:19] <snail> this earthquake stuff; it's happened before: http://www.nzetc.org/tm/scholarly/Cyc03Cycl-fig-Cyc03Cycl0555b.html http://www.nzetc.org/tm/scholarly/Gov06_01Rail-fig-Gov06_01Rail024a.html http://www.nzetc.org/tm/scholarly/tei-NHSJ06_03-t1-body1-d1-d5.html


[01:11] <MrWGW-> hey there
[01:12] <MrWGW-> I find it highly annoying that /bin/sh is symlinked to dash by default, because dash is not fully compatible with the Bourne Shell, let alone bash
[01:12] <MrWGW-> what would the chances be of that being changed to a symlink to /bin/bash?
[01:12] <MrWGW-> just symlinking it to bash would reduce the size of /bin slightly and improve compatibility with other distros and UNIX like OSes
[01:13] <MrWGW-> if that's a bridge too far, perhaps ash could be used; ash implements most of bash and is also properly backwards compatible with Bourne
[01:14] <infinity> MrWGW-: sudo dpkg-reconfigure dash
[01:15] <xnox> MrWGW-: see past discusions and reasons why we switched to dash. It's faster and significantly decreases boot speed. Bashism is not compiant. Debian also uses dash. If you depend on bash the you should specify #!/bin/bash
[01:15] <infinity> MrWGW-: dash is POSIX-compliant, which is all that one requires from /bin/sh so, no, we won't switch back.
[01:15] <infinity> MrWGW-: The above dpkg-reconfigure will let you change it on your own systems, if you prefer.
[01:16] <infinity> MrWGW-: But yes, as xnox states, if your scripts use bashisms, they're not /bin/sh scripts, and should specify #!/bin/bash
[01:17] <infinity> MrWGW-: (As for your statements about ash, ash in Debian is just a package that ships a symlink to dash...)
[01:17] <infinity> MrWGW-: dash was derived from ash.
[01:20] <MrWGW-> infinity: in ash, echo -e and functions work properly
[01:20] <MrWGW-> I have some Buffalo Linkstation NASes that use ash, and I have scripts that run correctly on that ash version, but not on your dash
[01:20] <infinity> MrWGW-: I suspect you're wrong, and what you really mean is "in my version of ash, echo isn't a builtin".
[01:21] <MrWGW-> I would propose that what you guys should have done, that would have been a better design: use dash during booting, but refer to it explicitly with the path /bin/dash in your scripts, but meh
[01:21] <infinity> MrWGW-: If you rely on non-POSIX extension to echo, use /bin/echo
[01:22] <infinity> MrWGW-: If you rely on non-POSIX shell functions, use the shell you want to use explicitly.
[01:22] <MrWGW-> my script uses a POSIX compliant function declaration which is breaking on dash
[01:23] <infinity> Really?
[01:23] <infinity> MrWGW-: If you're using the keyword "function", that's not POSIX.
[01:25] <infinity> MrWGW-: You want "funcname() { code; code; }" not "function funcname() { code; code; }".  The latter is a bashism.
[01:25] <MrWGW-> I'm using funcname()
[01:25] <infinity> Then what's breaking?
[01:25] <MrWGW-> when executing the script I'm getting an /usr/bin/nssync: 5: Syntax error: "(" unexpected
[01:25] <infinity> We have shell functions all over the place.
[01:26] <infinity> That's exactly what you'd see if you prefaced the line with "function".
[01:27] <MrWGW-> its not prefaced
[01:27] <MrWGW-> maybe the dash executable file is corrupt
[01:27] <MrWGW-> brb while I check this
[01:27] <infinity> Could you show us the script?
[01:27] <MrWGW-> btw one thing that I do appreciate, this dash business aside, is that you continue to ship upstart vs. systemd
[01:27] <geofft> Can you write a small example that demonstrates the problem?
[01:27] <geofft> foo() { echo hi; } appears to work for me, in dash.
[01:28] <MrWGW-> yes, once I verify its not a problem on my machine
[01:29] <MrWGW-> hmmm this is strange, the dash image file on this freshly provisioned 12.10 instance on Azure has a different md5 checksum than the same file on an ubuntu 12.10 system I have in the lab
[01:30] <MrWGW-> I'm going to provision another 12.10 instance and see if the problem persists, and if not, we can chalk it up to Microsoft stupidity
[01:30] <infinity> Both the same architecture?
[01:30] <MrWGW-> yes, x86_64
[01:31] <MrWGW-> do you guys have access for development purposes to a Windows Azure cloud account?   Its remotely possible there's an oddity with their image, but I've started the provisioning of another instance
[01:31] <infinity> The error you pasted doesn't sound like something that would come from a corrupt dash, just a broken script.
[01:31] <MrWGW-> its also remotely possible that someone somehow pwnt my 12.10 instance in between the time of its initial provisioning and my attempting to install this script on it
[01:31] <infinity> -rwxr-xr-x 1 root root 105712 Aug 15 04:41 /bin/dash
[01:31] <infinity> b0c9cf166a0a3051e1f1c359f3e50d17  /bin/dash
[01:31] <MrWGW-> the line of code in the script is conf_transfer()
[01:31] <infinity> ^-- This is what Q's dash should look like, though.
[01:32] <MrWGW-> that matches the md5 checksum on my lab box but not on the azure one
[01:32] <infinity> MrWGW-: Immediately followed by a {, I assume?
[01:32] <geofft> Is there a bashism on the previous line of code?
[01:32] <MrWGW-> infinity: yes
[01:33] <infinity> Oh, it's quite possible you have a rootkit and that's not dash at all, yes.
[01:33] <MrWGW-> that's my thought
[01:33] <MrWGW-> especially since the other instance just came up and the md5 checksum is what it should be on that
[01:33] <MrWGW-> weird though that it got pwnt in that manner, given that it only had ssh key based authentication
[01:33] <MrWGW-> strange
[01:33] <MrWGW-> fortunately it wasn't in production yet
[01:33] <infinity> Yeah.  We build the Azure images, I'd like to think I'd know if they were broken.
[01:34] <MrWGW-> I'm going to blow that instance away
[01:34] <MrWGW-> I use azure as a backup for my colo servers because I get it with my bizspark subscription
[01:34] <infinity> Makes a valid argument for doing security updates within seconds of initial install.  But still, ew.
[01:35] <MrWGW-> on another matter, are there any semi-official or official derivatives planned featuring Mate?
[01:35] <MrWGW-> I'd really like to see a Kubuntu or Lubuntu style derivative with Mate, designed to fit on a single CD ROM disc
[01:36] <infinity> Nothing planned that I know about, but I certainly won't stand in the way of someone willing to do the work.
[01:37] <MrWGW-> do you think if such a derivative were produced it could get recognized to the same extent as Kubuntu, Lubuntu, Xubuntu et al?
[01:37] <MrWGW-> assuming it was of sufficient quality and so on
[01:38] <infinity> Googling for Mubuntu (the obvious choice of name?) got me to http://sourceforge.net/projects/mubuntuproject/
[01:38] <infinity> No idea how active that is, and it's not in the Ubuntu archive.
[01:38] <MrWGW-> I myself miss the convenience of the single-CD live CD, as CD-Rs are a heck of a lot cheaper than DVD-Rs, the Mate vs Unity thing is less a big deal for me becauseI mainly use Ubuntu server-side, but a lot of the older guys at the LUGs I go to have been up and arms over Ubuntu, and are either not updating their systems or they're increasingly installing Mint or some other third-tier distro
[01:38] <infinity> Certainly, if someone was willing to do the work as an Ubuntu developer in the archive, we've not stop them.
[01:38] <MrWGW-> another good name for what I just proposed would be Ubuntu Classic Edition
[01:38] <infinity> MrWGW-: I gave up on spinny media long ago, and just install from USB sticks.
[01:39] <MrWGW-> infinity: USB sticks are good, but I own a vast collection of computers some of which lack boot from CD support
[01:39] <MrWGW-> also I prefer to use my USB sticks for other things
[01:39] <MrWGW-> so having a large array of disposable blank CD ROMs is useful as they're just dirt cheap
[01:39] <MrWGW-> even the drives are dirt cheap
[01:40] <MrWGW-> at fry's they're selling LG OEM blu ray disks for $10
[01:40] <MrWGW-> BD-ROM units
[01:40] <MrWGW-> so when my desktop systems have an optical drive failure, which is a fairly routine occurence, replacement is no big deal
[01:40] <infinity> MrWGW-: MATE also appears to have a repository of packages built for Ubuntu, so one can do a minimal install, then slap MATE on.
[01:40] <MrWGW-> its more of a headache on laptops and servers that use weird proprietary disk drives
[01:40] <infinity> (I'd still definitely prefer to see this happen in the Ubuntu archive, but whatever)
[01:41] <MrWGW-> infinity: well I'd love to roll a MATE variant which would feature MATE already on the syste, be sized to fit a single CD ROM, or smaller, and feature the Ubuntu font and desktop background
[01:41] <MrWGW-> providing a polished experience similiar to that of Ubuntu 10.10 (which I personally consider to be the zenith of Ubuntu desktop releases thus far)
[01:42] <infinity> 12.04 is pretty shiny.
[01:42] <MrWGW-> and my enthusiasm for this is driven by the fact that your distro is sticking to upstart, which is a really nice init system IMO
[01:42] <MrWGW-> I really like the GNOME 2.x interface that 10.10 featured, it was very nice, it also had the prettiest wallpaper IMO
[01:43] <infinity> Heh.
[01:43] <MrWGW-> I am looking forward to seeing some Ubuntu TVs and phones hit the market though
[01:43] <infinity> Well, wallpaper can always be rescued.
[01:43] <MrWGW-> I suspect we'll really start to see Unity shine on those systems
[01:43] <MrWGW-> infinity: I use The Dawn of Ubuntu wallpaper on one of my systems, from 6.10
[01:43] <infinity> I know I also had problems with the GNOME2->Unity transition, so much so that I used to run XFCE tailored to look just like old skool Ubuntu.  But, I eventually conformed.
[01:43] <MrWGW-> Edgy Eft
[01:43] <infinity> I now run a stock Unity setup on raring.
[01:44] <MrWGW-> as far as I'm concerned systems like Unity are optimized for tablets and should be used on them, but for workstation use something else is needed
[01:44] <MrWGW-> MS is making an even bigger mistake with the Metro UI
[01:44] <infinity> http://lucifer.0c3.net/~adconrad/xubuntu.png <-- My old XFCE desktop, before I switched to Unity.
[01:44] <MrWGW-> which is completely inappropriate for desktop or workstation use
[01:45] <MrWGW-> now if you don't care about workstation use then this is a moot point, but for a technical power user like myself, a different style of interaction is required
[01:45] <MrWGW-> at that, a lot of workstation guys like to use an even more minimal X system running blackbox or something of that nature
[01:45] <MrWGW-> but that's just a bit too spartan for me
[01:45] <infinity> I've become even more keyboard-driven since forcing myself to switch to Unity.  This isn't a bad thing.
[01:45] <MrWGW-> I do like having a nice pretty background and transparent menu bars
[01:45] <MrWGW-> I use ThinkPads and on my desktop, Thinkpad style USB keyboards, which feature trackpoint mice
[01:45] <infinity> Ditto.
[01:46] <MrWGW-> these reduce the overhead of moues usage
[01:46] <MrWGW-> I'm right hnaded, but I can maneuver the trackpoint with my left index finger
[01:46] <MrWGW-> (I also use Sun Type 7 UNIX layout keyboards on some of my workstations, and I have a few other keyboard varieties of a more conventional nature
[01:46] <MrWGW-> a Unicomp M series clone, a pair of keytronics keyboards, and so on
[01:46] <MrWGW-> I am a keyboard afficianado
[01:46] <MrWGW-> there's a really pretty $75 gaming keyboard at fry's that I want
[01:47] <MrWGW-> so I'm going to in the next few weeks look into the possiblity of doing the MATE variant we just discussed
[01:47] <MrWGW-> and if conditions permit, I'll start working on it
[01:47] <MrWGW-> I have a relative in the hospital now
[01:47] <MrWGW-> so that's the only real variable
[01:48] <MrWGW-> but if it can be done, it would be pretty cool, and it would also have the effect of silencing some of the anti-Ubuntu people who are whining about Unity or the other changes you've made
[01:48] <MrWGW-> changes which I should add are superficial and irrelevant
[01:48] <MrWGW-> the important thing is that you guys have avoided making unpleasant changes to the underlying system, i.e. systemd
[01:48] <MrWGW-> and I hope you keep it that way
[01:49] <infinity> We'll never silence all the detractors.  They could easily run Xubuntu, Lubuntu, or Kubuntu, but they choose to focus on what the "official Ubuntu CD" has on it.
[01:49] <MrWGW-> I have historically been a heavy CentOS/Scientific Linux user, but the new changes in the most recent Fedora builds that will be going into RHEL 7 are...unpleasant
[01:49] <infinity> And if it's not exactly what they want, complaints.  Such it life.
[01:49] <MrWGW-> infinity: having a Mubuntu or Ubuntu classic edition would silence the more legitimate detractors
[01:49] <MrWGW-> or rather
[01:49] <MrWGW-> it would keep them happy and in the fold
[01:49] <MrWGW-> and take marketshare away from Linux Mint
[01:50] <MrWGW-> you have a bunch of customers who use your product and like it, but odn't like some, but not all, of the new changes, so it makes sense to allow for a community-developed variant to meet their needs
[01:50] <infinity> I have no interest in sticking it to Mint.  But I also don't mind if MATE ends up in Ubuntu's archive.  So, whatever happens.
[01:50] <MrWGW-> that way they can be happy, you can be happy and so on
[01:50] <MrWGW-> the only Linux distro I really want to stick it to right now is Fedoera heh
[01:51] <MrWGW-> the arrogance of their engineering steering committee is astonishing
[01:51] <infinity> I thought there was an effort to get MATE into Debian.  If that's still ongoing, that would be the obvious first place to contribute.
[01:51] <infinity> Cause if it's in Debian, Ubuntu gets it (nearly) for free.
[01:51] <MrWGW-> the changes they've made have the effect of breaking compatibility with other distro, with other Unices, with sysv, with POSIX
[01:51] <MrWGW-> and brekaing everyone's management scripts and software
[01:51] <infinity> And building images based on that wouldn't be rocket surgery.
[01:51] <MrWGW-> I believe MATE is already in Debian
[01:52] <MrWGW-> but I'll check on that
[01:53] <mbiebl> MrWGW-: it isn't
[01:54] <infinity> But there's a lively debate in the ITP bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658783
[02:00] <MrWGW-> I'll take a look
[02:00] <infinity> Seems like the general concensus is "not while MATE still ships a bunch of duplicate old skool code".
[02:00] <infinity> But they're working hard on moving from gconf to gsettings, dropping old libs, moving to GNOME3 libs on the backend, etc.
[02:01] <infinity> So, may be more favourable soon.
[02:02] <MrWGW-> gah if the Debian developers block MATE I'm going to hate that project even more than I do already
[02:03] <infinity> I don't see any blocking going on.
[02:03] <infinity> There's a freeze in Debian right now anyway.
[02:03] <infinity> And pre-1.6 MATE was a no-go for a variety of good reasons.
[02:03] <infinity> Things may be shaping up now.
[02:04] <mbiebl> infinity: forking gconf was pointless in the first place
[02:04] <mbiebl> gconf is still maintained upstream
[02:05] <mbiebl> if they switch to gsettings fully, then hopefully this won't matter
[02:06] <Bluefoxicy> ughhhhh
[02:07] <Bluefoxicy> Find the person that decided it was a good idea to un-highlight when highlighting in the Rhythmbox search box or Playlist name (when editing the playlist name) and hang him.
[02:07] <Bluefoxicy> I can't believe somebody exerted positive energy to add this behavior.
[02:07] <Bluefoxicy> Omissions of stuff that really needs to be done yes.  Why would you take a perfectly round wheel and plaster corners onto it?
[02:08] <infinity> MrWGW-: I just commented on the Ubuntu bug, BTW: https://bugs.launchpad.net/ubuntu/+bug/876675
[02:08]  * Bluefoxicy complain.  Should file bugs.  Should git blame and file bugs.
[02:08] <MrWGW-> infinity: by the way
[02:08] <MrWGW-> you might just port over the Linux Mint repo
[02:08] <MrWGW-> since they're binary compatible with Ubuntu anyway
[02:08] <MrWGW-> at least in theory
[02:08] <infinity> MrWGW-: That's not going to happen. :P
[02:09] <MrWGW-> why not just fork their repo?
[02:09] <MrWGW-> if it works
[02:09] <MrWGW-> and would save time...
[02:09] <infinity> The "if it works" part is the important bit there.  And my experience with Mint's packaging quality hasn't been stellar.
[02:09] <MrWGW-> I'll take a look
[02:09] <infinity> Either way, I have no interest in packaging MATE.  It will need an active maintainer in Debian and/or Ubuntu, or it's really not going to happen.
[02:09] <MrWGW-> hmm and you know I tihn ktheir standard Mate is slightly modified
[02:10] <MrWGW-> they use a SUSE style taskbar with a start menu if I recall
[02:10] <MrWGW-> so yeah
[02:10] <MrWGW-> so suppose, if my relative is OK and I can commit the time, I become the maintainer of Mate and the shipper of the Mate variant we've discussed
[02:10] <MrWGW-> would that be alright with you?
[02:10] <MrWGW-> Mate would I presume live in the "universe" repo right?
[02:10] <infinity> Are you an Ubuntu developer?
[02:11] <MrWGW-> not at present
[02:11] <MrWGW-> i am a sysadmin who runs about 200 Ubuntu server systems though
[02:11] <infinity> Well, that's something you might want to work on if you want to seriously commit to maintaining an etire DE.
[02:11] <Bluefoxicy> that's different than maintaining a package
[02:11] <infinity> But you're not signing up for a simple/minimal task there, either.
[02:11] <Bluefoxicy> maintaining a package involves having a clue about what's going on around you, which is really the hard part since nobody e-mails you when a new version of your stuff is out.
[02:11] <infinity> Desktop environments take a ton of work.
[02:12] <Bluefoxicy> figuring out the packaging stuff is a one-off thing.
[02:12] <Bluefoxicy> when I tried to maintain the pax-utils package, every 6 or 7 versions the lead developer would poke me and ask why I didn't update the package in ubuntu
[02:12] <MrWGW-> I do understand the time commitment; that's why I have to wait to see how my relative is doing before I can commit
[02:12] <infinity> (Not trying to discourage, just warn... DE maintainers are grumpy people... Except for Riddell, nothing seems to get him down)
[02:17] <MrWGW-> I do get that
[02:17] <MrWGW-> and given the surge in popularity MATE is experienceing its also possible someone better qualified will rise to the occasion and do this
[02:17] <MrWGW-> but within the next few weeks I'll decide
[02:18] <MrWGW-> the other question I would have is if Ubuntu plans on introducing systemd in the next three years
[02:19] <MrWGW-> because what I'm really seeking for myself is to maintain a system that preserves the classic sysV init compatible upstart system, fits on a single CD, supports a wide range of Linux filesystmes for the root and boot partition, and has MATEand right now Ubuntu fits the bill
[02:19] <infinity> It's not in our current plans, no.  It would likely only happen if it ended up forced on us by outside influences.
[02:19] <MrWGW-> what about the fact that udevd and systemd are now developed from the same codebase?
[02:19] <infinity> Like, if all Linux systems become dependent on systemd and we have no choice.  But I don't see that happening, as much as the systemd guys want it to.
[02:19] <MrWGW-> could that force your hand to any extent?
[02:19] <infinity> Nah.
[02:19] <infinity> It can still be built independently.
[02:20] <MrWGW-> if that happened I'd just say screw it and switch all my stuff to OpenBSD and freeBSD
[02:20] <MrWGW-> I already use those OSes on half of my server systems
[02:20] <MrWGW-> all of my filers are FreeNAS systems and OpenBSD runs on all of my firewalls and network managemnet devices
[02:20] <MrWGW-> but as you of course know
[02:20] <MrWGW-> there are some things that are still more ocmfortable and pleasant to do on a Linux system
[02:21] <MrWGW-> Im of the opinion that Linux first took off in the 1990s because it was generally compatible with other UNIX systems, it of course had the GPL license, and it was also the leanest, most bloat-free UNIX system available in that timeframe
[02:21] <MrWGW-> even now some aspects like the Linux kernel's use of a generic task structure to represent both threads and processes set it apart from other more complicated systems
[02:22] <MrWGW-> so  Ithink the trick for Linux to remain relevant is to stick to these values on which its success was built
[02:22] <MrWGW-> as opposed to following in the footsteps of AIX and Solaris and OS X to unlimited bloat and ugliness and proprietary, incompatible extensions
[12:42] <bdrung> Sweetshark: when will libreoffice 3.5.7-0ubuntu2 be available in precise-proposed? i am hit by bug #585910
[12:44] <bdrung> Sweetshark: it would be nice to have at least libreoffice 3.6.4 in raring
[12:45] <bdrung> Sweetshark: can we sync 3.6.4-1 from debian experimental?
[12:46] <ricotz> bdrung, if you want you can use the quantal version in the libreoffice ppa with raring
[12:47] <bdrung> ricotz: i don't want i fix for myself. i want a fix in the archive.
[12:48] <ricotz> bdrung, raring will get 4.0 and he don't want to spent time on 3.6.x then
[12:49] <ricotz> bdrung, syncing is not possible due the missing ubuntu specific patches
[12:49] <mitya57> I don't think we can sync 3.6.4-1 because of unitymenus patch
[12:50] <bdrung> okay, i will look into merging 3.6.4-1 when i have time instead of waiting for 4.0 to arrive
[12:53] <ricotz> bdrung, i would recommend to forward port https://launchpad.net/~libreoffice/+archive/ppa/+sourcepub/2835951/+listing-archive-extra
[12:55] <ricotz> didnt have time for it, but the obvious problem was the recognizing python in raring
[14:03] <melodie> hello
[14:05] <melodie> does someone know what must be done to get a normal color background in Ubiquity frontend gtk please ? not around the window but inside ? Here is what I get (a remix project I try to put up) : http://meets.free.fr/debian/images/ubiquity-frontend-gtk-look.png
[14:05] <melodie> is xnox here ? :)
[18:36] <streulma> hello, is the Evolution-calendar bug already fixed in 12.10?
[18:41] <melodie> streulma, what is this bug ?
[18:43] <streulma> melodie: many of the people I know have the calendar bug in Ubuntu 12.10
[18:43] <streulma> Evolution is not used
[18:43] <melodie> streulma, and what does this bug do ?
[18:45] <streulma> melodie: see here: https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/1064136
[18:49] <Aeyoun>  Hi. I have a problem with deb packaging. Every file in debian/* is copied over to the build-area *except* for the upstart file so it fails to be detected by dh_installinit and is not included in the package.
[18:49] <Aeyoun> I have studied other deb packages and cannot see that any of them are doing anything different from what I am doing.
[18:50] <Aeyoun> Have verified that the upstart file is not copied over by monitoring the file system. Have also placed debug code in dh_lib and made sure it would have worked if the file was copied into the build-area correctly.
[18:51] <Aeyoun> What process is responsible for copying over files from src/debian/* to build-area/package-name/debian/?
[18:51] <infinity> Is it named <package>.upstart?
[18:51] <Aeyoun> infinity, I have tried with upstart and <package.upstart>
[18:51] <Aeyoun> and <package>.foo.upstart
[18:52] <infinity> It would be dh_installinit that's meant to install it.  Which should Just Work, if you're using dh(1), but if you're using old skool debhelper (by calling each one manually), you may be missing _installinit.
[18:52] <Aeyoun> The verbose output says shows that dh_installinit runs but it does not output anything. Debugging it shows that it does not find the file and this is skipped.
[18:52] <infinity> From here, I'd probably need to see the source package in question.
[18:52] <Aeyoun> The Ubuntu packaging guide learned me to package using `bzr builddeb -- -us -uc`
[18:53] <Aeyoun> infinity, I would be grateful if you could assist me. :-) I'll upload the source.tar and my debian/ now.
[18:53] <infinity> Oh, wait.  You mean bzr bd isn't exporting it?
[18:54] <infinity> That could be as simple as you needing to bzr add the file.
[18:54] <Aeyoun> if by "not exporting" you mean does not copy it from source/debian/ to ../build-area/packagename/debian, than yes.
[18:54] <infinity> (I assumed you meant it was in debian/ in the source package, but not getting installed into the binary package)
[18:55] <infinity> But if you mean it's in your source REPO, but not making it into the source PACKAGE, that sounds like maybe it's just not actually in the repo. :P
[18:55] <infinity> (ie: needs a bzr add, or a commit)
[18:55] <Aeyoun> Oh. I did not know that. o.O
[18:55] <Aeyoun> (Sorry for pasting directly)
[18:55] <Aeyoun> bzr status
[18:55] <Aeyoun> modified:
[18:55] <Aeyoun>   debian/control
[18:55] <Aeyoun>   debian/rules
[18:55] <Aeyoun> unknown:
[18:55] <Aeyoun>   debian/upstart
[18:55] <Aeyoun>   debian/watch
[18:55] <Aeyoun>   debian/source/format
[18:56] <infinity> The first step in bzr bd is to export the repo, so you have a clean source package.  Export (in any VCS) won't export files that aren't tracked.
[18:56] <infinity> So, "bzr add debian/upstart debian/watch debian/source/format" and try again.
[18:56] <Aeyoun> The Ubuntu Packaging guide should probably have mentioned that I needed to do that.
[18:57] <infinity> This is a mistake I make about 5 times a week when exporting from Debian glibc SVN to my source package and wondering where my new patches went. :P
[18:57] <Aeyoun> infinity, please kiss yourself and dance happily around on the floor with yourself from me! :-D You solved my eight day mystery problem!! :-D
[18:59] <Chipzz> make sure you also commit debian/control and debian/rules, because the package you build may not have these changes
[19:02] <infinity> Chipzz: Committing isn't necessary for test-building with bzr bd.
[19:02] <infinity> Chipzz: Export will catch modified files, just not untracked ones (to avoid cruft)
[19:03] <Chipzz> infinity: ah k. not used to bzr, slightly more familiar with git
[19:03] <Chipzz> different mindset :P
[19:04] <infinity> Well, git would behave the same if you did a git add, then export.  That's just not most people's git workflow (most people do "git commit -a" and just add the world, if random tutorials are to be believed)
[19:09] <Aeyoun> I am also more familiar with git. Never used bazar for anything.
[19:09] <Chipzz> I tend to stage/commit my changes with vim and gitv/fugitive ;)
[19:09] <Aeyoun> I assumed it would use my working directory and not the repo.
[19:10] <infinity> Aeyoun: It does use your working copy, but new files aren't actually part of your working copy without adding them, that's all.
[19:10] <infinity> Fairly classic behaviour inherited from CVS and SVN, among others.
[19:10] <Aeyoun> I really wish it would give me a warning. "These files are untracked or have uncommitted changes: $list"
[19:11] <Aeyoun> or some other indication that would have made the last few days more productive. :-P
[19:11] <infinity> You could file a wishlist bug on bzr-builddeb to warn about untracked changes on invocation.  Might be handy.
[19:12] <infinity> (Personally, I don't use any of the foo-builddeb packages, so I have a pretty low care-factor)
[19:17] <Aeyoun> https://bugs.launchpad.net/bzr-builddeb/+bug/1096433
[19:20] <infinity> Aeyoun: Danke.  Added a distro task to the bug as well.
[19:22] <Aeyoun> Another question, am I supposed to use the 0ubuntu1 tag to packages I upload to ppas? or is that just for "official" packages?
[19:22] <infinity> You can version PPA packages however you want.  BUT.  If you plan to upload to the archive later, and want smooth upgrade paths, I'd recommend something like:
[19:22] <infinity> Debian: 1.2.3-1
[19:23] <infinity> Ubuntu: 1.2.3-1ubuntu1 (or 1.2.3-0ubuntu1, if ours is a newer upstream)
[19:23] <infinity> PPA: 1.2.3-1ubuntu1~ppa (or 1.2.3-0ubuntu1~ppa, see above)
[19:24] <infinity> The "~ppa" on the end will make sure that version sorts just before the "real" -0ubuntu1, which would be what you'd want to upload to the archive.
[19:24] <infinity> And you can rev those (~ppa1, ~ppa2, ~ppa3, etc) ad nauseum, and still be able to use the proper version number for the archive later, with a sane upgrade path.
[19:25] <Aeyoun> thanks again, that makes sense.
[19:26] <infinity> (The string there doesn't matter, it's the ~ that's the magic "just before the previous bit" sorting, so you could use 1.2.3-0ubuntu1~aeyoun1, if you want them more personalised and easier to track when people whine about a specific version)
[19:27] <maxb> You might also see things like 1.2.3-0ppa1 or 1.2.3-0ubuntu0ppa1 which are accomplishing more or less the same thing - the important thing is how the version comparisons turn out compared to versions in Debian and Ubuntu official archives.
[19:27] <maxb> -0ppa1 is taking gratuitous advantage of the fact that 'p' comes before 'u'
[19:28] <infinity> maxb: Yeah, lots of schemes work.  I like the realversion~ppaversion thing because it denotes "I plan for this to eventually be released as 'realversion' some day".
[19:28] <infinity> But to each their own.
[19:28] <infinity> It doesn't even matter if PPAs sort lower than the archive (or clash, even) except, as I mentioned, giving users sane upgrade paths.
[19:29] <infinity> Which is always a nice thing to do.
[19:29] <maxb> I like the realversion~ppaversion thing too, when that is actually what is being denoted :-)
[20:04] <WONDERFULWONDER> #join
[20:08] <Deborah_Meltrozo> Hello
[20:09] <WONDERFULWONDER> hi
[20:09] <Deborah_Meltrozo> Can anyone recommend me a tool, framework, etc for Unit Testing, if its GUI-based is better
[20:09] <Deborah_Meltrozo> on Python
[20:26] <WONDERFULWONDER> quit
[20:26] <WONDERFULWONDER> #quit
[20:32] <WONDERFULWONDER> try download quickly but it is not downloading pls help
[20:34] <dkessel> WONDERFULWONDER, how do you try to download, and what is the error you get?
[20:50] <melodie> could someone help me with the ubiquity theme setup for a remix ?
[20:51]  * melodie annoyed after several days seeking the web docs and wikis
[22:27] <Aeyoun> Hi again. I ran into another problem. This time with pbuilder-dist quantal mypackage.dsc. "amd64" has snuck in at the end of the CFLAGS. Resulting in ""cc: error: amd64: No such file or directory" error.
[22:28] <infinity> Aeyoun: Can you point me at the sources?
[22:28] <infinity> (Also, I can't believe we still recommend pbuilder... Should really talk to someone about fixing that)
[22:29] <Aeyoun> the upstream makefile has $(ARCH) after $(CFLAGS). This is not a problem when running  `make build` nor `bzr builddeb`. pbuilder, however, sets this variable.
[22:30] <infinity> That seems like a goofy thing for the upstream Makefile to do unless it's meant to be setting it to something.
[22:31] <Aeyoun> it is set on OS X but no other platform. :-)
[22:32] <infinity> Set to what, though?
[22:32] <Aeyoun> fatbinary.
[22:32] <infinity> Anyhow, you could just explicitly unset it.
[22:32] <Aeyoun> 32+64 bit
[22:33] <infinity> "unexport ARCH" in your debian/rules might tidy that up.
[22:37] <infinity> A more correct fix to forward to upstream would be for them to explicitly set it to an empty string on all platforms, then twiddle it on OSX to whatever weird thing they want.


[23:15] <plenglin_> hello, im having trouble with my installation
[23:16] <plenglin_> when i try logging in through the login page, xorg apparently crashes
[23:17] <plenglin_> https://paste.ubuntu.com/p/xCpcnkxv9W/ this is the xorg.0.log
[23:17] <plenglin_> https://paste.ubuntu.com/p/zZfsNgwHf7/ this is the xorg.0.log.old
[23:17] <plenglin_> could anyone help me
[23:31] <plenglin_> can anyone help with my problem?


[01:07] <shadeslayer> i cant seem to be able to install a sid pbuilder on kubuntu :S
[01:27] <directhex> new sid builders are sometimes broken
[01:27] <directhex> sid's like that
[02:02] <maxwellian> Is the Ubuntu Applications menu built up from .desktop files in /usr/share/applications?  I'm on Xubuntu, and I have a different menu, but I'm working on a menu-related bug for Ubuntu.
[02:03] <wgrant> maxwellian: Yes, it uses .desktop files too.
[02:03] <maxwellian> wgrant: So what are the .menu files for?
[02:04] <wgrant> maxwellian: The Debian menu, which is used by some other WMs.
[02:04] <wgrant> But KDE, GNOME and XFCE all use freedesktop.org .desktop file standard.
[02:04] <wgrant> And not .menu files.
[02:05] <maxwellian> wgrant: Okay, that makes a lot more sense now.  Thanks!
[02:06]  * maxwellian wishes Google would index dot-files rather than just stripping the punctuation
[02:07] <wgrant> Yes :(
[02:07] <maxwellian> wgrant: In that case, does it make sense to send a patch to Debian which adds the .desktop file?  Ideally they would put it in their package so we could all benefit, but if it's not used by Debian, would they include it?
[02:08] <wgrant> maxwellian: Debian does use .desktop files.
[02:08] <wgrant> But some of the WMs don't.
[02:08] <wgrant> maxwellian: Better yet, send it upstream.
[02:08] <wgrant> So all distributions benefit.
[02:08] <wgrant> And neither us nor Debian have to maintain the delta forever.
[02:12] <maxwellian> wgrant: Right, well I'll send the patch to both Debian and upstream then.  Not sure if upstream would know what to do with it, but if Debian takes it then we can just sync the package from them next time.
[03:49] <bbordwell> Hello, I am a bug triager and I am not very familiar with the SRU process. Is there anything else that should be done to this bug to get the SRU team to look at it?
[03:49] <bbordwell> https://bugs.launchpad.net/gdebi/+bug/591470
[04:28] <jdong> heh. the goto usage in the openvpn SRU. :)
[04:36] <ScottL> jdong, could you answer a question about doing an SRU for ardour (#581786)
[04:36] <ScottL> #581786
[04:37] <ScottL> crap  https://bugs.launchpad.net/ubuntustudio/+bug/581786
[04:37] <ScottL> i cannot nominate the 10.04 LTS version as an SRU candidate
[04:37] <ScottL> i can nominate lots of others and the trunk series, should i just nominate the trunk and make mention in the SRU that it's for the 10.04 series?
[04:39] <lfaraone> jdong: I saw your comment on bug 601219, and I already uploaded to the queue earlier yesterday.
[04:40] <micahg> ScottL: try this link to nominate for lucid: https://bugs.edge.launchpad.net/ubuntu/+bug/581786
[04:40] <ScottL> i will micahg , thank you
[04:42] <ScottL> eh, micahg, it gives me an 'lost something?' page when i try to nominate from the link :(
[04:42] <ScottL> can i start a new bug for this?
[04:43] <micahg> ScottL: you should probably file a bug against malone for that
[04:43] <micahg> ScottL: here: https://bugs.edge.launchpad.net/ubuntu/+source/ardour/+bug/581786
[04:44] <ScottL> micahg, success!  many thanks
[04:45] <micahg> ScottL: np, LP just needed package/distro context
[07:32] <bilalakhtar> Please see bug #606610
[13:04] <shadeslayer> TheMuso: poke
[13:04] <shadeslayer> can you join #ubuntu-packaging if your around
[18:14] <ScottL> can someone help me with uploading to release-proposed on an SRU ? https://bugs.edge.launchpad.net/ubuntu/+source/ardour/+bug/581786
[18:17] <nigelb> ScottL: as per new policy, you should subscribe sponsors
[18:35] <ScottL> nigelb, ubuntu sponsors team?
[18:36] <nigelb> yes
[18:39] <ScottL> nigelb, done
[18:40] <ScottL> nigelb,  i am nervous about timing since this is for 10.04.01, am i to wait until sponsors contacts me or is there an irc channel i can talk to sponsors?
[18:42] <nigelb> sru can be done any time
[18:42] <nigelb> also of note, canonical employees are in prague at a platform "rally"
[18:44] <nigelb> but sponsors include a lot of community members and they'll get to it soon :)
[18:44] <nigelb> you can try asking here tomorrow
[18:48] <ScottL> nigelb, capital!  thank you very much
[18:49] <nigelb> ScottL: heh, what I can I say, I'm lazy ;)
[18:54] <fabrice_sp> ScottK, what tests did you in Lucid?
[18:55] <fabrice_sp> sorry, bad ping
[18:55] <fabrice_sp> ScottL,
[18:56] <ScottL> fabrice_sp, yes, i tested it locally in lucid
[18:57] <fabrice_sp> it has to be a new instalation, if I understand correctly the bug report
[18:59] <ScottL> fabrice_sp, that is correct
[18:59] <ScottL> i created another lucid install on a new partition to test it
[18:59] <fabrice_sp> ok. I'll try to reproduce it, and your patch fix it also here, I'll upload to -proposed
[18:59] <fabrice_sp> deleting the ardour directory in the home is also correct, no?
[19:01] <ScottL> yes fabrice_sp
[19:02] <ScottL> fabrice_sp, as per the bug
[19:03] <fabrice_sp> ok. Sorry for asking, then :-) (I am doing several things at the same time)
[19:04] <ScottL> fabrice_sp, oh, no...i wasn't chastising, i just wanted to make sure you knew the right directory!  sorry 'bout that
[19:05]  * fabrice_sp is installing ardour in a lucid chroot
[19:05] <fabrice_sp> np :-)
[19:05] <ScottL> i'm multitasking (heh, i just told the other person the same) and profusely apologize for the misrepresentation
[19:07] <fabrice_sp> don't worry ;-)
[19:08] <fabrice_sp> argh: it has to be a VM..
[19:16] <ScottL> fabrice_sp, i'll be in and out with the kids today, i'll keep checking irc throughout the day through
[19:29] <ScottL> fabrice_sp, this is my first SRU, i hope i'm doing everything correctly ;)
[19:30]  * shadeslayer wants a SRU too
[19:35] <shadeslayer> fabrice_sp: poke
[19:40] <shadeslayer> if someone can SRU bug 565376
[19:41] <shadeslayer> it even has a debdiff ;)
[20:18] <fabrice_sp> ScottL, all my vms are maverick ones. Sorry: I won't be able to upload your sru
[21:07] <crimsun_> ScottL: https://bugs.edge.launchpad.net/ubuntu/lucid/+source/ardour/+bug/581786/comments/10
[21:37] <micahg> if I click retry on 1 arch, does it retry all of them?
[21:38] <crimsun_> I've always had to iterate through all the desired arches
[21:39] <micahg> crimsun_: ok, thanks
[21:44] <ScottL> crimsun_, looking at comment
[21:45] <ScottL> crimsun_, does that mean it's uploaded for the SRU?
[21:46] <crimsun_> ScottL: did you receive a "waiting for approval" e-mail?
[21:46] <crimsun_> ScottL: i.e., you should have
[21:47] <crimsun_> ScottL: to answer your original question: yes, I uploaded it
[21:49] <ScottL> crimsun_, i haven't checked email yet, i shall however
[21:50] <ScottL> crimsun_, also apparently i didn't include changelog update, i shall do that in the future as well
[21:50] <ScottL> crimsun_, thanks!  :)
[21:53] <crimsun_> yw
[21:53] <ubutuser> hello
[21:54] <ubutuser> someone know how can i see all packages in one category using apt via command line?
[22:25] <geser> micahg: but there is a script that can give-back a package on all arch (or a subset if desired)
[22:29] <micahg> geser: I just wanted to give back on one arch to made sure it works
[22:29] <geser> it can do it too, if you don't want to use the web ui or have to repeat it for several packages
[22:30] <micahg> geser: k, is that in archive-tools?
[22:30] <geser> ubuntu-build from u-d-t
[22:30] <micahg> geser: k, thanks
[22:31] <geser> it has an old interface which only accepts one package and a new one (--batch) which accepts several packages
[23:14] <lfaraone> Does ~ubuntu-sru have the ability to approve SRU uploads, or is that part of the Archive Admin team?
[23:17] <geser> IIRC only AA
[23:17] <ScottK> If by approve, you mean accept into the archive, it's archive admin.
[23:17] <ScottK> Except for jdong, I think all ubuntu-sru members are archive admins.
[23:17] <ScottK> (or at least among the active ones)
[23:30] <devfil> ScottK, no
[23:31] <devfil> I'm not
[23:45] <RoAkSoAx> ScottK: Can you do me a favor? Could you please sync bug #605955 :)


[00:41]  * MarkMaglana likes butternut squash soup with coconut milk
[00:41] <MarkMaglana> but first, coffee
[08:33] <__chip__> MarkMaglana: calabacín relleno ftw
[08:33] <__chip__> good morning all
[08:34]  * __chip__ still in alter-ego mode for today
[08:39] <MarkMaglana> __chip__: damn that relleno looks yummy! now i gotta find me one of those.
[08:43] <__chip__> jam: dunno if you saw we landed a fix to master for the flake8 woes, just chaning the charm.py for now
[08:43] <__chip__> changing*
[08:43] <jam> __chip__, I didn't see that, thank you
[08:43] <__chip__> we can look at pinning versions at some point but for now this was alright
[08:43] <__chip__> jam: i was tempted to merge it into everything red but didnt' want to trip you up :)
[08:44] <__chip__> (just 279 bah)
[08:44] <__chip__> (i merged it into mine, and i expect facu merged it into his)
[08:53] <jam> __chip__, do we have any idea why it fails on travis but not locally?
[08:53] <jam> I struggled to get a working 'different' version of flake8
[08:53] <jam> tip seems broken against the pycodestyle it requires
[08:53] <__chip__> jam: it fails locally if you install flake8 and autopep8 from pip
[08:53] <__chip__> jam: last night the rules seemed more subtle than what you'd reported so maybe the issue you saw was fied
[08:55] <__chip__> jam: flake8 now asks for  pycodestyle<2.7.0,>=2.6.0a1
[08:55] <__chip__> jam: and autopep8, pycodestyle>=2.5.0
[08:56] <__chip__> so I get pycodestyle 2.6.0 and everything's happy (except our tests until we fixed master)
[08:56] <jam> Chipaca, https://paste.ubuntu.com/p/zVsD7qkmG9/
[08:56] <jam> flake 3.8.1, pycodestyle 2.6.0 pyflakes 2.2.0 and flake8 fails AFAICT
[08:56] <__chip__> jam: maybe pip install -U ?
[08:57] <__chip__> jam: I get flake8-3.8.1, pycodestyle 2.6.0, and pyflakes 2.2.0, and it's happy
[08:57] <jam> The original install was pip3 install --upgrade --user flake8 pydocstyle autopep8
[08:58] <__chip__> jam: maybe it's python 3.6 that's the issue?
[08:58] <__chip__> i'm on 3.8 here
[08:58] <__chip__> let me try with 3.6
[08:59] <jam> the traceback implicates importlib-metadata, but that has "skipping upgrade importlib-metadata; python_version < "3.8"
[08:59] <__chip__> er, can't do 3.6, doing 3.5
[09:00] <__chip__> jam: that's happy too
[09:00] <jam> __chip__, is there a clear 'uninstall everything and try again' ? Or I can just go back to whatever flake8 was working and stop fighting it :)
[09:01] <__chip__> jam: https://gitlab.com/pycqa/flake8/-/issues/406
[09:01] <__chip__> which points to …
[09:01] <jam> __chip__, opened 2 years ago, and fixed by depending on a specific version of pycodestyle
[09:01] <__chip__> yeah
[09:02] <__chip__> jam: wrt 'uninstall everything and try again', i just blow away the venv
[09:02] <jam> which now we're 2 versions beyond that
[09:02] <__chip__> jam: let's compare 'pip list' output
[09:03] <__chip__> jam: https://paste.ubuntu.com/p/nRgxRx4NSn/
[09:03] <jam> https://paste.ubuntu.com/p/FDyjwXB8x3/
[09:04] <jam> (that is the one that works, let me upgrade and try again)
[09:05] <jam> this flake8 fails to load: https://paste.ubuntu.com/p/QxcZMwwfrT/
[09:07] <__chip__> jam: what happens if you grep for break_around_binary_operator in the lib?
[09:07] <__chip__> I only see a _break_around_binary_operator method in pycodestyle
[09:07] <__chip__> nothing calling into it
[09:09] <mup_> Issue operator#282 opened: Harness: Unable to assert if framework was called correctly by charm <Created by relaxdiego> <https://github.com/canonical/operator/issues/282>
[09:10] <jam> lib/python3.6/site-packages/pycodestyle.py:1279:def _break_around_binary_operators(tokens):
[09:10] <jam> it is an '_break'
[09:11] <__chip__> jam: right, but what tries to call break_around_binary_operator ?
[09:12] <jam> __chip__, so it is something about magically loading plugins, but my system doesn't seem to have that string, digging
[09:12] <__chip__> that exception should really print what file it's trying to load, huh
[09:13] <__chip__> MarkMaglana: thanks for the bug report!
[09:13] <jam>  /usr/lib/python3/dist-packages/pycodestyle.py
[09:13] <jam> who installed that...
[09:13] <MarkMaglana> __chip__: no worries! :)
[09:14] <__chip__> jam: gremlins
[09:14] <jam> __chip__, 'apt install flake8' depends on pycodestyle
[09:14] <jam> apparently the plugin loading finds the dist package but imports from the non-dist ?
[09:14] <jam> so to have a 'pip3 install --user flake8' I can't have an 'apt install flake8'
[09:17] <jam> __chip__, so with apt remove flake8 and a bunch of dependencies, ./run_tests fails for the "right" reason
[09:18] <__chip__> jam: huzzah, maybe
[09:18] <jam> ok, so I at least can reproduce and merged the fix and pushed it
[09:19] <__chip__> MarkMaglana: question for you
[09:20] <__chip__> MarkMaglana: what does 'build_juju_unit_status' do?
[09:21] <__chip__> MarkMaglana: ah, found it
[09:21] <MarkMaglana> __chip__: it just returns a *Status object based on arguments: https://github.com/relaxdiego/charm-k8s-grafana/blob/b689a77cb2714075b2c88e5fe6442e26f1ca033e/src/domain.py#L72-82
[09:21] <MarkMaglana> :)
[09:21] <__chip__> MarkMaglana: what is pod_status?
[09:21]  * __chip__ digs more
[09:21] <__chip__> ah, something from k8s?
[09:22] <MarkMaglana> __chip__: you got it
[09:22] <jam> __chip__, so if I understand correctly, what Mark wants is to see that his code is setting the unit status to A, and then to B, and then finally to C as part of responding to the config_changed event.
[09:23] <jam> __chip__, however, we don't assert at each step, so you can only see the final "after all is done the status is correct"
[09:23] <__chip__> MarkMaglana: why wouldn't k8s.get_pod_status return a framework status directly?
[09:23] <jam> __chip__, the config-changed handler is looping on the result of a mocked get_pod_status and should notice the transition of the pod to being active
[09:23] <MarkMaglana> __chip__: that one is to actually check if the k8s pod's livenessProbe and readinessProbe both return true.
[09:24] <jam> MarkMaglana, does the above sound correct for what you are trying to do?
[09:24] <jam> There are 2 possibilities as I see it. 1) I do have code for a _get_backend_calls() that would give details of how you interact step by step, I don't knw that I recommend that route, but the PR is https://github.com/canonical/operator/pull/264
[09:25] <mup_> PR #264: test/test_model.py: Test Model using Harness._get_backend calls <Created by jameinel> <https://github.com/canonical/operator/pull/264>
[09:25] <jam> b) You could change your mock so that you check the unit status just before you return a new pod status
[09:25] <MarkMaglana> i think i found that calling the framework status directly doesn't give me the fine-grained result that i needed. at the time I wrote that, the framework reported the pod as ready but in the k8s layer it was just live but not yet ready to receive requests. I wanted to make sure I reported that correctly to `juju status` so that the user doesn't panic or wonder what's going on.
[09:25] <jam> so you can see "the unit status started as X, then I returned pod status Y, then the unit status updated to Y, then I returned Z, and the unit status updated to Z"
[09:26] <__chip__> "the framework reported the pod as ready but in the k8s layer it was just live but not yet ready to receive requests" ← isn't that a bug in the framework?
[09:26] <jam> __chip__, it is a practical reality that saying "start this" takes a while for it to actually start
[09:26] <jam> __chip__, there is the k8s layer that says the container has started
[09:27] <jam> __chip__, and there is the "can I actually connect to the socket of the app"
[09:27] <__chip__> ahhh
[09:27]  * __chip__ ahhhs
[09:27] <MarkMaglana> that's what i report with PodStatus: https://github.com/relaxdiego/charm-k8s-grafana/blob/b689a77cb2714075b2c88e5fe6442e26f1ca033e/src/adapters/k8s.py#L75-L99
[09:28] <MarkMaglana> is_running looks at the livenessProbe and is_ready looks at the readinessProbe
[09:31] <MarkMaglana> jam: sorry i didn't notice that you were chatting me up with a different topic :)
[09:31] <jam> MarkMaglana, all of that should be prefaced with, I believe in Juju 2.8 pod-spec-set was made "transactional" which means Juju won't ask k8s to start the pod until your hook exits. So setting the pod spec and spinning isn't going to get you anywhere because Juju hasn't actually started the pod yet.
[09:51] <MarkMaglana> jam: that "transactional" tip is good information. in that case what would be the best way to report back to the user about the actual status of the underlying workload?
[09:52] <jam> MarkMaglana, I'm raising the question internally if it should be transactional. one option is to hook into the 'update-status' hook that Juju fires periodically (approx every 5 min). It isn't a great update rate
[09:52] <jam> MarkMaglana, the other option is to use something like cron / a forked subprocess
[09:52] <jam> and use "juju-run" to get back into the hook context and report back
[09:52] <jam> I don't think we have much to make that easy in the framework, unfortunately
[09:53] <MarkMaglana> jam: yeah 5 mins is not ideal. :)
[09:53] <jam> There have also been conversations that Juju should be triggering events on pod state changes
[09:53] <jam> But all that is hypothetical
[09:53] <MarkMaglana> gotcha. hmmmm.
[09:54] <MarkMaglana> jam: interesting challenge to tackle but for now, what do you suggest i do with the assertion? should i forego checking if the status was set 3x in my unit test and just check if the final status is correct?
[09:55] <MarkMaglana> brb my washer/dryer is singing lol
[09:55] <jam> so there is (1) which is use my patch that adds direct checking of every backend call, (2) check in the individual steps, (3) break apart the two so the one side emits events, and then you can have a second handler that monitors what events are sent. (4) just assert the final state
[10:01] <MarkMaglana> jam: thanks! i'll check out all options. :)
[10:04] <__chip__> yuss, got a dispatch shim main working
[10:04] <__chip__> main.py is now a mess
[10:05] <__chip__> refactoring :)
[10:41] <MarkMaglana> in case this helps anyone else, this has been a godsend for me when reviewing code on github: https://chrome.google.com/webstore/detail/sourcegraph/dgjhfomjieaadpoljlnidmbgkdffpack
[11:03] <mup_> PR operator#283 opened: ops/main: handle dispatch being a shim  <Created by chipaca> <https://github.com/canonical/operator/pull/283>
[11:04] <__chip__> jam: ^ wdyt?
[11:05] <jam> __chip__, about SourceGraph or about dispatch? :)
[11:05] <__chip__> jam: the latter
[11:05] <__chip__> haven't looked at the former yet
[11:05]  * __chip__ looks
[11:06] <__chip__> MarkMaglana: doesn't github already do that?
[11:07] <MarkMaglana> __chip__: well sh**. you're right! lol.
[11:08] <__chip__> MarkMaglana: doesn't quite work in firefox yet :( but they'll get it there
[11:09] <MarkMaglana> __chip__: I'm more of a Brave browser hipster guy.
[11:10] <facubatista> Muy buenos días a todos!
[11:11] <__chip__> MarkMaglana: ah! it does work, i was just impatient
[11:11] <__chip__> facubatista: heyy
[11:12] <facubatista> hola __chip__
[11:13] <__chip__> facubatista: could you start your day with a nice fresh cup of #276?
[11:13] <mup_> PR #276: explicitly ask for a newer sphinx on rtd <Created by chipaca> <https://github.com/canonical/operator/pull/276>
[11:13] <facubatista> __chip__, gladly
[11:14]  * facubatista pours himself a cup of that
[11:14]  * __chip__ passes facubatista a smaller cup
[11:14]  * facubatista clumsyly spoils all the bytes all over desk and keyboard
[11:15]  * __chip__ hands facubatista the kitchen towels
[11:15]  * __chip__ watches facubatista dress up as a mummy
[11:15]  * __chip__ /o\
[11:16] <facubatista> jajaja
[11:16] <jam> __chip__, did you even send an email/meeting for Ajduk to reschedule?
[11:17] <__chip__> i did not even
[11:17] <__chip__> i did send one to jay
[11:23] <mup_> PR operator#276 closed: explicitly ask for a newer sphinx on rtd <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/276>
[11:38] <__chip__> jam: to schedule meetings with people in utc-6, should i make you optional, or is there any time that might work for you?
[11:40] <jam> __chip__, depends how much you want me to be there. :) I can make exceptions and work an evening here and there,and I'm willing to do a regular "monday nights I work evenings" but I wouldn't want it to be at arbitrary times
[11:41] <__chip__> jam: you kick ass at these meetings, not having you there makes them so much worse :) maybe one day a week you work evenings and we schedule these meetings for then? (i think it's just 2 (so far!) that are that far west)
[11:42] <jam> __chip__, one day a week is manageable
[11:43] <__chip__> jam: as it's just two, bi-weekly, tell me what day and at what hour :)
[11:43] <facubatista> jam, so, I deployed my blog as subordinate, which implied adding the relation to apache; at that moment "relation_joined" triggered on my charm, and I did some prints at that time...
[11:43] <jam> __chip__, so your thought is 2 every other week, or one every week?
[11:44] <facubatista> jam, as a next step, I wrote the proper code for that hook (configuring apache, if I'm right)... and then upgraded my charm... but "relation_joined" didn't trigger again... only "configuration changed"
[11:45] <facubatista> jam, what is the appropiate thing to do here? shall I hook that method to some other specific event and make it trigger? use config_changed for that? I'm failing to do a step properly?
[11:47] <jam> facubatista, so relation-joined only happens 1 time, when the new unit is seen. relation-changed would happen multiple times if Apache is giving you feedback.
[11:47] <jam> facubatista, I would think that telling Apache "here use this directory" only really needs to be told to it one time.
[11:47] <jam> Now, if some of your config causes a change in what content you are telling Apache about
[11:48] <jam> then in *config-changed* you would call self.model.get_relation('apache').data[self.unit] =new stuff
[11:48] <facubatista> jam, I don't really have a config that is related to Apache, in that sense
[11:48] <facubatista> jam, so, this is useful except when "bulding" my code :(
[11:49] <facubatista> yes, when all is done it should work ok
[11:50] <facubatista> jam, can I trigger that "relation_joined" manually somehow?
[11:50] <facubatista> or I could use an "action"
[11:50] <jam> __chip__, so 8am UTC-6 is 6pm UAE time. If that works, then doing those on Mondays at 6pm (just after our standup) would be a good time.
[11:50] <jam> If we need to go later because people don't start at 8am, then I'd still probably want to do them on Monday.
[11:51] <jam> facubatista, if you just want to test your code, I think you can do "juju run --unit some/1 'hooks/relation-joined'"
[11:52] <jam> the other option is to remove the relation and add it again, but that will kill the unit and create it again
[11:53] <facubatista> jam, if I do "juju run --unit some/1 'hooks/relation-joined'", the event I got still have a .relation pointed to apache?
[11:53] <facubatista> *will still have
[11:53] <jam> __chip__, so that would be Monday, UTC 14:00. But I could go until UTC 18:00 if necessary
[11:54] <jam> facubatista, I don't think Juju sets the JUJU_RELATION_ID, etc if you manually trigger a hook
[11:56] <jam> facubatista, 'get_relation' should still work, because the relation is still defined, but event.relation probably won't be set
[11:57] <facubatista> another reason to stop using `event.relation.data` and go to `self.model.get_relation('apache').data`, which looks less "backwards thinking" than the former
[11:59] <facubatista> jam, mmm... in `self.model.get_relation('apache').data` I'm expressing "the data from an application", not "the data from an unit"
[11:59] <jam> facubatista, you're looking at all the relation data there
[11:59] <jam> so you still need
[12:00] <jam> self.model.get_relation('apache').data[unit/or/app]
[12:00] <__chip__> jam: ack. I'll look at the calendar later and let you know what it looks like.
[12:00] <jam> __chip__, #283 reviewed. I think we're still missing a case
[12:00] <__chip__> I've jused realised the time, the bug revue, and the lack of lunch
[12:00] <mup_> PR #283: ops/main: handle dispatch being a shim  <Created by chipaca> <https://github.com/canonical/operator/pull/283>
[12:00]  * __chip__ takes the laptop to the kitchen
[12:02] <facubatista> jam, meeting?
[13:31] <facubatista> jam, __chip__, standup?
[13:42] <__chip__> https://github.com/sphinx-doc/sphinx/pull/7655  :-D
[13:42] <mup_> PR sphinx-doc/sphinx#7655: Make sphinx.util.typing.stringify render optional unions better <autodoc> <enhancement> <Created by chipaca> <Merged by tk0miya> <https://github.com/sphinx-doc/sphinx/pull/7655>
[13:47] <__chip__> facubatista: #280 GTG
[13:47] <mup_> PR #280: Included the dependencies in requirements files, updated README and .travis <Created by facundobatista> <https://github.com/canonical/operator/pull/280>
[13:47] <facubatista> __chip__, thanks
[13:47] <mup_> PR operator#280 closed: Included the dependencies in requirements files, updated README and .travis <Created by facundobatista> <Merged by facundobatista> <https://github.com/canonical/operator/pull/280>
[13:48] <facubatista> jam, boo https://paste.ubuntu.com/p/jSgxJZjzbT/
[13:48]  * facubatista will write an action for this
[13:48] <mup_> Issue operator#282 closed: Harness: Unable to assert if framework was called correctly by charm <Created by relaxdiego> <Closed by relaxdiego> <https://github.com/canonical/operator/issues/282>
[14:29] <DominikF> Hey all! I tested the `charm create -t operator-python` command today and wanted to provide some feedback. I didn't find the changes here https://github.com/juju/charm-tools , has the repository changed?
[14:34] <__chip__> DominikF: which changes?
[14:35] <DominikF> __chip__: The changes that enabled this new template
[14:35] <__chip__> DominikF: charm-tools is that repository, but we're not charm-tools (i don't really know what that command does... so maybe it's unmaintained?)
[14:38] <DominikF> __chip__: sorry maybe I misunderstood. Last week we had a conversation about having skeleton charms for the operator framework and I was told that this was added to the charm-tools. The command that I listed above does exactly that and works great, I thought it was the work that your team was talking about.
[14:39] <__chip__> DominikF: i'm glad it works :-D but if it was done by my team, it was done before i was on it
[14:39] <__chip__> DominikF: maybe cory_fu_?
[14:40] <DominikF> __chip__: sorry! I thought it was recent work and found it strange that there was no new commit for it.
[14:41] <__chip__> DominikF: sadly, no
[14:41] <__chip__> at _some_ point charmcraft will grow that ability, but not just yet (it didn't make the roadmap)
[15:54] <mthaddon> __chip__, DominikF: charm tools is maintained by cory_fu https://github.com/juju/charm-tools/tree/master/charmtools/templates and the operator-python template pulls from https://github.com/devec0/template-python-operator currently
[15:54] <__chip__> mthaddon: ack
[15:55] <mthaddon> __chip__: maybe that should at some point be owned by the charmcraft team (the python-operator template)?
[15:56] <__chip__> mthaddon: at some point there'll be a 'charmcraft init'
[15:56]  * __chip__ will also add a 'charmcraft innit' which will be like 'bruv'
[15:57] <mthaddon> hahaha, ah cool - would that have different options for "give me an IaaS charm" and "give me a k8s charm"?
[15:57] <DominikF> mthaddon: that's exactly what I wanted to ask
[15:57] <__chip__> mthaddon: it got kicked to the next cycle so i don't have details :) or i could say "probably"
[15:57] <DominikF> If there could be a template for k8s charms
[15:57] <__chip__> i mean
[15:57] <__chip__> ideally there'd be no difference :)
[15:58] <__chip__> we're almost there with dispatch
[16:00] <mthaddon> DominikF: there's some discussion about this on https://discourse.juju.is/t/first-steps-with-the-operator-framework/3006/4 fwiw
[16:03] <DominikF> mthaddon: thanks!
[16:46]  * __chip__ breaths a sigh of releif
[16:46] <__chip__> relief also
[17:16] <cory_fu> mthaddon, __chip__: Sorry for the long delay in replying; had some particularly long meetings today.  Getting caught up on the discussion
[17:16] <cory_fu> DominikF: ^
[17:20] <cory_fu> I'm the defacto maintainer of charm-tools but it's basically just been in maintenance mode rather than active development since we expect it to be phased out by charmcraft.  The template PR was contributed and comes from that external repo, as noted, so changes to the template should be proposed there.
[17:21] <cory_fu> My understanding, though, is that the intention with the new framework is to try to keep boilerplate small enough that ideally a template wouldn't be needed.  Ideally, creating a K8s charm vs a machine charm shouldn't be significantly different but might involve importing some different helpers to use with your charm class.
[17:22] <cory_fu> I think the template is a stop-gap and there is the issue that it is likely to get out of date as the design patterns evolve.
[17:23] <__chip__> cory_fu: thanks!
[17:24] <cory_fu> I'm also looking forward to charmcraft being a much more focused tool.  A lot of things, like the template system, have grown organically into charm-tools over the years that I think really make things more confusing for the end user.
[18:20] <mup_> Issue operator#269 closed: Warn that model.unit.is_leader() can raise an exception <Created by timClicks> <Closed by timClicks> <https://github.com/canonical/operator/issues/269>
[21:32]  * facubatista is out
[22:01] <Chipaca> 👋


[06:46] <didrocks> good morning
[07:03] <oSoMoN> good morning
[07:18] <MacSlow> greetings everyone
[09:44] <andyrock> njpatel, ping
[09:44] <njpatel> andyrock, hey
[09:44] <njpatel> andyrock, dude, I recompiled your branch yesterday and none of my branches were showing up!
[09:44] <njpatel> branches?
[09:44] <njpatel> devices
[09:45] <andyrock> njpatel, in ccsm the device option is Only Mounted right?
[09:45] <njpatel> andyrock, yes, i tried all the device options
[09:46] <andyrock> njpatel, how do you start unity?
[09:46] <njpatel> andyrock, also, you connect to GSettings automatically, but we have FavouriteStore to hide the implementation (and provide a nicer interface)
[09:46] <njpatel> andyrock, compiz --replace
[09:46] <andyrock> njpatel, from tty?
[09:46] <njpatel> andyrock, from gnome-terminal
[09:47] <andyrock> njpatel, this is weird...
[09:49] <andyrock> njpatel, sometimes if i start unity (and compiz) form tty (alt+ctrl+f1) gio stuff doesn't work
[09:49] <njpatel> andyrock, yeah, I'll try the branch again with clean compile in a couple of hours (in the office and have some meetings)
[09:49] <njpatel> andyrock, interestin
[09:50] <njpatel> andyrock, could you take a look at the favoritestore thing and i'll ping you once I've had a chance to rebuild?
[09:50] <andyrock> njpatel, i think the problem is in gio/glib... but i start unity from gnome-terminal it should work...
[09:50] <njpatel> andyrock, I'll also try logging out and logging in
[09:50] <andyrock> njpatel, of course...
[09:50] <njpatel> andyrock, I always start from gnome-terminal, that's why I was a bit worried
[09:51] <andyrock> njpatel, so DevicesSettings should be derived from favoritestore right?
[09:52] <andyrock> njpatel, i will look it this afternoon... i have to go to gym now :)
[09:53] <njpatel> andyrock, I think use the FavoritesStore instance (I think it's a singleton)
[09:53] <njpatel> andyrock, okay, have fun! :)
[09:53] <andyrock> njpatel, you too (meetings etc. :P )
[13:27] <andyrock> njpatel, do you have a moment?
[13:28] <njpatel> andyrock, somewhat, what's up?
[13:29] <andyrock> njpatel, about FavoriteStore...
[13:29] <andyrock> njpatel, FavoriteStoreGSettings derive from FavoriteStore
[13:29] <andyrock> DeviceSettings could derive from FavoriteStore...
[13:30] <andyrock> but in FavoriteStore.cpp we have:
[13:30] <andyrock> FavoriteStore& FavoriteStore::GetDefault()
[13:30] <andyrock> {
[13:30] <andyrock>   static internal::FavoriteStoreGSettings instance;
[13:30] <andyrock>   return instance;
[13:30] <andyrock> }
[13:30] <njpatel> andyrock, yeah
[13:31] <andyrock> njpatel, it'a a bit weird as a super class :)
[13:32] <andyrock> njpatel, maybe i can join DeiviceSettings in FavoriteStoreGSettings...
[13:33] <njpatel> andyrock, agreed :)
[13:33] <njpatel> andyrock, it's thumper's doing ;)
[13:34] <njpatel> andyrock, it's nice to have them sepeaate to be able to test them separately
[13:34] <njpatel> separate*
[13:35] <andyrock> njpatel, i don't understand.... can you make an example?
[13:35] <andyrock> njpatel, please :)
[13:38] <njpatel> andyrock, I just mean that, in devices settings, when you change the gsettings stuff, you should just be using FavoriteStore instead
[13:38] <njpatel> andyrock, i.e. there should be no "GSettings" in DeviceSettings, just FavoriteStore
[13:42] <andyrock> njpatel, but FavoriteStore is an abstract/virtual class...
[13:43] <njpatel> andyrock, FavoriteStore::GetDefault () gives you the singleton that you need to work on
[13:43] <njpatel> work with *
[14:05] <andyrock> seb128, around?
[14:05] <seb128> yes
[14:06] <andyrock> seb128, about this bug: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/806485
[14:06] <seb128> yes?
[14:07] <andyrock> seb128, a g_object_unref(stream) in make_pixbuf should be good...
[14:07] <seb128> right
[14:07] <seb128> we discussed it with thumper earlier and that's what he suggested as well
[14:08] <andyrock> seb128, but i have a question for you :) can you give me the right valgrind command to collect information? :)
[14:08] <seb128> but feel free to do a merge request to fix it ;-)
[14:08] <seb128> andyrock, https://wiki.ubuntu.com/Valgrind
[14:09] <seb128> use the command from there on "compiz --replace"
[14:09] <andyrock> seb128, g_input_stream_close doesn't unref the stream...
[14:09] <andyrock> seb128, ok thx
[14:10] <seb128> right, the api documentation is not really clear, it could suggest that it needs to be freed
[14:12] <andyrock> agreed
[19:06] <jcastro> Hi!
[19:06] <jcastro> anyone here for the unity contributor meeting?
[19:10] <jcastro> ok, looks like no one has pending issues, so I'll just stand by if people have questions


[12:15] <sakrecoer[bpist]> I made the error to let Discover take care of the kernel upgrade... and it crashed for some reason...
[12:15] <sakrecoer[bpist]> how do i find out which version of the kernel is the latest that is provided to apt?
[12:15] <sakrecoer[bpist]> But it looks like the kernel was properly installed
[12:15] <sakrecoer[bpist]> s/installed/upgraded
[12:20] <sakrecoer[bpist]> looks like it's current 5.15.0-41-lowlatency
[12:20] <sakrecoer[bpist]> i looked it up in packages.ubuntu.com but i'm not sure that's proper way to do it anymore...
[21:33] <arraybolt3[m]> To Setto Setto (UTC+2): Looks like that's the right one.
[21:33] <arraybolt3[m]> Yeah, packages.ubuntu.com should be a fine way to find out.
[21:33] <arraybolt3[m]> (Also, I let Discover update my kernel all the time, so that's odd that it crashed.)