[00:07] <YokoZar> ScottK: so the revolution R people are JUST NOW sending me their packages...
[01:52] <MTeck-ricer> So.. how do you make a package for the kernel?
[01:53] <MTeck-ricer> Or is it pretty much just like any other package?
[01:53] <crimsun> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
[01:53] <crimsun> pretty much, just read the knowledgebase
[01:54] <crimsun> meaning: "essentially you need to read the KB"
[01:54] <crimsun> not: "it's essentially the same as any other package"
[01:54] <MTeck-ricer> crimsun: I don't get what you mean, is there a wiki or anything?
[01:54] <MTeck-ricer> :P
[01:55] <MTeck-ricer> crimsun: thanks
[02:00] <CTho> what is the distinction between PPA and backports?
[02:00] <CTho> or, why would a package only be in a PPA?
[02:02] <crimsun> sometimes it doesn't make sense to continuously push to $release-backports
[02:02] <crimsun> e.g., daily builds of $package
[02:03] <CTho> so does the frequency of firefox patches push it above that threshold?
[02:03] <crimsun> I don't understand your intended question
[02:03] <CTho> why is firefox 3.6 not in backports?
[02:03] <crimsun> for which release?
[02:03] <CTho> security patches are too often?
[02:04] <CTho> karmic
[02:04] <MTeck-ricer> crimsun: wow
[02:04] <crimsun> are you not using the ubuntu mozillateam security ppa?
[02:04] <MTeck-ricer> crimsun: there's a LOT to that...
[02:04] <crimsun> ^^ CTho
[02:05] <crimsun> CTho: also, backports is not intended for security.
[02:05] <CTho> crimsun: should that be set by default?
[02:05] <crimsun> CTho: you're asking questions that I can't answer for an entire distribution.
[02:06] <CTho> i'm apparently not using the mozillateam ppa
[02:13] <ScottK> You shouldn't need to.
[02:13] <ScottK> Security fixes get pushed via the regular updates process.
[02:14] <ScottK> Ubuntu backports are part of the Ubuntu distribution and you can be assured that anything in an Ubuntu backport has been checked by an Ubuntu developer.
[02:14] <ScottK> Anyone can have a backport and put anything in it they want, so you need to evaluate them indifvidually and determine if you trust them.
[02:14] <ScottK> PPAs are not part of Ubuntu.
[02:16] <wgrant> ScottK: Did you mean 'Anyone can have a *PPA*'?
[02:16] <ScottK> wgrant: I did.  Thanks
[02:16] <ScottK> Long day.
[02:16] <wgrant> Heh.
[02:26] <funkyHat> Is it still worth working through FTBFS packages at this stage?
[02:54] <wgrant> funkyHat: Yes.
[02:54] <wgrant> The fewer FTBFSes we have, the easier LTS is going to be.
[02:54] <wgrant> If we need to do an SRU or security update on a package that we can't build, we are in trouble.
[03:38] <funkyHat> Just finished bug #565152 -- doesn't look like it will be relevant to debian unfortunately as they have a separate ftbfs relating to gcc 4.5
[03:44] <imbrandon> ouch not good i need memcached /me looks
[03:46] <imbrandon> funkyHat: i havent looked at the debdiff yet, but i noticed you say in the bug that you changed a bit of code, you did this via a patch file hopefully, correct ?
[03:47] <imbrandon> funkyHat: i actualy would like to see that fixed too so if it all works after a bit of testing i'll sponsor it for ya
[03:47] <funkyHat> imbrandon: yes, there were already some patches in the package so I added a new one. It's using quilt
[03:47] <imbrandon> funkyHat: great, give me about ~30 min to look it over etc and i'll sponsor if its ready
[03:47] <funkyHat> imbrandon: great ⢁)
[04:13] <ScottK> IIRC there was a memcached upload earlier today.
[04:14] <ScottK> Ah, which didn't build either
[04:14]  * ScottK lart's zul.
[04:17] <imbrandon> lol
[04:18] <imbrandon> this one looks fine, still doing a cursory test build though
[04:19] <imbrandon> funkyHat: looks good build / test install finished fine, patch looks sane, i'm just gonna update your changelog entry to be a bit more desciptive and upload , ok ?
[04:21]  * imbrandon is really suprised memcached isnt in main
[04:22] <wgrant> It's odd, yes.
[04:22] <wgrant> Particularly since LP uses it now.,
[04:22] <ScottK> Then that's probably a bug.
[04:23] <ScottK> But if Canonical IS doesn't care, why should I?
[04:23] <wgrant> Heh.
[04:23] <imbrandon> lol
[04:26] <imbrandon> funkyHat: uploaded
[04:27] <imbrandon> wgrant: just out of curiosity ( if you know ) what does LP use to run its python stack ? apache ?
[04:28] <imbrandon> err apache2 + mod_*
[04:30] <ScottK> Not in the queue yet.
[04:31] <imbrandon> ScottK: [ubuntu/lucid] memcached 1.4.2-1ubuntu3 (Waiting for approval)
[04:32] <wgrant> imbrandon: haproxy in front of Apache in front of a Zope server running on Twisted.
[04:32] <ScottK> There it is.  Let me have a look....
[04:32] <imbrandon> wgrant: ahh sounds like a fun job for the IS guys/gals
[04:34] <ScottK> Nice.
[04:34] <ScottK> imbrandon and funkyHat: Accepted.
[04:34] <imbrandon> ScottK: thanks
[04:34] <imbrandon> funkyHat: and thanks for looking at the bug
[04:34]  * ScottK hearts queuediff
[04:35] <imbrandon> i have fell in love with offlineimap, i have no idea why i never used the GREAT tool untill this week
[04:36] <persia> You were participating in the movement to avoid email at all costs?
[04:36] <ScottK> imbrandon: Would you mind taking a look at libgda4 and making a recommendation.  It's FTBFS in lucas_' rebuild and we're several upstream versions behind.  What's the shortest/safest path to something that builds.
[04:37] <imbrandon> persia: lol
[04:37] <imbrandon> ScottK: sure
[04:37] <ScottK> Thanks.
[04:39] <imbrandon> ScottK: upstream or upstream;upstream ? ( did that make sense ? e.g. Debian or further up )
[04:39] <ScottK> imbrandon: Debian.
[04:39] <imbrandon> k
[04:40] <imbrandon> my gut says a sync but lemme look at our deltas and such though
[04:40] <imbrandon> ( havent even looked yet )
[04:41] <wgrant> ScottK: That reminds me. I should see how hard it is to hook the diffs up into the UI.
[04:41]  * wgrant suspects three lines of template should do it.
[04:41] <ScottK> Nice.
[04:57] <imbrandon> dget http://ftp.de.debian.org/debian/pool/main/libg/libgda4/libgda4_4.0.8-1.dsc
[04:57] <imbrandon> err
[05:00] <imbrandon> ScottK: it looks like it can be just a solid sync, they have adopted all our deltas ( even the ones they dident need specifcly for debian , how nice of them ) BUT it might ftbfs on x86_64
[05:00] <imbrandon> thats what i'm checking now
[05:00] <imbrandon> per lp bug 537379
[05:00] <ScottK> OK.
[05:00] <ScottK> Also look at the rdepends and see if it might affect any of them negatively.
[05:01] <imbrandon> yup
[05:03] <imbrandon> suprisingly it has very few rdepends, but ya checkign them
[05:07] <ScottK> imbrandon: BTW, this one is in Main, so it's useful for your core-dev reactivation
[05:12] <imbrandon> ScottK: i noticed ;)
[05:56] <imbrandon> ScottK: looks like it builds fine on x86_64 too
[05:56] <imbrandon> dunno why it is not in debian
[05:56] <ScottK> Cool
[05:56] <imbrandon> anyhow looks like a solid sync, all deltas are accounted for, i'll say so on the bug
[05:56] <imbrandon> if you wanna do the honors
[05:56] <imbrandon> rdepends are also fine
[05:56] <imbrandon> there are only 3 real ones and none will be affected
[05:58] <imbrandon> done
[05:59] <ScottK> imbrandon: File the sync request then and give me the bug number so I can ack it.
[05:59] <ScottK> Explain how much you tested it
[05:59] <imbrandon> ok
[06:08] <imbrandon> ScottK: bug 537379
[06:11] <ScottK> imbrandon: Ack'ed.  Thanks.
[06:11] <ScottK> imbrandon: Want another one?
[06:13] <imbrandon> sure
[06:18] <ScottK> imbrandon: How about flite3 ee http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[06:19] <ScottK> imbrandon: err flite 1.3-release-2
[06:19] <imbrandon> k
[06:20] <imbrandon> strange ver nums ;)
[06:21] <imbrandon> sf.net hosts thinkgeek ? wow never knew
[07:14] <imbrandon> ScottK: please check bug 565207
[07:27] <imbrandon> ScottK: btw per the jorge and planet ...
[07:27]  * imbrandon hugs ScottK
[07:49] <imbrandon> ScottK: bug updated ( FFe info added )
[08:17] <imbrandon> ScottK: ping
[11:46] <dutchie> hi, I'm looking at pushing a fix to bug 64917 into my ppa. I've added a libwebkit-dev Build-Depends: into the debian/control.in file, but I can't work out how to regenerate the debian/control file from it
[11:54] <chrisccoulson> dutchie - the debian/control file should be regenerated automatically when you build the source package (debuild -S)
[11:54] <chrisccoulson> AFAIR it's regenerated as part of the clean target
[11:55] <dutchie> ok
[11:58] <chrisccoulson> dutchie - /usr/share/gnome-pkg-tools/1/rules/uploaders.mk has the hook for regenerating it, in case you are curious
[11:58] <dutchie> cool, thanks
[16:01] <lfaraone> Would any MOTU have a chance to approve the merge of a SRU to {Karmic, Jaunty, Intrepid} in bug 301190? (already been approved by ~ubuntu-sru)
[16:48] <kobrien> can someone review a patch for me in lucid libruby?
[16:49] <kobrien> bug 561432
[18:33] <kobrien> lfaraone: thanks
[18:35] <lfaraone> kobrien: no problem. looks fine, but I'm not a MOTU :)
[18:37] <kobrien> lfaraone: ah, I see. so what happens next?
[18:38] <lfaraone> kobrien: we wait for a sponsor (who *is* a MOTU) to go through the sponsorship list and commit your fix.
[18:38] <hyperair> lfaraone: you aren't? i thought you were.
[18:38] <kobrien> hyperair: are you?
[18:38]  * hyperair is.
[18:39] <hyperair> a motu with no time.
[18:39] <kobrien> I see, I know my patch works. Wouldn't take long :).
[18:39] <hyperair> wait until after my exams and i'll look through anything you like.
[18:39] <lfaraone> hyperair: heh, thanks, feel free to mention that on https://wiki.ubuntu.com/LukeFaraone/MOTUApp when you *do* have time :)
[18:39] <kobrien> lol, I know the feeling
[18:39] <hyperair> lfaraone: sure ;-)
[18:39] <hyperair> kobrien: glad you understand =)
[18:40] <kobrien> hyperair: I've got 2.5 weeks to finish off my project and thesis. :)
[18:40] <lfaraone> hyperair: actually, I just remembered ruby is in main, so we'll need to snag a core dev.
[18:41] <kobrien> well, I'm sure a motu will get to it. As soon as the thesis is done, I'm full steam for becoming a motu. :)
[18:41] <hyperair> kobrien: i've got 6 days to cover 2 months worth of study backlog ;-)
[18:41] <kobrien> RoAkSoAx: ping
[18:41] <RoAkSoAx> kobrien, pong
[18:41] <kobrien> hyperair: good luck
[18:41] <hyperair> kobrien: thanks
[18:41]  * lfaraone seconds kobrien wrt hyperair.
[18:42] <hyperair> lfaraone: thanks
[18:42] <RoAkSoAx> kobrien, how may I help you
[18:42] <kobrien> RoAkSoAx: are you a motu?
[18:42] <hyperair> i guess that's how grim my situation is eh >_>
[18:42] <RoAkSoAx> kobrien, yep
[18:42] <kobrien> good you review a patch for me?
[18:42] <kobrien> could*
[18:42] <RoAkSoAx> kobrien, bug?
[18:42] <lfaraone> kobrien: you don't just need a motu, you need a core dev.
[18:42] <RoAkSoAx> bug #?
[18:42] <lfaraone> RoAkSoAx: bug 561432
[18:42] <kobrien> oh ok, I misunderstood
[18:43] <lfaraone> kobrien: I misspoke earlier, no worries.
[18:44] <RoAkSoAx> kobrien, ruby is in main so you'll need a core dev
[18:45] <kobrien> RoAkSoAx: thanks. Seeing as how someone has subscribed "ubuntu sponsors" and "ruby motu" to the bug, do I need to do anything more?
[18:46] <geser> be patient :)
[18:46] <kobrien> cool cool. :)
[18:47] <lfaraone> geser: hm. that won't make it into lucid, will it...
[18:47] <RoAkSoAx> kobrien, nope, just wait for someone to review it and upload it
[18:47] <kobrien> RoAkSoAx: cheers
[18:47] <lfaraone> RoAkSoAx: but while we have your attention, could you review the merge proposals for SRUing bug 301190 ?
[18:47] <geser> lfaraone: hard to tell
[18:48] <lfaraone> RoAkSoAx: (it's the same change in each SRU, and I tested/built each in their own VM)
[18:50] <RoAkSoAx> lfaraone, ok will take a look at it
[18:50] <lfaraone> RoAkSoAx: thanks :)
[18:53] <kobrien> eh, someone has changed my bug to wishlist but I really don't agree.
[18:53] <kobrien> feedback?
[18:54] <kobrien> ah, it's RoAkSoAx :)
[18:55] <RoAkSoAx> kobrien, whenever you subscribe to ubuntu-sponsors you changed the bug to confirmed, and if possible, to wishlist
[18:55] <kobrien> i see, so is it still considered a bug, cause it is incorrect behaviour of the code?
[18:56] <RoAkSoAx> lfaraone, I'd get approvel from ubuntu-sru first, and then I'll sponsor your upload. And could you please provide buildlogs (of PPAs if possible) to test it?
[18:56] <lfaraone> RoAkSoAx: uh, I thought persia approved it when he accepted the SRU request. Did I miss something?
[18:57] <RoAkSoAx> lfaraone, i dont see any sru ack
[18:58] <persia> I didn't approve anything but the nomination.
[18:58] <RoAkSoAx> lfaraone, ^^
[19:00] <RoAkSoAx> kobrien, yes whenever you subscribe to ubuntu-sponsors mark the bug as confirmed
[19:00] <kobrien> RoAkSoAx: personally I can't
[19:01] <RoAkSoAx> kobrien, btw... I just saw that ruby1.8 is using a patch system. You should make your change in a patch
[19:02] <kobrien> RoAkSoAx: debdiff won't work? there's a link in the bugreport to a ruby site with a patch.
[19:03] <RoAkSoAx> kobrien, yes you have to attache the debdiff, however, you are modifying the source directly. You need to create a patch and make the change in the patch
[19:06] <kobrien> RoAkSoAx: ah, I've found docs, ok. thanks
[19:07] <RoAkSoAx> kobrien, i have unsubscribe your bug from ubuntu-sponsors for now, subscribe again when you made the proper changes..
[19:08] <kobrien> RoAkSoAx: ok, understood
[19:53] <lfaraone> persia: my apologies. would you have time to review the attached branches?
[19:56] <persia> lfaraone: I can't approve an SRU: you really want someone in the SRU team.
[20:01] <lfaraone> jdong: poke.
[20:03] <jdong> lfaraone: yeah, what bug number?
[20:04] <lfaraone> jdong: bug 301190
[20:05] <jdong> *looking*
[20:05] <jdong> apologies, I'm a bit behind in my SRU bug tracking.
[20:06] <lfaraone> jdong: no problem, I only posted it two days ago :)
[20:07] <jdong> lfaraone: ok, you've got a SRU ack :)
[20:07] <jdong> I do like the shiny new workflow with bzr :)
[20:12] <lfaraone> jdong: you and me both. I detested debdiffs, and the pretty colors make it easy to review.
[20:12] <lfaraone> RoAkSoAx: see above :)
[20:12] <hyperair> debdiffs rock.
[20:12] <jdong> lol and I started a war ;-)
[20:12] <hyperair> ;-)
[20:12] <lfaraone> hyperair: but when you need to make a fix you need to build a new source package, generate the debdiff, upload it as an attachment... :P
[20:13] <lfaraone> (vs. "commit, push, wait")
[20:13] <hyperair> lfaraone: actually no you don't.
[20:13] <hyperair> lfaraone: the thing about debdiffs are that... they are diffs.
[20:13] <hyperair> lfaraone: any -p1 diff would do.
[20:13] <lfaraone> hyperair: good point :)
[20:13] <hyperair> my workflow is: git diff <old-tag>, and fire off an email
[20:14] <lfaraone> well, we'll have both methods working for the immediate future; I don't think anybody's suggesting we dump them, I just think new people may find it easier. But I should shut up, since I havne't done testing.
[20:15] <hyperair> lfaraone: there are many who share that opinion
[20:15] <hyperair> lfaraone: but i just dislike bzr.
[20:21]  * ScottK tried the new way and found it slower and more complex so far.
[20:27] <directhex> ScottK, i tried it, then hyperair informed me (correctly) that the bzr branch on launchpad wasn't the same as the package in the archive. which annoyed me
[20:28] <ScottK> I can imagine.
[20:28] <directhex> given i'd spent my time preparing a bunch of changes which were already in the archive but not in bzr
[20:29] <lfaraone> directhex: interesting. usually it is only 12h behind or so.
[20:30] <Laney> 12h is way more than 0h
[20:30] <lfaraone> Laney: ideally, we'd use push mirroring :)
[20:30] <directhex> it's a good thing we don't have a release coming, or an un-warned 12h delay between developer doing one thing and being able to make changes to it would be vexatious
[20:30] <hyperair> i imagine it must take 12 hours to import all the changes made in the archive into the bzr trees >_>
[20:31] <Laney> I just accidently put Britain's Got Talent on
[20:31]  * Laney scrubs eyes with acid
[20:31] <hyperair> lol
[20:31]  * ScottK notes a distressing lack of stuff to review in the queue.  Please fix stuff.
[20:31]  * Rhonda sighs.
[20:31] <hyperair> ScottK: if you have main upload privileges go upload indicator-application please =p
[20:32] <directhex> Laney, i thought that wasn't until thursday evening
[20:32] <Laney> dunno, check ITV1 if you dare
[20:32] <ScottK> I do, but I'm not going to touch that one.  Also, stuff I upload, I can't accept.
[20:32] <Rhonda> ScottK: Good that I asked you to sync wesnoth 1:1.8-1 right ahead, seems my support for parallel build in 1:1.8-2 is giving troubles, at least on Debian buildds. %-/
[20:32] <directhex> IT'S A FUNNY POLITICS JOKE
[20:32] <hyperair> heheh
[20:32] <Laney> oh
[20:32] <Laney> :(
[20:32] <ScottK> Rhonda: I was about to ask.
[20:33] <hyperair> ScottK: oh yeah, i filed a sync request about nautilus-share.
[20:33] <ScottK> Rhonda: Is there anything in -2 we should cherrypick for a -1ubunu1 upload?
[20:34] <Rhonda> ScottK: The two patches that I pulled from upstream would make a lot of sense, yes.
[20:34] <hyperair> bug #565418
[20:34] <ScottK> hyperair: It's best to wait for an archive admin with shell access to deal with the syncs.
[20:35] <hyperair> ScottK: okay.
[20:35] <ScottK> Rhonda: If we could get a bug with a debdiff, then we could get that going.
[20:35] <hyperair> ScottK: i think it still needs an ack from someone with main-upload-privileges though.
[20:35] <ScottK> hyperair: I don't really know enough about Gnome stuff to have an opinion.
[20:36] <hyperair> ScottK: alright then
[20:38] <Laney> how does the rcbugs page look?
[20:38] <lfaraone> it's always interesting to see "ubuntu1) karmic" in debian changelogs :) http://packages.debian.org/changelogs/pool/main/n/ncpfs/ncpfs_2.2.6-7/changelog.html
[20:39] <Laney> looks like those changes should have been forwarded
[20:39] <lfaraone> Laney: they were merged back, yes.
[20:39] <ScottK> Laney: Lots of bugs on it.
[20:39]  * lfaraone is currently looking at syncing ncpfs.
[20:39] <Laney> pulled though, not pushed
[20:45] <sistpoty> ScottK: can you take a look at bug #542634 please? I'm a little bit lost there :/
[20:45] <ScottK> Sure.
[20:45] <sistpoty> thanks
[20:48]  * ScottK is confused too.
[20:50]  * imbrandon is always confused
[20:50] <ScottK> sistpoty: Let's see if we can get an opinion from doko
[20:50] <imbrandon> ScottK: did you see my note about libgda ?
[20:50] <ScottK> imbrandon: I did.  I subscribed the release team.  I think it's reasonable, but didn't want to decide all by myself
[20:50] <imbrandon> k
[20:51] <imbrandon> bdrung: ping ( re: apt-mirror )
[20:51] <ajmitch> sistpoty: sorry that I didn't comment on it, but I don't know that part well enough
[20:52] <sistpoty> k, thanks ScottK and ajmitch
[20:53] <ajmitch> zope has further turned into small piles of black magic :)
[20:53] <imbrandon> lol
[20:54] <lfaraone> ajmitch: it's always been magic :P
[20:54] <ajmitch> but they've cut it up into smaller piles
[20:54] <ajmitch> ScottK: do you know if ~ubuntu-archive is still syncing packages?
[20:55] <bdrung> imbrandon: pong
[20:55] <ScottK> ajmitch: It's a matter if someone has time.
[20:55] <ScottK> Should be so.
[20:55] <ajmitch> so I have to bribe someone, or perhaps change the importance away from wishlist
[20:56] <ScottK> Just put something suitable RC sounding in the description.
[20:56] <ajmitch> "package is burnt toast with php 5.3"
[20:57] <imbrandon> bdrung: i seen you applied ( and authored ) a few patches in apt-mirror, just wanted to let you know i have commited those to upstreams svn today
[20:57] <imbrandon> so they will be in the next release ( maybe today if i can get the other patches ready )
[20:58] <bdrung> imbrandon: great
[20:58] <ScottK> bdrung: Is Audacious all sorted out?
[20:59] <bdrung> imbrandon: one thing that does not work properly: killing apt-mirror with ctrl+c (it kills only a subprocess)
[20:59] <bdrung> ScottK: no, two bugs remain: bug #564087 and #564092
[21:00] <imbrandon> bdrung: probably, never thought about it being run interactively, my mindset is normaly run as a cron, but yea i'll have a look at that
[21:00] <ScottK> sistpoty: Since you approved the audacious FFe, I think you should help with those.
[21:00] <bdrung> imbrandon: thanks
[21:00] <lfaraone> bdrung: hm. whenever I kill it, the network IO stops, so I assume the threads die with it.
[21:00] <sistpoty> crap, that's what you got for only checking rdepends but not build-rdepends
[21:00] <lfaraone> but the lockfile does not go away :)
[21:01] <imbrandon> lfaraone: yea the lockfile bug is fixed in svn now
[21:01]  * sistpoty fixes
[21:02] <ScottK> excellent.
[21:10] <bdrung> sistpoty: and i forgot to check it completely.
[21:10] <sistpoty> well, yeah, things happen... :(
[21:10] <bdrung> lfaraone: do you use the latest version?
[21:12] <lfaraone> bdrung: no, I mean the version in karmic. Is there a behavioral change in this regard in Lucid?
[21:13] <ScottK> sistpoty: I'd appreciate your opinion on Bug 561631.
[21:13] <sistpoty> *looking*
[21:14] <bdrung> lfaraone: yes, the lock file removal is fixed in lucid
[21:17] <imbrandon> yes, and once 0.4.7 is out i'm going to do a -backport, just need to find enough fingers to get it all done ;)
[21:18] <bdrung> imbrandon: backport?
[21:18] <imbrandon> for apt-mirror to older supported releases
[21:18] <sistpoty> ScottK: libpcap is in main, and has very many rdepends, I fear I'll need to thouroughly review the entire diff
[21:19] <ScottK> sistpoty: I think it's worth considering, but I don't know enough to really decide.
[21:29] <bdrung> imbrandon: which releases?
[21:31] <imbrandon> bdrung: all that are still under support, should be fairly simple given the lax dependencys
[21:31] <crimsun> sistpoty: it's a bit big for my comfort, but I understand the discomfort with carrying the current version for 5 years, too.
[21:32] <crimsun> sistpoty: I'm happy to help; there seem to be only 3 source packages that b-d on libpcap0.8-dev
[21:33] <crimsun> 3 in main, that is
[21:35] <sistpoty> crimsun: sure, any help is welcome
[21:35] <sistpoty> crimsun: can you test the 3 packages in main?
[21:36] <crimsun> sistpoty: sure. I'll work on that in about seven hours for a stretch
[21:36] <sistpoty> excellent, thanks crimsun
[21:37] <sistpoty> crimsun: and if you find anything other noteworthy, just add a comment to the FFe in question
[22:00] <ScottK> geser: You TIL rbot.  There's a security fix in Debian I think we'd want.  Would you please have a look at a merge?
[22:03] <geser> ScottK: can do. Does the switch to v3 format need a FFe?
[22:03] <ScottK> geser: No.
[22:04] <ScottK> If that's going to cause problems it'll almost certainly fail to build and we'll know
[22:20] <geser> ScottK: merged
[22:20] <ScottK> geser: Thanks.  I'll accept it when it hits the queue.
[22:22]  * ScottK looks at http://qa.ubuntuwire.com/bugs/rcbugs/ and invites others to find fixes we could benifit from.
[22:26] <geser> ScottK: do you know if sync requests will be processed in time or should packages get synced with the syncpackage script?
[22:27] <ScottK> I don't know for sure, but I think they will.
[22:42] <sistpoty> ScottK: commented on libpcap. I think I'm ok with getting it in, but I'd like someone else take a look at it as well (crimsun maybe?) and see testing of all rdepends in main
[22:42] <ScottK> sistpoty: OK.  Please ask for that in the bug.  I think we should let slangasek make the final call on this one.
[22:43] <sistpoty> ScottK: already done. an opinion from slangasek would certainly be preferred :)
[22:43] <ScottK> lucas_: Is it possible your last rebuild was done with Main only even for Universe packages?  I see a lot of FTBFS due to non-existant packages that do in fact exist in Universe.
[22:47] <imbrandon> ScottK: the more i look at libgda4-4.0.8 ( and subsuqent fix for ftbfs ) we'll need to push that as a sru when we get the x86_64 worked out
[22:47] <imbrandon> ( thats the opinion of the DD's too from the gnome team )
[22:47] <ScottK> imbrandon: OK.  Thanks for looking into it.  BTW, I think deciding stuff shouldn't be uploaded yet should count on core-dev apps too.
[22:48] <imbrandon> heh
[22:49] <slangasek> sistpoty: do you have the bug # handy for that one?
[22:49] <sistpoty> slangasek: bug #561631
[22:50] <sistpoty> slangasek: crimsun volunteered to test rdepends in main, but will need a few hours before doing so
[22:53] <sistpoty> bdrung: do you have the HW to test g15daemon-audacious?
[22:53] <sistpoty> bdrung: as I've got a trivial fix around now
[22:54] <bdrung> sistpoty: no. you can give me 100 euro and i will buy the HW ;)
[22:54] <lfaraone> If a sync request would fix a bug (say, bug 549692), should I modify that bug, or create a new one?
[22:55] <sistpoty> bdrung: haha... then let's just cross fingers that it'll still work with the ftbfs fix (just updating one include directive)
[22:58] <sistpoty> bdrung: I haven't forwarded the change to debian yet, and am quite sure that I'll forget to do so... can you do that please (if it affects unstable as well)?
[22:58] <bdrung> sistpoty: currently it affects only experimental
[22:58] <sistpoty> bdrung: ah, ok
[22:58] <bdrung> sistpoty: didn't we have a tool for sending our changes to debian?
[22:59] <sistpoty> bdrung: could be... I prefer reportbug after checking on an unstable system though
[23:01] <Kangarooo> to get programm to universe i found i need to post to launchpad request for packaging or package myself. if that is done then i post it to revu but http://revu.ubuntuwire.com/ is down
[23:01] <Kangarooo> ups its forbiden
[23:01] <lfaraone> Kangarooo: new packages are not being accepted right now, so there's no rush :)
[23:01] <sistpoty> Kangarooo: hm? revu is down?
[23:01] <geser> bdrung: submittodebian? never used it personally
[23:01] <lfaraone> Kangarooo: I'd ask about it in #ubuntuwire
[23:01] <sistpoty> crap, revu *is* down :(
[23:01]  * sistpoty fixes it
[23:01] <bdrung> geser: yes
[23:01] <ajmitch> sistpoty: the server itself is down?
[23:02] <sistpoty> ajmitch: nope, just apache returns a 403
[23:02] <lfaraone> submittodebian works pretty well in my experience, but occasionally picks up extraneous changes (like debian/control)
[23:02] <ajmitch> sistpoty: ugh, that's bad
[23:02] <sistpoty> ajmitch: not necessarily, looks like md is not mounted
[23:02] <sistpoty> (where revu resides)
[23:03] <imbrandon> fun fun
[23:04] <ajmitch> that's still bad
[23:04] <sistpoty> ajmitch: or can you take a look, since you're already logged in?
[23:04] <Kangarooo> and what to do if i asked for packaging and someone else packages then will he also post to revu or i need to check LP page and get and post to revu that package?
[23:04] <ajmitch> yeah I can confirm it's not mounted
[23:04] <ajmitch> but /dev/md0 isn't looking happy
[23:05] <lfaraone> Kangarooo: most likely the packaging will  not be done unless you do it yourself :)
[23:05] <imbrandon> is revu still on spooky ?
[23:05] <ajmitch> sistpoty: the server was rebooted ysterday?
[23:05] <ajmitch> imbrandon: yep
[23:05] <Kangarooo> ajmitch: i hope this is small problem and server is in cloud :)
[23:06] <Kangarooo> like in cloud computer not rip
[23:06] <imbrandon> Kangarooo: revu will be fixed, its just a matter of when ( depending on the severity of the issue )
[23:06] <lfaraone> Did I update bug 549692 properly to reflect its status as a sync request? (syncing would fix the bug the reporter asked)
[23:07] <Kangarooo> lfaraone: but if i post package request then if not me then someone from motu packages it or anyone also who is not motu can do that? (if yes dont answer- i think yes but not sure)
[23:08] <lfaraone> Kangarooo: somebody *may* package it. if they are not in MOTU, they'll post it to REVU and be responcible for getting it accepted.
[23:09] <ajmitch> sistpoty: I think someone needs to take a look at the raid setup there, /dev/md0 doesn't want to go
[23:10] <Kangarooo> ok thx. ok now the bigest question this maybe a security issue: is programm put to universe checked by someone like checked All code it contains?
[23:10] <sistpoty> ajmitch: ok, I'll take a look
[23:10] <ajmitch> sistpoty: thanks :)
[23:10] <doctormo> http://doctormo.org/2010/04/17/input-debian-packaging-guide/
[23:10] <ScottK> sistpoty: g15daemon-audacious accepted.  Thanks.
[23:10] <lfaraone> Kangarooo: uh, yes, that's the purpose of the sponsorship / mentorship guide.
[23:10] <lfaraone> Kangarooo: * system, I mean
[23:10] <doctormo> I'm after some really simple deb packaging guides, I got a few links so far, but they're rather more verbose.
[23:10] <sistpoty> ScottK: thanks!
[23:11] <ScottK> doctormo: The problem is that packaging is inherently complex.  Anything simple is wrong or dangerously incomplete.
[23:11] <ScottK> Making it simple is an unsolved problem.
[23:11] <doctormo> ScottK: It doesn't have to simple in it's end condition, it just needs to build up with grace
[23:12] <doctormo> Instead of the lumbering clunky documents I read in a few of these links
[23:12] <ScottK> That's not easy either.
[23:12] <doctormo> At least I'll know where to come for critique ;-)
[23:12] <ScottK> Part of the problem is that as soon as you understand packaging, you're inherently unqualified to write documentation for people that don't.
[23:12] <ScottK> There's a very narrow window where you still remember what it was like to learn.
[23:12] <Kangarooo> so no one can put programm witch contains line witch simulates virus? like deleting files. gaining sudo and listening to keystrokes and at random time execute that.
[23:13] <ScottK> Trying to catch people in that window and force them to do documentation is hard.
[23:13] <doctormo> ScottK: Well I don't know how to make deb packages, even though I've done it several times.
[23:13] <ScottK> Kangarooo: In theory no.  In practice no system is perfect.  AFAIK it hasn't happened yet.
[23:13] <jdong> Kangarooo: in general, yes, for new packages 2 sponsors and an archive manager reviews the code comprehensively
[23:14] <slangasek> so I was just thinking yesterday that https://wiki.ubuntu.com/PackagingGuide/Complete could use some refining
[23:14] <jdong> Kangarooo: and for most uploads in general, there are developers that look at what's being uploaded
[23:14] <slangasek> but stopped short of editing it because I don't want to push things there that aren't considered community best practice
[23:14] <jdong> Kangarooo: from personal experience, when I've made some careless oversights in my uploads, I've had fellow developers email me a few hours afterwards.
[23:15] <jdong> (At the same time this does NOT mean you should blindly go trusting every package in the repository from a security standpoint...)
[23:16] <bdrung> sistpoty: now only bug #564092 remains
[23:17] <Kangarooo> ok. i wast just confused 2 days ago why i had system update for sudo. and i hoped it wont take something over with sudo. couse i have never experienced any problem with it and problem with sudo may do some big problem like not overwriting some config and telling all done.
[23:17] <sistpoty> bdrung: I'll take a stab at it
[23:17] <bdrung> thanks
[23:18] <bdrung> i will fix bug #563043 as counterpart
[23:18] <Kangarooo> ok thx all and sistpoty ur welcome :)
[23:20] <doctormo> What is the easiest way to install all build deps for a given control file?
[23:21] <Kangarooo> doctormo: yes make post why packaged things work. im similar like u - tryg to package but cant understand why they work
[23:21] <lfaraone> Kangarooo: if you have specific questions please ask.
[23:21] <dutchie> doctormo: there's a mk-build-deps thingy
[23:21] <dutchie> you can just "sudo mk-build-deps -i" and it creates and installs the build dependencies
[23:21] <lfaraone> dutchie: copy and paste :)
[23:21] <doctormo> This is very much like Alchemy, some things work, some others don't, no one knows quite why.
[23:22] <lfaraone> doctormo: well, there are usually good reasons for this, but it's poorly documented :)
[23:22] <doctormo> lfaraone: Of course! don't you know anything about Science!
[23:24] <bdrung> i had two problems at the beginning: 1. i didn't know all tools. there are a bunch of tools. you need to know how they play together 2. i didn't know how debian/rules worked. which targets were called in which order.
[23:25] <doctormo> bdrung: The targets thing sounds important
[23:26] <bdrung> doctormo: there are only one or two websites showing the targets graph
[23:26] <bdrung> doctormo: maybe it's time for a gui helping to create a package
[23:28]  * lfaraone just used CDBS and didn't worry about targets :)
[23:29]  * sistpoty recalls a packaging without helpes session


