[09:30] <mup> PR snapd#5251 opened: tests: reprioritise a few tests that are known to be slow <Created by chipaca> <https://github.com/snapcore/snapd/pull/5251>
[15:32] <skomorokh> Heya, how do I add exceptions to the sandbox?
[15:33] <skomorokh> Specifically, we share a computer and a stereo so pulse is running in daemon mode.
[15:33] <skomorokh> And we want to use the spotify snap so we don't have to trust its .debs with root.
[15:33] <skomorokh> But the confinement isn't taking daemon mode into account: apparmor="DENIED" operation="connect" profile="snap.spotify.spotify" name="/run/pulse/native"
[15:36] <skomorokh> ...so I think I want to make a local-only patch to the pulseaudio interface? Is it even possible to do that? In a way that survives snap updates?


[03:39] <lubot2> antonsmartphone was added by: antonsmartphone
 Good afternoon. I am the channel Creator on Ubuntu and Ubuntu Touch. On the channel I publish app updates, interesting facts and other information about UT. Subscribe please!
[03:39] <lubot2> @ubuntu01
[10:44] <lubot2> <Benson Koka> Hi
[12:39] <lubot2> <Bobcher Bob> Here all speack english?
[17:01] <wxl> m4sk1n and @VikingRedwolf it looks like you have a potential new member of the lubuntu-global team if you want to check in with them
[19:32] -lugito:#lubuntu-devel- [lubuntu-manual] tsimonq2 deleted HEAD at 2cb5614: https://git.io/vphYY
[19:32] -lugito:#lubuntu-devel- [lubuntu-manual] tsimonq2 deleted leafpad-changes at 3cffa1d: https://git.io/vAqKy
[19:33] <tsimonq2> lyn||orian: In Phab, could you please add the email address you use with GitHub?
[19:33] <tsimonq2> That way, we can track commits.
[20:25] -lugito:#lubuntu-devel- [lubuntu-manual] lubuntu-lugito created HEAD from master (+0 new commits): https://git.io/vNj7h
[21:26] <lubot2> Randy Robinson was added by: Randy Robinson
 Welcome!
[21:26] <lubot2> <Randy Robinson> Thank you
[21:54] <lubot2> <Randy Robinson> I have a question about making changes to lubuntu, but I'd like to make changes to my desktop first.  How do I get started?
 This really isn't a support channel, but if you could clarify, I can try to help. :)
[21:55] <lubot2> <Randy Robinson> I'm looking to make changes to lubuntu, maybe submit code.
 Ohh.
 OK.
 Which version are you running?
[21:56] <lubot2> <Randy Robinson> 16.04 lts
 What changes would you like to make?
[21:57] <lubot2> <Randy Robinson> Changes to the trashcan and I would like to add a couple of buttons to the panel. (Administration)
 Have you checked if these changes have already been implemented in 18.04 LTS?
[21:58] <lubot2> <Randy Robinson> not yet, I only work with longterm support.
[21:58] <lubot2> <Randy Robinson> wait, 18.04 lts?
 Yeah, 18.04 LTS.
 Our latest release.
 @Randy Robinson, Then you will love 18.04
[21:58] <lubot2> <Randy Robinson> okay, I'm looking into it.
 Lubuntu.me :)
[22:43] <lubot2> <Randy Robinson> Is there any other information you can share about developing apps for Lubuntu?
 Not much.


[09:36] <Odd_Bloke> smoser: So I'm looking at /sys, and I can't see how to find the logical sector size of a block device.
[10:26] <ndonegan> Is it possible to make cloud-init run an abitrary script after it has gone through it's other sources?
[13:11] <larsks> Odd_Bloke: I don't know about /sys, but this works, I think: blockdev --getbsz /dev/sda
[13:16] <Odd_Bloke> larsks: Yep, blockdev would do it; we're trying to avoid forking if we can.
[13:17] <larsks> It's just calling the BLKBSZGET ioctl.  I guess you could do that natively in python w/ the 'fcntl' module...
[13:19] <smoser> Odd_Bloke, i put iot in my comments.
[13:20] <smoser> oh carp. looks like i didn't hit 'submit' on some comments.
[13:21] <smoser> but anyway, its /sys/class/block/<devname>/qeueu/logical_block_size
[13:21] <smoser> and physical_block_size
[13:22] <smoser> ndonegan, yes. just send script as user-data . if it starts with '#!' it gets executed.
[13:22] <smoser> sucks that i lost that comment.
[13:22] <smoser> Odd_Bloke, i had also rquessted that we round reasonably well (to 1MB or 4MB) increments so we land on fs alignment. and also start at 1MB in.
[13:23] <ndonegan> smoser: Having issues with a certain meta data provider, hence why I want to be able to run a script after which verifies stuff happened.
[13:23] <Odd_Bloke> smoser: If {logical,physical}_block_size are actually sector sizes, why is there also hw_sector_size?
[13:24] <smoser> well, i dont know. in my tests, logical and physical match up with what i fed through qemu-system-x86
[13:25] <smoser> and qemu calls them 'logical_block_size' and 'physical_block_size'
[13:26] <smoser> so i'm justified in my assumption (as those names line up). but i admittedly did make an assumption :)
[13:26] <smoser> ndonegan, i dont really follow.
[13:27] <ndonegan> smoser: Having great fun with metadata proxy where it occasionally sends back crap.
[13:28] <ndonegan> As an example, the request it should be sending to nova-metadata-api gets sent as the resonse to the client.
[13:28] <ndonegan> So looking for some way to try and very that some valid data was sent back
[13:29] <ndonegan> *verify
[13:30] <Odd_Bloke> ndonegan: You're looking to change the image in order to do this, or configure cloud-init to do it from outside the instance?
[13:31] <ndonegan> Odd_Bloke: Exploring any option, including edits to the image, to see if there's some way to verify that what comes back from the metadata service is correct.
[13:31] <smoser> ndonegan, as in openstack ?
[13:31] <smoser> yeah.
[13:32] <ndonegan> It would actually be better if the proxy just failed entirely and timed out. That way I can have the "None" data source as a fallback, and let it write a raw userdata
[13:32] <ndonegan> However, it sends back just enough before screwing up that the Ec2 source doesn't fail outright.
[13:32] <ndonegan> smoser: Openstack with Contrail.
[13:32] <smoser> right.
[13:32] <ndonegan> And it's Contrail that's the issue.
[13:32] <smoser> 2 things you could try
[13:32] <smoser> a.) cirros
[13:33] <smoser> b.) if you can enable config drive in launching... then you can probably avoid cloud-init hitting the md so you can get in and debug from there.
[13:34] <smoser> ie, launch with 'config_drive=1'.
[13:34] <smoser> i suggest cirros because it will time out faster and you can log in with password : cirros/cubswin:)
[13:44] <Odd_Bloke> smoser: So, looking at the kernel source, hw_sector_size is the same value as... logical_block_size.
[13:45] <ndonegan> We already have a base image we use everywhere (mini Centos setup for our environment).
[13:45] <ndonegan> ConfigDrive might be a good option.
[13:45] <smoser> Odd_Bloke, i would not have thoguth that :)
[13:53] <mwak> smoser: I updated the PR to ensure we're on Scaleway when using the datasource, let me know if it's ok for you. I'll add unit test asap
[13:54] <smoser> mwak, and sign cla ?
[13:55] <smoser> mwak, the tewst there is fine, and does help some.
[13:55] <smoser> but.. we'd like to avoid hitting a network service if we can
[13:56] <smoser> as any connection to a network service might hang indefinitely
[13:56] <Odd_Bloke> smoser: OK, the BLKSSZGET ioctl calls bdev_logical_block_size, which calls queue_logical_block_size which is also called for the logical_block_size sysfs entry.
[13:56] <smoser> ie, in many environments a 'wget http://<IP_ADDRESS>/' will just block due to firewall rules and the like.
[13:56] <Odd_Bloke> smoser: So it looks like we can use /sys/.../logical_block_size. :)
[13:57] <smoser> Odd_Bloke, i'd like to fall back if that file isnt present. you plan on that , right ?
[13:57] <Odd_Bloke> smoser: Yeah, that was the plan.
[13:58] <smoser> ok. the other thing i didnt' say, that got lost in my browser.
[13:59] <smoser> if we can start first partition at 1MB and only use 1MB units in sizes, that'd be good.
[13:59] <smoser> i'm tempted to use 4MB units.
[13:59] <smoser> https://bugs.launchpad.net/maas/+bug/1502259
[14:00] <smoser> lvm uses 4MB extents by default.
[14:01] <natorious> morning
[14:03] <mwak> smoser: yep sign the cla too
[14:04] <smoser> hey
[14:05] <smoser> mwak, so does that make sense above ^
[14:05] <smoser> is there any way that we can determine "am i on scaleway" without hitting a network resource ?
[14:05] <smoser> hey. it is time for cloud-inti 2.0 meeting
[14:05] <mwak> smoser: not really
[14:05] <jgrimm> o/
[14:05]  * Odd_Bloke is in a partner meeting, so is MIA.
[14:06] <natorious> channel topic links need to be updated w/ new gerrit paths
[14:06] <natorious> ie - https://review.openstack.org/#/q/project:openstack/cloud-init+status:open,n,z
[14:06] <smoser> ah. yeah, i'll do that natorious
[14:07] <smoser> ok. so looking at that fine url that natiorisou added.
[14:08] <natorious> lol
[14:08] <smoser> a couple that i shoudl grab quickly
[14:08] <smoser> as they address the namespace change.
[14:08] <smoser> natorious, had you made any more progress on yours?
[14:09] <natorious> was just looking over harlowja's comments
[14:09] <smoser> k
[14:10] <natorious> ideally it would be nice if we had a utils.execute or similar shared subprocess call for exec
[14:11] <smoser> natorious, yeah.  there is a fairly good one in cluod-init
[14:11] <smoser> utils.subp
[14:12] <smoser> in 0.7
[14:12] <smoser> that i'd suggest we pull forward
[14:14] <natorious> k
[14:14] <natorious> assuming it is compatible with windows and all
[14:15] <smoser> ah. yeah, it would need some windows work likely.
[14:15] <smoser> it wrapps subprocess.
[14:15] <smoser> subprocess.popen
[14:15] <smoser> but i'd guess we could address anything non windows specific there
[14:15] <niluje> @smoser | ie, in many environments a 'wget http://<IP_ADDRESS>/' will just block due to firewall rules and the like. >> do you think we should add a timeout for the test?
[14:16] <niluje> that can easily be done with requests
[14:16] <smoser> niluje, for tests ?
[14:16] <niluje> to check the server's is on scaleway
[14:16] <niluje> (I'm working with mwak there)
[14:17] <smoser> yes, for sure.
[14:17] <smoser> timeouts suck
[14:17] <niluje> we thought about it for a while, and doing something else than a network test didn't seem straightforward
[14:17] <smoser> because you're either safe (meaning unnecessary long wait) or aggressive (meaning your endpoint might not return in time)
[14:18] <niluje> yes, I agree
[14:18] <smoser> niluje, are you in a place wehere you could feed some dmi data to the guest ?
[14:18] <smoser> it seems like generally good practice to identify your platform in such a way
[14:19] <smoser> wrt timeouts... i dont want to enable a datasource by default that could block boot as it waits.  I'd *like* to change EC2 to not do that.
[14:19] <smoser> but EC2 was "first" so i'm ok giving them a legacy grandfather-in.
[14:20] <niluje> I totally understand your point of view :)
[14:21] <niluje> unfortunately, at the moment, we can't really rely on something else than network resource and if we do, we won't be sure the test will still work in a few months/years
[14:22] <niluje> we prefered to add this not-so-good-test rather than a better test that might not work in a while
[14:22] <niluje> however if that's a blocker, we'll think about another solution
[14:25] <natorious> smoser: any ideas on windows configdrive detection?
[14:26] <smoser> natorious, i might look at how cloudbase has done it.
[14:26] <smoser> i think they read the device with bsd tar
[14:26] <smoser> !
[14:26] <smoser> you cant make that stuff up :)
[14:27] <smoser> but at least at one point that was what alexpilloti settled on.
[14:27] <smoser> (honestly, i wuldnt mind having a vfat and iso9660 filesystem reader in pure python)
[14:27] <natorious> oh wow, lol
[14:27] <natorious> yeah, looked at ctypes methods a bit
[14:28] <natorious> should be universal but alot less readable
[14:28] <smoser> i suspect also faster than 'mount ... read ... unmont' for the amount of data we're pulling.
[14:28] <natorious> uni to windows that is
[14:30] <natorious> k, I'll see how their doing it and go from there


