[00:17] <smartboyhw> 12.04.3 still NOT released?
[00:17] <smartboyhw> slangasek, ^
[00:19] <phillw> smartboyhw: has there been an announcement? :P
[00:19] <smartboyhw> phillw, what's the thing holding up 12.04.3? Wubi?
[00:19]  * smartboyhw has a serious hatred with Wubi
[00:20] <phillw> Riddell: you okay with i386 alternate for kubuntu? I'm currently downloading it for testing.
[00:21] <smartboyhw> phillw, I thought you should do desktop:P
[00:22] <phillw> ahh.. the lubuntu bot has been active :D
[00:22] <phillw> drat, he's darn good!
[00:26] <phillw> Riddell: can you mark xubuntu alternate i386 ready for release?
[01:13] <ScottK> phillw: I can do it, but you aren't a Xubuntu person are you?
[01:15] <skellat> ScottK: No, phillw is not.
[01:15] <ScottK> So it should be a Xubuntu product person saying it's ready.
[01:16] <skellat> ScottK: I've been pinging those who have the power to say so.  The ball is in their court, so to say.
[01:18] <phillw> ScottK: I'm a lubuntu release manager, but when all tests have been completed and passed, the big bosses can mark as ready. Unit193 is a xubuntu person, but not a release manager.
[01:20] <TheDrums> bluesabre: Didn't we elect you?
[01:21] <bluesabre> TheDrums: yes, I think I have release powers now
[01:23] <skellat> If Xubuntu is the only thing blocking, would we actually get a 12.04.3 release out or would it wait for a few hours anyhow?
[01:23] <phillw> bluesabre: ScottK TheDrums it is obviously not really for me to tell xubuntu that xubuntu is ready, in my defence I have been liasing getting the repsin done to correct a bug that was found, and another that smartboyhw found in kubuntu to get the very late respins done :)
[01:23] <phillw> skellat: I believe the straggler is now wubi.
[01:24]  * TheDrums didn't ping phillw.
[01:25]  * skellat feels invisible again
[01:25] <skellat> :-)
[01:25] <bluesabre> phillw: I've not heard anything against releasing from the xubuntu side, and it looks like all of our tests are passing
[01:26]  * phillw it has been an interesting excercise as 14.04 is lubuntus 1st LTS so I wanted a practice run with a friendly team :)
[01:26] <bluesabre> I'll mark our remaining iso as ready
[01:28] <phillw> bluesabre: If in the same situation with lubuntu, I'd be happy to mark as ready. Only one thing for release notes is that of the cryptoswap reporting an error on 1st boot when using encrypted /home area.
[01:29] <bluesabre> ah, is that happening on all flavors or just lubuntu?
[01:30] <phillw> bluesabre: I've seen it mentioned on lubuntu, so was not suprised to see it in xubuntu. The OP can do nothing about it, the system boots up okay and then you don't see the error message again.
[01:33] <bluesabre> best/worst kind of error :)
[01:33] <phillw> bluesabre: and royal pain to reproduce!
[01:34] <stgraber> slangasek: disappearing for today, so if you feel like releasing today, you'll have to take care of the announcement e-mail yourself, otherwise I'll be around tomorrow to take care of that
[01:34] <infinity> stgraber: Send someone the announce email, and we'll send it out on your behalf. ;)
[01:35] <infinity> stgraber: Or send it now and I won't moderate it. :P
[01:35] <infinity> (Hopefully no one else will either)
[01:36]  * phillw I thought that xnox had done the wubi tests, or is that still being a PITA?
[01:37] <stgraber> infinity: it's at: http://pad.ubuntu.com/ubuntu-12-04-3-announce (most flavour links 401/403/404 though so some coordination would be needed there)
[01:38] <infinity> stgraber: Given slangasek's relative silence, I'm guessing the release isn't in the next hour anyway.
[07:36] <ara> good morning all!
[07:36] <ara> what's the plan with the release of 12.04.3?
[07:39] <smartboyhw> Well, at least most likely we have to wait until slangasek awakes.
[07:47] <NikTh> Hello,
[07:47] <NikTh> any news about 12.04.3 ? https://launchpad.net/ubuntu/+milestone/ubuntu-12.04.3
[07:47] <ara> seb128, bonjour!
[07:47] <ara> seb128, do you have any news about 12.04.3?
[07:47] <seb128> ara, ola! how are you ?
[07:47] <smartboyhw> NikTh, aren't released
[07:47] <seb128> ara, no, I don't, but I'm not in the release team
[07:47] <smartboyhw> *Not yet
[07:48] <smartboyhw> Um, slangasek is asleep, that's mostly why
[07:48] <NikTh> smartboyhw: Do you know when ?
[07:48] <smartboyhw> The alternates got a late respin
[07:48] <smartboyhw> And Wubi got fixed
[07:48] <smartboyhw> NikTh, ask slangasek himself
[07:48] <ara> seb128, OK, thanks!
[07:49] <NikTh> Heah.. Ok smartboyhw  , thanks.
[08:50] <NikTh> This is a bit confusing.. People wait by yesterday the release of 12.04.3 and reviews are online : http://www.youtube.com/watch?v=MXPo1yA4S2w&feature=em-uploademail
[08:51] <smartboyhw> Oh, not again
[09:00] <NikTh> The message here [1] indicates that "Ubuntu 12.04.3 released" and giving a link that points to the daily image (which is obviously wrong), why? Because people know the schedule (2013/08/22)
[09:00] <NikTh> [1] - http://forum.ubuntu-gr.org/viewtopic.php?f=14&t=20877&start=550#p294744
[09:00] <smartboyhw> Yeah, we are late
[09:01] <NikTh> People search for a link to download the 12.04.3 , and because it's not exist, the only link they get ( I assume from Google search) is the daily image iso.
[09:20] <brendand> NikTh, released images are only the ones on releases.ubuntu.com
[09:20] <brendand> it's a case of people trying too hard
[09:20] <brendand> maybe cdimage should be renamed to not-released :)
[09:21] <NikTh> brendand: I know that, but others don't (I guess)
[09:24] <NikTh> brendand: I don't know, maybe it's a case of people that focused on other projects and finally there are no people for other projects left.
[09:25] <smartboyhw> brendand, but there are some Ubuntu images there which are officially released...
[09:28] <brendand> smartboyhw, on cdimage?
[09:28] <brendand> smartboyhw, is the same image also on releases?
[09:29] <brendand> smartboyhw, i.e. is there any officially released image that is on cdimage but not releases?
[09:29] <smartboyhw> brendand, yes
[09:29] <brendand> smartboyhw, which?
[09:30] <smartboyhw> brendand, http://cdimage.ubuntu.com/releases/13.04/release/
[09:30] <smartboyhw> And all the flavours
[09:31] <brendand> smartboyhw, it depends on your definition of 'officially released' i guess
[09:31] <smartboyhw> brendand, that page is "officially released"
[09:32] <brendand> anyway i agree it's not clear for some people
[09:38] <NikTh> cdimage.ubuntu.com has official released images also. The thing here is the /daily-iso/ . These are not stable images (at least are not considered as such).
[10:02] <xnox> smartboyhw: brendand: NikTh: 12.04.3 has not been released yet, nor published anywhere. The files actually need to have "12.04.3" in the file-name.
[10:02] <smartboyhw> xnox, we know
[10:02] <smartboyhw> But, the people are impatient
[10:03] <brendand> xnox, well i know, but some people seem to be very much willing to ignore the facts in front of them to get what they want
[10:03] <NikTh> We know xnox . We know.
[10:04] <NikTh> xnox:  Did you see the links I gave above ?
[10:05] <Laney> Jumping the gun happens every release; it's best to not worry about it
[10:06] <smartboyhw> Well, I remember at the 12.10 release date everybody mentioning the download links of 12.10 at #ubuntu-release-party are kick-banned:P
[10:06]  * smartboyhw didn't
[10:16] <NikTh> smartboyhw: brendand : Laney : Expect for the "Jumping the guns" thing this is quite true, lot of people that are interesting about the next point release of the current stable LTS, are remember the schedule release date. Which seems that one more time not been met.
[11:09] <jamespage> Daviey, ^^ re-introduction of py-juju for saucy
[11:13] <Daviey> jamespage: oh?
[11:14] <Daviey> jamespage: why are we bringing it back?
[11:14] <jamespage> Daviey, no upgrade path yet
[11:14] <jamespage> Daviey, its officially deprecated for 13.10 - but removing it was a step to far
[11:17] <jamespage> Daviey, ta
[11:21] <Daviey> jamespage: well, reviewing the delta from when it was last in the archive was pretty staright forward :)
[11:22] <jamespage> Daviey, indded
[13:37]  * smartboyhw wonders when slangasek will be awake
[13:38] <skellat> smartboyhw: It is still only 6:30 AM on the west coast of the United States.  Give slangasek time.
[13:40] <smartboyhw> skellat: OK:)
[13:40]  * smartboyhw doesn't have time concepts for USA.
[13:59] <slangasek> yeah, give me until at least 7
[14:00] <smartboyhw> Good morning slangasek:)
[14:01] <xnox> slangasek: if I remember correctly, in the YouTube interview about ubuntu releases "one stays up, releases, and crashes" or something like that =)))))
[14:01] <smartboyhw> lol
[14:02] <slangasek> xnox: that was a while ago, now I have other responsibilities to balance ;)
[14:02] <xnox> slangasek: wiser & older, just like in the avicii song. I like it =))))
[14:02] <slangasek> also, am jetlagged
[14:02] <xnox> slangasek: still or again? =)
[14:03] <slangasek> still
[14:08] <slangasek> ara: so I think we'll have the release ready to go out in about 3 hours
[14:09] <ara> slangasek, thanks!
[14:09] <slangasek> xnox: are you able to do the actual wubi tests for the tarballs? looks like we don't have those yet, and I'm not sure if plars is set up to test those
[14:10] <xnox> slangasek: ack, let me run those.
[14:10] <plars> slangasek: I should be able to, I have a windows partition on a test machine
[14:10] <xnox> plars: i386 or amd64?
[14:10] <plars> psivaa: ^ I think you have one too right?
[14:10] <xnox> plars: i can do amd64-only.
[14:10] <plars> xnox: amd64
[14:11] <slangasek> plars: there seems to be an outstanding test case for MAAS (Juju) - do you know if this is applicable to 12.04?
[14:11] <slangasek> seems like it should be
[14:12] <slangasek> hum, why do we still have a "JeOS on ESX" test case
[14:12] <psivaa> plars: i should be able to test both i386 and amd64
[14:13] <xnox> slangasek: wubi is not signed still.
[14:13] <plars> psivaa is a testing machine
[14:13] <plars> !
[14:13] <plars> :)
[14:13] <psivaa> :)
[14:13] <xnox> psivaa: plars: maybe use http://people.canonical.com/~xnox/wubi/precise/wubi-r279-precise.exe ? updated to say "12.04.3" et.al. but it's not signed yet.
[14:13] <slangasek> xnox: ah.  It can still be tested, right?
[14:13] <xnox> slangasek: correct. Hence I paste the URL above =)
[14:14] <xnox> slangasek: it will have a popup "This binary is downloaded from the internet and is not trusted by CIA"
[14:15]  * slangasek nods
[14:15] <slangasek> (..."but it is trusted by GCHQ")
[14:16] <xnox> slangasek: it's tusted by web-of-trust to the .asc file next to it, signed by my keay, with mean-square-distance < 5 to most people =)
[14:16] <xnox> slangasek: so that would make GCHQ trust it, I think.
[14:17]  * davmor2 waits for the knock on slangasek 's door, is that a black helicopter in the sky, run! ;)
[14:18] <slangasek> I only trust binaries signed by Phil Zimmerman
[14:19] <xnox> slangasek: i choked laughing =)
[14:44] <rtg> slangasek, your goldfish kernel awaits flushing from the NEW queue
[14:46] <slangasek> rtg: yep - thanks for the quick turnaround :)  once I have 12.04.3 out of the way I'll process it (if no one beats me to it)
[14:46] <rtg> oh, I thought the point release was out the door already
[14:47] <stgraber> can all the flavour leads confirm that the following URLs are correct:
[14:47] <stgraber>     Kubuntu:       http://www.kubuntu.org/news/12.04.3-release
[14:47] <stgraber>     Edubuntu:      http://www.edubuntu.org/news/12.04.3-release
[14:47] <stgraber>     Mythbuntu:     http://www.mythbuntu.org/home/news/12043released
[14:47] <stgraber>     Ubuntu Studio: http://ubuntustudio.org/2013/08/ubuntu-studio-12-04-3-released/
[14:48] <slangasek> rtg: I'm a bit behind :)
[14:48] <xnox> slangasek: signed wubi is in my public_html dir now, not sure where it should move next.
[14:48] <slangasek> xnox: exact URL?
[14:49] <xnox> slangasek: i think something like into: ~ubuntu-archive/wubi/precise/ & update stable symlink.
[14:49] <xnox> slangasek: http://people.canonical.com/~xnox/wubi/precise/wubi-r279-precise-signed.exe
[14:51] <slangasek> xnox: well, we can push it to ~ubuntu-archive, sure; I don't think that's ever used for anything but testing though?  So I'm more concerned about getting it onto release.u.c
[14:52] <xnox> slangasek: i think nausacan knows how to fetch it from ~ubuntu-archive. It was hardcoded to fetch from ~ev before, and when ev was out riding motorcycles during raring release it was switched to use ~ubuntu-archive
[14:52] <smartboyhw> stgraber: That link will 404 for now, but it's correct, it will become good as you release it
[14:52] <slangasek> xnox: ah, ok
[14:52] <xnox> slangasek: or some such. cjwatson twiddled it.
[14:54] <slangasek> ok, copied &symlinkified
[14:54]  * xnox awaits for magic to happen.
[14:55]  * smartboyhw awaits for the release to happen.
[15:06] <slangasek> plars: it looks like we're ready to go except for wubi, and the MAAS (juju) test I mentioned above
[15:07] <plars> slangasek: having trouble getting anywhere with maas, I got pretty far but I'm not really set up for it here. I asked jamespage yesterday but I don't think he was in a position to try it at the time
[15:07] <slangasek> ok
[15:08] <plars> jamespage: is matsubara out? I haven't seen him show up
[15:09] <slangasek> jamespage: ^^ can you help us with this MAAS (juju) test for 12.04.3?
[15:09] <plars> slangasek: at least from the install side, the maas stuff is fine. I just couldn't get my nodes up and configured enough to make juju happy, but it's not something I have much experience with
[15:10] <plars> slangasek: so I think the problem is between the chair and the keyboard rather than a bug in juju or maas
[15:10] <slangasek> plars: understood.  I would be a lot more comfortable with pushing the release out knowing that juju+maas actually works, however
[15:11] <plars> indeed
[15:21] <superm1> stgraber: yeah the URL should already be live
[15:35] <xnox> Laney: can ADT results from mysql-5.5 5.5.32-0ubuntu2 be hinted to be ignored (never passed?) and upstart be hinted to becuase it did actually pass?
[15:37] <Laney> xnox: never passed> has someone looked into it at all?
[15:38] <slangasek> xnox: why do we want to give it a pass?
[15:38] <slangasek> people should be fixing those adt failures
[15:38] <slangasek> ... and why does upstart need a hint if it *did* pass? :)
[15:39] <xnox> slangasek: because britney thinks it's running.
[15:39] <slangasek> ah, right
[15:39] <Laney> the jenkins-britney stuff is busted atm and nobody knows how to fix it. :-)
[15:39]  * slangasek nods
[15:39] <Laney> dh_holidayfactor
[15:40] <xnox> slangasek: it should skip mysql failure, since it never passed, thus upstart is not introducing a regression. Similar way britney lets packages through that e.g. never managed to build on some architecture.
[15:40] <slangasek> xnox: "since it never passed"> I don't believe that's the standard we're supposed to be holding packages too
[15:40] <slangasek> s/too/to/
[15:41] <slangasek> the goal should be to have all autopkgtests *passing* routinely, not just being waved through when they fail
[15:41] <Laney> It's valid for packages to not build on some architectures
[15:41] <xnox> slangasek: sure, "never passed" should block that package from migrating, and should let the reverse-deps through.
[15:41] <Laney> for autopkgtests, not so much
[15:42] <slangasek> xnox: oh, I see
[15:42] <slangasek> I thought you meant to ignore mysql-5.5 test failures for its own migration
[15:42] <slangasek> carry on then!
[15:42] <xnox> slangasek: nope =) just to get upstart through.
[15:42] <Laney> I'm doing 'force-skiptest'
[15:42] <Laney> which makes it ignore all of the tests triggered by that upload IYSWIM
[15:42] <xnox> Laney: btw, I'm loving the new wallpapers =)
[15:42] <Laney> force-badtest is the other thing
[15:43] <Laney> oh yeah? approve that MP then :P
[15:43] <Laney> always impressed by how quickly omgubuntu finds these things
[15:44] <xnox> Laney: he subscribes to lp:ubuntu-wallpapers merge proposals.
[15:44] <Laney> evidently
[15:59] <Laney> xnox: it'd be nice if there were at least a bug for mysql filed with the server team / author of the autopkgtest assigned
[15:59] <Laney> ;-)
[16:02] <xnox> Laney: done https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1216008
[16:02] <ubot2`> Launchpad bug 1216008 in mysql-5.5 (Ubuntu) "ADT tests failing" [High,Confirmed]
[16:02] <Laney> ♥
[16:45] <jamespage> slangasek, plars: looking now
[16:45] <jamespage> sorry its late
[16:45] <slangasek> jamespage: thanks!
[16:46] <plars> jamespage: smoser has been helping me too, he pointed me to some scripts which I was able to use to get things mostly going and configured
[16:46] <plars> jamespage: but we are both hitting a juju problem at the end
[16:46] <plars> http://paste.ubuntu.com/6018407/
[16:46] <plars> jamespage: ^
[16:49] <jamespage> plars, hmm - I see the same thing
[16:50] <jamespage> plars, you need a :80 in your MAAS url
[16:50] <jamespage> ffs
[16:51] <jamespage> plars, that was not directed at you btw
[16:51] <plars> ?
[16:51] <plars> jamespage: yeah, I think I agree with the sentiment
[16:51] <jamespage> plars, for example :    maas-server: 'http://<IP_ADDRESS>:80/MAAS/'
[16:51] <jamespage> OK
[16:51] <jamespage>     maas-server: 'http://<IP_ADDRESS>/MAAS/'
[16:51] <jamespage> #bang
[16:52] <jamespage> plars, OK - I have a server bootstrapping now
[16:53] <jamespage> plars, very slowly bootstrapping (~6MBps link)
[16:55] <plars> ok, slangasek, jamepage ^ might be something that should be release noted then?
[16:55] <slangasek> seems like something that should be part of the MAAS install documentation?
[16:56] <jamespage> slangasek, plars: I'm guessing its always been like that
[16:56] <jamespage> juju has not changed for this release and its a juju problem
[16:56]  * slangasek nods
[16:59] <jamespage> plars, over the slow bit now - everything hitting local cache!
[17:00] <smoser> jamespage, thank you.
[17:01] <plars> jamespage: looks like https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1084514 maybe
[17:01] <ubot2`> Launchpad bug 1084514 in juju (Ubuntu) "Unable to connect to EC2 instance after bootstrap" [Medium,Confirmed]
[17:01] <jamespage> plars, nope - thats an ec2 provider issue - this is a maas provider issue
[17:03] <jamespage> plars, https://bugs.launchpad.net/juju/+bug/972829
[17:03] <ubot2`> Launchpad bug 972829 in juju (Ubuntu Precise) "maas-server setting requires port even when using http default" [Low,Triaged]
[17:04] <jamespage> plars, I'll persuade someone to backport that to precise
[17:06] <smoser> jamespage, i've fixed virtual-maas to add the :80
[17:06] <jamespage> smoser, great
[17:07] <jamespage> smoser, fwiw I never testing it on precise - just quantal at the time
[17:07] <plars> yeah, I know
[17:07] <smoser> right. well its now mostly fucntional on precise.
[17:07] <smoser> which is nice.
[17:07] <plars> but it sounds like everyone uses the new (recommended) stuff rather than run on precise
[17:07] <plars> so
[17:09] <jamespage> plars, it should still be functional - thats a minor niggle but a low risk change imho
[17:10] <jamespage> plars, 97% on bootstrap node
[17:10] <plars> slangasek: so in that case, though there is a bug here, it doesn't seem to be a regression
[17:10] <slangasek> plars: ack
[17:17] <jamespage> plars, juju bootstrap test passed - doing the deploy test now
[17:23] <plars> jamespage, slangasek: smoser just made it through a run successfully
[17:24] <jamespage> plars, ack - I'm done as well
[17:24] <jamespage> deploy is deploying
[17:24] <slangasek> great!
[17:24] <smoser> ship it
[17:25] <plars> jamespage, smoser: thanks a lot for your help
[17:25] <jamespage> plars, np - sorry it was a little late in the day!
[17:26] <plars> jamespage: np
[17:26] <plars> slangasek: Is that it then? or do we still need something else?
[17:28] <slangasek> plars: nope, that's it - thanks for all your help
[17:33] <plars> awesome
[18:03] <plars> have to move locations, need to disconnect for a bit
[18:08]  * infinity raises his brow.
[18:08] <infinity> Who NEWed linux-goldfish to main?
[18:09] <infinity> slangasek: Was that you?  Is there a reason we want it in main?
[18:10] <slangasek> infinity: yeah, that was me.  If we don't want it in main, it'll fall back out on its own soon enough; but we may find that we want it in main for the SDK
[18:10] <slangasek> are the kernels for the other reference devices in main?
[18:11] <infinity> Nope.
[18:11] <slangasek> ok
[18:11] <infinity> Because they're effectively unsupportable.
[18:11] <slangasek> sure
[18:13]  * infinity tosses goldfish to universe for now, and waits for someone to argue it should be otherwise so he can invoke the security and kernel team for a cage match.
[18:13] <slangasek> heh
[18:14] <slangasek> I am disappointed that 'checksum-directory . ~/cdimage/www/full/releases/precise/release .' appears to be reprocessing images.
[18:29] <slangasek> infinity: you don't happen to know the checksum-directory code, do you?
[18:31] <infinity> slangasek: Not since the python rewrite.
[18:31] <infinity> slangasek: Is it doing something angry and wrong?
[18:32] <infinity> slangasek: If it's doing weird things when you include the previous directory arguments in a silly attempt to save I/O and CPU time, you could just call it without that.
[18:32] <slangasek> infinity: given the runtime, I get the impression that it's actually re-checksumming some images as I'm archiving them, instead of just using the existing checksums from the OLD_DIRS
[18:32] <slangasek> right, the problem I'm having is that it's *not* saving I/O and CPU time, or at least not as much as it ought
[18:33] <infinity> Err, wait, you're re-checksumming while archiving?  We archive in whole directories, why would you need to do that?
[18:34] <infinity> Anyhow, no idea why it would be hating on your OLD_DIR bits, but that always seemed fragile in both the shell and python versions (in fact, I disabled it in the shell version, due to strange fragility, coming to the conclusion that correct was better than clever)
[18:34] <slangasek> because we don't archive whole directories for point releases
[18:34] <slangasek> (never have)
[18:35] <infinity> Oh, indeed, the point release layout is special.
[18:35] <infinity> (And wrong, IMO, but whatever.  Still special)
[19:42] <slangasek> grr, publish-release isn't coping properly with DIST=precise
[19:51] <phillw> slangasek: update Wubi is not marked ready. Are you not going with it?
[19:52] <slangasek> phillw: that's the upgrade test case, which doesn't affect publishing.
[19:52] <phillw> okies :D
[20:21] <slangasek> ok, published
[20:21]  * slangasek squints at http://releases.ubuntu.com/12.04.3/. "Desktop cd"?  Who missed their capslock?
[20:22] <infinity> Huh, it's probably been like that ever since the Python rewrite, I've never noticed.
[20:23] <slangasek> actually, raring says 'Desktop image' rather than 'Desktop cd'... is that because we admitted to ourselves that it doesn't fit on a CD?
[20:24] <infinity> Yeah.  For image sizes over the 700MB constraint, it just says image.
[20:24] <infinity> Which may be why we never noticed the capitalisation thing.
[20:24] <slangasek> actually, it seems to key on release
[20:24] <infinity> Cause that would only affect ubuntu/precise and... lubuntu/saucy maybe.
[20:24] <slangasek> lib/cdimage/tree.py, lines 464 ff.
[20:25] <phillw> lubuntu saucy should also be CD sized. it is something we strive hard for,
[20:25] <infinity> Oh, hah.
[20:25] <infinity> Cute.
[20:26] <infinity> phillw: Yeah, we're not talking about actual sizes, just the text on the HTML pages.
[20:26] <phillw> okies, get's over minor heart attack :D
[20:26] <phillw> s/get's/me get's/
[20:26]  * infinity wonders why the "< quantal" bit at all, and suspects ditching that for "image" everywhere wouldn't hurt anyone's feelings.
[20:28] <slangasek> dunno, but this 'titlecase' function is also teh broĸen
[20:30] <phillw> I'm here learning, so please do excuse my n00b questions, lubuntu will have this 'fun' as of 14.04 so only this and one more to learn via :)
[20:37] <TheDrums> Not that it matters, but I'd recommend image too since they are hybrid (and USBs being nicer to boot anyway. ;) )
[20:37] <infinity> Oh, and now I remembered how I was going to get the precise CDs under 700M again: I was going to drop sl-modem-daemon.  Too late now.
[20:49] <slangasek> stgraber: nearly there; just waiting for the website updates to take
[20:50] <stgraber> slangasek: ok. I have the e-mail ready here, so just need to hit send and poke infinity to get it through moderation
[20:50] <infinity> Don't poke too hard, I'm squishy.
[20:51] <infinity> PLEASE DON'T MAKE ME RUN, I'M FULL OF CHOCOLATE.
[20:51]  * infinity wonders if it might be time for a Simpsons marathon.
[20:52] <stgraber> ;)
[20:52]  * infinity also wonders how many months of vacation he'd have to book to get through all 24 seasons.
[21:51] <qengho> Hi hi.  For phased updates, where is the "Phased-Update-Percentage" value set?  Can someone point me to an example of it in use?
[21:52] <qengho> I think I should find it in a archive Packages.gz file, but I don't see it yet.
[22:03] <stgraber> slangasek: any progress on the website?
[22:08] <qengho> bdmurray: Got a sec?  Where is a package's Phased-Update-Percentage stored and retrieved from?
[22:09] <bdmurray> qengho: if there is no phased-update percentage then it will not appear
[22:10] <bdmurray> qengho: you should be able to find it for the packages listed here http://people.canonical.com/~ubuntu-archive/phased-updates.html
[22:11] <bdmurray> and yes Packages.gz is the right place to look
[22:11] <bdmurray> just be sure it is the one from raring-updates
[22:12] <qengho> bdmurray: er, is "-updates" a condition for the test in update manager, or is it just the only place we'll practically apply those kinds of updates?
[22:13] <qengho> bdmurray: (I'm "asking for a friend" who is interested in using this mechanism for his software archive.)
[22:13] <bdmurray> only packages in -updates will have the Phased-Update-Percentage set
[22:13] <qengho> Right.
[22:24] <qengho> bdmurray: CC'd you on email reply, so you can tell me I'm wrong. I hope that's okay.
[22:26] <bdmurray> qengho: yep, that's fine
[23:19] <darkxst> hi, can I get ddebs enabled on ppa:gnome3-team/gnome3-next
[23:20] <stgraber> Riddell, ScottK, highvoltage: about to push the announcement out, please make your posts public
[23:22] <stgraber> infinity: announcement sent
[23:26] <stgraber> infinity: hmm, I immediately got a "Your message was rejected" back from lists.ubuntu.com...
[23:27] <slangasek> stgraber: X-Ubuntu magic sekrit header?
[23:28] <infinity> Oh wait, this is going to ubuntu-announce, not devel-announce, I can't moderate that anyway.
[23:28] <stgraber> right, that's an e-mail to ubuntu-announce. I think it's the first time I need to send something to that one.
[23:28] <infinity> stgraber: You need an "X-Ubuntu: random string, vorlon likes to hide jokes in here" header.  And to ask IS to moderate it.
[23:29] <stgraber> infinity: ok
[23:34] <slangasek> infinity, stgraber: I can moderate it
[23:34] <infinity> slangasek: Oh, shiny.  I didn't realize anyone outside IS had mod on that list.
[23:34] <phillw> has kate left chasing up release notifications etc?
[23:40] <stgraber> slangasek: ok, so announcement is out and I updated the tracker to mark the milestone as released, anything else?
[23:40] <slangasek> stgraber: that should do the trick, thanks


[00:24] <blackboxsw> meena: will have to get to it tomorrow. we're wrapping up SRU testing (and should be done tomorrow)
[00:25] <blackboxsw> softlayer SRU redone https://github.com/cloud-init/ubuntu-sru/pull/71 repushed. should be done tomorrow w/ puppet testng
[12:00] <otubo> meena: I could take a look at your PRs. Not sure if 93, 53 or 42. Or all of them.
[13:43] <meena> otubo: cool thanks
[13:45] <meena> i tried to write a patch to @goneri's code, but somehow sleep seemed like a much more attractive option
[13:46] <otubo> meena: all those PRs? Or just one of them?
[13:47] <meena> Goneri: your code is missing at least one function, _supported_write_network_config
[13:48] <Goneri> meena, Aloha! Thanks for the information. I plan to work on it next week-end.
[13:53] <meena> otubo: let's start with #93. but generally, whatever you can independently verify would be great to ➕1
[13:54] <meena> Goneri: i might get to it earlier
[13:54] <Goneri> meena, Yeah! You're a machine :-)
[13:56] <meena> nah, i just have a very nice evening ritual off sitting in front of the TV with my partner, after the baby is in bed, and we both stare at our laptops
[13:58] <meena> otubo: #42, by some miracle, is merged. but #69 is not, and isn't freebsd specific
[13:58] <otubo> meena: awesome, I think I still have some time today. So I'll take a look :)
[14:47] <Odd_Bloke> meena: I've been using Python since 1.5.x, I have all sorts of trivia stored in my head. :p
[14:50] <Odd_Bloke> meena: I'm not sure, but I wouldn't be surprised if the mock object doesn't know its fully qualified name.  It's just a (special) Python object with a name attribute, really.  But maybe there's some trivia for me to learn here. :p
[15:01] <smoser> someone needs to file an lxc issue for pstart fails.
[15:02] <smoser> lxc-pstart really isn't doing anything hacky.  basically it just
[15:02] <smoser>  - creates a profile with its own network
[15:02] <smoser>  - modifies container to be on that profile
[15:02] <smoser>  - inserts an 'init' and sets 'lxc.initcmd=<that>'
[15:03] <smoser>  - starts container and runs stuff
[15:03] <smoser>  - stops container
[15:03] <smoser>  - removes profile
[15:03] <Odd_Bloke> meena: One minor change requested on #93. :)
[15:04] <smoser> and lxc-proposed-nsapshot just does that, and then uses lxc publish.
[15:06] <Odd_Bloke> smoser: Is there an easy way we can dump the lxd commands that lxc-pstart is performing?  A bug report would probably have less friction if we don't need upstream to use our tooling to reproduce.
[15:07] <smoser> it does have pretty good debug output
[15:09] <smoser> Odd_Bloke: https://hastebin.com/levavikayi.cs
[15:10] <smoser> oh
[15:10] <smoser> there it is
[15:10] <smoser> --dump-commands
[15:14] <smoser> Odd_Bloke: https://hastebin.com/agolazazin
[15:26] <meena> Odd_Bloke: will have to sit until 19:00, or else you propose a change, or, even push directly to my branch
[15:28] <MrGeneral> Hello guys:
[15:28] <MrGeneral> 2019-12-12 14:55:06,854 - __init__.py[DEBUG]: Searching for local data source in: ['DataSourceNoCloud', 'DataSourceConfigDrive', 'DataSourceOpenNebula', 'DataSourceDigitalOcean', 'DataSourceAzure', 'DataS>
[15:28] <MrGeneral> 2019-12-12 14:55:06,855 - handlers.py[DEBUG]: start: init-local/search-NoCloud: searching for local data from DataSourceNoCloud
[15:28] <MrGeneral> 2019-12-12 14:55:06,855 - __init__.py[DEBUG]: Seeing if we can get any data from <class 'cloudinit.sources.DataSourceNoCloud.DataSourceNoCloud'>
[15:28] <MrGeneral> 2019-12-12 14:55:06,855 - __init__.py[DEBUG]: Update datasource metadata and network config due to events: New instance first boot
[15:28] <MrGeneral> Can't get cloud-init in proxmox to be read from ide2
[15:28] <MrGeneral> Any hint? Sorry for the spam btw.
[15:52] <Odd_Bloke> meena: No rush. :)
[15:53] <Odd_Bloke> MrGeneral: What is "ide2"?
[16:00] <MrGeneral> Odd_Bloke , Cloud-init drive in proxmox :\
[16:00] <MrGeneral> is there any way to specify the /dev/srID for cloud-init?
[16:01] <Odd_Bloke> MrGeneral: Before we get into specific solutions, let's make sure we understand the problem.  Can you open a bug at https://bugs.launchpad.net/cloud-init/+filebug and attach the tarball produced by `cloud-init collect-logs` to it, please?
[16:02] <Odd_Bloke> That'll get us the info we need to properly help you out. :)
[16:02] <MrGeneral> I'll try thanks Odd_Bloke
[16:02] <MrGeneral> yep :)
[16:02] <MrGeneral> trying to sort the issue tho
[16:02] <MrGeneral> supposedly, the data source is a cdrom generated by proxmox mounted in the server
[16:02] <MrGeneral> though as I install an ISO and load the cloud-init drive it sets by default from /dev/sr2
[16:02] <MrGeneral> actually
[16:02] <MrGeneral> sr1
[16:02] <MrGeneral> instead of sr0
[16:13] <MrGeneral> Ouch was finally able to get it working @Odd_Bloke, just didn't setup the network!
[16:13] <MrGeneral> let's find out why.
[16:14] <MrGeneral> resize, hostname, root login enabled, etc. did work.
[16:14] <MrGeneral> k, I know what to do I think.
[16:55] <MrGeneral> @Odd_Bloke may have more info. So, I install the iso which already comes with cloud-int, then I create a template in proxmox. everything is confgiured other than networking, any idea?
[17:01] <ahosmanMSFT> blackboxsw: any updates on the bug merge?
[17:07] <Odd_Bloke> MrGeneral: Not really; gathering the info I requested earlier is really the next step.
[17:07] <MrGeneral> Got it all working, Odd_Bloke, thanks, was my fault tho. :P
[17:08] <MrGeneral> Windows with Cloud-init WILL be a pita tho!
[17:08] <Odd_Bloke> Glad to hear it's working! :)
[17:08] <MrGeneral> Thanks sir :)
[17:09] <Odd_Bloke> blackboxsw: Am I remembering correctly that the Softlayer SRU PR is ready for re-review?
[17:12] <blackboxsw> Odd_Bloke: yes it is https://github.com/cloud-init/ubuntu-sru/pull/71   I repushed late yesterday
[17:12] <blackboxsw> increased a timeout to an unreasonable amount
[17:14] <Odd_Bloke> Cool, will look in a minute.
[17:15] <meena> Odd_Bloke: im too old/young to be in a rush
[17:19] <blackboxsw> ahosmanMSFT: I left you comments on the PR
[17:20] <blackboxsw> ahosmanMSFT: https://github.com/canonical/cloud-init/pull/84#discussion_r356369812
[17:20] <blackboxsw> last item and should be good
[17:25] <ahosmanMSFT> blackboxsw Just fixed and pushed
[17:30] <blackboxsw> thx
[19:03] <rharper> blackboxsw: Odd_Bloke: https://github.com/cloud-init/ubuntu-sru/pull/75
[19:09] <blackboxsw> reviewing
[19:10] <blackboxsw> rharper: https://github.com/cloud-init/ubuntu-sru/pull/66
[19:10] <rharper> reviewing
[19:40] <meena> Odd_Bloke: pushed. (and rebased again)
[20:05] <Odd_Bloke> meena: Merged, thanks!
[20:05] <meena> Goneri: any chance you can tell me what function _supported_write_config is supposed to be?
[20:07] <meena> Odd_Bloke: what about my other seventeen patches & bugs tho?
[20:07] <Odd_Bloke> Oh wow look what's that over there behind you
[20:07]  * Odd_Bloke runs
[20:08] <meena> Odd_Bloke: a santa hat.
[20:08] <meena> incidentally, we're also watching Rare Exports rn.
[20:11] <blackboxsw> rharper: btw that is a painful script to have to have written for intermittent Openstack deployment failures :/
[20:12] <rharper> =(
[20:12] <rharper> took better part of a day; but it's written now =)
[20:14] <meena> how do i ask cloud-id to give me debug (trace!) output from why it thinks it's on a None cloud?
[20:14] <powersj> ha I have a merge to update our FAQ with that very command
[20:15] <powersj> sudo DEBUG_LEVEL=2 DI_LOG=stderr /usr/lib/cloud-init/ds-identify --force
[20:15] <powersj> we should clean that up fwiw
[20:15] <powersj> and give cloud-id an alias to run that
[20:15] <blackboxsw> nice powersj (your FAQ radar was up on that ;) )
[20:17] <meena> powersj: i've hacked up ds-identity to do the right thing… but cloud-id / cloud-init don't
[20:17] <Odd_Bloke> meena: As background, cloud-id just reads data that cloud-init wrote when it was running.  Josh has pointed you at the command that does the actual determination.
[20:17] <Odd_Bloke> Hmm, interesting.
[20:17] <Odd_Bloke> meena: Can you describe the problem in more detail?
[20:19] <meena> actually, let'stry to run that command, and see wht happens, cuz i just looked at my /run/cloud-init/cloud.cfg and i modified it, so it might be wrong: https://gist.github.com/56a994dc4ccba1a81d7024c24bcd2aa4
[20:24] <meena> https://gist.github.com/27ac6b7ad02e1fa9de9145b1f4458f4d ← output
[20:25] <meena> cloud-id is stil saying none
[20:28] <rharper> cloud-init pulls from the instance-data.json in /run/cloud-init ;  so unless you've re-run cloud-init after making ds-identify changes, you won't get a new instance-data.json file
[20:29] <rharper> meena: so, 1) modify ds-identify 2) forcefully run it;  3) cloud-init clean --logs  4) cloud-init init --local; cloud-init init
[20:29] <rharper> that'll be enough to have cloud-init go through the datasource and write out instance-data.json
[20:30] <meena> rharper: ds-identify is giving the right response: datasource_list: [ Hetzner, None ]
[20:30] <rharper> look at instance-data.json
[20:31] <meena> i think the problem is still that i'm on Goneri\s branch and the network stuff is write-only…
[20:32] <rharper> right, if you can;t reach the hetzner network IMDS, then you won't get the DataSourceHetzner to indicate that it was found; and no datasource was processed
[20:34] <meena> now let's fix that before i continue to nonsensicle debugging…
[20:43] <meena> rharper: https://twitter.com/emilyst/status/1204823144956977152 apropos of almost nothing. (except, perhaps, https://github.com/canonical/cloud-init/pull/53 ;)
[20:52] <Odd_Bloke> blackboxsw: https://trello.com/c/6Pr4OxuI/48-sru-verification-10-azure-do-not-lock-user-on-instance-id-change doesn't have anyone's face on it but is marked complete, and I don't see a verification script in the repo.
[20:52] <Odd_Bloke> Was that intentional?
[20:53] <blackboxsw> Odd_Bloke: yes was intentional as we pinging the microsoft bug author on that one since we can't reproduce that failure mode easily
[20:54] <blackboxsw> so I marked complete, but no owner for us Odd_Bloke
[20:54] <Odd_Bloke> blackboxsw: But don't we need the SRU template stuff for our exception?
[20:57] <blackboxsw> Odd_Bloke: nope. The SRU template stuff is for us to continue to go above and beyond our existing exception in cases where we think we might have a regression.  Our exception is really just. does cloud-init CI and integration test suite continue to pass, and can manual upgrade validation on ## clouds validate we haven't regressed (plus maas and cdoqa)
[20:58] <blackboxsw> Odd_Bloke: any other one off validation we do (with SRU templates) is just performed as we see fit (because we don't officially have to do that anymore due to our exception)
[20:58] <blackboxsw> Odd_Bloke: rharper we were planning on dropping some of this one-off validation additional work when we've cleared a couple of SRUs without detecting potential regressions during SRU validation process.
[20:59] <blackboxsw> earlier it had  been fairly frequent where we have detected some potential regression during our one-off SRU validation.
[20:59] <Odd_Bloke> "The test case should be developed as a part of each resolved bug or new feature." <-- this makes it sound like it's expected that we are validating bug fixes and features
[21:01] <blackboxsw> Odd_Bloke: I had been those test cases as only those applicable to the given manual cloud test (as we require unit tests for any new feature/bug fix that is added in general)
[21:01] <blackboxsw> and in the previous 6 or so SRUs, we don't attach any manual SRU one-off validation test output to the SRU bug
[21:02] <blackboxsw> only the cloud-specific test
[21:02] <blackboxsw> and maas/cdoqa
[21:04] <Odd_Bloke> OK, fair enough.
[21:05] <Odd_Bloke> I hadn't realised (or had forgotten :p) we were doing more than we needed, that may have modified my opinion on which issues needed additional verification.
[21:05] <blackboxsw> we are just *that* amaaaazing
[21:06] <blackboxsw> yeah, which is also why our reviews on this one-offs (non-cloud) don't really need to be too strict. But, good to show that the feature is exercised without regression to common install behavoir.
[21:26] <blackboxsw> rharper: https://github.com/cloud-init/ubuntu-sru/pull/75/files#r357378780 one question otherwise +1 on openstack
[21:28] <meena> def _supported_write_network_config() is part of distros/__init__.py
[21:31] <meena> is there a way to set a breakpoint in the distro base class, so that when i run what rharper suggested, I'll know which methods i need to fix / reimplement / restore?
[21:32] <Odd_Bloke> meena: Is what he suggested not addressing the issue?
[21:34] <meena> Odd_Bloke: as mentioned previously, @goneri's branch is currently write only, in terms of networking, he was quite zealous in removing some quite rusty code… instead of trying to grease it
[21:35] <meena> but that rusty code was still capable of answering questions like, are we connected?
[21:35] <meena> is this interface up?
[21:36]  * meena taps mic: is this thing on?
[21:36] <Odd_Bloke> meena: Sorry, is this related to the cloud-id issue, or a separate thing?
[21:36] <meena> yesno
[21:37] <Odd_Bloke> blackboxsw: rharper: https://bugs.launchpad.net/cloud-init/+bug/1849731 <-- do you have any suggestions on how to construct a test for this?
[21:37] <meena> it's python debugging: how do i find out when my parent class is being called, so i know which methods i need to implement
[21:39] <Odd_Bloke> meena: I'm afraid I still don't really understand what you're trying to do.
[21:40] <Odd_Bloke> But maybe trying to do One Big Branch which will address a bunch of issues is what is tripping (you|Goneri) up?
[21:40] <meena> https://stackoverflow.com/questions/6954116/ruby-s-method-missing-in-python this. i basically need to log here
[21:41] <Odd_Bloke> Yeah, that would do what you described.
[21:42] <meena> thanks for rubbery duckling
[21:42] <meena> even though you doubted me 😒
[21:46] <Odd_Bloke> meena: My concern with using the __getattr__ method is that it presupposes that you will be running the code in a way which will actually call all the methods that are missing.
[21:47] <Odd_Bloke> If this is about working out which of the removed methods should be restored, I think you're better inspecting the codebase to work that out.
[21:48] <meena> but there's so much code 🙀
[21:49] <meena> but, yeah, might be more feasible
[21:49] <Odd_Bloke> meena: FreeBSD has a grep implementation though, right? ;)
[21:50] <meena> i use ripgrep, and emacs' jump to definition
[21:53] <meena> well, on my Ubuntu (elementary) laptop. on the servers its mostly vi, cuz i keep forgetting I've installed nvim
[21:57] <Odd_Bloke> meena: https://github.com/canonical/cloud-init/pull/61/files#r357391834 <-- I broke down how I looked at one of these, as I figured my working might be useful reference
[21:58] <Odd_Bloke> meena: I think my most important realisation was that all of our Distro subclasses are also called Distro, so the `Distro.get_devicelist` calls are referencing cloudinit.distros.freebsd.Distro, _not_ the super-class.
[21:58] <Odd_Bloke> Which is _extremely_ confusing when reading that code.
[22:02] <blackboxsw> Odd_Bloke: for testing config drive you could create an lxc with a /config-drive directory (via lxc-proposed-snapshot  on bionic)
[22:02] <meena> Odd_Bloke: i do have that much figured out already, but, yeah, it's incredibly confusing, and, unnecessarily so
[22:04] <blackboxsw> Odd_Bloke: this may be helpful https://github.com/cloud-init/ubuntu-sru/blob/master/bugs/lp-1673637.txt
[22:05] <blackboxsw> it's a test case seeding config-drive content on lxc
[22:06] <blackboxsw> and the validation would be cloud-init query v1.subplatform
[22:08] <powersj> blackboxsw, so are we all set on the SRU minus some internal testing?
[22:08] <blackboxsw> powersj: yep, I'm adding a nit for puppet validation of csr. I think Odd_Bloke is grabbing the configdrive
[22:08] <blackboxsw> I'll attach the cloud logs now
[22:08] <blackboxsw> so SRU will be ready minus internal testing
[22:09] <powersj> ok so monday, darn
[23:06] <blackboxsw> just attached all SRU logs to the bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1854872
[23:09] <blackboxsw> ahosmanMSFT: and I just published tip of cloud-init to Ubuntu Focal 20.04:   cloud-init v. 19.3-74-g129b1c4e-0ubuntu1
[23:10] <blackboxsw> coincidentally this will also drop a package dependency on ifupdown2 from focal as well
[23:34] <tribaal> awww rharper spent some time on my unfinished branch... sorry man!
[23:35] <tribaal> I should not have opened it (even though it's a "draft" PR


[00:01] <Ubulette> hmmm, i'm building with nss/nspr cvs
[00:01] <Ubulette> i should not do that as i know it will fail
[00:10] <Ubulette> asac, DBUILD_ID=0000000000
[00:10] <Ubulette> .. but that's no longer a merge if i start fixing things
[00:14] <asac> Ubulette: thats ok ... fix it
[00:14] <asac> its a minimal thing ... push the patch upstream
[00:15] <asac> ( as in debian)
[00:15] <asac> i already told him once ... no idea why he dropped it again ... nor when
[00:15] <asac> Ubulette: its important that in the end the changelog reads liks:
[00:16] <asac> Ubuntu changes:
[00:16] <asac>  + list
[00:16] <asac>  + all
[00:16] <asac>  + changes
[00:16] <asac>  + that
[00:16] <asac>  + currently
[00:16] <asac>  + exist
[00:16] <asac>  + in
[00:16] <asac>  + package
[00:16] <asac> :)
[00:16] <Ubulette> i only filled the blanks
[00:16] <asac> e.g. document the complete debdiff
[00:17] <asac> then ... list which modifications were dropeed/applied upstream .. so nothing really particular
[00:17] <Ubulette> I did lines 4..11
[00:27] <asac> Ubulette: 61_python_py_ssize_t_detect
[00:27] <asac> wasn't that applied?
[00:28] <Ubulette> no
[00:28] <asac> i think we don't need that anymore as we have a patch that doesn't require modification of configure.ac anymore
[00:28] <asac> which patch did mike include?
[00:28] <asac> (I think he mentioned my name in changelog)
[00:28] <Ubulette>  Drop debian/patches/68_python25_api_breakage.dpatch adopted by Debian as debian/patches/35_python_2.5.dpatch
[00:28] <asac> Ubulette: use the one we have in xul 1.9
[00:29] <asac> instead of both
[00:29] <asac> it should apply cleanly
[00:29] <Ubulette> noone will accept to review that. it already has 70 patches
[00:30] <Ubulette> i'll wait forever like for seamonkey1
[00:30] <asac> what do you mean?
[00:30] <asac> Ubulette: no ... its just the debdiff that is important
[00:30] <Ubulette> if i touch more than just the merge
[00:30] <asac> not the total diff
[00:30] <asac> hmm .. ok
[00:30] <asac> then keep it that way
[00:30] <Ubulette> even debdiff it already big
[00:30] <Ubulette> is
[00:31] <Ubulette> instructions say to keep changes to the minimum
[00:31] <asac> yes
[00:31] <Ubulette> so if it's dirty, keep it dirty
[00:31] <asac> then follow the instructions
[00:32] <asac> bluekuja: why does sm1 take so long?
[00:32] <asac> bluekuja: you waste fresh blood :) ... people that contribute and don't get sponsored ;)
[00:32] <Ubulette> I don't know, it's in a far better shape than it has ever been
[00:37] <Ubulette> http://paste.ubuntu.com/2042/
[00:37] <asac> Ubulette: well ... give him some time ... he probably has never dealt with such a huge package :)
[00:37] <Ubulette> hmm
[00:37] <asac> yes thats known to debian
[00:37] <asac> i saw it on ml today
[00:38] <Ubulette> and ?
[00:38] <asac> http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/2007-November/003146.html
[00:38] <asac> oh thats iceape
[00:38] <asac> Okay, this was broken by the latest gtk+2.0 package.
[00:38] <asac> The patch at https://bugzilla.mozilla.org/attachment.cgi?id=264996
[00:38] <asac> should fix this. (If you give it a try, don't forget to run autoconf to
[00:38] <asac> update configure)
[00:38] <asac> (thats what mike commented)
[00:40] <Ubulette> what's the bug id ?
[00:47] <asac> naturally he keeps that open :)
[00:48] <asac> https://bugzilla.mozilla.org/show_bug.cgi?id=344818
[00:48] <ubotu> Mozilla bug 344818 in Build Config "Linking - missing library deps" [Normal,Unconfirmed]
[00:49] <Ubulette> not the same
[00:51] <asac> Ubulette: yes it is
[00:51] <asac> https://bugzilla.mozilla.org/attachment.cgi?id=264996
[00:51] <asac> thats the same link?
[00:51] <asac> looks like ... thats from that bug
[00:51] <asac> the last attachment
[00:53] <Ubulette> god i hate dpatch
[00:54] <Ubulette> too slow for such a big tree
[01:31] <Ubulette> asac, i don't get it, in the tarball i've got from the merge site, there's a debian dir in it
[01:31] <Ubulette> http://paste.ubuntu.com/2043/
[01:44] <asac> Ubulette: yes ... from what i know that is the tarball which attempted to do the merge
[01:44] <asac> only conflicts are marked
[01:45] <asac> and you have to fix them
[01:45] <asac> thats merge-o-matic :)
[01:45] <Ubulette> problem is that tarball is not vanilla
[01:46] <asac> Ubulette: which tarball=
[01:46] <asac> ?
[01:46] <Ubulette> is it the one i'm supposed to push ?
[01:46] <asac> http://merges.ubuntu.com/x/xulrunner/
[01:46] <asac> Ü
[01:46] <asac> which?
[01:46] <Ubulette> xulrunner_<IP_ADDRESS>.orig.tar.gz
[01:47] <asac> that should be the orig yes
[01:47] <Ubulette> http://paste.ubuntu.com/2043/
[01:47] <asac> like a copy from debian
[01:47] <asac> Ubulette: don't bother about that
[01:47] <asac> its in pristine upstream
[01:47] <asac> that debian dir
[01:47] <asac> it has always been there ... abandoned for agaes
[01:47] <Ubulette> ok
[01:48] <asac> its pristine upstream
[01:48] <asac> i think
[01:48] <asac> http://merges.ubuntu.com/x/xulrunner/xulrunner_<IP_ADDRESS>-1ubuntu1.src.tar.gz
[01:48] <asac> is the one that was automerged
[01:48] <asac> not sure though
[01:48] <asac> i am a lame merger after all
[01:48] <Ubulette> yes, it's auto unpacked as xulrunner-<IP_ADDRESS>-1ubuntu1
[01:48] <asac> Ubulette: actually there is a script you should run
[01:48] <Ubulette> which is not usual
[01:48] <asac> http://merges.ubuntu.com/grab-merge.sh
[01:48] <Ubulette> i did it
[01:48] <asac> run that with xulrunner
[01:49] <Ubulette> i did it
[01:49] <asac> ah
[01:49] <asac> ok ... yes then there should be conflicts or something in the source tree
[01:49] <Ubulette> that's why i'm slow, it's an unusual way to do everything
[01:49] <asac> right :)
[01:49] <asac> but its effective for that purpose
[01:50] <Ubulette> i'm tempted to mv xulrunner-<IP_ADDRESS>-1ubuntu1 xulrunner-<IP_ADDRESS>
[01:50] <asac> well ... that doesn't really matter ;)
[01:51] <Ubulette> .. except that dpkg-sources complains
[01:51] <asac> yeah ... butin the end its not a problem ... its easier to debdiff later ... as you see which is which
[01:51] <Ubulette> debdiff looks clean. i'm rebuilding as i've touched configure
[01:54] <Ubulette> asac, http://paste.ubuntu.com/2045/
[01:56] <asac> Ubulette: you don't needtoadd the pysize configure.in patch
[01:56] <asac> mike did it manually
[01:57] <asac> like
[01:57] <asac> ++#if defined(__x86_64__) || defined(__ia64__)
[01:57] <asac> ++	if (PyObject_AsWriteBuffer(obBuffer, &buf, (long *)&buf_len) != 0) {
[01:57] <asac> ++#else
[01:57] <asac> + 	if (PyObject_AsWriteBuffer(obBuffer, &buf, (int *)&buf_len) != 0) {
[01:57] <asac> ++#endif
[01:57] <asac> looks a bit like he will miss archs with 64 bits that way
[01:57] <asac> like s390 64-bit ppc64
[01:57] <asac> no idea whatelse
[01:57] <asac> Ubulette: maybe resurrect the patch we had in previous version
[01:58] <asac> but its your decision
[01:58] <asac> if you keep mikes you don't need the other
[01:59] <asac> otherwise: thumbs up
[02:01] <Ubulette> if i drop 61_python_py_ssize_t_detect i have to redo the damn 99 :(
[02:02] <asac> yeah :)
[02:02] <Ubulette> not difficult, just slow
[02:02] <asac> happy dpatching
[02:02] <asac> tell that the other core-devs that want to fight quilt for something more simpler :/
[02:02] <asac> s/more/
[02:03] <asac> s/more//
[02:03] <Ubulette> quilt is easy if you know what a stack is
[02:04] <Ubulette> moz will use it
[02:04] <asac> right ... but maybe not easy enough to grow the motu community as big as we want it to be :)
[02:04] <Ubulette> either natively or through hg
[02:05] <Ubulette> a few lines of tutorial and it's enough
[02:05] <Ubulette> push/pop, new, add, refresh, fold
[02:05] <Ubulette> that's it
[02:05] <asac> right ... you don't need to convince me :)
[02:05] <Ubulette> :)
[02:06] <asac> debian goes to git + merge-new-upstream-on-top approach \O/
[02:06] <asac> and i don't have a key anymore :(
[02:09] <Ubulette> merge-new-upstream-on-top ?
[02:09] <asac> yeah ... just commit new upstream releases to git ...
[02:09] <asac> with you patches getting melted
[02:10] <Ubulette> gasp, full tree
[02:13] <asac> yeah ... merge on top :)
[02:13] <Ubulette> what's the benefit ?
[02:14] <asac> no idea ... to piss at me?
[02:14] <Ubulette> lol
[02:15] <asac> http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/2007-October/003052.html
[02:16] <asac> http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/2007-October/003062.html
[02:18] <Ubulette> still no mention of the benefits
[02:19] <asac> thats true
[02:19] <asac> he references: http://blog.madduck.net/debian/2007.10.03_packaging-with-git
[02:19] <asac> in fact we had various discussions before ... mike was always _for_ a patch ystem ... while eric wasn't
[02:20] <asac> and funny thing  is that I chatted with him about that topic before
[02:21] <asac> anyway ... i cannot upload to debian anymore :(
[02:22] <Ubulette> gpg key ?
[02:23] <asac> yes ... they updated gpgv and now it thinks that my key has expired ... because a subkey has expired
[02:23] <Ubulette> can't you just drop it ?
[02:24] <asac> tried ... keyservers appear not to honour any delkey
[02:24] <asac> e.g. maybe i need to change seomthing else so the new key is updated
[02:25] <asac> looked like the keyservers just ignored it
[02:36] <Ubulette> (lady) bugs never disappear for lp/code ?
[02:38] <asac> he?
[02:39] <Ubulette> https://code.edge.launchpad.net/~mozillateam/xulrunner/xulrunner-1.9.dev
[02:39] <Ubulette> top right and bottom
[02:40] <Ubulette> bottom is released so i expected it to disappear
[02:40] <asac> no idea :)
[02:40] <asac> maybe a bug in lp
[02:45] <Ubulette> is xulrunner in main in debian ?
[02:45] <asac> debian only has main
[02:45] <asac> everything else is non-free
[02:45] <asac> and contrib ... which is non-free as well (e.g. source is free, but depends on non-free)
[02:45] <asac> so everything that is free goes to main
[02:46] <Ubulette> i remember nonfree, nonus, contrib
[02:46] <Ubulette> ok, go for main
[02:48] <Ubulette> asac, same bug
[02:48] <Ubulette> ../../dist/lib/components/libgklayout.a(nsCanvasRenderingContext2D.o): In function `nsCanvasRenderingContext2D::SetDimensions(int, int)':
[02:48] <Ubulette> collect2: ld returned 1 exit status
[02:49] <asac> bad
[02:50] <Ubulette> and before you ask, yes, the patch is applied
[02:50] <Ubulette> and configure updated too
[02:51] <asac> yeah ... i know that you know how to do it :)
[02:51] <asac> i just brought my blog back up :)
[02:51] <asac> not that there is anything interesting :) ... but after being 2+ month down this is a precious moment ;)
[02:52] <Ubulette> malone is timeouting and oopsing me
[02:52] <asac> a friday night update?
[02:52] <asac> nice
[02:53] <Ubulette> bug 118500
[02:53] <ubotu> Launchpad bug 118500 in xulrunner "Please merge xulrunner (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/118500
[02:53] <Ubulette> bug 61395
[02:53] <ubotu> Launchpad bug 61395 in xulrunner "please sync xulrunner <IP_ADDRESS>-4.2 from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/61395
[02:53] <Ubulette> bug 78587
[02:53] <ubotu> Launchpad bug 78587 in xulrunner "please sync xulrunner <IP_ADDRESS>-1 from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/78587
[02:53] <Ubulette> bug 119946
[02:53] <ubotu> Launchpad bug 119946 in xulrunner "Please merge xulrunner <IP_ADDRESS>-2 from Debian unstable" [Wishlist,Fix released] https://launchpad.net/bugs/119946
[02:53] <Ubulette> bug 89561
[02:53] <ubotu> Launchpad bug 89561 in xulrunner "[UVF exception] Merge xulrunner <IP_ADDRESS> from Debian unstable" [Medium,Fix released] https://launchpad.net/bugs/89561
[02:54] <Ubulette> hmmm, that one is ahead of me
[02:54] <asac> ahead?
[02:54] <Ubulette> oh no
[02:54] <Ubulette> i'm on <IP_ADDRESS>
[02:55] <Ubulette> thought it was chronological
[02:56] <Ubulette> bug 163271
[02:57] <ubotu> Launchpad bug 163271 in xulrunner "Please merge xulrunner <IP_ADDRESS>-1 (universe) from Debian unstable (main)" [Undecided,In progress] https://launchpad.net/bugs/163271
[02:59] <asac> hehe
[02:59] <Ubulette> mozilla bug 368576
[03:00] <ubotu> Mozilla bug 368576 in Build Config "undefined reference to `XRenderFindStandardFormat' while compiling" [Normal,Resolved: duplicate] http://bugzilla.mozilla.org/show_bug.cgi?id=368576
[03:01] <Ubulette> the patch from before didn't even contain "Xrender"
[03:02] <Ubulette> so -lXrender , nada
[03:02] <Ubulette> damn
[03:04] <asac> welll its still the duplicate bug of that one
[03:04] <Ubulette> i needed the other patch
[03:04] <Ubulette> https://bugzilla.mozilla.org/attachment.cgi?id=242438
[03:04] <asac> which?
[03:05] <Ubulette> +EXTRA_DSO_LDOPTS	+= -lXrender
[03:05] <asac> maybe you need all three ;)
[03:57] <Ubulette> mozilla bug 381216
[03:57] <ubotu> Mozilla bug 381216 in Places "prevent bookmarks dataloss when a user goes from Firefox 2, Firefox 3 beta, Firefox 2, and then back to Firefox 3 [was: After initial import, minefield with bookmarks-on-places throws out Firefox 2 bookmarks changes]" [Normal,Verified: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=381216
[04:07] <asac> late ... + off
[13:33] <Greenery> is there firefox 3 beta rc in repo?
[13:48] <asac> Greenery: in hardy ... yes.
[13:49] <Greenery> oh i'm on gutsy
[13:49] <Greenery> is there a way to get it?
[13:51] <asac> hmmm ... not yet ... we wiill update gutsy once beta is final :)
[13:51] <Greenery> cool...now if beta is out, do i have to remove current firefox 2.0 or can bothe 3.0 and 3.0 work together?
[13:52] <Greenery> *2.0
[13:52] <asac> you can have both at the same time ... they won't share the profile though
[13:52] <Greenery> ah nice, i would love to test firefox 3 cos its amazing one windows so far
[13:53] <Greenery> thanks asac
[13:53] <asac> you can already install it ... firefox-3.0 is the package name
[13:53] <asac> but its a8 in gutsy
[13:53] <asac> once the new one gets in the archive you will automatically upgrade
[13:53] <Greenery> it will use different profile?
[13:53] <asac> yes
[13:53] <Greenery> ok gonna try it out
[15:23] <gnomefreak> asac: iceape fur gutsy is done i just want to run lintian and linda on it real fast before i push
[15:25] <Ubulette> hi
[15:25] <gnomefreak> ill let you know when its ready i have to go upstairs for coffee first
[15:25] <gnomefreak> hi
[15:25]  * gnomefreak knows i need to remove .bzr :(
[15:26] <Ubulette> coffee is a nice idea, i'll do that too :)
[15:27] <gnomefreak> ok ill be back after coffee
[15:31] <asac> gnomefreak: you can add -i.bzr to your dpkg-buildpackage parameter list
[15:49] <Ubulette> bluekuja, hi, any eta for sm1 ?
[15:49]  * asac => sport
[15:53] <bluekuja> Ubulette, I've built it
[15:53] <bluekuja> and seems fine
[15:53] <bluekuja> need to check lintian and other packaging issues
[15:53] <bluekuja> but not today
[15:53] <bluekuja> it's the weekend
[15:54] <bluekuja> :)
[15:54] <bluekuja> I'm full of stuff to do on this period
[15:55] <bluekuja> that's why there is a small delay
[15:55] <bluekuja> but don't worry, for the next week it can inside
[15:55] <bluekuja> *be
[17:11] <Ubulette> asac, i've fixed all the ftbs with xul1.8, i just have a few concerns about the python stuff
[17:13] <Ubulette> in debian/tmp, i have usr/lib/python2.5/site-packages/xpcom  while in the debs, it goes to usr/share/python-support/python-xpcom
[17:13] <Ubulette> and mike has a checker at the end of the build showing that
[17:14] <Ubulette> oh, and xulrunner-{nss,nspr}.pc are not installed at all. there's nothing to install those 2, there's just in debian/tmp
[17:57] <Ubulette> asac, i'm done. debdiff attached to bug 163271
[17:57] <ubotu> Launchpad bug 163271 in xulrunner "Please merge xulrunner <IP_ADDRESS>-1 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/163271
[18:14] <gnomefreak> asac: i do
[18:15] <gnomefreak> i would say it didnt work last time but revu was broken anyway so ther eis no telling
[18:16] <Ubulette> i'm wondering who would volunteer to review the merged xul1.8 with 2*300k of debdiff
[18:17] <gnomefreak> Ubulette: why are you building xulrunner-1.8 for hardy?
[18:17] <Ubulette> it's a merge
[18:17] <gnomefreak> atleast thats what i got from lastnights conversation
[18:17] <gnomefreak> merge for hardy you cant merge for gutsy and 1.9 is in hardy
[18:17] <gnomefreak> are we planning on supporting both in hardy?
[18:18] <Ubulette> http://merges.ubuntu.com/x/xulrunner/
[18:18] <Ubulette> i just did that pending merge
[18:18] <gnomefreak> unles security only it cant be merged into gutsy
[18:19]  * gnomefreak waiting  for browser
[18:19]  * gnomefreak doesnt see 1.9 there
[18:19] <gnomefreak> i see <IP_ADDRESS>
[18:20] <Ubulette> yes
[18:20] <Ubulette> it's the old 1.8 branch
[18:20] <gnomefreak> in hardy or gtusy?
[18:20] <Ubulette> hardy i guess
[18:20] <gnomefreak> why would we need 2 versions of xulrunner
[18:20] <Ubulette> because they are not compatible
[18:21] <gnomefreak> hardy should have everything depend on xulrunner-1.9
[18:21] <Ubulette> that's why 1.9 uses a different package name
[18:21] <Ubulette> gnomefreak, it will take a while
[18:21] <gnomefreak> so we have to have packages depend on 1.9 | 1.8?
[18:21] <Ubulette> depends
[18:22] <gnomefreak> what does 1.8 do that 1.9 doesnt?
[18:22] <Ubulette> we want to be able to install 1 xul per branch at the same time, like upstream
[18:23] <Ubulette> 1.9 changed the API to much for some old projects
[18:23] <Ubulette> too
[18:23] <gnomefreak> firefox 2.0 cant depend on 1.9 afaik but 3.0 should be final before we release hardy
[18:23] <Ubulette> ff2 will never use libuxl
[18:24] <Ubulette> ff3 already does for us, but 1.9
[18:24] <gnomefreak> i know but since 3.0 will be final (assuming it will be ready by jan1) we can drop 2.0 from repos when 3.0 is final
[18:25] <Ubulette> what about everything else depending on gecko/xul ? (miro, kaze, epiphany, python-moz, etc..)
[18:25] <Ubulette> they will eventually catch up with xul 1.9 but it will take time
[18:26] <gnomefreak> seamonkey 2.0 wont be released in time for hardy, kaze uses 1.9 not sure about the others but i dont see why they cant.
[18:26] <gnomefreak> and i know seamoney doesnt use libxul at all
[18:26] <Ubulette> so we need to continue to provide xul1.8 (merged from debian) in parallel to xul1.9 that we are maintaining here
[18:26] <Ubulette> kaze doesn't
[18:27] <Ubulette> i've tried, i've patched, it's far from obvious
[18:27] <gnomefreak> right now none of the above listed apps depend on libxul at all except maybe miro
[18:27] <Ubulette> my latest kaze depends in xul 1.8
[18:27] <Ubulette> on
[18:27] <gnomefreak> so why not just keep them not depending on it, is there something that 1.8 will do that isnt done for these apps no
[18:28] <gnomefreak> sno/sow
[18:28] <gnomefreak> s/no/now
[18:28] <Ubulette> just the api
[18:29] <gnomefreak> api doesnt do anything for epiphany ect since it depends on firefox
[18:29] <Ubulette> btw, xulrunner 1.8 is already in hardy, why won't it be upgraded like everything else ?
[18:29] <gnomefreak> Ubulette: i was figuring it would be pulled
[18:29] <gnomefreak> since 1.9 is there but i forgot about other apps
[18:30] <Ubulette> depending on ff-dev is a mistake, we need to get rid of that but it's only possible starting to xul 1.9
[18:30] <gnomefreak> Ubulette: no installing epiphany installs firefox
[18:31] <Ubulette> doesn't mean it's good
[18:31] <gnomefreak> that is the point of adding libxul in gutsy we were gonna make use of it installing xul instead of firefox
[18:31] <gnomefreak> but we couldnt due to time we got xul in
[18:31] <Ubulette> asac told upstream (epiphany) is working on supporting xul 1.9
[18:31] <gnomefreak> linda takes too damn long to run
[18:33] <Ubulette> gnomefreak, xul is also a SDK, what do we know about users of the SDK ? there are tons of xulapp that are not packaged but still need xulrunner
[18:33] <gnomefreak> im assuming everything installs firefox/depends on it due to mainly depending on gecko
[18:33] <gnomefreak> if they are not packaged for ubuntu it shouldnt matter at all
[18:35] <Ubulette> not to you maybe but to others maybe. difficult to know for sure
[18:36] <gnomefreak> we dont support outside of our repos (we == ubuntu)
[18:36] <gnomefreak> person wants to build it its on them to get build-deps
[18:38] <gnomefreak> i didnt say its a bad idea i just didnt understand why 2 versions were needed
[18:38] <gnomefreak> but if packages depend on 1.8 in gutsy than i see why its added in hardy
[18:38] <Ubulette> the merge was pending, i volunteered, done, period.
[18:38]  * gnomefreak doesnt understand why we should make apps depend on 1.8 if they didnt in gutsy
[18:39] <Ubulette> i don't care about gutsy. i'm talking about merges on mom/dad for hardy
[18:40] <Ubulette> it was in the list with other even more obscure stuff, so why not ?
[18:41] <Ubulette> at least, i'm familiar with that beast so it made sense
[18:45] <gnomefreak> did we talk about moving xul to main?
[18:45] <Ubulette> i don't remember
[18:45] <Ubulette> for sure, not 1.8
[18:45] <gnomefreak> right
[18:45] <Ubulette> 1.9, maybe, could be interesting
[18:45] <gnomefreak> well when ffox3.0 is released we have to move it to main afaik
[18:46] <gnomefreak> i dont think main apps depend on universe but that might have changed since universe is enabled by default
[18:47] <gnomefreak> but xul still maybe not needed but wanted
[18:49] <asac> everything in main _must_ be xul 1.9 for hardy
[18:49] <asac> otherwise it will get demoted
[18:49] <asac> python mozembed is ready ... just the xul classifier issue
[18:49] <asac> but that is a xul issue
[18:50] <asac> epiphany will take a bit though
[18:50] <gnomefreak> asac: thats what i thought so shouldnt we move it to main
[18:50] <Ubulette> (as i said)
[18:50] <asac> gnomefreak: yes ... I will write a MIR as soon as we have beta and fixed the url-classifier issue
[18:50] <gnomefreak> if epiphany or ff3.0 are releasedd
[18:51] <gnomefreak> i think epiphany is in main
[18:51] <gnomefreak> !info epiphany
[18:51] <ubotu> epiphany: clone of Boulder Dash game. In component universe, is optional. Version 0.5.1-4 (gutsy), package size 63 kB, installed size 236 kB
[18:51] <asac> yes ... yelp + devhelp + epiphany + gnome-mozembed
[18:51] <gnomefreak> !info epiphany-browser
[18:51] <ubotu> epiphany-browser: Intuitive GNOME web browser. In component main, is optional. Version 2.20.1-0ubuntu1 (gutsy), package size 3527 kB, installed size 14412 kB
[18:51] <asac> those 4 should cover a good amount of main stuff we need to port
[18:51] <gnomefreak> thats right yelp does need it
[18:51] <asac> epiphany is probably the most tricky one
[18:52] <gnomefreak> depends when upstream releases it if they can
[18:52] <asac> gnome-mozembed = python-gtkmozembed
[18:52] <gnomefreak> well linda isnt doing anything but checked lintian and its good
[18:53] <gnomefreak> let it work for 5 more minutes than if nothing ill kill it and upload to revu for you to grab, will push to branch if linda is good if it runs on revu
[18:54]  * gnomefreak glad sunbird is no longer an issue TBH
[18:54] <gnomefreak> brb
[18:58] <asac> gnomefreak: ok ... if you have an orig it might be fine :)
[19:00] <gnomefreak> i do ;) im running it in chroot ;)
[19:00] <gnomefreak> will run it on gutsy partition whne i get that far
[19:01] <gnomefreak> i gave up gwget todday
[19:13] <gnomefreak> if i find time later im gonna work on bugs since my packages will be done for now
[19:14]  * gnomefreak might play catch up on sm2 since i have older version installed
[19:18] <asac> ok out getting drunk :) ... german beeerr \O/
[19:18] <asac> i hate american beer
[19:18] <asac> its the worst i ever had
[19:21] <gnomefreak> have fun ;)
[19:50] <gnomefreak> Ubulette: are you moving seamonkey to nobinonly for hardy?
[19:50] <gnomefreak> we cant add it to gutsy afaik since its not security
[19:54] <Ubulette> 1 or 2 ?
[19:55] <gnomefreak> Ubulette: either for hardy
[19:55]  * gnomefreak thinks it a "must" for all moz apps
[19:55] <Ubulette> i did coth
[19:55] <Ubulette> both
[19:55] <Ubulette> have a look at my ppa
[19:56] <Ubulette> https://edge.launchpad.net/~fta/+archive
[19:56] <Ubulette> mozclient is now producing nobinonly tarballs only
[19:57] <Ubulette> and for sm1, i've added a rule to create the nobinonly tarball from the upstream one
[19:57] <gnomefreak> ah ok
[19:57] <Ubulette> no need to tar by yourself anymore
[19:57] <gnomefreak> that makes life easy
[19:57] <Ubulette> indeed
[19:58] <gnomefreak> needs to pull mozclient to see what apps are in there sometime after push is done
[19:58] <Ubulette> i just hate to do the samething twice, so i script everything
[20:03] <gnomefreak> i agree
[20:07] <gnomefreak> anyway to add sunbird and sm 1.1.x to mozclient?
[20:07] <Ubulette> we're not doing cvs for those two
[20:08] <gnomefreak> not sm1?
[20:08] <Ubulette> it's still possible to do it but it was not the initial purpose of mozclient
[20:09] <gnomefreak> i understand, its easy enough to do it
[20:09] <gnomefreak> just a thought
[20:09] <Ubulette> i don't see the reason to do sm1 cvs, releases are enough
[20:10] <gnomefreak> true cvs is better for unreleased appz
[20:10] <gnomefreak> -z +s
[20:10] <Ubulette> for sunbird, maybe. it's not clear what is trunk
[20:11] <Ubulette> for sunbird, maybe. it's not clear what trunk is
[20:11] <gnomefreak> sunbird is a bit messed up still on thier versioning
[20:11] <Ubulette> yep
[20:11] <Ubulette> a bit young, that's it
[20:11] <gnomefreak> maybe when devel starts on 1.0
[20:12]  * gnomefreak wounld mind playing with it a bit when they start on it but still hard to get a source tarball for no released apps without cvs
[20:14] <Ubulette> well, i agree. i can add sunbird quite easily now that i've introduced the debtag=tag=version
[20:15] <gnomefreak> yeah i was looking at that (the second section in Makefile) seems its just add the 3-4 lines of stuff and your done
[20:15] <gnomefreak> is that fairly true?
[20:15] <gnomefreak> target appname file and url is the part i mean
[20:16] <Ubulette> in that case, i need to add the proper branch name in addition to the tag, as it's not trunk
[20:16] <gnomefreak> ah
[20:20] <gnomefreak> i broke bzr again, brb smoke
[20:24] <Ubulette> too bad it's still MOZILLA_1_8_BRANCH
[20:26] <gnomefreak> what sunbird?
[20:27] <Ubulette> yes
[20:27] <gnomefreak> yeah until 1.0
[20:27] <gnomefreak> 1.x
[20:31] <gnomefreak> hmmm seems to just sit there now
[20:37] <gnomefreak> can i remove debian/.pc dir ?
[20:39] <Ubulette> you should not have it in there in the 1st place, so yes
[20:39] <gnomefreak> ah ok cool
[20:39] <Ubulette> it's supposed to be in the root dir (where you run dpkg-buildxxx)
[21:06] <gnomefreak> does firefox support import bookmarks from windows?
[21:06] <Ubulette> no idea
[21:18] <Ubulette> gnomefreak, i've patched mozclient
[21:18] <Ubulette> $ make DEBIAN_TAG=SUNBIRD_0_7_RELEASE=0.7 sunbird-orig
[21:18] <Ubulette>   => lightning-sunbird_0.7+nobinonly.orig.tar.gz
[21:18] <Ubulette> $ make sunbird-orig
[21:18] <Ubulette>   => lightning-sunbird_0.8~cvs20071116t1332+nobinonly.orig.tar.gz
[21:19] <gnomefreak> ty
[21:19] <gnomefreak> i dont need to add nobinonly to make command right?
[21:19] <Ubulette> no, it's automatic
[21:19] <gnomefreak> sweet thank you ;)
[21:42] <gnomefreak> hmmm ihave a .zip file for BeOS and not sure how to burn it
[21:45] <Ubulette> i wonder why sunbird fetches SeaMonkeyAll
[21:51] <gnomefreak> cvs?
[21:52] <Ubulette> yes
[21:52] <gnomefreak> Ubulette: maybe because it is based on the now removed seamonkey calendar
[21:52] <Ubulette> maybe
[21:52] <gnomefreak> they stopped supporting sm-cal so maybe that is reason
[21:52] <Ubulette> that's another huge tarball
[21:53] <Ubulette> maybe we can try the trunk version and see if it can use xul1.9 like our ff3
[21:53] <gnomefreak> have they started work on 1.0 yet?
[21:54] <gnomefreak> i havent seen anything on it yet
[21:54] <Ubulette> no but there are tons of commits in trunk
[21:54] <gnomefreak> ah
[21:55] <gnomefreak> noone pushed songbird as a bzr branch yet?
[21:56] <Ubulette> nope
[22:08] <gnomefreak> Ubulette: seamonkey2 needs font size or size in general made smaller
[22:08] <gnomefreak> its huge by default
[22:09] <Ubulette> ? for me it looks normal
[22:09] <Ubulette> http://www.sofaraway.org/ubuntu/tmp/SeaMonkey-2.0a1pre-startup.png
[22:09] <gnomefreak> for me its 3 times the size of firefox
[22:10] <gnomefreak> and im using 1600x1200 screeen res
[22:10] <Ubulette> 1440x900
[22:10] <Ubulette> exactly the same as ff3
[22:12] <gnomefreak> is there a place i can upload instead of tinypics
[22:13] <Ubulette> ImageShack ?
[22:13] <gnomefreak> im trying now
[22:16] <gnomefreak> [URL=http://img441.imageshack.us/my.php?image=firefox20wb1.png][IMG]http://img441.imageshack.us/img441/7581/firefox20wb1.th.png  << ffox-2.0
[22:17] <gnomefreak> http://img441.imageshack.us/img441/7581/firefox20wb1.th.png <<ff2.0
[22:17] <gnomefreak> http://img441.imageshack.us/my.php?image=seamonkeyhp8.png  << sm2
[22:22] <Ubulette> visit about:config and layout.css.dpi to 0
[22:22] <Ubulette> set
[22:25] <gnomefreak> it was -1
[22:25] <Ubulette> try 0
[22:25] <gnomefreak> i am
[22:25] <Ubulette> and ?
[22:25] <gnomefreak> waiting for it ot restart
[22:25] <gnomefreak> even bigger
[22:25] <gnomefreak> well some of it
[22:26] <Ubulette> should be your gnome prefs
[22:26] <gnomefreak> higher number smaller size?
[22:26] <Ubulette> unless your X driver is not able to do that with gnome
[22:26] <gnomefreak> its just the content on site
[22:26] <Ubulette> try 84
[22:26] <gnomefreak> 84?
[22:26] <gnomefreak> holy shit
[22:26] <Ubulette> 84 dpi
[22:27] <Ubulette>  xdpyinfo | grep dot
[22:27] <gnomefreak> much better
[22:27] <Ubulette> 0 should get the size from X, -1 is to use moz prefs
[22:28] <gnomefreak>   resolution:    126x121 dots per inch
[22:28] <Ubulette> so that's why it's huge
[22:28] <gnomefreak> why?
[22:28] <gnomefreak> nothing else is that big
[22:28] <Ubulette> fta@ix:~ $ xdpyinfo | grep dot
[22:28] <Ubulette>   resolution:    89x87 dots per inch
[22:28] <gnomefreak> its just sm2 and firefox3.0
[22:29] <gnomefreak> everything else is right size
[22:29] <Ubulette> the rendering engine of 1.9 :)
[22:29] <gnomefreak> in sm2 also?
[22:30] <Ubulette> yes, it's just internal
[22:30] <gnomefreak> so how do i change xdpyinfo?
[22:32] <Ubulette> you can play with System / Preferences / Appearances / Fonts / Details... / Resolution
[22:32] <Ubulette> but you're good to go for a headache
[22:33] <gnomefreak> most likely yeah
[22:33] <Ubulette> it's dynamic so try (just remember the initial value ;))
[22:33] <gnomefreak> it has 96 in there
[22:34] <gnomefreak> why do i have 126x121 if it has 96 :(
[22:34] <gnomefreak> what does yours have? so i have a base to work off of
[22:34] <Ubulette> 84
[22:35] <gnomefreak> i have to restart X for it to take affect?
[22:35] <Ubulette> i don't
[22:37] <gnomefreak> so i should set sm back to 0?
[22:38] <Ubulette> yes
[22:38] <gnomefreak> k
[22:39] <gnomefreak> with 84 its still huge
[22:39] <Ubulette> my feeling that noone will step up to review my xul1.8 merge is starting to get stronger ;)
[22:40] <gnomefreak> with layout.css.dpi set to 0
[22:41] <Ubulette> i don't know. dpi in linux has always been dark magic for me. i've done some vodoo then something nice appeared, i'm stucking with that now
[22:44] <gnomefreak> Ubulette: when you open sm2 does it give you the start up notifcation? like ff does
[22:45] <Ubulette> i just see the default homepage
[22:45] <Ubulette> oh, 1st time, you probably got the profile migrator
[22:46] <gnomefreak> hmmmmmmm firefox2.0 and 3.0 are perfect sm2 is still huge no matter what i do other than changing layout.css.dpi
[22:46] <gnomefreak> Ubulette: no look at your taskbar while its starting up
[22:46] <gnomefreak> does it say seamonkey is starting up or loading
[22:47] <gnomefreak> notice firefox does have it
[22:47] <gnomefreak> cant remember but i could have swroe i added it to tbird and iceape
[22:47] <Ubulette> could you screeenshot it ?
[22:47] <gnomefreak> sworn
[22:47] <gnomefreak> i can try
[22:48] <gnomefreak> its changed in .desktop
[22:48] <gnomefreak> iirc
[22:50] <gnomefreak> brb while it takes it sweet time to post
[22:50] <gnomefreak> http://profile.imageshack.us/user/gnomefreak/images/detail/#132/startupoh7.png
[22:50] <gnomefreak> look at the lower panel the 2 window names
[22:50] <gnomefreak> second one says starting firefox
[22:51] <gnomefreak> sm2 is only one so far that doesnt have it (im pretty sure i added it to sunbird and i swear i did for IA but cant rmemeber off hand
[22:52] <Ubulette> i've never seen that
[22:53] <gnomefreak> ff 2 and 3 tb do it sunbird i am fairly sure does as well
[22:54] <gnomefreak> iirc i added it due to a bug report but its been a long time
[22:54] <Ubulette> i have only 1 panel and i don't use the "window list" applet
[22:55] <gnomefreak> that would be why you dont see it
[22:59] <asac> ole
[23:00] <Ubulette> yop
[23:01] <gnomefreak> asac: everything is pushed to revu ill give you links tomorrow im gonna keep working on font issue in sm2 after dinner
[23:02] <gnomefreak> dinner i think is now since i havent eaten yet today
[23:03] <gnomefreak> Ubulette: im pretty sure it was in *.desktop that the change was made, asac should remmeber why we did it he would know if we should bother, im at no opinion for most part on it but if i did fix it due to bug expect some user to file one on it
[23:03] <gnomefreak> bbl
[23:09] <Ubulette> asac, how was the beer ? :)