[18:22] <Robdgreat> Guest61898: >.>
[18:33] <Robdgreat> meh
[18:52] <hfwilke> he wasn't much of a talker
[19:42] <Robdgreat> so it seemed
[19:43] <Robdgreat> he needs to learn to work his client
[20:07] <hfwilke> that sounds a little salacious
[20:10] <Robdgreat> ;)
[20:10] <Robdgreat> so I'm a troll
[20:11] <Robdgreat> I shall rephrase
[20:11] <Robdgreat> he ought to learn how to avoid ending up with a guest nick on irc


[06:41] <mup> Bug #1975666 opened: Random subnets appearing in the subnet list <MAAS:New> <https://launchpad.net/bugs/1975666>
[15:49] <mup> Bug #1975728 opened: Recommissioned machine now fails power control due to cipher suite <MAAS:New> <https://launchpad.net/bugs/1975728>
[16:19] <mup> Bug #1975730 opened: MAAS fails to release machine and provides no means to force release <MAAS:New> <https://launchpad.net/bugs/1975730>
[16:22] <mup> Bug #1975730 changed: MAAS fails to release machine and provides no means to force release <MAAS:New> <https://launchpad.net/bugs/1975730>
[16:25] <mup> Bug #1975730 opened: MAAS fails to release machine and provides no means to force release <MAAS:New> <https://launchpad.net/bugs/1975730>
[16:28] <mup> Bug #1973427 changed: doc problems on how-to-install-maas page <MAAS:Invalid by billwear> <https://launchpad.net/bugs/1973427>
[21:29] <mup> Bug # changed: 1906328, 1938573, 1939456, 1939608, 1952216, 1958433, 1958451, 1962519, 1970435, 1970643, 1970962, 1971742, 1971754, 1972052, 1972865, 1973304, 1974031
[22:17] <mup> Bug #1975750 opened: MAAS netplan config uses deprecated items <MAAS:New> <https://launchpad.net/bugs/1975750>