[00:02] <micahg> asac: don't we have to keep xulrunner for the other apps built on it?
[00:04] <asac> but as daily?
[00:04] <fta> sure, but no need to do dailies for those
[00:06] <micahg> asac: well, probably not, the only thing I can think of is if people want to test other apps with the daily
[00:09] <asac> question is: can we add xulrunner to universe without feeling too bad because we already know it will be abandoned security wise soonish?
[00:10] <micahg> asac: well, it should get at least 6 months after release
[00:10] <asac> thats the old world ;)
[00:10] <asac> i am not sure what will happen, but the idea is to even stop doing that
[00:10] <asac> :)
[00:10] <micahg> asac: I thought it was still in debate
[00:10] <asac> not sure if mozilla abandoned the idea
[00:11] <micahg> iirc, there was no resolution either way
[00:11] <micahg> but, I think we have to at least throw something in there for the other apps
[00:11] <micahg> what other choice do we have?
[00:12] <micahg> otherwise, we can provide the -dev packages in ff and let them know they might break?
[00:12] <asac_> reconnect
[00:12] <asac_> 01:11 < micahg> iirc, there was no resolution either way
[00:12] <asac_> 01:12 -!- asac_<EMAIL_ADDRESS>has joined #ubuntu-mozillateam
[00:13] <micahg> (06:11:31 PM) micahg: but, I think we have to at least throw something in there for the other apps
[00:13] <micahg> (06:11:46 PM) micahg: what other choice do we have?
[00:13] <micahg> (06:12:20 PM) micahg: otherwise, we can provide the -dev packages in ff and let them know they might break?
[00:13] <asac_> -> its just a huge axe hanging above us, so imo we need to plan as if they will do it ;) (for now)
[00:13] <asac_> other apps get removed ;)
[00:13] <micahg> ok, then, if we can get clearance for major changes in the depending apps, we can try to bump them to be compliant during the release cycle
[00:13] <asac_> or migrated to webkit
[00:13] <asac_> at best
[00:15] <asac_> well. the major/minor session basically had the input from release team etc. that we should try to get rid of it ...
[00:15] <asac_> one idea would be to provide a trimmed down firefox-3.5-plugin-dev package
[00:15] <asac_> so we can still build plugins (which tend to be not as bad to maintain)
[00:16] <asac_> or we review apps manually and decide on case by case base, what we want to keep supporting
[00:16] <asac_> for those we need committmenet to provide backports in time for _all_ supported archs
[00:16] <micahg> does prism come with it's own xul code?
[00:16] <asac_> no
[00:17] <asac_> well. it could be made to have that ... but ;)
[00:17] <asac_> thats getting ugly
[00:17] <micahg> I'm certainlly willing to help with the backporting
[00:18] <micahg> in general, we'll be doing it for the devel release anyways
[00:18] <asac_> we have a few areas that are hard to get right ...
[00:18] <asac_> a) mozjs ... we have couchdb depending on that
[00:19] <asac_> b) we xul apps that would become more or less void
[00:19] <asac_>  -> if we have xulapps without binary components, we should remove them imo -> they can be provided upstream directly somewhat i guess
[00:19] <fta> asac_, i don't get the migrated to webkit part.. why would moving the burden of security maintenance to webkit change anything?
[00:20] <asac_> first: the world moves to webkit. thats a fact ;)
[00:20] <asac_> so we will have to maintain webkit ;)
[00:21] <micahg> asac_: so, is the moziila team expanding to become the browser team?
[00:21] <asac_> second: embedders like webkit more
[00:22] <asac_> i would think that making a browser team in the long run becomes more and more viable ;)
[00:23] <asac_> thunderbird will stay around for a while longer too i guess
[00:23] <fta> and if users like chromium more, would you move firefox to universe?
[00:24] <asac_> stuff gets moved to universe when its not on CD, nor on dvd usually
[00:24] <asac_> on any officially support image is more accurate i guess
[00:24] <micahg> wouldn't that depend on the archive restructuring?
[00:25] <asac_> yes. i have no clue about what exactly will happen then ;)
[00:41] <asac> at some point we should get rid of firefox-3.1 transitional packages i guess
[00:41] <asac> those were only in ppa, right?
[00:42] <asac> should be safe to drop then in lucid i presume
[00:43] <micahg> they certainly weren't in a production release
[00:44] <asac> my innovate gnome component shuffeling didnt work out as good as expected :/
[00:44] <asac> (speaking to myself) ;)
[01:17] <asac> hmm ... xdg-open is kind of borked
[01:18] <micahg> yeah
[01:18] <micahg> I meant to look into that
[01:23] <fta> asac, http://paste.ubuntu.com/330715/
[01:24] <fta> the thing is, i don't know when branches are abandonned
[01:32] <asac> fta: hmm. wasnt gears integrated in chromium?
[01:32] <fta> no
[01:33] <fta> they won't do it
[01:33] <asac> instead?
[01:33] <fta> their prefer to wait for the html5 offline feature
[01:33] <fta> they
[01:33] <asac> is there any mstone targetted for that?
[01:34] <asac> http://stackoverflow.com/questions/1194784/which-browsers-support-html5-offline-storage
[01:35] <asac> Google Chrome: Gears Database API, which is built into Chrome and thus doesn’t require a separate install. Surprisingly, Chrome doesn’t yet natively support any form of HTML5 Storage.
[01:35] <asac> hmm
[01:35] <asac> so only win
[01:37] <asac> http://code.google.com/p/chromium/issues/detail?id=17443
[01:41] <fta> i know
[01:42] <asac> svn20091128r33239/build-tree/src/third_party/protobuf2/src/src/google/protobuf/dynamic_message.cc:66:
[02:30] <fta> http://paste.ubuntu.com/330748/plain/ with trunk
[02:31] <asac> fta: we are well past 2200 ;)
[02:31] <fta> grrr
[02:31] <asac> hehe
[02:31] <asac> ok its saturday
[02:31] <asac> so its ok i guess ;)
[02:31] <asac> what a pity ... gvfs backend for gdocs does not "just work (tm)"
[02:32] <asac> /home/asac/Development/upstream/gvfs/gvfs_gdata/daemon/gvfsgdocsfile.c:665: undefined reference to `gdata_documents_presentation_get_download_uri'
[02:32] <asac> guess we need a better libgdata ;)
[02:34]  * asac spins 0.5.1 from debian sid
[02:34] <asac> rather than 0.4 we have in karmic
[02:35] <asac> so ... i managed to get chromium mailto: handler to work
[02:35] <asac> for yahoo and gmail
[02:35] <asac> except that xdg-open is broken ... but thats probalby xdg bug (escaping?)
[02:35] <asac> but opening mailto: in firefox now opens yahoo/g mail in chromium
[02:37] <asac> now we just need to mount gdocs as HOME/Documents ;) ... and then somehow ensure that we wrap the proper content types by something that opens browser with the right url ;)
[02:39] <asac> and resolve some "minor" online/offline handling issues before we can provide a good user experience ;)
[02:39] <asac> feels hard :/
[02:41]  * asac wonders if gvfs is in theory good for offline
[07:11] <AnAnt_> Hello, why isn't libmozjs1 built for xulrunner-1.9 ?
[07:42] <micahg> AnAnt: what version of ubuntu?
[07:42] <AnAnt> micahg: karmic & lucid
[07:42] <micahg> AnAnt: xul-1.9 doesn't exist in either
[07:42] <AnAnt> errm, oops
[07:43] <AnAnt> 1.9.1
[07:44] <AnAnt> sorry I dunno it is named xulrunner-1.9.1
[07:44] <AnAnt> so, the same issue holds for that version
[07:44] <micahg> I thought it was part of it
[07:44] <AnAnt> why isn't libmozjs1 built for it ?
[07:45] <micahg> AnAnt: I think it's part of xulrunner-1.9.1
[07:46] <AnAnt> micahg: libmozjs-dev is part of xulrunner-dev ?
[07:46] <micahg> yes
[07:46] <micahg> xulrunner-1.9.1-dev
[07:46] <AnAnt> in 'xulrunner' there is libmozjs-dev & libxul-dev
[07:46] <micahg> xulrunner is old
[07:48] <AnAnt> I see, so that's a big deviation from Debian
[07:48] <micahg> AnAnt: we don't import xul from debian
[07:52] <AnAnt> micahg: do you know since which version (1.9 or 1.9.1) did xulrunner start using heartbeat ?
[07:52] <micahg> no, sorry
[07:52] <micahg> idk what heartbeat is
[07:55] <AnAnt> ok
[09:49] <ripps> Damn, chromium is segfaulting on me. Now I have to install the huge debug package and get a backtrace
[09:52] <ripps> okay, nevermind. Everything is segfaulting, I think I just got a kernel bug
[09:59] <micahg> asac: you wouldn't happen to be on would you?
[10:40] <AnAnt> Hello, back to the libmozjs* packages question, I hope that separate packages for libmozjs* are built from xulrunner-1.9.1 (as have been done for old xulrunner)
[10:40] <micahg> AnAnt: they are not and will not be
[10:40] <AnAnt> some packages use libmozjs, and they can't find mozjs library in xulrunner-1.9.1-dev long path
[10:41] <AnAnt> micahg: any reason for this ?
[10:41] <micahg> hmmm
[10:41] <micahg> idk
[10:41] <micahg> simplicity?
[10:41] <micahg> let me see if I can find a bug
[10:42] <AnAnt> micahg: when you said "will not be", I thought you knew a reason for this
[10:42] <micahg> ah, sorry
[10:42] <micahg> that's my tiredness
[10:42] <micahg> 4:45 in the morning :)
[10:42] <AnAnt> I see
[10:43] <AnAnt> you need to sleep
[10:43] <micahg> I meant to say I don't think there are plans to revive it, but I'm trying to see if I can find the reason why it's no longer
[10:43] <AnAnt> ok
[10:44] <AnAnt> so, asac is asleep ?
[10:44] <micahg> well, probably not at noon, but it's sunday
[10:45] <AnAnt> asac is in europe ?
[10:45] <micahg> UTC+1
[10:45] <AnAnt> ok
[10:51] <micahg> I don't think it was ever in 1.9
[10:51] <micahg> so that's since hardy
[10:53] <micahg> AnAnt: asac usually pops in sometime Sunday...I'll try to ask if I remember
[10:57] <micahg> AnAnt: apparently you're not the only one with this issue
[11:11] <AnAnt> ok, thanks
[13:49] <asac> fta: do you see any error here: http://people.canonical.com/~asac/tmp/chromium-browser_4.0.260.0~svn20091128r33239-0ubuntu1~ucd1_armel.build.bak.bz2
[13:49] <asac> it failed to build
[13:49] <asac> but i dont see anything that is an error
[14:37] <asac> ok we worked around it by tweaking as
[18:04] <AnAnt> asac: ping
[18:06] <asac> AnAnt: ?
[18:06] <AnAnt> asac: can separate packages for libmozjs* are built from xulrunner-1.9.1 (as have been done for old xulrunner)
[18:06] <AnAnt> s/are/be
[18:06] <asac> no
[18:08] <AnAnt> why is that ?
[18:08] <asac> there is a abug open about providing a stable ABI/APi
[18:08] <asac> they say they dont want to do that
[18:08] <asac> so shipping libmozjs would be wrong
[18:08] <asac> its not ment for consumption outside of xulrunner/firefox upstream
[18:08] <asac> let me check something
[18:09] <AnAnt> there are packages using libmozjs
[18:10] <asac> https://bugzilla.mozilla.org/show_bug.cgi?id=506890
[18:10] <asac> AnAnt: right. those in theory use something that isnt allowed
[18:10] <asac> its not my decision
[18:10] <asac> read the bug
[18:10] <asac> ;)
[18:11] <asac> anyway. xulrunner will be either removed completely from archive (unlikely) or go to universe
[18:11] <asac> when that happens we can provide a mozjs there
[18:11] <asac> which doesnt really help couchdb ;)
[18:11] <asac> bad situation
[18:12] <asac> thy dont even want to keep abi/api promise within a stable branch ;)
[18:12] <asac> that means: doomed
[18:14] <asac> so all our hope is on libseed ;)
[18:14] <asac> rather webkit ;)
[18:20] <AnAnt> libseed ? webkit ? what's those for ?
[18:22] <asac> other js lib
[18:38] <AnAnt__> so, is xulrunner going to be removed in lucid ?
[18:39] <AnAnt__> removed or go to universe that is
[18:42] <fta> asac, jcastro: http://www.sofaraway.org/ubuntu/tmp/chromium-forest.html  131 releases in 60 days, incl 59 in branches (the rest in trunk)
[18:50] <asac> yes
[18:50] <asac> AnAnt: yes
[18:50] <AnAnt> ok, thanks
[19:33] <fta> asac, i think i will add a get-branch-source target, using something like RELEASE_BRANCH=249, and use that for another PPA
[19:34] <fta> it's probably best to work in a dedicated branch tough :(
[19:34] <fta> +h
[20:11] <micahg> asac: around?
[20:30] <asac> dh_link -p chromium-browser-dbg
[20:30] <asac> dh_md5sums -pchromium-browser-dbg
[20:30] <asac> dh_builddeb -pchromium-browser-dbg -- -Z lzma
[20:30] <asac> dpkg-deb: building package `chromium-browser-dbg' in `../chromium-browser-dbg_4.0.260.0~svn20091128r33239-0ubuntu1~ucd1_armel.deb'.
[20:30] <asac>  \o/
[20:30] <asac> fta: ^^
[20:30] <asac> ;)
[20:31] <asac> micahg: for a moment. yes.
[20:31] <asac> ;)
[20:31] <micahg> ah, ok
[20:31] <micahg> if I'm adding different .desktop translations, are they separate commits in bzr and are they separate lines in the changelog?
[20:32] <asac> micahg: if you add a batch at once you can have them in onecommit/line
[20:32] <asac> but i wouldnt merge them when i land a second translation a few days later
[20:32] <micahg> Lang1, Lang2, Lang3 (LP: 1, LP: 2, LP: 3)?
[20:32] <asac> if they have more than one bug i would still go for the multi commit/changelog approach
[20:32] <micahg> ok
[20:33] <micahg> so one per commit one per line
[20:33] <micahg> do I list the file after each line?
[20:33] <asac> or say something like: add translation for XX (LP: # ...), YY (LP: #...)
[20:33] <asac> but i dont think we need to save lines in changelog ;)
[20:33] <asac> micahg: if you dont merge them, then yes
[20:33] <micahg> ok
[20:33] <asac> i undertand a changelog line as a entry + file modification
[20:33] <micahg> got it, I found 2 other translations over the weekend, so I'm adding them to 3.5.head
[20:34] <asac> hmm. ok
[20:34] <micahg> the other thing is, do you remember why we don't break out libmozjs anymore?
[20:34] <asac> ;)
[20:35]  * asac has to remember to update branch before committing the all-in-one-wonder changes ;)
[20:35] <asac> micahg: we never did it
[20:35] <micahg> asac: why not start that with 3.6 unless we are backporting all in one to hardy
[20:35] <asac> read: https://bugzilla.mozilla.org/show_bug.cgi?id=506890
[20:36] <asac> that explains the reason why what debian does is insane - support wise ;)
[20:36] <micahg> well, it used to be a separate package in xul 1.8
[20:36] <asac> that was debian heritage
[20:36] <micahg> ah
[20:36] <asac> maybe if we go away from xulrunner we can sync debian xulrunner ;)
[20:36] <asac> and then get libmozjs in universe
[20:36] <asac> but even then its a bad feeling because we already know we wont be able to support
[20:37] <asac> (same as for xulrunner we discussed yesterday)
[20:37] <asac> only a subset of applications we can pick and then prepare for porting ;)
[20:37] <asac> thats the same for mozjs
[20:37] <asac> mozjs gets > 1/3 of security fixes
[20:38] <asac> and those are usually of tricky kind (and nont many not working for mozilla - who wont help us according to bug) would be able to maintain that
[20:38] <micahg> wow
[20:39] <asac> if you read bug: they didnt even want to commit to not break API on a stable branch :/
[20:39] <micahg> yeah, I saw that
[20:39] <micahg> that's what the wow was for :)
[20:39] <asac> so asking for stable minimal API across branches is definitly not right
[20:39] <asac> for them ;)
[20:39] <asac> they basically say: dont use mozjs anywhere but in firefox/tbird
[20:40] <micahg> so it almost seems like there's no point in shipping it at all
[20:40] <asac> right ;)
[20:40] <asac> thats the whole point ... and if you ship it you need to hire core js devs from mozilla ;)
[20:41] <micahg> ok, we have a few bugs on this, now I know, should I create a master bug or keep telling people to build against xulrunner-1.9.1-dev
[20:41] <micahg> or both?
[20:41] <asac> we have a master bug afaik
[20:41] <asac> micahg: tell people to not use mozjs ;)
[20:41] <asac> the building against xulrunner-1.9.1-dev has the same messy implications
[20:41] <asac> just that we make it harder for them to do (and increase likelyhood we will bump into them)
[20:41] <micahg> asac: suggest they port to webkit?
[20:41] <asac> maybe ;)
[20:42] <asac> for now its probably the only way we can send them
[20:42] <asac> v8 has same approach as mozjs
[20:42] <asac> i the most accurate answer is: do not use javascript ;)
[20:42] <asac> sad but true
[20:45] <micahg> I don't see a master bug
[20:45]  * asac looks
[20:46] <asac> great. search for "mozjs" on xulrunner-1.9.1 package -> no result
[20:46] <asac> but: bug 486079 exists ;
[20:46] <asac> thats launchpad
[20:46] <micahg> yep
[20:47] <asac> i thought there was a bug open ;)
[20:47] <asac> which bugs do you look at?
[20:47] <asac> maybe i didnt name it MASTER, but consider it a master :)
[20:47] <micahg> generally just ff, but someone came in here last night asking
[20:47] <asac> bug 286906
[20:47] <asac> micahg: yes. that was anant
[20:47] <micahg> yep
[20:47] <asac> already told him that mozjs is bad ;)
[20:48] <micahg> should I make that bug the master?
[20:48] <asac> one sec
[20:48] <asac> maybe i wont fix it
[20:49] <asac> ok cannot find it
[20:49] <asac> go ahead then
[20:49] <asac> move to 1.9.1 i guess
[20:50] <micahg> should I link to the upstream bug also
[20:51] <asac> why not ;)
[20:52] <asac> make it a wishlist bug with title: "provide and support a top-level library package for libmozjs"
[20:52] <asac> make it a wishlist bug with title: "provide and support a top-level library package for libmozjs (Was: Unable to use libmozjs.so in an application, because of library path problem.)"
[20:52] <asac> or something similar
[20:56] <micahg> ok
[22:12] <micahg> ugh, they hijacked the builders again
[22:12] <asac> they == us? or QA folks? ;)
[22:12] <micahg> QA folks it seems :)
[22:12] <asac> there are 5/8/5
[22:12] <micahg> I"m going to pbuilder songbird to see if it works
[22:12] <asac> thtas better than 2/2/3 ;)
[22:13] <micahg> yeah
[22:14] <micahg> asac: it looks like I'm going to have to use songbird's sqlite for the moment
[22:15] <asac> thats in line with everything we do ;)
[22:15] <asac> are you on lucid yet?
[22:15] <micahg> nope
[22:15] <micahg> should I be?
[22:15] <asac> no
[22:15] <asac> just was curious
[22:15] <micahg> I wasn't planning on jumping until beta 1
[22:15] <asac> if sqlite is at least new enough there in theory
[22:15] <fta> asac, could you add "killall -q -v -9 $(basename $TEST)" at the end of debian/run-test.sh and use it on base_unittests?
[22:16] <asac> fta: how do i use it on base_unittests?
[22:16] <fta> debian/run-test.sh path/to/the/bins/base_unittests
[22:17] <asac> hmm... i dont see the base_unitttests
[22:17] <asac> did it clean them at end of build?
[22:17] <asac> oh sorry
[22:17] <asac> wrong host ;)
[22:18] <fta> well, run it from sconsbuild/Release
[22:18] <asac> ./debian/run-test.sh build-tree/src/sconsbuild/Release/base_unittests
[22:18] <asac> Usage: run-test.sh [-x] [-t sec] test_file log_dir [filter]
[22:18] <asac> -x               Run test_file under xvfb -t sec           Timeout in seconds after which we kill the test
[22:18] <asac> hmm
[22:19] <asac> -t20 ?
[22:19] <asac> o log dir was missing
[22:19] <asac> its running
[22:20] <asac> ok had to create the right log subdir too
[22:21] <asac> now running ;)
[22:21] <asac> how long is that supposed to run ;)?
[22:21] <asac> 27873 asac      20   0 76256 2212  364 R 99.1  0.5   0:15.12 base_unittests
[22:21] <asac> running
[22:22] <fta> at most 10 min
[22:22] <asac> on your system ;)?
[22:22] <asac> hehe
[22:22] <asac> ok let me take a quick break
[22:22] <fta> no, it's the timeout
[22:22] <asac> then finish a few specs
[22:22] <asac> hmm ok
[22:22] <asac> already more than a minute CPU time ;)
[22:23] <fta> maybe 10min is not enough to run normally on arm
[22:23] <fta> the log file shoud grow
[22:23] <fta> +l
[22:25] <asac> http://paste.ubuntu.com/331343/
[22:25] <asac> thats what is at end atm
[22:25] <asac> so its either stuck ... at end ... or woking on getting OOM
[22:27] <asac> fta: its already defunct
[22:27] <asac> but looping
[22:27] <asac> http://paste.ubuntu.com/331345/
[22:41] <fta> hm, but it run-test still running?
[22:41] <asac> it runs forever
[22:42] <asac> i restarted in the meantime
[22:42] <asac> so ask in 6 minutes or so ;)
[22:42] <asac> (karmic)asac@jocote:~$ ls -l /tmp/log/build-tree/src/sconsbuild/Release/base_unittests.txt
[22:42] <asac> -rw-r--r-- 1 asac warthogs 29575 Nov 29 22:37 /tmp/log/build-tree/src/sconsbuild/Release/base_unittests.txt
[22:42] <asac> (karmic)asac@jocote:~$ date
[22:42] <asac> so latest at 2247
[22:42] <asac> Sun Nov 29 22:42:16 UTC 2009
[22:42] <asac> it should stop, right?
[22:42] <fta> strange, next time, run it with sh -x
[22:42] <asac> i ran a killall base_unitttests after killing the process
[22:42] <asac> that left a gdb process still running
[22:43] <asac> k
[22:44] <fta> well, if the 1st instance died, i re-run it in gdb, so you have to be patient before killing everything
[22:44] <asac> how patient?
[22:44] <asac> 20muntes?
[22:45] <asac> is that a new log i can check for progress? (with gdb)
[22:45] <asac> [----------] 14 tests from OutOfMemoryTest
[22:45] <asac> [ RUN      ] OutOfMemoryTest.New
[22:45] <asac> [WARNING] /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/testing/gtest/src/gtest-death-test.cc:741:: Death tests use fork(), which is unsafe particularly in a threaded context. For this test, Google Test couldn't detect the number of threads.
[22:45] <asac> thats really the end from what i can see
[22:45] <asac> maybe that warning is FATAL?
[22:45] <asac> ok 10 minutes almost past ...
[22:45]  * asac waiting
[22:47] <asac> ok 10 minutes done -> gdb appeared
[22:47] <asac> thats correct, right?
[22:47] <fta> during your build, the script properly exited, but with some processes left behind, so here, the script should terminate itself normally too
[22:47] <asac> [WARNING] /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/testing/gtest/src/gtest-death-test.cc:741:: Death tests use fork(), which is unsafe particularly in a threaded context. For this test, Google Test couldn't detect the number of threads.
[22:47] <asac> Timeout: aborting command ``./build-tree/src/sconsbuild/Release/base_unittests'' with signal 9
[22:47] <asac> Killed
[22:47] <asac> so the killing worked a bit
[22:47] <asac> the defunct proc is gone at least
[22:48] <asac> now i got ## list of FAILED tests:
[22:48] <asac> [  FAILED  ] ConditionVariableTest.FLAKY_MultiThreadConsumerTest (792 ms)
[22:48] <fta> good
[22:48] <fta> and no zombie, gdb, whatever?
[22:49] <fta> the killall i asked you to add has a -v, to show if it has catched something
[22:50] <asac> http://paste.ubuntu.com/331357/
[22:50] <asac> fta: gdb is now active
[22:51] <asac> and apparently under gdb we have a new defunct too
[22:51] <asac> kind of expected
[22:51] <asac> so after another 10 minutes this will finish?
[22:51] <fta> 10min max for a run, so 10min minus the running time
[22:52] <asac> the process with zombie is already dead and gdb keeps on going ...
[22:52] <asac> anyway 4 more minutes at max with gdb i hope
[22:52] <asac> lets see
[22:53] <fta> xul-ext-adblock-plus ? wtf
[22:53] <fta> oh, debian
[22:53] <fta> why am i getting all those debian bug mails?
[22:53] <asac> subscribed to pkg-moz-extmaintainers or something list?
[22:54] <asac> maybe they have that list as maintianer and then mails go there
[22:54] <asac> or its mozillateam malining list ;)
[22:54] <asac> we still get the icedove mail there
[22:54] <asac> (next upload will fix that)
[22:54] <fta> it's the m-t mailing list
[22:55] <fta> from mozilla-devscripts
[23:07] <asac> fta: test ended
[23:07] <asac> [  FAILED  ] ConditionVariableTest.FLAKY_MultiThreadConsumerTest (792 ms)
[23:07] <asac> ---- crash logs ----
[23:07] <asac> Killed base_unittests(29141) with signal 9
[23:07] <asac> Killed base_unittests(29433) with signal 9
[23:07] <asac> no process left
[23:07] <asac> great
[23:07] <asac> hmm
[23:07] <asac> asac     17020     1  0 18:37 ?        00:00:01 Xvfb :99 -screen 0 640x480x8 -extension Composite -nolisten tcp
[23:07] <asac> asac     19033     1  0 19:19 ?        00:00:01 Xvfb :100 -screen 0 640x480x8 -extension Composite -nolisten tcp
[23:07] <asac> asac     22097     1  0 19:51 ?        00:00:01 Xvfb :104 -screen 0 640x480x8 -extension Composite -nolisten tcp
[23:08] <asac> asac     22348     1  0 20:01 ?        00:00:01 Xvfb :106 -screen 0 640x480x8 -extension Composite -nolisten tcp
[23:08] <asac> asac     22368     1  0 20:01 ?        00:00:00 Xvfb :107 -screen 0 640x480x8 -extension Composite -nolisten tcp
[23:08] <asac> those are still running
[23:08] <asac> i guess those were started during tests, but never killed
[23:08] <asac> anything i should do before killing those?
[23:08] <asac> fta: ?
[23:16] <asac> 3
[23:16] <asac> 2
[23:16] <asac> 1
[23:17] <asac> killed ;)
[23:33] <fta> based on the time, yeah, from your previous attempts
[23:33] <micahg> fta: is trunk fixed for you with the funny characters?
[23:34] <fta> asac, ^^, it seems i should kill that too, but the tricky part is to kill only ours
[23:34] <fta> micahg, no idea, i only see that at work, and i'm at home
[23:34] <micahg> ah, ok
[23:38] <micahg> fta: I'm having songbird build it's own sqlite, hope that and a patch refresh will fix it
[23:39] <rcmaehl_linux> I need help
[23:39] <rcmaehl_linux> every time i load firefox i get this
[23:39] <rcmaehl_linux> Could not initialize the application's security component. The most likely cause is problems with files in your application's profile directory. Please check that this directory has no read/write restrictions and your hard disk is not full or close to full. It is recommended that you exit the application and fix the problem. If you continue to use this session, you might see incorrect application behaviour when accessing security
[23:39] <rcmaehl_linux> features.
[23:40] <micahg> rcmaehl_linux: is your home partition full?
[23:45] <rcmaehl_linux> no
[23:45] <rcmaehl_linux> and the guys in #firefox gave me the answer
[23:45] <micahg> ok, bye rcmaehl_linux