[00:33] <dmcglone> paultag: for?
[01:18] <dmcglone> Hiya Cheri703
[01:47] <canthus13> bah. My mouse has suddenly decided to flip out on me.
[01:47] <canthus13> ....and now it's working again.
[01:47] <canthus13> that was weird.
[01:53] <dmcglone> lol
[02:13] <dmcglone> I got it
[02:56] <Cheri703> hey
[02:56]  * Cheri703 was driving home earlier
[03:06] <canthus13> ...as long as you're not driving home now, while IRCing. :)
[03:06] <Cheri703> nah
[03:07] <Cheri703> sitting on my couch eating an ice cream cone
[03:09] <Cheri703> was verreh tasteh
[03:13]  * BiosElement wants an ice cream cone! >.>
[03:13] <Cheri703> BiosElement: if you make it up to mansfield, I'll make some ice cream for you
[03:14] <BiosElement> haha careful, I might hold ya to that :P
[03:14]  * Cheri703 still has a little bit of the chocolate/hazelnut left
[03:15] <paultag> dmcglone, humm?
[03:16] <Cheri703> seriously, if/when we have the multi-reloco gathering up here (still hoping to do that in the spring) I can take requests and make up various types
[03:17] <BiosElement> Yeah, I think it's a must to get the diff reloco's gathered all over
[15:08] <thafreak> Anyone know what the name of the app to change monitor settings is?
[15:08] <thafreak> I'm trying to run it from fluxbox, to get my netbook to switch to external monitor
[15:08] <thafreak> the keyboard keys are not seeming to work.
[15:12] <thafreak> nevermind...gdm can figure it out before I log into fluxbox
[16:35] <BiosElement> Morning folks
[16:35] <BiosElement> :P
[17:56] <thafreak> BiosElement: you have my vote...under one condition...I get to call you "willy" chambers...
[17:56] <thafreak> ?
[17:57] <BiosElement> >.> I really don't care. :P
[18:18] <paultag> thafreak, ahahahahahahahahahaha
[19:20] <canthus13> Heh.
[20:16] <thafreak> Oh nice...I just had to show my boss amazon's AWS website, and I notice that new users now get 5GB free storage on S3/month for their first year
[20:22] <paultag> thafreak, :)
[20:22] <deejoe> yeah, I'm wondering if I'll be able to get a free instance for work, and then a free instance for personal.
[22:12] <BiosElement> Wow...
[22:12] <BiosElement> Apache Foundation is protecting Oracle/Sun's breach of contract by trying to scuttle the JCP Council agreement for Java 7 and yet people make Apache out to be the bad guys. Awesome
[22:13]  * BiosElement has a solution. apt-get purge java
[22:21] <deejoe> BiosElement: they're what?
[22:21] <deejoe> got link?
[22:22] <BiosElement> deejoe, A few pages ago, lemme grab it ^_^
[22:23] <BiosElement> deejoe, http://arstechnica.com/open-source/news/2010/11/apache-foundation-to-vote-down-java-7-protesting-oracle-abuses.ars
[22:26] <deejoe> BiosElement: ah, thanks
[22:26] <BiosElement> deejoe, The long/short of it is sun/oracle release some of the code FOSS but the 'java test suite' to verify it's a legit java setup and such is 'not' open source. Meaning Apache's java thingy isn't actually java per oracle/sun
[22:26] <deejoe> got it
[22:26] <BiosElement> Kinda a joke really. >.>
[22:27] <deejoe> I think it's safe to say that detractors of Apache's position are invested in Java first, and have concerns about software freedom only second, if at all.
[22:27] <deejoe> not that hard to imagine, given the prevalence of java in CS education of late
[22:27] <BiosElement> deejoe, Heck, some of the comments are "I DUN CARE!" flat out :P
[22:27] <deejoe> heh
[22:28] <deejoe> well, guess what, Apache et al dun care back at you.
[22:28] <deejoe> ("you" meaning "them" of course :-)
[22:28] <BiosElement> Hey, the way I see it, Oracle/Sun wanna play games and destroy their own JCP thingy, Apache's just playing the same game in return