[01:11] <thumper> and support type people around?
[01:26] <ralsina> thumper: not really, but maybe I can help you
[01:26] <thumper> ralsina: hi
[01:26] <thumper> ralsina: my server has stopped syncing
[01:26] <thumper> the U1 window says "File Sync starting..."
[01:26] <thumper> but nothing changes
[01:27] <thumper> where should I look?
[01:27] <ralsina> thumper: did you recently add a huge number of files? Like, dozens of thousands?
[01:27] <thumper> yes
[01:27] <thumper> well...
[01:27] <thumper> not that many
[01:27] <thumper> 500
[01:27] <ralsina> ok, what version of ubuntuone-client do you have installed?
[01:27] <ralsina> 500 should not be a problem :-)
[01:28] <thumper> how should I find the version?
[01:29] <thumper> 3.0.1-0ubuntu1.0.1
[01:29] <thumper> from apt-cache policy
[01:30] <thumper> from precise-updates
[01:32] <ralsina> ok, I suggest you file a support request and attach your logfiles
[01:32] <ralsina> because we don't have any known problems that sound like it
[01:32] <ralsina> thumper: logs are in ~/.cache/ubuntuone/log/
[01:33]  * thumper looks
[08:57] <JamesTai1> Good morning all! :)
[11:18] <gatox> good morning
[11:24] <mandel> gatox, morning!
[11:24] <gatox> mandel, hi
[11:25] <mandel> gatox, have you seen the comments here: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/darwin-fsevents-1/+merge/110382
[11:26] <mandel> gatox, I'd love to land the refactoring you did regarding the pyinotify stuff etc (specially so that I merge my branch with that) but we are blocked my the refactoring you did with the tests :(
[11:26] <mandel> as alecu mentioned
[11:27] <gatox> didn't understand this part: "but we are blocked my the refactoring you did with the tests :("
[11:28] <mandel> gatox, that I cannot land that until you fix that skip decorators work :)
[11:28] <gatox> mandel, ahhhhh yes..... also...... did you read the comment of alecu in darwin-fsevents-2?
[11:28] <mandel> gatox, so, I would have done the refactoring around and done a diff branch for the tests, but we know have to wait for those to things
[11:29] <mandel> gatox, yes, we have to talk :)
[11:29] <gatox> mandel, i'm reading alecu's mail
[11:30] <mandel> gatox, I think is better to not do everything in one step, copy if needed, refactor once it works and passes tests
[11:30] <mandel> one step at a time
[11:31] <gatox> mandel, ok..... i've read all the emails
[11:32]  * gatox thought he was almost done with fsevents..... so young and innocent
[11:32] <gatox> jejee
[11:33] <mandel> gatox, yes + code completion hehehehe
[11:33] <mandel> gatox, how are you doing that?
[11:33] <mandel> gatox, I mean, code completion :)
[11:34] <gatox> mandel, take a look: http://youtu.be/xCqiOEXfZd4 :P
[11:34] <gatox> we arre getting there
[11:34] <mandel> gatox, ok, but the backend, how do you store the info?
[11:35] <mandel> gatox, specially for a project
[11:38] <gatox> mandel,  at this moment i'm saving the info only in memory for the opened files, i'm just starting with the part of the completion daemon..... where it resolves the symbols that couldn't be resolved in the first analysis of the code (because of imports, or variables pointing to symbols in the same file, etc), so the daemon explores the different modules, looking at everyone symbols based on the imports,  and who call each function, etc.....
[11:38] <gatox> and try to resolve those cases..... then i'm going to stored the info collected with sqlite, using the paths of the files as keys.... and only update them and access them when necessary, so you don't have a lot of things being processed, or the memory full of stuff
[11:39] <gatox> and i'm doing alllllll the analysis of the code using a lot of tokenizer and ast
[11:40] <gatox> but i think i can reach a level where code completion will be really accurate
[11:41] <mandel> gatox, so, what you could do is not use the path of the files as keys but store in the db the info per module using the module as the key, for example, everywhere you use threading the info is going to be the same
[11:41] <mandel> gatox, what you can do is divide the data in two, that common to everyone (os, threading, etc..) and that just for the project
[11:42] <mandel> gatox, common info can be build when imported or you can even build/deploy the common lib info since should be present always
[11:43] <gatox> mandel, yes, the "storing" part i haven't resolve it yet... i'm still thinking about that..... saving it as module has sense...... but also i'm saving mostly information about the projects, not threading, because that is really cheap to calculate
[11:44] <gatox> not threading, os, etc i mean
[11:44] <mandel> gatox, the problem would be the index.. so you can on top of the normal  autocomplete create a 'first hit cache' with the most common used methods/objects by the current user
[11:45] <mandel> gatox, oh, but being cheap to calculate I don't care.. I want it to be fast.. also, how do you deal with the objects being dynamic? if I  do t = Thread() t = '' ?
[11:45] <gatox> mandel, i was thinking of load in memory the "completion info" of the file being currently edited in the editor
[11:46] <mandel> gatox, you must add a limit to that, you don't want the IDE to use a lot of memory, I think visual studio stores eveything on disk (but they cheat, they have compiled langs)
[11:46] <gatox> mandel, for that i'm calculating the distance going up based on the line number, and analysing the scope of the variable...... also i know is not going to be always 100% accurate..... and if it founds that is confuse between 2 values.... is going to suggest first the possible object.... and then the symbols for that one....... BUT THIS IIS NOT COMPLETE YET!!
[11:47] <mandel> gatox, just poking your brain, I know is not done yet :)
[11:48] <gatox> mandel, and it's the only part of ninja that has tests
[11:48] <gatox> jejeje
[11:48] <mandel> lol
[11:48] <gatox> mandel, ok.... going back to filesystem notifications
[11:48] <gatox> mandel, do you want to talk about something?
[11:48] <gatox> or should i start looking at the code and see how to refactor everything to create the sauron ring?
[11:49] <gatox> the good news..... is that based on the test, mac is working... the bad news..... is that we need to change all the implementations
[11:50] <mandel> gatox, uh... I'm fixing my bits to work correctly, when I do a move from a watch path to a not watch path is not currently converted in a delete (I think is the only bug)
[11:50] <mandel> gatox, I do have a small review request (which is useful for you too) :)
[11:50] <mandel> let me find the MP
[11:51] <mandel> gatox, here: https://code.launchpad.net/~mandel/ubuntuone-client/sys-init-done-darwin/+merge/110967
[11:51] <mandel> gatox, that was harder to find than expected hehe
[11:51] <gatox> mandel, ok.... so i can do the reviews...... look at the code and the possible issues of the refactoring...... and we can wait for alecu to have a mumble with him about fsevents....... what do you think?
[11:51] <mandel> gatox, sounds perfect :)
[11:52] <gatox> mandel, okkkkkkkkk
[11:52] <gatox> mandel, so you are going to europython...... lucky bastard!
[11:52] <gatox> jejee
[11:53] <mandel> gatox, yes :)
[11:53] <mandel> gatox, oh, if you have the mac around, I'd appreciate reviews for the fsevents daemon.. I have lots left :(
[11:53] <mandel> gatox, and will propose a talk for pyconar :)
[11:53] <gatox> mandel, https://code.launchpad.net/~mandel/ubuntuone-client/sys-init-done-darwin/+merge/110967 JAJAJAAJ
[11:54] <gatox> mandel, +1...... i saw the talk yesterday.... and it has sense, because that has to be done in the package
[11:54] <gatox> mandel, yes? what are you going to propose?
[11:55] <mandel> gatox Como hacer programacion asincrona con coroutinas (greenlets)  antes de que los deferreds de twisted te hagan hablar en gallego ;)
[11:55] <gatox> jejejejeje
[11:55] <gatox> mandel, start sending your branches for review in this direction
[11:56] <mandel> gatox, ok, let me make a list with the correct order :)
[11:56] <gatox> mandel, i know you want to come to pyconar because you can't keep away of argentina for so long
[11:56] <gatox> jejejee
[11:57] <mandel> lol
[12:03] <mandel> gatox, here is the list in the correct order: http://paste.ubuntu.com/1048968/
[12:03] <gatox> mandel, roger that
[12:03] <gatox> mandel, start reviewing now, waiting for alecu
[12:04] <mandel> gatox, after the addition of the integration tests you can do sudo ./run-integration-tests which will start the fsevents-daemon and run tests that send events from the fs to python :)
[12:04] <gatox> mandel, it says that in the description of the branches?
[12:04] <mandel> gatox, I'll check
[12:31] <mandel> gatox, looks like it works, I just deleted all my u1 files :(
[12:31] <gatox> mandel, on purpose?
[12:32] <mandel> gatox, accident.. I used my account, not big deal I do have a back up :)
[12:33] <alecu> gatox: mandel, hello all!
[12:33] <mandel> alecu, hello!
[12:34] <gatox> alecu, hi!
[12:34]  * alecu catches up with the backlog
[12:34] <mandel> alecu, I have no picts but yes it works!
[12:34] <alecu> mandel: orsom!
[12:34] <mandel> alecu, I have logs to prove it :)
[12:35] <mandel> oh, and the inhibitor on mac has a bad stub.. I'll have to fix that I see an exception in the logs due to that
[12:36] <gatox> mandel, could it be that your branches depends of something of u1-client that is not yet in trunk?
[12:37] <mandel> gatox, why, are you getting errors?
[12:37] <gatox> mandel, ImportError: no module named txsocketserver in u1-dev-tools
[12:37] <mandel> gatox, is in trunk, you might not have the u1-dev-tool up to date in the mac
[12:38] <gatox> mandel, i just updated...... weird.... i'll try to delete it and branch it again
[12:38] <mandel> gatox, ok
[12:38] <mandel> alecu, gatox I'm off to have lunch, mumble with ralsina when I get back?
[12:38] <gatox> mandel, ralsina or alecu?
[12:39] <mandel> gatox, both, je ne se pa!
[12:39] <gatox> mandel, okok
[12:41] <mandel> alecu, gatox, I left sd syncing all my music back to the cloud to see if it fully works
[12:41] <gatox> mandel, ack
[12:41] <mandel> alecu, gatox, is from a samba share to the cloud, 14 gb.. shall be interesting to see the results
[12:42]  * mandel is scared it seems to work and is fast!
[12:42] <dobey> hmm
[12:42] <dobey> cloud is just a synonym for /dev/null
[12:43] <mandel> dobey, I have back ups for that.. and cloud == weather, right ?
[12:43] <mandel> hehe
[12:43] <mandel> ok, I'm off to have lunch
[12:43] <dobey> cloud == rain. that's what looking outside shows anyway
[12:48]  * alecu bbaiab
[12:54]  * alecu is back
[13:00] <gatox> mandel, i needed to change your script to run the python tests.... are you creating the script taking into account the buildout?? or there was any change in the buildout regarding u1lint and u1trial and i wasn't notify? :P
[13:01] <ralsina> good morning!
[13:01] <alecu> hola boss!
[13:02] <dobey> oi
[13:03] <gatox> ralsina, hi
[13:03] <ralsina> aloha *!
[13:12] <gatox> mandel, PING PING! (when you are back :P)
[13:14] <dobey> i wonder if there is any way we can run qt tests without using qt4reactor
[13:15] <dobey> well, i guess "rewrite u1trial to not use twisted/trial" would be how :-/
[13:17] <gatox> alecu, do you have time to mumble when mandel get back?
[13:19] <ralsina> dobey: a test runner that did what we want and didn't require twisted would be a great thing to have.
[13:19] <dobey> yes
[13:19] <alecu> gatox: sure!
[13:20] <dobey> but it basically involves rewriting trial to not use twisted :-/
[13:20] <gatox> alecu, cool
[13:20] <ralsina> dobey: is there *no* test runner that takes deferreds from tests and doesn't use twisted?
[13:21] <dobey> it's not the deferreds that are the problem
[13:22] <ralsina> dobey: if it's a short explanation, what is?
[13:24] <dobey> the problem is that all the infrastructure to do test running is in twisted trial. u1trial is just a very thin wrapper on top of that to do some extra stuff we need
[13:24] <dobey> so there's reactors which we need to deal with for various tests because our code is using twisted, and thus needs a reactor
[13:24] <dobey> and there's mainloop integration stuff, so we have to use certain reactors for certain tests
[13:25] <dobey> for some projects we probably don't really need a reactor, but for some we still do
[13:27] <dobey> fixing u1trial to not rely on twisted trial is no small/trivial thing. :-/
[13:50]  * mandel back
[13:50] <mandel> gatox, I'm back!
[13:50] <gatox> mandel, did you read my comment about the tests in your branches?
[13:51] <mandel> gatox, it is present, but in one of the later branches.. dont know which one
[13:51] <mandel> gatox, I really hate that $u1trial solution..
[13:51] <gatox> mandel, ahhhh.... so you change it to $u1trial and $u1lint later?
[13:51] <mandel> gatox, yes, it was after one of the comments from mmcc
[13:52] <dobey> buildout really needs to install dev-tools and dirspec from trunk, rather than tarblals
[13:52] <gatox> mandel, ahhhhh ok...... don't lie to me!! i'll check jejejeje
[13:52] <dobey> tarblahs
[13:52] <mandel> gatox, is there, I promise
[13:56] <mandel> gatox, where are the control panel logs written?
[13:56] <mandel> nothing, found them
[13:56] <gatox> ack
[13:58] <dobey> how is s/raise Exception(...)/# TODO: .../ a bug fix exactly? :)
[13:58] <mandel> ralsina, alecu, mmcc, gatox: I have sd running (it has uploading 3,5 gb with no problem) tested move and delete and everything works. Control panel does not start because it cannot find the binaries to execute, so we are in a situation where we need to start packaging this things asap to have it running
[13:58] <mandel> once we solve the binary problems we can move to have control panel working
[13:58] <ralsina> mandel: yay!
[13:58] <mandel> atm, sd with my implementation works
[13:59] <alecu> mandel: awesome! Now, urgently, stop moving upwards and let's get all this landed! :-)
[13:59] <ralsina> mandel: mmcc is not here yet, so let's bring it back when he arrives
[13:59] <mandel> alecu, I agree, landing all the code this week must be a priority
[14:00] <alecu> mandel: right. Also, be aware that there's a holiday in .AR tomorrow.
[14:00] <mandel> alecu, gatox, shall we mumble about the comments in the fsevents branches?
[14:00] <mandel> alecu, really.. ok had no idea..
[14:00] <gatox> mandel, stop showing off! i also think that my implementation works.... at least all the tests are ok ejjee
[14:00] <gatox> haven't tested it yet :P
[14:01] <gatox> mandel, mumble now sounds good to me
[14:01] <gatox> alecu, ?
[14:02] <alecu> gatox: already there!
[14:02] <mandel> going
[14:32] <dobey> man, triaging bugs is not fun. nor his having to create these pretty commit messages for merging a bunch of changes into stable branches
[14:33] <dobey> also, that powerbar energy gel thing i just had is making me tire
[14:41] <mmcc> Hi Folks
[14:47] <dobey> hi mmcc
[14:49] <mmcc> hi dobey. just caught up on the logs
[14:50] <mmcc> mandel, for your set_application_name fix, it shouldn't be a TODO. It should just be a no-op, since the app name is set in the info.plist on macos
[14:50] <mandel> mmcc, sure, I can remove the comment
[14:51] <mmcc> mandel: cool. also, send reviews my way today
[14:52] <dobey> ooh
[14:52]  * dobey suddenly remebers how cool bzr log -r -1 -n0 is
[14:53] <mandel> mmcc, sweet, hereis a list with all the reviews I need in order: http://paste.ubuntu.com/1048968/
[14:53] <mandel> mmcc, some might have already the +1 but it should not be the case
[14:54] <mmcc> ok mandel
[14:54] <mmcc> btw mandel, you said controlpanel doesn't start because it doesn't find the binaries to execute, but I'm not seeing that problem (or maybe I am and I don't know it..) - can you explain more? which binaries? On my system, it finds sso-login correctly, but freezes later. However I didn't see any evidence of trying to find another binary - ie, no backtrace
[14:57] <mandel> mmcc, TODO removed :)
[14:58] <mandel> mmcc, when I look at the logs I'm getting that it cannot find the file to execute the sso. I'm not surprised since I have sso in a diff location etc.. so the problem I have is just that the code is not packaged and when it tries to run the backend/sso things go wrong
[14:59] <mandel> mmcc, is expected when I just executing things from source without setting the paths etc..
[15:00] <dobey> meh
[15:00] <mandel> me
[15:00] <briancurtin> me
[15:00] <mmcc> ah ok. yeah, when I'm testing I'm setting PYTHONPATH on the commandline. I have a branch pending to get the right paths when packaged...
[15:00] <mmcc> me
[15:00] <mandel> mmcc, exactly, so is a no issue in the current state
[15:00] <ralsina> me
[15:00] <dobey> alecu, thisfred, gatox?
[15:00] <gatox> me
[15:00] <alecu> me
[15:01] <thisfred> me
[15:01] <dobey> λ DONE: tarmac tweakery, uploads, bug #1009786 (u1sync), bug #1014772, got MRE approval
[15:01] <dobey> λ TODO: finish 3.99.0 triage/releases/uploads
[15:01] <dobey> mandel
[15:01] <dobey> λ BLCK: None.
[15:01] <mandel> DONE: fixes for bug 1014752 bug 1015053. Got syncdaemon running on mac os x, synced 3,5 gb so far out of 15 gb. Tested cretion, deletion and rename of files.
[15:01] <mandel> TODO: Get the fsevents-branches landed. Stress tests the sd on mac os x.
[15:01] <mandel> BLOCKED: no
[15:01] <mandel> briancurtin, please
[15:01] <briancurtin> DONE: jenkins stuff, reviews, created installer for signing, but that's screwed up
[15:01] <briancurtin> TODO: do more testing on this installer to make sure it was created properly, then go back through the signing process
[15:01] <briancurtin> BLOCKED: no
[15:01] <briancurtin> NEXT: mmcc
[15:02] <mmcc>  DONE: poking at controlpanel UI all day
[15:02] <mmcc>  TODO: review mandel's 6 branches, other reviews, awaken controlpanel
[15:02] <mmcc> BLOCK: need help with controlpanel UI freeze
[15:02] <mmcc>  NEXT: ralsina
[15:02] <ralsina> DONE: reviews, mgmt call, misc stuff TODO: get a Q VM up because u1cp iscompletely broken there, help in u1db build system BLOCKED: no NEXT gatox
[15:02] <gatox> DONE:
[15:02] <gatox> Reviews, refactoring, mumble with alecu and mandle
[15:02] <gatox> TODO:
[15:02] <gatox> Refactor windows and darwin implementation.
[15:02] <gatox> BLOCKED:
[15:02] <gatox> No
[15:02] <gatox> alecu, go
[15:02] <alecu> DONE: leveled up to undead-dog cough, took a sick day, mumbled with mandel and gatox about reviews and refactorings
[15:02] <alecu> TODO: do lots of reviews for the mac team
[15:02] <alecu> BLOCKED: no
[15:02] <alecu> NEXT: thisfred
[15:02] <thisfred> DONE: bug #1006872 TODO: bug #1006872 BLOCKED: no NEXT: NULL
[15:04] <ralsina> comments?
[15:05] <alecu> n/c
[15:05] <mandel> ac/dc
[15:05] <dobey> i can hear the sine wave resonating in the cyrstals of one of my LCDs
[15:06] <alecu> (newtons/coulomb)
[15:06] <ralsina> ok, EOM
[15:06] <mmcc> comment: I should be busy with reviews today, but if anyone has tips on debugging hung PyQt UI, I'd appreciate it for after
[15:06] <dobey> which is weird, since it should be DC at that point
[15:07] <dobey> so probably the power supply is slowly going the way of kaboom
[15:07] <alecu> mmcc: if you point me at the branch I can try running it.
[15:07] <mmcc> ie, debug Env vars or stuff...
[15:07] <mmcc> alecu, ok - let me check that I have everything relevant pushed and I'll ping you in a sec
[15:07] <mandel> mmcc, let me fix a branch I have left, deal with email and I'll poke you to see if I can give a hand
[15:08] <alecu> mmcc: btw: is this only inside the py2appd control panel, or it happens when running from trunk too?
[15:08] <dobey> ok, i need to get lunch and deal with a couple things, before i end up taking a nap on the futon
[15:08] <mmcc> thx mandel. I'll paste the info and link it here for both you guys
[15:08] <dobey> bbiab
[15:08] <mmcc> alecu, only testing from source for now, I haven't tried it from the .app
[15:09] <alecu> "+TODO: nap"
[15:09] <alecu> sounds like a plan :-)
[15:13]  * gatox lunch
[15:14] <thisfred> alecu: you and me both: My coffee pot broke, so I'm going through serious withdrawal
[15:22] <mmcc> thisfred: I recommend always having three or four backup coffee pots. Two french presses, and a stovetop espresso maker, at a minimum. Engineer some redundancy!
[15:23] <thisfred> mmcc: you are of course correct (this was a french press, actually, which I really love). I suggested this morning that it was no reason for panic, and my wife damn near killed me. I'm starting to come around to her point of view.
[15:24] <thisfred> next day shipping a replacement part from amazon
[15:24] <thisfred> I think I'll walk to a coffee place over lunch to get my fix
[15:29] <mandel> all with a mac machine, I have sent you a mail on how to get sd runnig on it for you to tests the current status and crush my happiness, let me know if it works :)
[15:31] <ralsina> mandel: you left out the explanation about how to get the whole environment setup :-)
[15:31] <mandel> ralsina, meh, I have high expectations with you :)
[15:32] <ralsina> mandel: but you did not mail *me* you mailed ubunet-discuss!
[15:32] <mandel> ralsina, as cc, those are second class citizens..
[15:32]  * mandel writes a second email pointing to the google doc
[15:38] <mmcc> alecu, mandel, *, here is a paste about the UI issues I'm having with control-panel: http://paste.ubuntu.com/1049301/
[15:38]  * mandel looks
[15:47] <Moscherkobold> hi
[15:48] <Moscherkobold> rye: are there any news about my double account problem?
[15:51] <rye> Moscherkobold: hi, matiasb is working on mergint the accounts now and this is still in progress
[15:52] <Moscherkobold> ok thank you
[16:14] <mandel> dobey, I fixed the lint issues for https://code.launchpad.net/~mandel/ubuntu-sso-client/fix-tcp-activation/+merge/109367 can it be set to approved?
[16:21] <alecu> mmcc: http://stackoverflow.com/a/1745965/1098199
[16:22] <mmcc> alecu: handy, thanks!
[16:26] <mmcc> mandel, your python test suite for fsevents-daemon still doesn't run for me without tweaking...
[16:26] <mmcc> oh man, we really need to fix this buildout install
[16:26] <mandel> mandel, which branch?
[16:26] <mmcc> s/install/situation on macos/
[16:26] <mandel> herb, soy tonto
[16:26] <mandel> mmcc, which branch?
[16:26] <mandel> mmcc, and yes, we have to fix that
[16:26] <mmcc> mandel, mandel, the reduce-json-tools branch
[16:27] <mmcc> yeah, i have two different dev-tools branches in parts/ so now when I run env-mac, it defines $u1trial to be BOTH of them
[16:27] <mmcc> >_<
[16:27] <mandel> mmcc, yes, sorry I added that in the following one.. but yes, we ought to fix that asap
[16:28] <dobey> mandel: i set it so
[16:29] <mandel> dobey, superb, thx I also updated https://code.launchpad.net/~mandel/ubuntuone-fsevents-daemon/fsevent-is-directory/+merge/109826 following your comment, is not a constant in a header that I know so I created one
[16:30] <mmcc> mandel, ok I see the change in the next branch, but I'm still wondering how you set your environment up. what's your PYTHONPATH when you run those tests?
[16:30] <mandel> mmcc, I set everything manually 'cause I hate the way is done atm.. so I'm not a good citizen..
[16:31]  * mmcc is not happy about how fast I'm getting at typing 'PYTHONPATH'
[16:31] <dobey> mandel: where did you get those hex values from originally?
[16:31] <mmcc> mandel: ok, well I'm inclined to approve the branch, since I can make the tests work and they do pass. but we need to fix the buildout env setup
[16:32] <mmcc> mandel, ping me when you and dobey are done - I have a question and don't want to weave two conversations together
[16:32] <dobey> mmcc: you can make a script called PYTHONPATH, that runs "PYTHONPATH=blahblahblah $@" then you can just tab-complete it! :)
[16:33] <mmcc> urgh
[16:33] <dobey> haha
[16:35] <mandel> dobey, from here: http://osxbook.com/software/fslogger/
[16:36] <dobey> i wonder where he got them from then :)
[16:39] <mmcc> mandel: I approved your json-size branch with a note about post-ARC refcounting changes we might need to make. Maybe you've already addressed them in later branches
[16:40] <mandel> mmcc, I have not looked at remove arc just yet, I was focused on getting the thing in u1-client
[16:40] <mandel> dobey, no idea..
[16:40] <mmcc> ok, sounds good
[16:42] <mandel> mmcc, I'll be away for pycon in a few weeks and then holidays so I want you to have the thing working from point to point and arc is not that necessary right now
[16:43] <dobey> i need to take some holidays
[16:44] <mmcc> mandel: that's fine. I will be getting a laptop with 10.7 on it shortly anyway
[16:47] <mandel> mmcc, ok, nevertheless, I don't want to go and, as spaniards say, dejarte en bragas
[16:48] <mmcc> "dejarte en bragas" -> google translate -> "leave in panties"
[16:48] <mmcc> I TOTALLY UNDERSTAND
[16:51] <mandel> hehehe
[17:03] <mmcc> mandel: ok I read through the add-integration-tests branch and it looks good, but I can't actually run the tests, because I can't build the daemon. can we get someone else to run them? I'm guessing dobey couldn't, and he's the other reviewer on there now
[17:03] <mandel> mmcc, yes, add a +1 but do not approve and gatox can run them :)
[17:03] <dobey> i can't run the tests, no
[17:04] <mmcc> ok
[17:05] <gatox> mandel, i'm going to keep reviewing your branches now.... and keep refactoring later
[17:05] <mmcc> ok, marked and requested gatox
[17:05] <mmcc> hi gatox
[17:05] <mmcc> :)
[17:05] <gatox> mmcc, hi
[17:06] <mmcc> mandel, btw did you get a chance to run control-panel as I pasted earlier? notice anything?
[17:07] <mandel> mmcc, I'm doing it right now, just finished with the old branches..
[17:07] <mmcc> great, thanks mandel
[17:07] <alecu> mandel: I agree with dobey: what's with the "0xfffff000" for the type?
[17:08] <alecu> mandel: it makes no sense that the last nibble of the va_type is also the first nibble of the va_mode.
[17:09] <alecu> mmcc: I'll run the tests
[17:09] <mandel> alecu, the kea->data.mode is the combination of the type and the mode
[17:09] <alecu> mandel: right. But the code is using "and" to split them.
[17:09] <mandel> alecu, why... no idea, I gathered that form the fslogger code which has no doc what so ever..
[17:10] <alecu> mandel: and it makes no sense the way it is now, because it's not exactly splitting them.
[17:10] <alecu> mandel: can you point me at that line in fslogger?
[17:11] <alecu> mandel: don't worry, I've found it.
[17:11] <mandel> alecu, http://osxbook.com/software/fslogger/download/fslogger.c
[17:12] <gatox> mandel, run-integration-tests need to run it with sudo or something?
[17:12] <mandel> gatox, sudo, if you don't it will tell you to do so :)
[17:12] <gatox> mandel, ack
[17:13] <mandel> mmcc, I get the following paste.ubuntu.com/1049486
[17:14] <gatox_mac> mandel, http://paste.ubuntu.com/1049488/
[17:14] <mmcc> mandel, that looks familiar. do you also see the UI with the frozen overlay?
[17:15] <mandel> mmcc, yes, gets there does nothing
[17:15] <mmcc> yep that's what I see. glad it's not just me
[17:15] <mmcc> btw also mandel, quick typo needs-fixing on https://code.launchpad.net/~mandel/ubuntuone-fsevents-daemon/fsevent-is-directory/+merge/109826
[17:15] <mandel> mmcc, ok, I'm EOD I'll fix tom morning
[17:16] <gatox> mandel, before you leave
[17:16] <mandel> gatox, u1trial does have a --reactor option 100% sure, you env is funny
[17:16] <gatox> mandel, cra
[17:16] <gatox> crap
[17:16] <mandel> gatox, if you have the latests version you can remove the --reactor because the default in os x is twisted
[17:17] <mandel> gatox, but yes, your env is funky
[17:17] <gatox> mandel, i'll try
[17:18] <mandel> mmcc, I'm EOD, I'll look into control panel tom once I have fixed some little bugs in the u1-client/fsevents integration (not major, nedd to ignore -spotligh files)
[17:18] <dobey> mmcc, thisfred: sanity check for https://code.launchpad.net/~dobey/ubuntuone-client/update-4-0/+merge/111063 ?
[17:19] <mmcc> mandel: ok, sounds great. consider controlpanel low priority,
[17:19] <mmcc> dobey, will do.
[17:20] <mandel> mmcc, ack
[17:20] <mandel> all, I'm off, laters!
[17:22] <gatox> mandel, bye
[17:23] <thisfred> dobey: +1
[17:23] <mandel> gatox, send me an email if I need to review your branches tom morning, ok?
[17:23] <dobey> thanks thisfred
[17:24] <gatox> mandel, ack
[17:24] <mandel> alecu, I unzipped the linux source code (kernel) in the u1 folder, nothing has happened yet because is processing the music lib I added (5 gb out of 15 gb) I'll let you know how it went tom
[17:25] <alecu> mandel: great.
[17:25] <alecu> mandel: I'm interested in the memory consumption on the python side, and if "DROPPED_EVENTS" shows up.
[17:27] <mandel> alecu, ok, I can give you a num of sd at the moment: Ream mem size 26.5 MB, Virtual Mem 2.42 GB (normal with all those files??) Shared Meme 216 kb Private Mem: 24.6  MB Virtual Private Mem: 111.7 MB
[17:28] <mandel> alecu, cpu % is 7% ~ 9%
[17:28] <alecu> mandel: re: "Virtual Mem", check the size of the tritcask files
[17:29] <alecu> mandel: (regarding the 2gig size)
[17:31] <mandel> alecu, not a single file from the tritcask folder is bigger than 9.2 MB
[17:33] <mandel> alecu, the fsevents daemon virtual meme is also 2.4 GB so the domain..
[17:33] <mandel> alecu, lets look closer tom
[17:33] <alecu> mandel: sure.
[17:33] <mandel> alecu, the systems seems stable but certainly those numbers do not look good
[17:34] <alecu> mandel: it's awesome that's stable, now we can work on making it smaller.
[17:36] <mandel> alecu, yes, is not the worst to have an alpha version that is memory hungry
[17:36] <alecu> mandel: btw: I seem to be missing ocmock...
[17:36] <gatox> mandel, i can't run your testes..... i remove the --reactor thing but there is another problem now..... i'll try to debug it or submit the need fixing in the MP
[17:37] <alecu> mandel: should we install that from the buildout scripts?
[17:37] <mandel> alecu, sorry, yes, the url is given in the description as well as how to add it to the path
[17:37] <mandel> alecu, I don't know.. but I'd say is too much work for what it brings to add it to the buildout
[17:37] <alecu> mandel: probably not on this branch :-)
[17:38] <alecu> mandel: I mean, it's not on the description of this branch.
[17:38] <mandel> alecu, oh, let me find the one that gave it :)
[17:39] <mandel> alecu, here you have it: https://code.launchpad.net/~mandel/ubuntuone-fsevents-daemon/add-dispatcher-tests/+merge/107766
[17:39] <alecu> mandel: thanks. Let's add that bit at least to some readme or wikipage. Tom, of cource.
[17:39] <alecu> *couse.
[17:40] <mandel> alecu, yes, will do
[17:40] <mandel> alecu, added to that branch description too
[17:40] <briancurtin> sigh...new binaries uploaded for signing, my hope that we could skip that step turned out to be wrong
[17:40] <alecu> *course, dam it. (said the beaver)
[17:40] <mandel> alecu, the 11.04 mini specs share from cparrino are a good tests to see if we support : on mac :)
[17:41] <alecu> mandel: awesome. Do we?
[17:41] <mandel> gatox, mmcc, alecu, I should expect a file with the name 'Foundations 11: Faster Uploads' fail, right?
[17:42] <mandel> alecu, I don't think we do atm, will be a pita since we use the linux methods which do not have the translate decorators..
[17:42] <mandel> but lets not support that just yet
[17:42] <gatox> mandel, fundations file?
[17:43] <mandel> gatox, yes, look at the evil ':' in the name :)
[17:43] <mandel> evil evil..
[17:43] <gatox> ahhhhhhhhhhhhhh
[17:43] <mandel> gatox, I remember that share 'cuase it gave me nightmares in the windows port
[17:43] <mandel> ok, really leaving now, laters!
[17:43] <mandel> o/
[17:43] <gatox> mandel, bye
[17:44] <mmcc> mandel, it might not fail... :)
[17:44] <mmcc> in terminal, do 'touch foo:bar'
[17:44] <mmcc> ls -l shows it as foo:bar
[17:44] <mmcc> the Finder shows it as foo/bar
[17:45] <mandel> mmcc, great!
[17:45] <mandel> mmcc, I wonder what happens with the event from the fsevents
[17:45] <mandel> I'll tests tom
[17:45] <mandel> stop being interesting, bye!
[17:45] <mmcc> yep, we'll see
[17:45] <mmcc> bye mandel
[17:48] <mandel> mmcc, just tested it, it uses ':' correctly :)
[17:48]  * mmcc going for lunch
[19:36] <joshuahoover> ralsina: how's the windows release going? :)
[19:36] <briancurtin> joshuahoover: waiting for binaries to be re-signed...i sent bad ones
[19:37] <ralsina> joshuahoover: ^
[19:37] <joshuahoover> briancurtin: ah, k
[20:01] <gatox> ok...... eod and i need to leave...... i'll finish with the refactor tomorrow
[20:01] <gatox> bye peoplle!
[20:45] <ralsina> EOD for me, see you all in 2 days!
[20:45] <briancurtin> see ya ralsina, i'll be pushing the release on whenever they get back to me
[20:45] <ralsina> briancurtin: awesome, thanks
[21:22] <mmcc> uh-oh. mandel's fsevents daemon uses a JSON parsing api that's only available on 10.7.
[21:27] <mmcc> But that's hopefully not a blocker - There's an alternative, https://github.com/johnezang/JSONKit that's supposed to be faster and is BSD licensed.
[21:28] <mmcc> mandel knows about it. we'll see tomorrow
[21:39] <dobey> ok, i gotta run. have a good evening all
[22:10] <mmcc> almost EOD and I've finished my 7 reviews. Anyone still around and have anything I need to review?
[22:31] <ralsina> mmcc: no, go to sleep :-)
[22:32] <mmcc> ralsina: I'm so far from sleep it's not even funny. I have painting to do...
[22:32] <ralsina> mmcc: or hibernate, depending on your system settings
[22:33] <ralsina> mmcc: just kidding, have fun!
[22:33]  * mmcc wonders if I can use the "boss told me to sleep instead" line
[22:41]  * mmcc heads out to go buy paint