[00:41] <lifeless> igc: lifeless is just my irc handle
[01:15] <jam> beuno: I feel bad that everytime I follow your link it calls bzr garbage
[01:16] <beuno> jam, hahah, so do I  :)
[01:16] <jam> beuno: right now I'm getting a timeout trying to connect
[01:16] <jam> is it down?
[01:16] <beuno> I tend to name stuff that will need deleting _garbage
[01:16] <beuno> I'm home
[01:16] <beuno> lemme get you the IP
[01:17] <beuno> http://<IP_ADDRESS>:8080/bazaar/bzr/changes
[01:18] <beuno> (remove the "garbage" bit, may also throw off googlebot)
[01:18] <jam> :)
[01:18] <jam> beuno: when I type "robert" it selects robert for a second, then a huge list of entries, and then goes back to robert
[01:18] <jam> any idea why it "flickers" ?
[01:19] <jam> beuno: also, it doesn't seem to match "collins" as it doesn't seem to be indexing the committer name
[01:19] <jam> oh, and switching windows and switching back causes it to flicker again
[01:19] <beuno> hrm, it shouldn't
[01:19] <beuno> FF3?
[01:20] <jam> yep
[01:20] <beuno> ah, yes. I know what's happening
[01:21] <beuno> I don't stop calls to the server when you type faster than 200ms per ketstroke
[01:21] <beuno> *keystroke
[01:21] <jam> I also tried "Refactoring" as I see that in a commit message right away
[01:21] <jam> and it doesn't find the rev
[01:21] <beuno> so you get delayed calls thrown at you
[01:21] <beuno> it's in my ToDo
[01:22] <jam> actually, I haven't gotten a successful hit from any of the recent commit messages
[01:22] <jam> Though it will put it in the helper list
[01:22] <beuno> interesting, I may of broken something
[01:22] <jam> 'logic' worked
[01:23] <jam> 'crude' did not
[01:23] <jam> maybe you just need to regenerate it?
[01:23]  * beuno tries
[01:24] <beuno> well, running "bzr search Refactoring" from terminal works
[01:25] <jam> is it case sensitive?
[01:25] <beuno> shouldn't be, no
[01:30] <beuno> ok, so I'm doing something wrong in my logic, bzr-search does sent me those results
[01:39] <lifeless> whats up?
[01:39] <beuno> LH is failing at some point, and I don't quite understand why...
[01:40] <lifeless> jam: the index is case sensitive for now - Foo vs foo in c++ is important
[01:40] <jam> lifeless: sure, but it was still failing
[01:40] <jam> I tried both forms
[01:41] <jam> anyway, I'm done for the night
[01:41] <lifeless> jam: yah, just letting you know the guts
[01:41] <beuno> yes, I'm getting back a list with sets instead of a list with strings
[01:41] <lifeless> beuno: from search ?
[01:43] <beuno> it seems RevisionHit gives me a set, and FileTextHit a string, so I'm not showing RevisionHits
[01:43] <lifeless> beuno: point me at your code
[01:45]  * beuno waits for LH to load in LP
[01:45] <beuno> lifeless, http://bazaar.launchpad.net/~beuno/loggerhead/bzr-search_integration/annotate/argentina%40gmail.com-20080620063154-mztu3hdo7t70l781?file_id=search.py-20080614235103-lpt63f7b2drplju8-1
[01:45] <beuno> line 52
[01:45] <beuno> I wonder how I managed to miss this up to now...
[01:48] <beuno> ah
[01:48] <beuno> needed a [0]
[01:48] <beuno> thanks for pointing it out jam   :)
[01:49] <beuno> pushing the fix now..
[01:50]  * Peng stares at bzr-svn.
[01:51] <lifeless> bzr-svn stares back
[01:51] <Peng> :P
[01:51] <Peng> It's complaining about my svn Python bindings.
[01:51] <lifeless> beuno: well I was complaining about funky results ;P
[01:52] <lifeless> man
[01:52] <lifeless> linkedin is such a fanboyclubthing
[01:52] <beuno> lifeless, heh, right. Well, jam found the search term I could debug  :P
[01:53]  * beuno has avoided linkedin up to now
[01:54] <beuno> anyway, search results seem coherent with the CLI
[01:57] <jam> lifeless: you are the one who asked *me* to join... and now you say it is just fanboy. I feel... dirty
[01:57] <lifeless> jam: :)
[01:57] <lifeless> jam: You're not a acquaintance rather than trusted colleague/friend
[01:57] <lifeless> jam: its folk I've met twice wanting to 'link up' than I was complaining about
[01:58] <lifeless> beuno: cool
[01:58] <jam> It is just that you are so amazing everyone wants to be your friend
[01:58] <lifeless> And I thought I had ego problems
[01:58] <lifeless> :)
[01:59] <Peng> If I can import svn.delta, why can't bzr-svn?
[01:59] <Peng> Oh.
[02:00] <Peng> Word of advice: don't go scattering things called "svn" around your PYTHONPATH.
[02:02] <lifeless> :P
[02:02] <lifeless> absolute imports ftw
[02:04] <Peng> That wouldn't help. bzr-svn tries to import svn.delta, but found my thing instead.
[02:05] <lifeless> k
[02:06] <Peng> Oh well. The only damage done is a little wasted CPU and disk I/O.
[02:06] <Peng> Sorry for the interruption. :)
[02:10] <lifeless> lol np
[02:41]  * Verterok wonders why utf-8 isn't used by everyone...
[02:45] <lifeless> Verterok: oh, I wish
[02:46] <Verterok> lifeless: I have bundleBugggy running on mysql, but I have some problems with blob encodings :P
[02:47] <beuno> Verterok, really?  didn't have to change any queries for it?
[02:48] <beuno> altright. I won't take that personal
[02:49] <beuno> (and type properly either)
[02:49] <Verterok> sorry...pushed the wrong button :P
[02:50] <Verterok> beuno: I think the problem is in the migration code, not in BB itself or it queries
[02:50] <beuno> ah, thought you already had it running
[02:51] <beuno> abentley did mention that encodings where really wierd and mixed up
[02:51] <Verterok> yes, if I don't import the mergerequests from sqlite, it work like a charm :P
[02:51] <beuno> can't you convert it as you migrate?
[02:51] <Verterok> indeed, they are
[02:52] <Verterok> beuno: I don't know in what encoding is each blob...so I basically try:...catch: until it works :)
[02:52] <beuno> ah, sounds fun
[02:53] <Verterok> try: except
[02:53]  * Verterok is writtin too much java code
[02:53]  * beuno is glad he passed that on
[02:53]  * Verterok too :)
[02:58] <Verterok> beuno: something is wrong with the inserts in mysql, i get some warnings about data truncated... :(
[02:59] <beuno> Verterok, that's odd. Truncated for blobs?
[02:59] <Verterok> yep..
[02:59] <Verterok> and came directly from MySQLdb module
[03:00] <xif> hello
[03:00] <xif> congrats for MySQL switching to Bazaar.
[03:01] <Verterok> beuno: here is the traceback http://rafb.net/p/T5fBZX72.html
[03:01] <lifeless> xif: hi, thanks
[03:01] <xif> is there any way to implement a form of locking with bzr?
[03:02] <beuno> Verterok, very odd. On the other hand, we may be able to get help from mysql now  :p
[03:02] <xif> or generally, any way to make sure no more than one developer is working on a particular file?
[03:03] <Verterok> beuno: that would be great, but first I want to be sure I'm not doing something wrong ;)
[03:03] <beuno> Verterok, I don't see where it's been truncated there, just an encoding error
[03:04] <Verterok> oh, I wasn't clear... I get the truncate warnings when I'm running the migration script
[03:05] <Verterok> beuno: sqlite2mysql.py:95: Warning: Data truncated for column 'text' at row 1
[03:05] <beuno> Verterok, it may be worth a try changing that column's name
[03:05] <beuno> I suspect it may be a reserved name
[03:05] <beuno> so it could confuse mysql
[03:06] <lifeless> xif: no, because you can have two independent branches
[03:06] <lifeless> xif: imagine that there is only one file in your tree; two branches being independent implies concurrent editing of that file
[03:06] <Verterok> beuno: yes, but that is the 2dn warning, the firstone is: sqlite2mysql.py:95: Warning: Data truncated for column 'patch_text' at row 1
[03:07] <beuno> Verterok, ah, that throws my theory off the table   :/
[03:07] <beuno> Verterok, probably a mysql configuration
[03:07] <beuno> max_something
[03:07] <xif> lifeless: hm, too bad. we're trying to manage some binaries here. merging never works for that, of course. so we simply must find a way to prevent - or at least alert - when someone tries to edit a file that somebody else is working on.
[03:07] <beuno> (not helpful, I know, finishing the bzr-upload [ANN])
[03:08] <Verterok> beuno: ok, i'll check
[03:08] <Verterok> beuno: thanks
[03:08] <xif> I'm not sure this can't be done (at least in a "cover 90% of the need" way) by a bazaar plugin....
[03:08] <lifeless> xif: if you had a single branch, a plugin could conceptually write a file describing advisory locks
[03:09] <lifeless> xif: I suggest bringing it up on the list; may strike someone's interest.
[03:09] <xif> lifeless: yeah, that's what I was thinking too. a master branch for the binaries.
[03:09] <xif> thanks!
[03:09] <beuno> xif, maybe by having a similar file to .bzrignore
[03:09] <beuno> version that
[03:09] <beuno> make sure everyone pulls
[03:09] <beuno> and write a plugin on top of that
[03:10] <beuno> looks in that file, does magic
[03:10] <xif> beuno: yeah, sort of what I was thinking...
[03:10] <beuno> that way you could have a lock with regexes!
[03:10] <beuno> "no one else touch my jpgs"
[03:10] <beuno> or something more professional
[03:12] <beuno> pre_commit hook that checks if that has been changed...
[03:12] <beuno> seems fairly possible, if someone puts some work into it
[03:16]  * xif nods
[03:27]  * beuno is off to the movies
[03:31] <xif> enjoy!
[03:41] <lifeless> have fun beuno
[03:51] <jshaffer> is there a way to copy a file and have bzr recognize it as a copy? is there a copy command?
[03:52] <rockstar> bzr cp
[03:53] <jshaffer> Bazaar (bzr) 1.5
[03:53] <jshaffer> bzr: ERROR: unknown command "cp"
[03:53] <rockstar> Nevermind, thought I used that today but I didn't...
[03:55] <lifeless> jshaffer: not yet; its been discussed
[03:55] <jshaffer> ok. thanks
[07:17] <teratorn> anyone know how to make bzr-svn work on remote SVN repositories that require authentication? I get an error: bzr: ERROR: Invalid http response for https://svn2.hosted-projects.com/Phoenix/PCP/branches/fxcm-3/.bzr/branch-format: Unable to handle http code 401: Authorization Required
[07:18] <bob2> you should be able to provide a username in the url and then get prompted for a password
[07:19] <teratorn> ah, I found the problem: https://answers.launchpad.net/bzr-svn/+question/24177
[08:05] <lifeless> anyone looked at clearsilver ?
[08:35] <felipec> in bzr each branch has only one head, right?
[08:38] <lifeless> yes, we define branch as being a head
[08:38] <lifeless> you can have many heads in a repository, and many branches in a repository, repositories give you storage sharing across branches
[09:04] <felipec> lifeless: I see, but a branch is a head?
[09:08] <lifeless> well, its an entry to the graph, it doesn't acctually have to be a head
[09:18] <felipec> lifeless: ah, perhaps we have different definitions of "head"
[09:18] <felipec> lifeless: by head I mean a node with no childs
[09:19] <lifeless> yes, thats what head means
[09:19] <lifeless> so, we have two separate objects involved
[09:19] <lifeless> we have Branch, which has a 'tip', that points into the revision graph
[09:20] <lifeless> the revision graph is stored in a Repository. An instance of Repository is one part of the distributed database
[09:20] <lifeless> there is no requirement that the tip of a branch be a head in the distributed database (because that would be logically inconsistent with people being able to branch and commit without affecting the source branch)
[09:21] <lifeless> but
[09:21] <lifeless> we only include revisions reachable from the tip when we do log and other operations
[09:22] <lifeless> so being a head in a graph sense really doesn't matter - it only matters for systems like git and hg that conflate branch storage with history storage
[09:23] <lifeless> (For instance, I have a repository with 13000 heads; I can make a branch from it to a new project in 0.2 seconds or so)
[09:24] <felipec> lifeless: ah, true, being a head doesn't matter
[09:24] <felipec> lifeless: in that example you would only have one head in the new branch, right?
[09:25] <lifeless> if I branched into an empty repository yes; the tip of the branch and what it references gets copied, which would leave the tip as the head (when you consider only the data in that repository)
[09:27] <felipec> lifeless: but why you say git and hg conflate branch storage with history storage?
[09:27] <lifeless> well, its possibly more true for hg than git
[09:28] <lifeless> in hg when you have 2 heads in its history storage, it shows up as have two branches
[09:28] <lifeless> in git you have a list of 'heads' and 'refs'
[09:29] <lifeless> AFAICT they won't scale to very large numbers of branches
[09:29] <lifeless> (though it is very cheap to enumerate the branches because its in a single file)
[09:30] <lifeless> felipec: anyhow, why were you asking whether we have more than one head per branch?
[09:30] <felipec> lifeless: in git a branch is just a pointer to a commit (a ref)
[09:31] <felipec> lifeless: I'm writing a document explaining why mtn sucks, and although I'm a git fan I want to show how things are dong in other decent DSCMs
[09:31] <felipec> s/dong/done/
[09:32] <lifeless> felipec: monotones management of divergence is a little awkard
[09:32] <felipec> lifeless: I think having multiple heads in a branch is chaos
[09:32] <lifeless> so for bzr heads in teh repository is entirely unrelated to whats in a branch
[09:33] <lifeless> a branch has a tip, which is a ref to a commit; same as git
[09:33] <lifeless> branches also have tags, which themselves are ref's to commits
[09:33] <felipec> lifeless: tags are part of the branch or the repo?
[09:34] <lifeless> felipec: each branch has its own tags; the point into the repo
[09:34] <lifeless> s/the /they /
[09:34] <felipec> so, two branches can have a 1.0 tag, for example
[09:34] <lifeless> right
[09:35] <lifeless> a concrete use case would be a single repository storing project A and project B which is a fork of A
[09:35] <lifeless> they may both have done 1.0 releases that are different code bases.
[09:35] <felipec> yeah, I get it
[09:36] <felipec> lifeless: by the way, do you know about any reference to the internal design of bzr?
[09:36] <lifeless> but storage is shared between their history, and any merges as well
[09:36] <lifeless> felipec: doc/developer/, the wiki has a Classes/ sub area
[09:38] <lifeless> and there is all the docs in the code itself - docstrings
[09:56] <felipec> lifeless: I couldn't find much on doc/developer
[09:57] <lifeless> http://doc.bazaar-vcs.org/bzr.dev/developers/index.html
[10:47] <felipec> lifeless: http://doc.bazaar-vcs.org/bzr.dev/developers/repository.html
[10:48] <felipec> lifeless: http://doc.bazaar-vcs.org/bzr.dev/developers/container-format.html
[10:48] <felipec> that's the most similar I can find to branch representation, but not really useful
[10:50] <AfC> felipec: obviously this is more work, but if you were to read the archive of this list over the last 18 months or so you'd find a fair amount of anecdotal information you could use towards your research.
[10:50] <lifeless> pydoc bzrlib.branch/Branch
[10:50] <lifeless> erm, bzrlib.branch.Branch, thats the Branch object
[10:50] <AfC> s/this/the Bazaar project's/
[10:52] <lifeless> felipec: that talks about the serialization of the packs in the repository
[10:53] <lifeless> felipec: I guess it depends on what you mean by design
[10:53] <lifeless> felipec: we are _very_ modular
[10:53] <lifeless> felipec: as we learn better ways of doing things we implement them
[10:54] <lifeless> felipec: so to us design really talks about responsibilities and layers, not about disk formats per se
[10:54] <lifeless> felipec: (in part because svn can be considered an implementation detail of bzr due to how deep bzr-svn hooks in)
[10:55] <felipec> lifeless: I thought so, so there's no way I can for example create a test application independent of bzrlib to find all the branches in a repo?
[10:55] <felipec> without looking at the code of bzrlib
[10:56] <lifeless> uh,
[10:56] <lifeless> 'bzr branches'
[10:56] <lifeless> but no, no more so than you can for git or hg
[10:56] <lifeless> (I've looked at doing it independent of git's tools, and had to go to the code to get details)
[10:58] <lifeless> it doesn't seem particularly useful to me to try to pin disk details down so that other folk can implement when the code is free; anyone that wants to know can read the /actual/ spec (not a poor proxy); also they can just use the code directly in the first place.
[10:58] <lifeless> things like bzrlib.dirstate do offer EBNF descriptions of the file format
[10:59] <lifeless> but this isn't intended for external reimplementation (though I know that DVCS for emacs actually used that to write a parser for the dirstate)
[11:04] <felipec> lifeless: I've tried to understand the repository format by looking at bzrlib but I couldn't, I guess I will have to try harder
[11:09] <AfC> I suppose different repository implementations have different formats.
[11:09] <AfC> {shrug}
[11:11] <lifeless> felipec: pydoc bzrlib.repofmt.pack_repo
[11:11] <lifeless> felipec: that should get you somewhere
[11:13] <lifeless> felipec: with our current default repository format (the best performing one to date :))
[11:18] <AfC> felipec: to all appearances the Bazaar hackers have worked very hard to give  bzrlib a decent public face capable of manipulating arbitrary Bazaar branches, working trees, repositories etc. If you do speak Python then you'll probably do well to use bzrlib directly to ask the questions you have of a given branch.
[11:42] <lifeless> I'm off, bbiab
[12:57] <cdleary> does anybody know if pushing to a remote location triggers a post_pull hook at the remote location?
[13:27] <lifeless> cdleary: if you are using a recent enough bzr, and bzr+ssh, it should I think; it will certainly trigger your local bzr's post_push hook locally with the remote location as the target parameter
[13:32] <cdleary> lifeless: yeah, I was trying to avoid a push-and-update style hook, because I feel like the whole "ssh in after and clean up" thing is a little too hackish when there's a bzr instance running on the other end of the transport
[13:33] <lifeless> I hear it works quite well
[13:33] <lifeless> or you can look at bzr-upload I think it is; if you are deploying via bzr
[13:35] <cdleary> ah that's a cool plugin, but I was thinking more about modifying bzr-email to send email after pushing to a "central" branch
[13:36] <lifeless> well, my understanding is that that is available
[13:36] <lifeless> but you need to be using bzr+ssh so that there is a bzr process on the other end
[13:38] <cdleary> oh, it's already available? do you know if there's a recommended way to go about doing it, or do I switch bzr-email from a post_commit to post_pull hook like I thought?
[13:38] <Jc2k> beuno: ping
[13:38] <lifeless> cdleary: you'll need to read the list archives and recent release notes I think
[13:39] <lifeless> cdleary: it would be a post-push, not post-pull
[13:39] <lifeless> cdleary: you are pushing after all
[13:39] <lifeless> Jc2k: his midnight I think
[13:39] <lifeless> Jc2k: argentinian
[13:40] <cdleary> lifeless: thanks for the tips :) didn't know that post-push got triggered at both ends, and I'll go check out the lists
[13:40] <lifeless> cdleary: I'm hazy on details, I know andrew bennets was working on this, and email was one of the primary use cases
[13:40] <lifeless> sorry I can't be more useful :P
[13:40] <Jc2k> lifeless: yeah i thought he'd be asleep
[13:41] <cdleary> well if I get a solution working that's not a total hack I'll be sure to propose a merge on launchpad ;)
[13:41] <cdleary> but if it's already done then I'm golden
[13:45] <cdleary> lifeless: (oh, and thanks for bzr-email :)
[13:47] <lifeless> cdleary: my pleasure
[14:35] <matid> Hi there!
[14:35] <matid> Just wondering, what is the preferred way to set up Bazaar on the server to share a single push repo in a team of 5+ developers?
[14:36] <matid> I mean I could do with bzr+ssh, but how about permissions for different projects, etc.?
[14:58] <db-keen> http://pastey.net/89808
[14:59] <db-keen> The part that isn't working is straight out of the guide
[15:00] <Peng> I'm not sure, but I think install_named_hook may be pretty new. Maybe your bzr is too old.
[15:00] <Peng> Also, ew, complicated os.system().
[15:02] <Peng> Also, isn't it executing Ruby code that only executes something else and does a trivial check on the output? Python can handle that...
[15:02] <db-keen> yeah, I'm sure with a little effort I could easily convert it to python, but I don't really know python
[15:40] <AfC> matid: what do you mean by "single push"?
[15:40] <matid> I should say a common push repository.
[15:40] <matid> So that all devs can push to it.
[15:42] <AfC> matid: Well if you've only got ~5 people I'm not terribly sure what you need permission barriers for, but regardless, standard unix permissions apply. If they own the repository (ie, the .bzr/repository) directory at . or .. then they can push to it.
[15:42] <AfC> etc
[15:42] <AfC> If you want them to be able to push to each others', then I'd suggest they all be in a "bzr" group or something and make the directories appropriately sticky and/or umasked.
[15:45] <matid> OK, I think I found what I was looking for...
[15:45] <matid> I had the directory chmoded 02770 but it wasn't enough to make the permissions work as I wanted them to work.
[15:45] <matid> I had to add a shell script to change umask before running bzr.
[16:06] <jelmer> teratorn, see the bzr-svn FAQ
[16:21] <matid> jelmer: Hi. You're the maintainer of bzr-svn, right?
[16:21] <jelmer> matid, yep
[16:21] <matid> jelmer: A quick question: which version of bzr is best suited for bzr-svn as of now?
[16:21] <jelmer> matid: Depends on the version of bzr-svn you're using
[16:22] <antoranz> Hi guys! when is bzr 1.6 coming out?
[16:22] <jelmer> matid: There's a list on the wiki
[16:23] <matid> jelmer: I currently use bzr 1.3.1 with bzr-svn 0.4.9
[16:23] <matid> jelmer: I wanted to upgrade bzr and I was wondering if it's going to break bzr-svn or not.
[16:23] <jelmer> matid: Yes, you'd have to upgrade bzr-svn as well
[16:24] <antoranz> jelmer: how about my question? :-D
[16:24] <matid> jelmer: Does bzr-svn work with 1.6 or it's 1.5 only?
[16:24] <jelmer> antoranz, Sorry, I don't know what the release plans for 1.6 are
[16:24] <antoranz> k
[16:25] <jelmer> matid: 1.6 isn't out yet
[16:25] <antoranz> I saw 1.6 beta 2 was released almost 2 weeks ago. how did it go?
[16:25] <matid> jelmer: I should go with 1.5 and newest bzr-svn then, right/
[16:25] <matid> ?
[16:26] <antoranz> matid: I guess so.
[16:26] <jelmer> matid: Yes, 0.4.10
[16:28] <antoranz> what repository for gutsy and hardy) do I have to enable to get the beta?
[16:29] <antoranz> or it has to be done by hand?
[16:33] <jelmer> I think you can only get it from the source tarball
[16:34] <matid> jelmer: What version of svn should I get to have bzr-svn working?
[16:34] <matid> jelmer: I upgraded bzr and bzr-svn and now I get this error: http://pastie.org/219489
[16:35] <matid> jelmer: That's after I try bzr pull on an svn branch I used to use with bzr 1.3.1 and bzr-svn 0.4.9
[16:35] <jelmer> matid: That's an issue with 0.4.10 and Subversion 1.5
[16:35] <jelmer> I think there's an open bug about it
[16:36] <matid> jelmer: What should I do then?
[16:36] <jelmer> matid: Use Subversion 1.4, comment out that particular assert in Subversion 1.5 or stay with bzr-svn 0.4.9 for now
[16:38] <antoranz> OK... I added the repositories for betas and release candidates
[16:38] <matid> Commenting this assert out and recompiling subversion should do the trick, right?
[16:38] <jelmer> matid, yep
[16:38] <antoranz> but now bzr is kept from updating
[16:45] <matid> jelmer: Thanks! That fixed the issue.
[16:46] <jelmer> antoranz, how do you mean?
[16:50] <jelmer> beuno, ping
[16:54] <antoranz> http://www.pastebin.ca/1052494
[17:09] <jelmer> you probably have some plugin installed that can't be upgraded
[17:09] <jelmer> but relies on the version of bzr you have currently installed
[17:31] <antoranz> let me see
[17:34] <antoranz> the problem is the version of python-central
[17:35] <antoranz> bzr: Depends: python-central (>= 0.6.5) but 0.5.15ubuntu2 is to be installed
[17:35] <antoranz> any ideas?
[18:37] <Jc2k> lo all
[18:38] <Jc2k> i have a launchpad question, just grabbing a link..
[18:38] <Jc2k> so...
[18:38] <Jc2k> jelmer created https://code.edge.launchpad.net/~gnome-bzr-mirror
[18:39] <Jc2k> which is awesome
[18:39] <Jc2k> does launchpad use shared repositories?
[18:40] <Jc2k> i.e. by the simple fact that bzr-mirror.gnome.org is getting mirrored by launchpad, do personal branches become really cheap?
[18:40]  * Jc2k goes to test
[18:40] <fullermd> No.
[18:40] <Jc2k> ah
[18:41]  * fullermd dashes hopes in only 2 letters!
[18:41] <Jc2k> that would have been wicked levels of cool
[19:02] <clemente> Hi, I'm still unable to run bzr from the bzr branch, since when I do ./bzr, it still uses the bzrlib from /usr/lib, that means the old one which was installed on the system
[19:03] <clemente> I have this problem each time I want to run a Python program without installing it...
[19:03] <Verterok> clemente: you need to modify your PYTHONPATH envvar
[19:04] <clemente> Verterok: however that doesn't work. I tried:  PYTHONPATH=/w/bzr.dev/  /w/bzr.dev/bzr fast-import  ......
[19:04] <clemente> And I still get in „plugins“:  bzrtools             /usr/lib/python2.5/site-packages/bzrlib/plugins/bzrtools
[19:05] <Verterok> clemente: couldd you paste the output of YTHONPATH=/w/bzr.dev/  /w/bzr.dev/bzr version
[19:05] <clemente> Bazaar (bzr) 1.6b3
[19:05] <clemente> The problem is not with the bzr executable but with bzrlib
[19:08] <Verterok> clemente: it's clearly a pythonpath issue, for some reason python is looking first in /usr/lib
[19:09] <Verterok> clemente: something is overriding your pythonpath :(
[19:10] <clemente> Ok, thanks, I will search the cause
[19:11] <Verterok> clemente: sorry I can give you more help with this issue
[20:09] <tro> is there any way to convert a rich-root-pack repo into a pack-0.98
[20:09] <tro> ?
[20:12] <Jc2k> create a brand new repo as pack-0.98 and pull from the old one to the new one?
[20:13] <jelmer> tro: No, that's not possible
[20:13] <jelmer> (I think you mean pack-0.92, btw)
[20:18] <tro> right. 0.92
[20:18] <tro> looks like this branch i'm working with was imported using bzr-svn
[20:18] <tro> i guess it uses rich-root-pack by default?
[20:18] <jelmer> tro: Yep
[20:19] <jelmer> tro: rich-root-pack will hopefully become the defualt format in bzr 1.6
[20:19] <tro> hmm ... so how will people upgrade from pack-0.92?
[20:21] <jelmer> "bzr upgrade --rich-root-pack" will upgrade a branch
[20:23] <tro> does the same go for shared repos? i'm setting one up right now
[20:37] <jelmer> tro: yep
[20:38] <jelmer> tro: You can also create a rrp one using "bzr init-repo --rich-root-pack" (saves you an upgrade)
[20:38] <tro> jelmer: so if i run that command on a shared-repo, will all the branches it hosts be converted as well?
[20:39] <jelmer> tro: yes
[20:39] <tro> neat
[20:39] <tro> thanks
[21:15] <eMxyzptlk> Hey guys, is there an alternative to "darcs amend-record" ??
[21:16] <eMxyzptlk> If you don't know what it means well it will record new changes under the old revision..
[21:16] <eMxyzptlk> Add to it not replace it
[22:40] <lifeless> eMxyzptlk: no there is not, because in a distributed database a revision id needs to have a single unique value
[22:40] <eMxyzptlk> lifeless, ah ok
[22:41] <lifeless> eMxyzptlk: however, you can for the mst recent commit do 'bzr uncommit; bzr commit' to pop off the last commit and then make a new one
[22:41] <eMxyzptlk> lifeless, thanks anyway :)
[22:41] <eMxyzptlk> lifeless, yea that's what I am actually doing right now
[22:42] <eMxyzptlk> lifeless, but it would be nice to create something that does this ( maybe a plugin ), it saves me time copying/pasting the log of the commit
[23:03]  * Verterok dances
[23:03] <Verterok> BB now runs on mysql :D
[23:18] <lifeless> Verterok: cool
[23:18] <lifeless> beuno: hi
[23:18] <Verterok> hi, lifeless
[23:19] <Verterok> I finally won the encodings battle :P
[23:19] <beuno> hey lifeless
[23:19] <beuno> Verterok, oh, yay!  does that mean BB working with MySQL?
[23:19] <Verterok> beuno: yep :D
[23:19] <beuno> oh, very cool
[23:20] <beuno> is it reproducable?  the migration I mean
[23:20] <Verterok> http://steppenwolf.selfip.net:8089
[23:20] <Verterok> beuno: it should, I'm writting the README ATM
[23:21] <beuno> Verterok, push to LP, mail the list!  ;)
[23:22] <Verterok> beuno: there is only one unresolved issue, that odd warning about "data truncated" in a blob :P
[23:23] <Verterok> I'll push to LP as soon I finish the docs..
[23:23] <beuno> Verterok, ah. Have you mean able to track down if it actually removes data or not?
[23:24] <Verterok> not yet, I focued on fighting against encoding errors :)
[23:24] <Verterok> beuno: next iteration is to track down the warning
[23:25] <beuno> Verterok, congrats!
[23:25] <Verterok> thx beuno
[23:26] <fullermd> Well, blob/text only store 65k...   bundles can get bigger than that fairly commonly.
[23:26] <Jc2k> lo beuno
[23:26] <fullermd> You can get 16 meg in a mediumblob, which is probably enough.  But might as well just go to the 4 gig in longblob.
[23:27] <lifeless> jelmer: around?
[23:27] <jelmer> lifeless, jup
[23:27] <Verterok> fullermd: thanks for the tip
[23:27] <lifeless> beuno: have you show jelmer loggerhead-super-search?
[23:27]  * Verterok cheking what kind of blob is using
[23:28] <beuno> lifeless, I don't think so...
[23:28] <beuno> jelmer, http://<IP_ADDRESS>:8080/bazaar/bzr/changes
[23:28] <lifeless> beuno: got time to run up your demo ?
[23:29] <beuno> lifeless, I left it up. Googlebot keeps trying revids  :p
[23:29] <beuno> hey Jc2k
[23:29]  * Verterok waves fullermd (0 warnings)
[23:29] <Jc2k> :)
[23:29] <Verterok> fullermd: thanks!! it worked like a charm
[23:29] <lifeless> jelmer: go to that url, and type into the search box
[23:30]  * fullermd has his uses   8-}
[23:30] <beuno> Jc2k, did you get my ping yesterday?
[23:31] <Jc2k> beuno: yes. im using the wsgi-ify branch, and our priorities are clean urls and any of bkors bug reports that are possible. and i want it to look GNOMEy. :p
[23:31] <Jc2k> i cant think much more than that right now
[23:31]  * Jc2k is ready to pass out
[23:32] <jelmer> wow, works nicely :-)
[23:32] <lifeless> Jc2k: I believe wsgify is in trunk now
[23:32] <beuno> Jc2k, clean urls and wsgi and other fixes have been merged intro trunk
[23:32] <lifeless> jelmer: thats 'how complete' bzr-search is :)
[23:32] <Jc2k> ace
[23:32] <beuno> Jc2k, if you pull from there, you should have all of it.
[23:32] <beuno> I'll start playing to get it looking gnomish
[23:32] <jelmer> lifeless: Does it work without loggerhead as well?
[23:33] <lifeless> jelmer: grab the plugin and give it a whirl :)
[23:33] <lifeless> jelmer: clearly, you have not done so :)
[23:36] <lifeless> jelmer: it can index about 6MB/minute at the moment
[23:36] <lifeless> (it did a 509MB code base - launchpad - in 80 minutes)
[23:38] <Jc2k> beuno: cleaner urls, i should have said even cleaner urls ;)
[23:38] <Jc2k> beuno: http://bzr-mirror.gnome.org:9876/conduit/trunk/annotate/1445?file_id=276%401811c9d2-c306-0410-a128-ae57aa55c946%3Atrunk%3AChangeLog
[23:38] <beuno> Jc2k, ah, file paths instead of fileids. Gotcha. That can get tricky, but I'll see what I can do  :)
[23:39] <Jc2k> it would be nice to be able to have discovarable links like /conduit/trunk/ChangeLog :)
[23:40] <lifeless> Jc2k: I think you mean predictable
[23:40] <lifeless> Jc2k: or guessable
[23:40] <lifeless> Jc2k: (I agree, having such links is important)
[23:40] <beuno> yes it would. Just have to figure out a good way for weird characters not to come back and bite us. Maybe I can add it as an experimental feature off by default
[23:40] <lifeless> beuno: weird characters?
[23:40] <beuno> lifeless, in filenames
[23:41] <beuno> passing them through URLs
[23:41] <beuno> apart from that, it should be easy
[23:43] <lifeless> beuno: so, output urls as utf8
[23:43] <lifeless> beuno: decode as utf8, failure to decode is a 404
[23:45] <beuno> lifeless, yes. I'm just not sure if that would be good enough to go on by default. I'll get it done, and see what mwhudson thinks, he's looked into that before
[23:45] <beuno> it may have been a cherrypy limitation, which we already got rid of
[23:45] <lifeless> its a std66 recommendation FWIW
[23:46] <lifeless> internally paths are unicode to bzrlib
[23:46] <lifeless> so url = urlescape(path.encode('utf8'))
[23:46] <lifeless> and the reverse is urlunescape.decode('utf8')
[23:46] <lifeless> if framework foo is doing some or all of that for you, thats fine
[23:47] <beuno> sounds simple enough. Jc2k may get everything he wants then  :)
[23:48] <lifeless> the only failure mode is clients who guess at a url and are using a different encoding (e.g. utf16, or non-latin* or cpWHACKO)
[23:48] <lifeless> if they guess though, thats where I suggest 404;
[23:48] <lifeless> _most_ unix clients will be using utf8
[23:49] <lifeless> and I think many browsers transcode to utf8 when you type in a url, because its such a common case
[23:49] <lifeless> (though if they do that they do make it hard to actually go to a url hosted by e.g. a russian windows user)
[23:50] <Jc2k> \o/
[23:50] <lifeless> (which btw is one thing that really bites about standard 66) - 'undefined' is firmly entrenched as far as 'what charset was this url encoded as'
[23:52] <beuno> I suppose that if it gets complicated, we can allow generating fileids instead. It's just a matter of what we leave on by default, as both can work always, we just present on or the other to the user in links
[23:52] <lifeless> well, users can always browse to a url
[23:53] <lifeless> start at the root and client down, even the biggest code base should be only a few clicks to get to a path; then they can copy the bit of the url they want
[23:53] <lifeless> copy and paste is good at preserving stuff :)
[23:55] <beuno> True. I'll poke mwhudson on monday in case he already has a good reason why it isn't as straightforward