[08:44] <tomwardill> cjwatson: done and pushed
[09:30] <SpecialK|Canon> cjwatson: yay for symlink hack!
[09:45] <SpecialK|Canon> cjwatson: good email (re livefs webhooks)
[09:46] <SpecialK|Canon> ilasc: please make sure ^ go in the weekly!
[09:46] <SpecialK|Canon> on the subject of naming things
[09:46] <ilasc> SpecialK|Canon noted.
[09:47] <SpecialK|Canon> one of the things Przemek inherited when we last worked together was a Django/Celery service I'd built to manage webhooks
[09:47] <SpecialK|Canon> called...Spiderman
[09:47] <SpecialK|Canon> because it...shoots webs
[09:47] <SpecialK|Canon> (I'll get my coat)
[09:49] <cjwatson> SpecialK|Canon: I put it in the weekly yesterday
[09:49] <cjwatson> FWIW
[09:49] <cjwatson> These days I try to do that as a post-deployment step, because otherwise I forget
[09:49] <Spads> this reminds me of when I wrote a STONITH mechanism into something, and took great glee in naming everything based on that metaphor.  other_node_to_be_shot_in_the_head = gethostbyname(...)
[09:50] <Spads> head_in_which_other_node_is_shot = IMPI(...).port()
[09:50] <Spads> etc
[09:53] <cjwatson> OK, I'm generally not fond of the "shoot in the head" metaphor, but "head_in_which_other_node_is_shot" breaks the unpleasant bits of the metaphor enough to make it funny
[09:55] <SpecialK|Canon> cjwatson: hah way ahead of me, thanks :)
[09:55] <SpecialK|Canon> and agreed re STONITH
[09:56] <ilasc> cjwatson: thank you for all the help on the webhooks for livefs and for adding it to the weekly!
[09:56] <cjwatson> my pleasure
[14:01] <tomwardill> cjwatson: https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/376431 is rebased on top of the latest concrete branch and ready for another look when you get chance
[16:13] <cjwatson> tomwardill: approved, but a few small comments and one critical one.  Go ahead and land once you've fixed those
[16:14] <tomwardill> cjwatson: righto, will do :)
[16:15] <cjwatson> tomwardill: (er, by which I mean concrete-oci-recipes, not the next one along yet)
[16:15] <tomwardill> indeed :)
[16:15] <tomwardill> Just got the email
[16:23] <tomwardill> okay,I can go from nothing to 'running' launchpad in one command
[16:23] <tomwardill> shame I can't login once it's running...
[16:24] <cjwatson> Not bad though
[16:26] <tomwardill> cjwatson: ah, those tests arrive in the next MP (oci-ocirecipebuild)
[16:27] <tomwardill> although come to think of it, that is missing anything that tests that, as virtualized being inferred is new
[16:31] <cjwatson> Right, so maybe it's quick to just move the relevant bits over
[16:31] <tomwardill> yeah, doing tha tnow
[16:37] <tomwardill> blergh, the next one has a bunch of rebase fails in it I've just found
[16:50] <tomwardill> wee, this is a fun pile of yaks. Currently adding more interface declarations to IOCIRecipe, because I missed the Admin ones
[17:00] <tomwardill> cjwatson: does https://git.launchpad.net/~twom/launchpad/commit/?id=c5e1d572e1ee61ffa33d73abb73cc87b0b67958a look reasonable?
[17:00] <tomwardill> had to backport some more infrastructure from the next MP
[17:02] <cjwatson> tomwardill: LGTM
[17:02] <tomwardill> cool, will land that, and then rebase/fix the next one
[17:18] <tomwardill> cjwatson: https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/376431 is up I think
[18:16] <cjwatson> wgrant: I fixed up the type naming in https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/373765 (db-bugsummary-statement-triggers) slightly.  OK now?
[22:50] <wgrant> cjwatson: Yay!
[22:58] <cjwatson> OK, let's see how long an LP test run takes on my home server now it has an SSD to play with
[22:58] <cjwatson> Older CPU than my laptop (Ivy Bridge), but seems a bit faster in some situations so we'll see
[22:58] <cjwatson> Er, server is Ivy Bridge, laptop is Broadwell
[22:59] <cjwatson> I tried before but it was too slow to be pleasant on rotating rust
[22:59] <cjwatson> Would be nice to be able to run LP tests somewhere that isn't my laptop