[15:21] <pavlushka> Hello Kilos ,How are you?
[15:21] <Kilos> hi pavlushka  bad head day but ok ty and you?
[15:22] <Kilos> when is this channel ever going to grow
[15:23] <pavlushka> Kilos: I've been few kilos away, just arrived and so far so good :)
[15:24] <pavlushka> I would be more than happy if I could answer that (still optimistic)
[15:47] <Kilos> lol


[00:03] <OerHeks> i think to the root of your Home folder, or ~/Downloads?
[16:29] <wlan2> I am having a problem with HiDPI, or maybe I should rather say without.
[16:30] <wlan2> I'm on 18.04.2. How can I collect relevant information?
[16:33] <wlan2> It's like, not even krita is scaling now.
[18:54] <Jason17> Hi, everyone..
[18:57] <Jason17> For instance, I am having troubles with Shared_Folders that is not being recognized by Ubuntu 19 studio, running under VirtualBox 15_26.. If anyone could send my some WA I apreciate.


[02:50] <infinity> BenC: When you get a chance, can you test the new ppc kernel on one or two of your freescale platforms?  Seemed happy on my IBM kit.
[07:27] <smb> infinity, I may do when I could stop holding my breath for some progress by others on other things. Bah!
[07:57]  * apw yawns
[08:10]  * ppisati reboot
[08:10] <ppisati> almost
[09:47] <apw> smb, heads up ... luks encrypted partitions seem to have a size ... so when you have an fs in an ecrypted lvm one needs to resize the volume, the luks, and the fs
[09:48] <smb> apw, nifty
[09:49] <apw> i had assumed that it would be 'sizeless' that it would be encrypt data, write to block number +1
[09:49] <apw> and not care how big it is, seems not
[09:50] <smb> Hm, there seems to be a resize for cryptsetup plain... not found anything obvious for luks prefix yet
[09:51] <xnox> apw: it is sizeless, but it needs a tiny bit of header padding in the beginning.
[09:52]  * xnox did a successfully shrank encrypted lvm without causing data loss.
[09:52] <apw> xnox, there is a 'resize' command at the cryptsetup which 'collected wisdom' (read googling) implies you should run that, so e2fsresize smaller, cryptsetup resize smaller, lvm resize smaller
[09:53] <apw> xnox, but it sounds like you missed the middle step and still have your data :)
[09:53] <apw> smb, do you know what happens if you snapshot an LV and then resize the original smaller
[09:53] <smb> apw, no
[09:54] <apw> smb, i assume there is a way to take a snapshot and promote it to a full LV with its own blocks ?
[09:54] <xnox> well I had: partition -> crypt -> lvm -> volumes. So yeah, i did e2fsrezise, vgresize, and partition resize. I guess i should have used cryptsetup resize =))))))
[09:55] <smb> apw, Sure you can dd it...  :-P
[09:55] <smb> xnox, vgresize ? not lvresize?
[09:56] <smb> hm, eh probably implies
[09:56] <xnox> smb: implies, i had enough spare extends.
[09:56] <xnox> or whatever lvm measures it's vgs in.
[09:59] <smb> xnox, just was wondering about one of the things sounding odd without being clear which. If all volumes are in the vg and that has enough spare extents, one would not need to resize any fs
[10:01] <xnox> smb: depends where physically extends are allocated for used volumes. So for me i had ||||||||________|||____|| so I had to move extends in the VG to make it look like |||||||||||||___||______ and then I was able to shrink it to |||||||||||||___||
[10:01] <smb> apw, For that dreaded vg on loop and dd on snapshot bug I would be glad if there was a quick snapshot to full lv (or actually any). But as the snapshot is reference to origin plus delta it is not that simple
[10:06] <smb> xnox, Sure that just needed to ensure that all lvs only use extends before the parts you want to reduce. If there is enough free that is just moving some blocks and making the mapping a bit more complex. As long as the lvs can stay the same e2fsresize is not needed. So you had the dm device that crypt produces as a pv for lvm?
[10:06] <smb> (just wondering whether that did not also require a crypt resize)
[10:08] <xnox> i believe yes. just the default encrypted install which d-i / ubiquity produce.
[10:17] <smb> Ah, hm that may actually have been part->lvm->lvs->crypt... (though I would need to do an install again to be sure) Somehow I think it was a bit hard(er) to convince lvm to expect pvs in device-mapper volumes...
[10:19] <xnox> smb: there is a single crypt device which contains one vg which has volume for rootfs and a volume for swap.
[10:19] <xnox> that's how d-i/ubiquity does it in automatic partitioning.
[10:20] <xnox> but one can in the manual partitioning setup the scheme you described.
[12:32] <apw> rtg_, i am just prepping a saucy upload, as there is some doubt over the overlaysfs fixes, so i am reving it to v18
[12:32] <apw> (as overlayfs is key for the CDs)
[12:32] <rtg_> apw, ack
[12:33] <apw> rtg_, it'll carry your debug change as well
[12:33] <rtg_> that one wasn't all that important
[12:34] <apw> nope but it may as well go in, otherwise there is nothing and that is probabally good, so i can just touch test this
[12:41] <rtg_> apw, did 3.10.0-0.7 break the dailies ?
[12:41] <psivaa> hello, I reported bug #1195710 that is impacting multi-lvm saucy server installations of today's image
[12:41] <ubot2`> Launchpad bug 1195710 in linux (Ubuntu) "'Kernel bug - invalid opcode: 0000 [#1] SMP' is reported at 'Preparing linux-image-extra-3.10.0-0-generic' stage of multi-lvm installations of amd64 saucy server " [Undecided,Confirmed] https://launchpad.net/bugs/1195710
[12:42] <apw> rtg_, i don't think it did, but rather than there be any risk of it being wrong i think i'll update it
[12:42] <psivaa> a failed installation is active in one of our servers, aldebaran if anyone would like to look into
[12:44] <psivaa> this appears to happen during kernel installation stage
[12:44] <apw> psivaa, have we had any good installs on anything today ?
[12:45] <psivaa> apw: yes, apart from multi-lvm on amd64 server images, the other server installs are good
[12:45] <psivaa> apw: desktop had some other ubiquity issues though
[12:45] <apw> psivaa, ok good thanks
[12:54] <apw> psivaa, and this only happens  on complex lvm installs, what does multi-lvm mean in this context
[12:58] <smb> funnily most of that backtrace is about ext4
[12:58] <apw> smb, i know odd isn't it, odd that it only appears on lvm
[12:59] <rtg_> seems like an indirect op's pointer got corrupted ?
[12:59] <smb> psivaa, It might help us a lot if you could elaborate in the bug what multi-lvm actually means in the way of setup
[13:01] <apw> smb, and only on 64 bit as well
[13:02] <psivaa> smb: ok, ill try to include that info
[13:02]  * henrix -> back in 15 mins
[13:03] <apw> there is only one BUG in that routine
[13:03] <apw> so i guess it has to be that one, which implies we found non-preallocate space on the list to free
[13:08] <psivaa> apw: so it appears that this is occurring in i386 as well, saw that on the second attempt. ill update the bug
[13:14] <apw> psivaa, but only on lvm, very odd
[13:17]  * apw can see no way overlyfs could be in involved in that error at least
[13:17] <apw> psivaa, in hte i386 failure, the same stack trace ?
[13:19] <psivaa> apw: yes to my eyes, but please see http://pastebin.ubuntu.com/5807755/
[13:20] <apw> it may be hinting at one layer deeper, but feeling related
[13:22] <apw> a slightly different manifestation, but here we are complaiing that osmething on the never allocated list is marked as deleted
[13:22] <apw> psivaa, and nothing like this on non lvm testing
[13:23] <psivaa> apw: i'm running a couple of more tests just to confirm that. will update once the tests finish
[13:30] <rtg_> apw, want me to wrap up Ubuntu-3.10.0-1.8 while you are messing with that LVM bug ?
[13:31] <apw> rtg_, i have pushed the tag, and built some test kernels
[13:31] <rtg_> ok, np
[13:31] <apw> and have it ready to upload, so prolly i can just ocmplete it
[13:31] <rtg_> fireaway
[13:32] <apw> i have the source package ready to go now, just do this boot test, and touch test overlayfs
[13:34] <rtg_> hallyn, USER_NS seems to be getting close in 3.10. Only XFS_FS is left in the UIDGID_CONVERTED dependencies. Perhaps by 3.11 ?
[13:35] <ppisati> brb
[13:39] <hallyn> rtg_: perhaps.  Dwight at oracle is actually trying to get that done right now, but the xfs folks have some problems...
[13:39] <hallyn> most of all, they're wondering what to do with bulkstat
[13:40] <rtg_> hmm, well its getting close to the 3.11 merge window.
[13:40] <hallyn> yeah :(
[13:41] <hallyn> does anyone here have terrific insights into xfs?
[13:41] <hallyn> and its peculiarities?
[13:53] <apw> rtg_, do you have saucy linux-meta sitting unpushed ?
[13:53] <rtg_> apw, checking
[13:53] <apw> rtg_, ta
[13:54] <rtg_> apw, ok, pushed
[13:58] <apw> rtg_, thanks
[13:59] <psivaa> apw: no other server installations see this bug not even single lvm. only multi-lvm tests installations are failing. Incidentally only the failing (multi-lvm) installations use "d-i base-installer/kernel/override-image	string linux-generic-pae"
[14:00] <psivaa> all the other installations (which pass) use linux-server
[14:01] <apw> psivaa, but in both of those cases linux-generic-pae and linux-server are meta packages to linux-generic, so there sould be no difference in the version running
[14:02] <apw> (in saucy)
[14:07] <apw> psivaa, so multi-lvm just means use LVM and to split root into various partitions
[14:08] <psivaa> apw: yes as far as i understood.
[14:08] <psivaa>  "d-i partman-auto/choose_recipe select Separate /home, /usr, /var, and /tmp partitions" in multi-lvm as opposed to "d-i partman-auto/choose_recipe select All files in one partition (recommended for new users)"
[14:09] <apw> which doesn't sound overly differnet really
[14:10] <psivaa> ok, i have run the latter a number of times, 6 in total but could not see the failure
[14:11] <apw> and of the multi-lvm ones whats the failure rate there
[14:12] <psivaa> apw: 3 out of 4
[14:13] <apw> o.O is all i can say to that
[14:22] <apw> psivaa, which image are you testing, so i can test the saem one, and do i see you testing in kvm yes?
[14:23] <psivaa> apw: yes that's in kvm and today's saucy server images (20130628)
[16:26]  * smb -> EOW
[17:14]  * henrix -> EOW
[17:56]  * rtg_ -> lunch
[20:00]  * rtg -> EOW
[20:38] <phillw> Hi, a very quick question... Someone installs 10.04 via the netboot / mini.iso from, say, http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-i386/current/images/netboot/ and then drops a DE onto it. They will get no security updates for the DE, but they will they still get kernel updates?