[06:25] <zyga> good morning!
[06:30] <zyga> hey mvo
[06:30] <zyga> long time no see
[06:34] <mup> PR snapd#10606 opened: o/hookstate/ctlcmd: unify the error message when context is missing <Simple 😃> <Created by mardy> <https://github.com/snapcore/snapd/pull/10606>
[06:39] <mvo> good morning zyga - indeed!
[06:56] <mardy> hi zyga, mvo!
[06:56] <zyga> hey mardy
[06:58] <mvo> hey mardy - good morning!
[06:59] <mup> PR snapd#10604 closed: wrappers: measure time to enable services in StartServices() <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10604>
[11:35] <mup> PR snapd#10607 opened: o/snapstate: install snap after prereq snaps are done installing <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/10607>
[13:37] <mardy> ijohnson[m]: about that /run/mount/utab* file, I'm a bit hesitant to add a `deny` for it, given what's written here: https://gitlab.com/apparmor/apparmor/-/wikis/AppArmor_Core_Policy_Reference#subtracting-permissions
[13:38] <mardy> ijohnson[m]: there are other interfaces (such as the udisks2 one) which explicitly allow access to this file, so denying it would make it harder to use these two interfaces at the same time
[13:41] <ijohnson[m]> mardy: hmm let me take a look now that I'm back at my computer, I seem to remember deny's for it elsewhere but perhaps I'm mistaken
[13:43] <ijohnson[m]> mardy: ah so I think I remember, we deny it for the kubernetes-support interface, but I think that's probably something specific to kubernetes-support, as we are in "more control" over the users of kubernetes-support and what other plugs they use alongside kubernetes-support
[13:43] <ijohnson[m]> mardy: so given this I think it's fine to just allow /run/mount/utab for the mount-control interface
[13:55] <mardy> ijohnson[m]: ok
[15:41] <mup> PR snapd#9094 closed: corecfg: add "system.hostname" setting to the system settings <:birthday:> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9094>
[15:42] <ijohnson[m]> mvo: I've got a branch for the install-device files thing we discussed today, I'm working on a spread test for it now, shouldn't be too bad but requires even more hackiness to nested.sh
[15:48] <mvo> ijohnson[m]: \o/
[15:49] <mvo> ijohnson[m]: I did not manage to work on the KDF parameters for the recovery key from the gadget.yaml :( but I will try again tomorrow
[15:49] <mvo> ijohnson[m]: it's also not really designed yet so … anyway, gtg
[19:56] <mup> PR snapd#10593 closed: c/snap,o/hookstate/ctlcmd: add JSON/string strict processing flags to snap/snapctl <Created by MiguelPires> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10593>
[23:24] <bandali> hey amurray, can i /msg you?
[23:26] <amurray> bandali: sure
[23:27] <bandali> thanks!