[20:25] <skellat> jrgifford, Unit193, belkinsa: <AOL> You've Got Mail! </AOL>
[21:23] <skellat><PHONE_NUMBER>00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[21:23]  * skellat didn't realize the cat wanted to pounce the keyboard and use IRC too
[22:09] <dzho> /bin/cat apparently
[22:09]  * dzho is wondering what the alignment for that bitstring is
[22:10] <yano> .py print len("000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000")
[22:10] <jenni> 141
[22:11] <thafreak> just a bit too long to tweet
[22:14] <dzho> .py print "what"
[22:14] <jenni> what
[22:14] <dzho> uh
[22:15] <dzho> .py dir*(
[22:15] <jenni> SyntaxError: unexpected EOF while parsing (<string>, line 1)
[22:15] <dzho> .py dir()
[22:15] <jenni> ['args', 'command', 'output', 'self']
[22:15] <dzho> .py dir(command)
[22:15] <jenni> ['__add__', '__class__', '__contains__', '__delattr__', '__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__', '__getnewargs__', '__getslice__', '__gt__', '__hash__', '__init__', '__le__', '__len__', '__lt__', '__mod__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmod__', '__rmul__', '__setattr__', '__str__', 'capitalize', 'center', 'count', 'decode', 'encode', 'endswith', 'expandtabs', 'find', 'index', '
[22:21] <thafreak> That won't be used for evil...
[22:22] <skellat> Define evil these days
[22:24] <thafreak> .py print requests.get('http://icanhazip.com/').content
[22:24] <jenni> NameError: name 'requests' is not defined
[22:24] <thafreak> awe
[22:24] <thafreak> .py import requests;print requests.get('http://icanhazip.com/').content
[22:24] <jenni> ImportError: No module named requests
[22:26] <yano> .py print urllib2.urlopen("https://wtfismyip.com/text").read()
[22:26] <jenni> <IP_ADDRESS>
[22:26] <thafreak> ha
[22:26] <thafreak> was just about to do that :)
[22:26] <thafreak> well, icanhazip.com
[22:26] <yano> it runs on a Google App Engine
[22:26] <yano> i switched to wtfismyip.com
[22:26] <yano> they have SSL and ipv4 and ipv6 subdomains and tor-checks
[22:27] <thafreak> how are you runnin the python on app engine? Like can you create a sub process, or some kind of gae specific worker thing?
[22:29] <yano> i think so
[22:29] <yano> it was created byt somebody else and then they left it to me
[22:29]  * thafreak heading home...
[22:29] <thafreak> ah
[22:29] <thafreak> it's neat any way
[22:29] <yano> oh yea
[22:29] <yano> i proxy the auto-titles through it too
[22:29] <thafreak> if it's on gae, I doubt too much evil can be done :)
[22:29] <yano> https://www.obviouslynotarealdomain.com/
[22:29] <jenni> [ GO AWAY: <IP_ADDRESS> Mozilla/5.0 AppEngine-Google; (+http://code.google.com/appengine; appid: tumbolia) ] - https://j.mp/1q0zfHS
[22:30] <jenni> yeah I just learned how to type.
[22:30] <jenni> mi.
[22:30]  * thafreak AFK
[22:47] <PCLine_> Good evening everyone.
[23:00] <Unit193> Howdy.
[23:02] <PCLine_> Hello Unit193
[23:59] <andygraybeal> heya


[12:48] <_MMA_> Hello guys. Can anyone point me a good Usplash documentation?
[11:48] <lapo> hi
[04:58] <newz2000> Do you guys get [what seems like]  a bazillion bug notices per week about a "pango" bug?
[08:27] <klepas> does anything actually get done here anymore? =\
[08:33] <newz2000> pascal, good morning
[08:40] <klepas> moin
[11:00] <troy_s> klepas:  no