[12:19] <saeed> lool
[12:19] <saeed> ogra
[12:32] <armin76> saeed
[12:35] <saeed> hi armin
[13:22] <lool> saeed: Hey
[14:18] <saeed> as you know, the suspend button worked for me
[14:19] <saeed> but when I convert it to KEY_POWER , and configure the g-p-m to "Ask Me" when power pressed
[14:19] <saeed> nothing happens
[14:20] <saeed> when I configure the g p m to suspend when power pressed, it works
[14:45] <persia> saeed: So, g-p-m is capturing your button press, but not launching the GUI when configured to "Ask Me"?
[15:06] <lool> saeed: In a terminal, killall gnome-power-manager and then run gnome-power-manager --verbose
[15:06] <lool> saeed: That should give you some debugging info on what GPM is seeing
[15:52] <saeed> persia yes exactly
[16:08] <therealgalen> What is everybody using to build for ARM? Are there particular compilers that are optimized for ARM?
[16:09] <armin76> codesourcery's
[16:12] <therealgalen> armin76: fastest?
[17:07] <persia> therealgalen: We use native compilation in Ubuntu: compiling ARM on ARM.
[17:29] <therealgalen> persia: I don't mean the hardware so much as the software - the compiler
[17:29] <therealgalen> a lot
[17:29] <therealgalen> of vendors claim to have "faster" or "better" compilers
[17:30] <persia> Ah.  I don't think Ubuntu claims faster or better, but I know a lot of work has gone into making it appropriate for ARMv7+Thumb2
[17:31] <persia> But no special secret sauce: most of the changes are upstream, so I suspect anyone could grab them if they felt it was a competition.
[17:31]  * persia is more concerned about making the software work than about the compiler being especially fast
[17:32] <therealgalen> persia: architecture-specific issues, or just general development?
[17:32] <persia> Both :)
[17:33] <persia> Although a lot of what I personally do is actually neither, but rather just things like improving developer tools to make it easier to do those, or reviewing cases where something didn't build for reasons involving how the distribution is developed, etc.
[17:36] <therealgalen> well, i am looking at a variety of companies offering gcc alternatives claimed to be faster; i was hoping to hear from people who have tried them
[17:40] <armin76> therealgalen: its known to be the most optimized, yes
[17:41] <therealgalen> armin76: are there any benchmarks *not* from the vendor online?
[17:42] <persia> armin76: optimised for which?  execution time, code size, compilation time, etc.?
[17:42]  * persia is fairly certain it's not possible to optimise for those three things simultaneously, and suspects there are other similar variables.
[17:43] <therealgalen> execution performance primarily; compilation time does not matter, code size does not matter
[17:47] <armin76> persia: no clue, its just what they tend to say
[17:47] <armin76> persia: in fact they tend to say that vanilla gcc sucks
[17:47] <armin76> therealgalen: no clue, sorry
[17:48] <persia> therealgalen: From what I understand, it really depends on which code you need so optimised.
[17:49] <persia> Try a few different toolchains, and see which one compiles your application in the fastest way.
[17:53] <therealgalen> hmm, ok
[17:53] <therealgalen> persia: most of the functions are kernel stuff, ath9k, ec.
[17:54] <persia> The kernel gets kinda fussy about opimisation.  Generally, I think it's better to walk the code path and optimise in code than try to adjust toolchains for that class of issues.
[17:54] <persia> Just because the kernel code makes some assumptions about how it will be compiled.
[19:35] <DanaG> oh heya, where do I get the ARM toolchain for cross-compiling stuff?
[19:35] <DanaG> apt-cache search gcc doesn't show anything related to ARM.
[19:36] <persia> We don't cross-compile :)
[19:36] <persia> we just rebuilt everything natively.
[19:37] <DanaG> How'd you get the first one up, then?  =þ
[19:37] <persia> Used Debian's compilation.
[19:37] <armin76> they stole it :D
[19:37]  * persia prefers to think of it as "sharing"
[19:53]  * DanaG wishes somebody would make something like that "touchbook" but with the new Marvell 1.2GHz thingy.
[19:56] <DanaG> The worst embedded thing I've ever (tried to) use: Microblaze. It was so bad, that building the cross-compiler made the HOST compiler segfault!
[20:04] <DanaG> hmm, what systems do you run the armel compilation on?
[20:06] <persia> I'm not sure precisely.  I suspect there's at least one package that shows it in the build log, but :)
[20:06] <persia> I do know that they are ARMv7 machines.
[20:07] <persia> Personally, I do test-compilation on a Sharp Netwalker, but we only upload sources.
[20:13] <DanaG> Oh yeah, worst distro fail I've ever seen was Angstrom on a Zaurus SL-5500.  I can understand drivers not working... but to have your kernel config for that board not enable the ALREADY-IN-KERNEL drivers for that board?  That's just epic fail.
[20:13] <DanaG> I wish I could get Ubuntu running on the thing.
[20:16] <persia> The 5500?  That's too old.
[20:16] <persia> Jaunty should run on the 1000, 1100, 3000, 3100, 3200, and 3300
[20:16] <persia> But karmic or lucid won't.
[20:18] <DanaG> My gripe was that they discontinued OpenZaurus in favor of the supposedly superior "Angstrom" -- but then seemingly didn't even TRY to make the old hardware work.
[20:19] <DanaG> Having it work slowly and poorly... fine.... but disabling in-kernel touchscreen driver?  fail.
[20:19] <DanaG> Anyway, now I'm using a beagleboard, and that's cool.
[20:19] <persia> Well, Sharp discontinued the device, which may have had something to do with that.
[20:19] <persia> You're running lucid on your beagleboard?
[20:20] <DanaG> Yeah.
[20:20] <DanaG> Still, they could've at least set CONFIG_UCB1100_TS true, or whatever that was.
[20:20] <DanaG> anyway, enough bashing Angstrom.
[20:20] <DanaG> I'm using Ubuntu on it because it'll be just like my main development environment.
[20:20] <DanaG> Too big for the onboard flash, though -- I'm using a 2-gig SD card.
[20:21] <DanaG> hmm, is there anything useful I COULD use the onboard flash for?
[20:21] <persia> I think we still need a slightly better way to dispatch test-builds to other machines though.  I have to manually scp sources to armel or powerpc devices from my laptop to build them.
[20:21] <persia> But other than that, I think it works just fine.
[20:21] <persia> How big is the onboard flash?
[20:22] <DanaG> I think it's just 256 megs.
[20:22] <armin76> i didn't know the bb had internal flash
[20:22] <DanaG> And u-boot takes up some of that.
[20:23] <persia> That's tight.  You might be able to stuff your kernel and initramfs in there.
[20:23] <persia> But I don't think you can do anything advanced with it.
[20:23] <DanaG> Might as well just leave it on initramfs.
[20:24] <DanaG> now, this would be cool, if not for the tiny battery: http://eeepc.net/superthin-netbook-runs-on-marvell-armada-510/
[20:26] <DanaG> Oh yeah, I did have a lot of trouble getting the usb host-to-device networking working.... it was encoding the packets badly (off-by-one error).
[20:26] <persia> Nobody seems to want to put a full-size battery in with a low-power device.  I really wouldn't mind an extra 100g for an extra 10 hours of power.
[20:27] <DanaG> yeah, that sucks.
[20:27] <DanaG> My network issue: I set guest device to mac address 00:11:22:33:44:55, and the parent saw "Ethernet II" frames from address ff:ff:00:11:22:33 sending packets of type 4455.
[20:27] <persia> Well, it probably also costs an extra 12,000円 for that extra 100g, which makes it perceived as less competitive.
[20:28] <DanaG> What currency unit is that?
[20:28] <persia> Wah!  That's just not right :)
[20:28] <DanaG> I finally fixed it by passing g_ether.use_eem=0
[20:28] <persia> Oh, right.  That gets used in multiple contexts.  JPY is what I was thinking.
[20:28] <DanaG> then it used full cdc-ether instead of cdc-subset.
[20:32] <jonnor> Hi. What libc implementation is being used in Ubuntu ARM?
[20:32] <armin76> windows!
[20:33] <armin76> jonnor: eglibc
[20:34] <jonnor> armin76: cool, thanks!
[20:35] <DanaG> heh, note to self: ext4 as root on flash means I can't use ext2load.
[21:12] <DanaG> init: ureadahead main process (41) terminated with status 5        mountall: Could not connect to Plymouth       init: procps main process (369) terminated with status 255        init: ureadahead-other main process (466) terminated with status 4
[21:12] <DanaG> that's on the beagleboard.
[21:29] <ogra> seems your kernel misses a good bunch of options and plymouth isnt installed
[21:31] <ogra> none of these issues should stop it from finishing the boot though
[21:32]  * ogra goes back to weekendish stuff
[21:34] <DanaG> init: ureadahead main process (40) terminated with status 5
[21:35] <DanaG> oh yeah, I don't plan to use the video output for much (at least for now), anyway.
[21:35] <DanaG> Also weird: the default user's named group is not 1000 like it is on the host system.
[21:39] <DanaG> beagleboard has this:
[21:39] <DanaG> mtdparts: mtdparts=nand:512k(x-loader),1920k(u-boot),128k(u-boot-env),4m(kernel),-(fs)
[22:40] <DanaG> !find pkg-config
[22:40] <ubot4> DanaG: Found: pkg-config
[22:40] <DanaG> =þ
[22:40] <DanaG> odd that command-not-found doesn't seem to work on ARM.
[22:51] <DanaG> !find dbus-glib-1
[22:51] <ubot4> DanaG: Found: libdbus-glib-1-2, libdbus-glib-1-2-dbg, libdbus-glib-1-dev, libdbus-glib-1-doc


[00:42] <ironhoof> Hey I just installed xubuntu 16.04 on my netbook, it installs fine, updated and now it just sits on recovering journal, after I had hard reset it. It was just a blank screen before that. There is also a nomodeset on my kernel so its not that
[00:43] <ironhoof> Anyone know whats going on?
[04:25] <nu7shell> Hi
[05:01] <nikolam> I turned off lightdm with ' echo "manual" | sudo tee -a /etc/init/lightdm.override ' to save RAM, for thinking to use it as smallish web server
[05:01] <nikolam> maybe I should just uninstall desktop parts (12.04LTS)...
[05:02] <nikolam> Or reinstall newest LTS with minimal install
[05:03] <nikolam> Thinking of getting rid of Pulseaudio and how to have network working, without need to run NetworkManager (also so save some RAM)
[05:05] <nikolam> On plus side newest server brings ZFS by default. On minus side it's smallish 512MB machine
[07:42] <xubuntu87w> Hello I have installed xubuntu and my WiFi is not working.  Model is 802AIN2 what do I need to do to get it working?
[07:56] <xubuntu87w> Is there more information about the wireless adapter I'm using I need to give?
[08:02] <xubuntu87w> Is anyone able to help me please?
[08:22] <xubuntu87w> Can somebody help me please?
[08:32] <xubuntu87w> Is anyone in this irc chat?
[08:34] <pavlushka> !patience | xubuntu87w
[08:36] <xubuntu87w> Ok
[19:13] <xubuntu505> всем привет))
[19:16] <ax562> no nintendo
[20:46] <xubuntu48> Hello I have installed Xubuntu and my WiFi is not working. Model of wireless usb adapter is 802AIN2, what can I do to get it working?
[20:53] <xubuntu95w> Yo guys, is there anyone around feeling like giving some basic help?
[20:54] <flocculant> xubuntu95w: just ask the question - if someone awake can answer they will
[20:54] <ax562> xubuntu95w check for drivers
[20:58] <xubuntu95w> I have a problem with Xubuntu installation from a bootable USB Drive and a DVD. No matter which one I choose it doesn't go through the "Boot from CD/DVD" or just hangs with the underscore. Downloaded twice already, created bootable USB with both Rufus and Unetbootin, any ideas?
[21:00] <ax562> xubuntu48w check for drivers
[21:05] <xubuntu48> ax562 no drivers that i know of to download. When it is plugged into windows its listed as cd drive and has .exe file to install drivers for windows from it.
[21:06] <ax562> so works on windows?
[21:06] <xubuntu48> ax562 Yeah not sure how to it working on Linux though.
[21:07] <xubuntu48> Get*
[21:07] <ax562> check the model and manifacturer and look up linux driver download
[21:08] <knome> atheros dongles don't have the best support for linux..
[21:10] <xubuntu48> I have, Model 802AIN2. There doesnt seem to be any driver downloads because it comes with it on it.
[21:11] <knome> yes, the windows driver
[21:12] <xubuntu48> What can i do with the windows driver?
[21:12] <knome> not much on linux
[21:12] <knome> as i said, dongles with an atheros chip have bad support on linux
[21:13] <xubuntu48> Oh i would really like to use Linux, so hopefully there is a way. If you don't think its possible to get it working let me know, since you said this adapter has bad linux Support
[21:14] <knome> do you have any chance to try another adapter?
[21:16] <ax562> or wired ethernet port connection?
[21:16] <xubuntu48> I have another i could plug in but its a big problem and bricks the computer, makes it completely freeze.
[21:16] <knome> wired != wireless, but sure, that's also an option
[21:16] <knome> xubuntu48, that's probably not a good idea either then ;)
[21:16] <knome> what about a third one O:)
[21:18] <xubuntu48> I can still plug it in if need to download stuff, but it will eventually freeze the computer. Sadly i dont have a third one
[21:19] <knome> just to explain why support is often bad; the hardware manufacturers do not share the specs on how their hardware works, so it's impossible to create linux drivers for the devices without reverse-engineering, which takes a lot of time (and means a developer with that time has to have that device and the motivation to make it work)
[21:19] <knome> with often cheap usb dongles it's often too easy to just buy a new one rather than try to reverse-engineer anything
[21:20] <xubuntu48> Okay yeah
[21:21] <xubuntu48> I have a few extra routers if i could somehow use that as wifi? lol
[21:25] <knome> you probably could with some soldering, but it's probably worth it, again considering how (relatively) cheap usb dongles are
[21:28] <xubuntu48> Oh thought it might be easy then that. Well i guess ill have to wait until i can get a new one or something. Thank you for your help, and you too ax562
[21:29] <knome> np, and before you get the new one, search a bit in the internet about compatibility :)
[21:29] <ax562> :)
[21:29] <xubuntu48> Ok :)  bye
[21:43] <pavlushka> xubuntu48: I think you should post this issue to ubuntuforum or askubuntu
[21:53] <knome> pavlushka, first, they are gone already; second, that wouldn't help if there isn't any support for his devide
[21:53] <knome> *device
[21:55] <pavlushka> knome: in the mean time, I was reconnected, and everything happened in between, so missed, :)
[23:12] <greg_> pipelight instalationhelp


[00:02] <lifeless> jfroy: pack doesn't alter what data is visible or how its indexed
[00:03] <lifeless> jfroy: all it does is shuffle it around on disk so that fewer I/O operations are needed to get at related data
[00:06] <jfroy> well it definitely fixed my problem
[00:06] <jfroy> I was able to pull the remote svn branch after packing my local repository
[00:06] <jfroy> whereas before the pack it would die on a missing revision exception.
[00:11] <lifeless> how confident are you that no other operations were done in between the failure and the pack
[00:12] <lifeless> include updates to svn/bzr-svn/bzr
[00:17] <lifeless> if pack does fixit there is a critical bug in bzr's repository code
[00:22] <SamB> lifeless: and not bzr-svn's ?
[00:22] <lifeless> SamB: bzr-svn implementation a repository proxy around libsvn
[00:23] <lifeless> SamB: it doesn't, as far as I know, rummage around through bzr's repository implementation internals
[00:23] <SamB> true
[00:23] <SamB> it doesn't mess with access to a native repository ...
[00:24] <lifeless> so if packaging a repository you're pulling into stops a bzr-svn bug happening, packing has changed the behaviour of [some] public interface || bzr-svn is poking under the hood badly
[00:25] <lifeless> I think the latter is unlikely and that leaves the former, assuming that jfroy has gathered the evidence accurately
[00:25] <lifeless> jfroy: next time this happens, can you take a backup of your bzr repo and your ~/.bazaar/bzr-svn cache die
[00:25] <lifeless> *dir*
[00:25] <lifeless> jfroy: then, try the pull again, if it fails again, pack and pull
[00:26] <lifeless> if that works, backup your backups and then put them back in place
[00:26] <lifeless> jfroy: and try the pull again, if it fails once more, we'll have a reproducable dataset to work with
[00:26] <lifeless> if the repo is private we'll write code for you to test
[00:27] <lifeless> if its not private you can schlep it to us
[00:27] <SamB> is schlepnet fast?
[00:28] <lifeless> it can be
[00:29] <jfroy> lifeless: will do
[00:32] <lifeless> thanks
[01:41] <Peng_> Is there an equivalent to "bzr revno" that shows the revid?
[01:41] <jelmer_> jfroy: hi
[01:41] <Peng_> Well, bzr lookup-revision $(bzr revno)
[01:43] <jelmer_> yeah, bzr only uses public interfaces
[01:47] <jelmer_> jfroy: which bug was it exactly that seemed to be fixed by a 'bzr pack' ?
[01:54] <jfroy> jelmer_: hey
[01:54] <jfroy> Sorry just checked IRC
[01:54] <jfroy> jelmer_: https://bugs.launchpad.net/bzr-svn/+bug/364416
[01:58] <lifeless> Peng_: bzr revision-info
[01:59] <Peng_> lifeless: Oh, nice.
[02:01] <jelmer_> jfroy: any chance you can comment on what seems to fix it in the bug report?
[02:03] <jfroy> sure
[02:03] <jfroy> but I don't know much
[02:03] <jfroy> I simply packed to "try see if it does anything", and it unexpectedly did.
[02:04] <jfroy> I didn't make a backup of the repository before packing, unfortunately.
[02:04] <jfroy> although...
[02:04] <jfroy> we may be in luck, actually.
[02:04] <jfroy> I backup my documents automatically
[02:05] <jfroy> I most likely can revert the repository to its state prior to packing
[02:05] <jfroy> and try the sequence all over again
[02:05] <jelmer_> jfroy: which repository format are you using?
[02:06] <jfroy> 1.14
[02:06] <jfroy> (-rich-root of course)
[02:12] <lifeless> jfroy: really? bzr info and paste the format details please
[02:12] <jfroy> lifeless: 1.14-rich-root or 1.9-rich-root
[02:12] <lifeless> ah actually nvm
[02:12] <lifeless> its 1.9 repo
[02:12] <jfroy> anyways, restoring from backup and trying again
[02:12] <lifeless> a new tree format is in 1.14 is all, it supports filters [yay]
[02:12] <jfroy> see if I can reproduce
[02:14] <jfroy> ahhh, backups :)
[02:16] <jfroy> Is there any flags I can use to spit out more info in the bzr.log?
[02:16] <jfroy> the repo is confidential, I won't be able to share it
[02:16] <lifeless> jfroy: for this operation, nothing offhand
[02:16] <jfroy> Although I can certainly paste logs and what not
[02:16] <lifeless> we may write some custom patches to debug
[02:17] <jfroy> jelmer_: I'll be using your bzr foreign branch and bzr-svn for this
[02:17] <jfroy> it's what I usually use
[02:22] <jfroy> eh this time it's still dying after the pack
[02:22] <jfroy> this is very odd
[02:23] <jfroy> mmmm
[02:23] <jfroy> interesting
[02:23] <jfroy> so after the pack, I still got the missing revision exception
[02:24] <jfroy> I then pulled the trunk branch (which was already in the repository)
[02:24] <jfroy> repacked
[02:24] <jelmer_> jfroy: at this point my bzr-foreign branch is basically bzr.dev with bzr+http removed
[02:24] <jfroy> and the the branch command worked
[02:24] <jfroy> so it may be the trunk pull that fixed it, not the pack
[02:25] <jfroy> let me try this again starting at the beginning...
[02:25] <jelmer_> k
[02:26] <jfroy> jelmer_: I think it does a few more things, no?
[02:26] <jelmer_> jfroy: no, the other things have been merged now
[02:26] <jfroy> push working to create new branches and printing the svn revno when pulling
[02:26] <jfroy> I see
[02:26] <jfroy> gotcha
[02:26] <jfroy> good to know
[02:26] <jelmer_> jfroy: it used to be more
[02:26] <jfroy> yeah
[02:26] <jfroy> was the fallback credential store stuff merged in too?
[02:26] <jfroy> I adopted the protocol in my keychain store and it's working great
[02:27] <lifeless> jfroy: the trunk pull is likely it
[02:27] <jfroy> It makes a lot more sense, yes
[02:27] <lifeless> yes, yes it does :)
[02:28] <jfroy> pack should not fundamentally change the content of the history
[02:28] <lifeless> right
[02:28] <jfroy> it just makes it tidier
[02:29] <jfroy> confirmed
[02:30] <jfroy> the trunk pull fixes the branch command
[02:31] <jfroy> I also confirmed I cannot pull the branch in a new repository without having trunk in it
[02:31] <jfroy> if trunk is not there, it always dies with a no such revision exception
[02:31] <jfroy> so it's unlikely that the svn cache is involved here either
[02:34] <lifeless> jfroy: are you pulling from svn
[02:34] <lifeless> or from bzr
[02:34] <lifeless> there is a bugfix in bzr (server side) for 'NoSuchRevision' pulling from a stacked branch
[02:35] <jfroy> pulling from svn
[02:35] <jfroy> in all cases
[02:35] <jfroy> jelmer_: confirmed, I just made a brand new repository
[02:36] <jfroy> tried to pull the svn branch in it, died with the usual error
[02:36] <jfroy> I then pulled the svn trunk in that repository and then pulled the svn branch again
[02:36] <jfroy> and that worked
[02:36] <jfroy> so it seems bzr-svn is failing to pull certain revisions it needs
[02:36] <jfroy> I've updated the bug with that finding.
[02:39] <jelmer_> thanks
[02:40] <jfroy> if you need revprop / file props to debug this when you get around to it, let me know
[02:56] <jelmer_> will do, thanks
[03:55] <jelmer_> lifeless: btw, did I mention dpush to remote git branches works now?
[03:56] <jelmer_> the only thing remaining now is 'proper' push
[03:58] <lifeless> ye
[03:59] <jelmer_> it would be nice if somebody could fix up hg support at some point
[04:01] <jelmer_> I think the API changed or something but it can't do much else than view revision history atm
[08:58] <pzico> hola, I have a stupid question that I couldn't figure out from "Bazaar in 5 minutes".. If I want to force checkout the latest revision of file abc.py in current folder, what is the command?
[08:59] <bob2> if you want the one corresponding to the currently checkout'd revision, bzr revert abc.py
[09:00] <bob2> (ie it will undo all uncommited local changes)
[09:00] <LarstiQ> pzico: Bazaar considers the entire tree 1 object. If you are using a checkout `bzr update` will make it up to date with the master location. If you're using a branch, `bzr pull` will pull in all the new revisions from your parent location.
[09:00] <LarstiQ> pzico: or possibly what bob2 said, from your wording it isn't clear to me what effect you're looking for
[09:03] <pzico> Well, I haven't yet learned to think "bazaar" way. So I just made simple project and used bzr init, add and commits.. now I just want to revert back to previous committed version..
[09:03] <pzico> and only for one of the files I have edited
[09:04] <LarstiQ> pzico: ah ok, if the most recent commit is the one you want to go back to `bzr revert abc.py`
[09:04] <pzico> It seems that the revert command did the job. Thanks.
[09:04] <LarstiQ> pzico: or if you would like to bring it to an arbitrary revision, `bzr revert -r 123 abc.py`
[09:04] <LarstiQ> cool
[09:54] <awilcox> Does anybody know of an Xcode plugin for Bazaar?
[13:51] <ronny> hmm
[13:52] <ronny> anyone aware of an api that kind of combiness Workingtrees iter_changes and list_files ?
[13:53] <ronny> i need renames and unknown files at once if possible
[14:25] <luks> ronny: TreeDelta?
[14:25] <luks> of working tree against the basis tree
[14:25] <ronny> currently im using wt.iter_changes(wt.basis_tree())
[14:26] <james_w> ronny: can't you ask for unknown in iter_changes?
[14:27] <james_w> want_unversioned=True
[14:27] <ronny> ah,
[14:28] <ronny> hmm
[14:28] <ronny> i have that, yet its still somehow missing something
[14:29]  * ronny rechecks his test helpers
[14:30] <ronny> hmm, i have include_unchanged and want_unversioned
[14:33] <ronny> do i have to invalidate a workingtree after a commit?
[14:35] <lifeless> ronny: how do you mean
[14:36] <ronny> hmm, i think im confusing something about the api here
[14:39] <ronny> ok, i think i found my error
[14:39] <ronny> lifeless: i didnt notice i had a broken test
[14:40] <vxnick> hi guys - a question: is there much difference between push/pull and commit/checkout when working on a remote repo with others?
[14:44] <ronny> oh darn
[15:43] <LeoNerd> vxnick: Not really.. they're basically the same... A "bound" branch is just one that pushes after it commits. etc...
[15:43] <vxnick> LeoNerd: thanks, I thought it might've been something like that
[17:31] <vxnick> guys - I think I'm going crazy here. I've created a shared repo and a trunk on a remote server, but can't checkout locally - I get the "bzr error not a branch" error
[17:35] <jelmer_> vxnick: are you checking out the branch location?
[17:35] <jelmer_> I mean, the location of trunk
[17:36] <vxnick> jelmer: I am indeed
[17:36] <vxnick> jelmer: I 'bzr init-repo project_name' and then 'bzr init trunk" within  that dir
[17:36] <jelmer_> vxnick: so the url ends in /trunk?
[17:36] <vxnick> jelmer: that's right
[17:37] <jelmer_> does bzr info work on the URL?
[17:37] <vxnick> nope
[17:37] <vxnick> not a branch
[17:38] <vxnick> oh dear
[17:38] <vxnick> the path was wrong
[17:38] <vxnick> *embarrassed*
[17:38] <vxnick> thanks for your help
[17:38] <jelmer_> np
[18:53] <vxnick> bzr-upload stores the remote location by default, but is there a way that I can switch between locations, perhaps by using some form of alias? I think I might have read about this somewhere but can't find anyhting
[18:53] <jkakar> Sometimes I wonder if 'bzr update' should automatically fall back to 'bzr pull' when the branch isn't bound.
[18:57] <cdecarlo> hi, I'm new to bzr and distributed vcs all together, I've created my first bzr repo with a friend an we are using the decentralized workflow, we wanted to use PQM as our gate keeper but I'm having trouble even getting started, is there a good how to available, I can't find one
[18:59] <james_w> vxnick: have a look at bzr-bookmarks, it allows you to refer to different locations by short names
[19:00] <vxnick> james_w: thanks
[19:00] <james_w> cdecarlo: I don't know of one I'm afraid
[19:19] <Laney> is --fixes lp:xxx just supposed to link the branch?
[19:20] <james_w> that's all it does currently
[19:20] <james_w> there are plans to be a bit more useful I believe
[19:20] <Laney> ok, I thought it would set fix committed too
[19:20]  * Laney does so
[19:58] <ronny> jelmer: ping?
[20:34] <dirkD> is it possible to manage permissions/access rights with a bazaar smart server?
[20:35] <LarstiQ> dirkD: yes
[20:35] <dirkD> LarstiQ: :O
[20:35] <dirkD> how?
[20:35] <dirkD> just with unix permissions?
[20:35] <dirkD> (i can't find it in the user guide)
[20:37] <luks> LarstiQ: I'd say "yes" is a kind of cheating, until the smart server still has VFS calls
[20:40] <dirkD> luks: i'm using bzr 1.14
[20:40] <dirkD> so... RPC calls?
[20:41] <luks> dirkD: you can ignore me, that was purely technical :)
[20:41] <luks> what kind of access rights do you want to setup?
[20:42] <dirkD> i want to give some users access to a branch, and some users not
[20:42] <dirkD> or groups...
[20:43] <luks> the easiest way is probably to use contrib/bzr_access
[20:43] <luks> assuming you want to use bzr+ssh
[20:43] <dirkD> indeed
[20:44] <dirkD> is there any documentation on bzr_access?
[20:44] <dirkD> (it's a plugin i assume? or a patch?)
[20:44] <luks> there are some examples in the file itself
[20:45] <luks> you basically give users ssh access and restrict the commands they can execute
[20:45] <dirkD> ah
[20:45] <luks> it's in the source code tarball
[20:49] <dirkD> luks: looks fine :)
[20:49] <dirkD> but they're talking about .ssh/authorized_key
[20:49] <dirkD> is that about ~/.ssh
[20:50] <dirkD> + ?
[20:50] <dirkD> so i do have to edit authorized_keys for every user?
[20:50] <dirkD> (or create a symlink to a system-wide one of course
[20:50] <dirkD> + )
[20:52] <luks> sorry, I don't know more about that
[20:52] <luks> maybe there is a global way, I don't know
[20:52] <dirkD> ok, thanks for your help
[20:52] <bluszcz> hello, how can i create plugin on the bzr server?
[20:53] <bluszcz> i've got bzr+ssh server - on the client side pre_commit works as expected, but i cannot make it run on server on (bzr co, bzr up, bzr ci -m "" flow)
[20:58] <bluszcz> is this possible?
[20:59] <CardinalFang> bluszcz: Plugins don't do that.  Consider the SFTP transport -- it *couldn't*.
[21:01] <luks> I think there is a post push hook
[21:02] <luks> hm, no, that's not the one
[21:02] <CardinalFang> On the client, maybe.
[21:02] <LarstiQ> luks: I see what you mean, and what I was thinking of is also not directly helpful (Launchpad/ClueBzr style smartserver)
[21:03] <bluszcz> hmmmm...
[21:03] <LarstiQ> luks: post_branch_tip_change or something like that
[21:03] <luks> yeah, that one
[21:03] <bluszcz> CardinalFang: plugin's don't do what? sorry, but i didn't understand
[21:03] <LarstiQ> bluszcz: `bzr help hooks` should mention which ones get run on the server
[21:03] <bluszcz> ok
[21:04] <luks> strange, I can see post_tip_change mentioned in tests, but not the code
[21:04] <bluszcz> i was reading BranchHook.__init__ ;)
[21:05] <LarstiQ> let me fish up how I run bzr-email on the server
[21:07] <bluszcz> ok, i read help hooks but still have no idea how to install server side hook
[21:07] <LarstiQ> bluszcz: in all ~user/.bazaar/locations.conf I have: [chroot-*:///srv/bzr/]\npost_commit_push_pull = True\npost_commit_url = bzr+ssh://server/srv/bzr\npost_commit_url:policy = appendpath\npost_commit_to = commits@
[21:07] <LarstiQ> etc
[21:08] <LarstiQ> bluszcz: the plugin you execute must be loaded by the bzr your users execute
[21:08] <LarstiQ> (on the server)
[21:08] <LarstiQ> bluszcz: other than that, that should be it
[21:08] <bluszcz> reading
[21:09] <bluszcz> hm, bit complicated
[21:09] <LarstiQ> true.
[21:09] <LarstiQ> some of that is due to how bzr-email works
[21:10] <LarstiQ> bluszcz: if you write your own plugin, the key thing is to make sure your plugin code gets loaded, and that you configure for the right branch
[21:10] <LarstiQ> if you do it for all branches, that last bit doesn't matter.
[21:15] <bluszcz> hm
[21:15] <bluszcz> my configuration is:
[21:15] <bluszcz> i've got ssh acount on my server
[21:15] <bluszcz> my user
[21:15] <bluszcz> ;)
[21:16] <bluszcz> there are branches
[21:16] <bluszcz> which are checkout locally and using it as i write above (locally make commit for remote branches)
[21:17] <bluszcz> generally at this time, i am not interested in any wide system/multi user solution, only "wide" in my needs is that i want to run some plugins on the server during commiting to that branches, all branches.
[21:19] <bluszcz> (reading http://bazaar-vcs.org/ConfiguringBz)
[21:24] <bluszcz> i found also this:
[21:24] <bluszcz> https://lists.canonical.com/archives/bazaar/2008q3/044390.html
[21:27] <bluszcz> pre_change_branch_tip (Branch)
[21:29] <LarstiQ> bluszcz: does that get run on the smartserver?
[21:31] <mwhudson> jelmer: so what's new and sexy about bzr-git 0.3.0 ?
[21:33] <bluszcz> yeah
[21:34] <lifeless> moin
[21:35] <bluszcz> bzr: ERROR: Received bad protocol version marker: 'sage 3 (bzr 1.6)\n\x00\x00\x00\x1dd16:Sof'
[21:35] <bluszcz> lol
[21:35] <bluszcz> server: Bazaar (bzr) 1.14.1
[21:35] <bluszcz> local: $ bzr version
[21:35] <bluszcz> Bazaar (bzr) 1.14.1
[21:35] <bluszcz> so, wtf?
[21:35] <lifeless> bluszcz: its been mangled
[21:36] <lifeless> bluszcz: you have something outputting to stdout while you login to your machine, if you're using bzr+ssh
[21:36] <lifeless> that will also break sftp
[21:38] <bluszcz> stdout from my local?
[21:38] <lifeless> the server
[21:39] <lifeless> what protocol are you using?
[21:39] <bluszcz> yes, pluging is talking to me
[21:39] <bluszcz> bzr+ssh, ssh2
[21:39] <lifeless> ok, if you do "ssh host: echo"
[21:39] <lifeless> do you get anything shown ?
[21:39] <lifeless> sorry, get rid of the : there
[21:39] <bluszcz> bluszcz@atomic [(nie maj 10) 22:39]:~/projekty/blogi
[21:39] <bluszcz> $ ssh bzr-bluszcz echo
[21:39] <bluszcz> bluszcz@atomic [(nie maj 10) 22:39]:~/projekty/blogi
[21:39] <bluszcz> $
[21:40] <bluszcz> only \n
[21:40] <lifeless> ok that looks fnie
[21:40] <lifeless> *fine*
[21:40] <lifeless> must be something else
[21:40] <bluszcz> yes, i now
[21:40] <bluszcz> how can i pass -vvv for ssh in bzr+shs?
[21:40] <bluszcz> ssh
[21:40] <lifeless> if you have a plugin, which execs something and that writes to stdout, it can also interrupt a bzr session
[21:41] <lifeless> because the bzr protocol is writing to stdout
[21:41] <bluszcz> hm
[21:41] <bluszcz> so, i should use stderr?
[21:41] <lifeless> oh yes
[21:41] <bluszcz> to write information about "your commit message is empty?"
[21:41] <lifeless> in a plugin on the server?
[21:41] <bluszcz> btw, lifeless  - nice nick ;)
[21:42] <bluszcz> lifeless: yes, on the server
[21:44] <lifeless> one sec I'm looking up a bug for you
[21:44] <bluszcz> ok
[21:44] <bluszcz> it looks like working now
[21:45] <bluszcz> :)
[21:45] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/364908
[21:45] <lifeless> thats a closely related issue
[21:46] <lifeless> however, if your plugin is actually stopping the commit/push, you should probably just raise an exception -  except that won't get formatted well. hm time for another bug
[21:46] <bluszcz> yea
[21:47] <bluszcz> raise "You should check first you *py files, or die"
[21:49] <lifeless> if this is a pre-tip-change hook
[21:49] <lifeless> there is a specific exception for that you can raise
[21:49] <lifeless> which I think gets formatted nicely
[21:49] <lifeless> errors.TipChangeRejected
[21:51] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/374605
[21:51] <lifeless> just filed that for you
[21:53] <bluszcz> :)
[21:54] <bluszcz> Robert Collins 2 minutes ago Changed in bzr:
[21:54] <bluszcz> importance: 	Undecided → High
[21:54] <bluszcz> status: 	New → Confirmed
[21:54] <bluszcz> things really goes fast
[22:03] <bluszcz> ok, now i have to read how to read file liste
[22:46] <bluszcz> ech, it has only:         # (params) where params is a ChangeBranchTipParams with the members # (branch, old_revno, new_revno, old_revid, new_revid)
[22:46] <bluszcz> no way i suppose to check the commited files
[22:47] <mwhudson> is it possible that getting a dev6 branch over http would use very large amounts of RAM?
[22:48] <bluszcz> dev6?
[22:48] <bluszcz> user ram on which element? client or server?
[22:49] <mwhudson> bluszcz: the development6 format
[22:49] <bluszcz> "uses"
[22:49] <lifeless> mwhudson: if it is file a bug
[22:49] <lifeless> mwhudson: it might if transcoding
[22:49] <mwhudson> lifeless: ok, finding out now
[22:49] <mwhudson> lifeless: it really really shouldn't be doing that
[22:49] <mwhudson> but i guess i can find out
[22:51] <[tpd]> Hey folks, does anyone here use bazaar for website deployment?
[22:51] <mwhudson> [tpd]: some people do, and they find the bzr-upload plugin useful
[22:52] <[tpd]> Ah, is that a standard way of doing it? I'm new to vcs.
[22:55] <mwhudson> [tpd]: it's what the plugin is for
[22:56] <[tpd]> I understand that, but is this how it "should be done"?
[22:56] <mwhudson> i don't know of any better way
[23:31] <bluszcz> how is the best way to gest list of modified files using bzrlib.?
[23:31] <lifeless> in a commit?
[23:31] <bluszcz> si
[23:31] <lifeless> bzr st -c rev
[23:31] <lifeless> oh, bzrlib
[23:31] <bluszcz> si
[23:32] <lifeless> tree1, tree2 = bzrlib.repository.revision_trees([rev1, rev2])
[23:32] <lifeless> changes = tree2.iter_changes(tree1)
[23:32] <bluszcz> checking, thanx
[23:33] <bluszcz> no such revision_trees hm
[23:34] <lifeless> sorry
[23:34] <lifeless> I meant 'repository.revision_trees'
[23:34] <lifeless> where repository is a bzrlib.repository.Repository object
[23:34] <lifeless> if you have a branch its branch.repository
[23:34] <lifeless> if y ou have a working tree its wt.branch.repository
[23:34] <bluszcz> working tree is easiest i think


[05:45] <jugmac00> @wontfix[m]: Mabye this quick intro helps you to get started https://jugmac00.github.io/blog/just-enough-bazaar-to-be-dangerous/
[07:48] <surfzoid> hi
[07:48] <surfzoid> cjwatson: after so many test, i got a lot of source pkg in my ppa, is there away to delete them or do i need to delete recipe?
[07:59] <surfzoid> i find it! sorry for distrib
[13:19] <surfzoid> Buildlog is slow , so it become useless
[13:20] <surfzoid> we see a very litle part and refresh 2 or 3 time dring te bhild
[13:34] <cjwatson> That's https://bugs.launchpad.net/launchpad/+bug/1617809 (which I would love to fix, but it's quite a big project)
[13:34] -ubottu:#launchpad- Launchpad bug 1617809 in Launchpad itself "Show the full log during builds" [Low, Triaged]
[13:36] <surfzoid> cjwatson: well we could imagine keep this small size but refresh "in real time"
[13:36] <cjwatson> I can imagine lots of things :-)
[13:37] <cjwatson> But buildd-manager polls the builder for updates every 15 seconds at present, so there's no point in the web interface refreshing more frequently than that.
[13:39] <surfzoid> cjwatson: well there is more than 15 sec, you use tail -f or it is a sql db?
[13:41] <cjwatson> buildd-manager currently fetches the last 2KB of the build log from the builder and stores it in the Launchpad database.  We recognize this design isn't ideal, but it's a fair bit of work to change.
[13:41] <cjwatson> (When the build completes, it fetches the full log.)
[13:44] <surfzoid> cjwatson: i guess 2kb to increse network traficc?
[13:48] <surfzoid> cjwatson: about drop *.so, is the following workaround isn't too mutch dirty https://git.launchpad.net/~surfzoid/+git/QtVsPlayer/tree/debian/rules
[13:49] <cjwatson> It certainly doesn't seem like a good idea to attempt to fetch the entire build log from all of our hundreds of builders very frequently.  But mostly it's just an old design.
[13:49] <cjwatson> A workaround like that is certainly one I considered, though I thought it was too ugly to actively recommend to you
[13:50] <surfzoid> cjwatson: i'm agree you need only the display rea not the full log
[13:51] <surfzoid> cjwatson: now i don't understand ow to overwrite prefix of bild/install
[13:52] <surfzoid> **build
[13:52] <cjwatson> I'm sorry, I don't have time to help with that kind of detail
[13:52] <surfzoid> cjwatson: oki
[13:53] <cjwatson> Too busy trying to wrap my head around a tangled mess of service redeployments
[15:11] <surfzoid> is it possible to build aarch64 with launchpad?
[15:12] <cjwatson> yes, it's called arm64
[15:13] <surfzoid> cjwatson: it throught the control file or with somewhere in launchpad front end?
[15:19] <surfzoid> it  is through the control file or  somewhere in launchpad front end?
[15:29] <cjwatson> surfzoid: "Change details" on your PPA, look for the list of checkboxes under "Processors"
[15:29] <surfzoid> 👍


[21:23] <mup> Bug #1681278 opened: cmd cmd.go:129 Fetching Juju GUI 2.5.0 hangs up and fails <juju-core:New> <https://launchpad.net/bugs/1681278>
[23:05] <mup> Bug #1681278 changed: cmd cmd.go:129 Fetching Juju GUI 2.5.0 hangs up and fails <juju:New> <https://launchpad.net/bugs/1681278>
[23:41] <mup> Bug #1681287 opened: juju should retry failed update-status hooks <juju-core:New> <https://launchpad.net/bugs/1681287>
[23:48] <axw> babbageclunk: morning. do you have time for a small review? https://github.com/juju/juju/pull/7197
[23:54] <veebers> axw: the calender has babbageclunk as on leave today, so if he doesn't respond I don't think it's because he's being rude :-)
[23:54] <axw> veebers: doh, thanks :)
[23:59] <axw> anastasiamac: seeing as christian is out, can you please review ^^ if you have time


[05:43] <openstackgerrit> Nate House proposed stackforge/cloud-init: [WIP] Updating openstack.base to support configdrive inheritance  https://review.openstack.org/225465
[05:43] <openstackgerrit> Nate House proposed stackforge/cloud-init: Removed buffer return from http source vendor data  https://review.openstack.org/229246
[13:51] <natorious> morning!
[13:54] <smoser> good morning natorious
[13:56] <natorious> hopefully I did that patch right ^^.  Didn't see anything else mentioned to directly address.  I'd fixed that spelling thing via amend.
[13:56] <claudiupopa> hey folks.
[13:56] <claudiupopa> Are we doing a meeting today?
[13:56] <smoser> yes.
[13:57] <natorious> got a ways on configdrive and was looking at doing that as a separate request for that and it'd make it read a whole lot better w/ that in etc.
[13:58] <openstackgerrit> Merged stackforge/cloud-init: LICENSE: correct wording with respect to Apache 2  https://review.openstack.org/228471
[13:59] <natorious> was planning a separate request for network json config too.  Feel free to correct me if I'm going about things wrong or backwards
[13:59] <natorious> hi claudiupopa o/
[14:00] <claudiupopa> Hi natorious \o!
[14:00] <smoser> hey.
[14:00] <claudiupopa> so irc or hangouts?
[14:00] <smoser> irc i think for now.
[14:01] <smoser> ok. so well walk over list of reviews quickly, and then open discussion and we can talk to natorious some there on his questions.
[14:01] <smoser> https://review.openstack.org/#/q/project:stackforge/cloud-init+status:open,n,z
[14:01] <smoser> i just accepted a license file change.
[14:01] <smoser>  https://review.openstack.org/#/c/228471/
[14:02] <smoser> the change was to make the LICENSE file not self contradictory.
[14:02] <smoser>  https://review.openstack.org/#/c/228471/1/LICENSE
[14:02] <claudiupopa> I'm not a lawyer, but looks good to me. ;-)
[14:02] <smoser> as previously it basically said "if you want to offer as apache 2.0 only, then put the GPLv3 header above"
[14:03] <smoser> which doens't make sense :). now its says
[14:03] <jgrimm> +1
[14:03] <openstackgerrit> Nate House proposed stackforge/cloud-init: [WIP] Updating openstack.base to support configdrive inheritance  https://review.openstack.org/225465
[14:03] <smoser>  "if you want to offer as apache 2.0 only, then put apache header above"
[14:03] <smoser> thansk to jgrimm for that.
[14:04] <smoser> i think reasonably thats all we have for the reviews. i think we should just help natorious a bit, with his questions and then we should try to get moving.
[14:04] <smoser> i have a couple topics for open discussion
[14:05] <smoser> is that ok? (i'm not skipping the reviews, i do want to talk about them, but i dont think they're jsut "quick")
[14:05] <smoser> Odd_Bloke, you here ?
[14:05] <claudiupopa> Sure, let's go with open discussion then and see where natorious can use our help.
[14:05] <Odd_Bloke> o/
[14:05] <smoser> k
[14:05] <smoser> heres hwat i had foro open discussion topics
[14:05] <smoser>  * python2.6 support: shall we bother with this?
[14:05] <smoser>     + need someone to look at viability of 2.7 on rhel 6.
[14:06] <smoser> the primary immediate driver of this is desire of using taskflow.
[14:06] <smoser> but generally.. if we can do without 2.6, that might be nice.
[14:07] <smoser> the goal would be to have *some* solution for running this on rhel 6
[14:07] <claudiupopa> It would be nice to not need it, yes, but it depends after all on your supported platforms.
[14:07] <smoser> and probably some sles, but i'm not so familiar with sles family of products.
[14:07] <claudiupopa> so the problem is rhel 6?
[14:07] <smoser> well, and probably some sles.
[14:07] <claudiupopa> when it's scheduled for EOL?
[14:08] <Odd_Bloke> The heat death of the universe (which will largely be caused by people having to maintain software for RHEL 6). :p
[14:08] <Odd_Bloke> Wikipedia says 2020.
[14:08] <natorious> they have a 10 year cycle :/
[14:08] <claudiupopa> in the same year as python 2.7
[14:09] <claudiupopa> not a coincidence.
[14:09] <Odd_Bloke> More, if we want to cover their extended lifecycle support. :p
[14:09] <smoser> i'm very  much ok to say "supported with python2.7 on rhel 6" if there is some sane path to getting python 2.7 on rhel 6.
[14:09] <smoser> but not if that path includes "go to some dude's web site" or "download python2.6 and compile"
[14:09] <smoser> ie, i'd accept 'enable EPEL'
[14:11] <Odd_Bloke> Is there going to be a path to installing cloud-init 2.0 on RHEL6 that fits your criteria?
[14:11] <smoser> thats what i want to know. i'd like someone to dig on that a bit.
[14:12] <smoser> smatzek, might know. also might have info on sles
[14:13] <natorious> what about pinning taskflow to before the 2.7 dep change?
[14:13] <claudiupopa> that doesn't sound that good.
[14:13] <claudiupopa> And if I'm not mistaken, the problem is with a dependency of taskflow.
[14:13] <smoser> well, apparently taskflow isn't itself 2.7 only.
[14:13] <smoser> right.
[14:14] <smoser> but generally speaking if we can say "no 2.6" then that woudl make life easier.
[14:14] <smoser> so i'm looking ofr a way, and a sane path for that.
[14:14] <smoser> i kond of hoped someone woudl take this and run with it.
[14:14] <smoser> i guess i can do that a bit after meeting
[14:15] <smoser> ok. so next topic, then.
[14:15] <claudiupopa> Btw, let's use trello for this as well.
[14:15] <smatzek> I would have the same criteria as smoser, if there is a sane path to getting 2.7 on rhel 6.  I don't have info on if there is a sane path for that or not.  I don't have the "python version included with" info for SLES 11 or 12 but could dig it up without much trouble.
[14:15] <smoser> claudiupopa, good idea.
[14:15] <smoser> claudiupopa, you want to add a task and give it to me ?
[14:15] <claudiupopa> yep.
[14:15] <smoser> smatzek, ok. you can help me :). thanks for offering.
[14:16] <smoser> google doesn't seem to know about assane path to 2.6 that does not include "people.readhat.com/some-dude" (yes, thats better than some.dude.com, but...)
[14:16] <smoser> anyway..
[14:16] <Odd_Bloke> That's because you have to be insane to still be running RHEL6. :p
[14:16] <natorious> we could make a rhel/cent rpm for alt installing python2.7 that would work though
[14:17] <smoser> natorious, as in smoser maintain python2.7 on rhel ?
[14:17] <smatzek> I still like Odd_Bloke's suggestion from several weeks past that those who bundle / ship python 2.6 after its EOL be made to sit in a corner and think about what they've done.
[14:17] <smoser> smoser == some-dude-i-wouldn't-trust
[14:17] <natorious> iir it can't replace the python2.6 due to yum or some such
[14:18] <smoser> natorious, yeah, python2.7 would be the name installed. i'd never expect that /usr/bin/python would be 2.7.
[14:18] <smatzek> maybe we just hande RHEL 6 and those other OS levels on 2.6 out to dry with cloud-init 2.0 and if those distros really want it, they get python 2.7, on their distro.
[14:18] <smoser> but i really dont want to maintain pytthon package.
[14:18] <smoser> smoser, that is how i am leaning
[14:18] <smatzek> hande = =hang
[14:19] <smoser> ok.
[14:19] <smoser> lets move on.
[14:20] <smoser> actually one more thing here.
[14:20] <Odd_Bloke> Well, they could also maintain distro patches for taskflow/networkx/cloud-init 2.0 which would make it work on Python 2.6; the point is it's their problem. :p
[14:20] <smoser> please everyone here just join cloud-init mailing list . https://launchpad.net/~cloud-init
[14:21] <smoser> and i'll use that list to write to.
[14:21] <smoser> k?
[14:21] <Odd_Bloke> Done.
[14:21] <smoser> smatzek, natorious claudiupopa you are all actioned to join that :)
[14:21] <smoser> ok. natorious now lets move on.
[14:22] <smoser> you want to ask some questions to the channel ?
[14:22] <natorious> yeah, sure
[14:22] <natorious> so configdrive
[14:22] <natorious> do we want to support v1 and v2?
[14:22] <claudiupopa> done.
[14:23] <natorious> are the only differences vfat vs iso
[14:24] <smoser> i really dont care about v1.
[14:24] <claudiupopa> What's the difference between v1 and v2? We're also interested in vfat for cloudbaseinit for instance.
[14:24] <smoser> it was pretty bad i think
[14:24] <smoser> and i think that v2 has been in place for probably 2 years ?
[14:24] <smoser> https://review.openstack.org/#/c/11184/
[14:25] <smoser> s/2/3/
[14:25] <smoser> no one other than possibly natorious's employer is running a 3 year old openstack cloud :)
[14:25] <natorious> burn
[14:25] <natorious> -.-
[14:26] <smoser> natorious, do you have a need to support config drive v1 ?
[14:26] <smoser> i'm reallynot terribly opposed to it.
[14:26] <smoser> but it woudl not land high on my priority list
[14:26] <natorious> I somewhat feel like most of the detection can be refactored down to detect umounted blockdevs searching f iso9660 and vfat fs w/ the same dir structure
[14:26] <smatzek> anyone have links to a spec or other doc that describes v1 and v2?
[14:26] <smoser> well, we dont want to assume 'unmounted'
[14:26] <natorious> k
[14:26] <smoser> really we want to look for the filesystem label
[14:27] <natorious> k, that might make it even easier
[14:27] <smoser> that seems to me to be the biggest thing.
[14:27] <smoser> it would seem to me to be a low possibility of non-desired false positive if you found a drive with a label 'config-v2'
[14:27] <smoser> s/drive/drive or partition/
[14:28] <smoser> ie, if someone put something like that... they probably did it so you would find it.
[14:28] <smoser> now... obviously such a person could be malicious
[14:28] <natorious> are we still doing an on first boot hook?
[14:28] <smoser> thats a good question
[14:28] <natorious> didn't see any examples of that in the http ds
[14:29] <smoser> cloud-init 0.7 basically always searches for a datasource.
[14:29] <smoser> (on every boot)
[14:29] <smoser> unles the  user sets 'manual_cache_clean' or some such
[14:29] <smoser> the reason for that is so that it can detect "new instance".
[14:29] <smoser> so that the user who does:
[14:29] <smoser>   * boot instance
[14:30] <smoser>  * install a package
[14:30] <smoser>  * shutdown and snapshot
[14:30] <smoser> doesn't have to also do: 'run cloud-init clean'
[14:30] <natorious> right
[14:30] <smoser> now that search is painful
[14:30] <smoser> in many ways.
[14:31] <natorious> its also ordered and limited by the datasources defined config right?
[14:31] <smoser> as for config drive, it means that if you messed up the label, then the instance would get all foobarred.
[14:31] <smoser> right.
[14:32] <smoser> we could possibly take a position that we do a quick check to see 'is this a new instance'
[14:32] <smoser> and only go looking further if that quick check failed
[14:32] <smoser> and if that quick check was buggy in that it did not recognize a new instance when it should have, we tell the user 'well, run "clean"'
[14:33] <smoser> i'm open to ideas here, and i dont knwo what a good "quick check" is.
[14:33] <smoser> i suspect that a lot of people do something like the above
[14:33] <Odd_Bloke> BTW, on Python 2.7 in RHEL6: https://twitter.com/ncoghlan_dev/status/649228375135903744
[14:33] <smoser> so that probably needs to generally work
[14:33] <smoser> Odd_Bloke, scl that references http://people.redhat.com
[14:34] <Odd_Bloke> I found this: https://www.softwarecollections.org/en/scls/rhscl/python27/
[14:34] <smoser> natorious, you ahve thoguths on that ?
[14:34] <smoser> i'd like to not have to search every boot
[14:34] <natorious> stuck on quick check.  So if the instance is new but from a snap
[14:34] <natorious> it could have previous instance data in it
[14:35] <smoser> right.
[14:35] <smatzek> I don't think there is a "quick check".  I think the only real check you can make is to query datasources and get the instance ID from them to compare with ID on disk.
[14:35] <natorious> instance uuid is sourced from ds so we couldn't use that to determine caching of ds method
[14:35] <smoser> well, there might be a heuristic that is sane.
[14:36] <smoser> similar to what MS does / did when you bought a new hard drive and you had to call their customer support to allow you to run windows again.
[14:36] <natorious> there's also hw identifiers that can be used no?
[14:37] <smoser> ie some look at the system (hard drive ids, cpu number ... might be a suffiicent quick check)
[14:37] <natorious> so like tie an instance id data to hw identifiers somehow
[14:37] <natorious> yeh
[14:37] <smatzek> checking hw identifiers doesn't work because you could have done a cold VM migration.
[14:37] <smatzek> or live followed by a reboot.
[14:38] <smoser> in which case the 'quick check' said "looks like it changed".
[14:38] <smoser> so we'd just do a longer check.
[14:38] <smoser> and if thats annoying to the user, then can still manually set "manual clean" or something.
[14:38] <smoser> you see what i mean ?
[14:39] <natorious> live migrate wouldn't hit cloud-init until a new reboot too
[14:39] <smatzek> I've struggled with these checks to see if you're a new instance for several years with both cloud-init and non-cloud-init based VM activation.  I've found that cloud-init has the best way to check, with instance ID.
[14:39] <smoser> well, and live migrate would surely have the same (virtual) hard drive id
[14:39] <natorious> so processing the ds detection and determining the same instance uuid should keep things going still
[14:39] <smoser> right.
[14:39] <smatzek> a quick check to see if HW changed would not trigger a deeper check if you too a VM snapshot and created a new VM using the snap on the same physical hardware.
[14:40] <smoser> smatzek, correct.
[14:40] <smoser> in which case, a user there would have to tell cluod-init that it should check every time.
[14:40] <smoser> i dont knwo how i feel about it.
[14:42] <smatzek> if we had a setting like that users would have to flip it on if they plan to snap and deploy snaps.  Also, wouldn't a hardware quick check require some hardware info in the base image for the public images you create?  I suppose you could put bogus hw info in there so as not to disclose the actual HW you're creating them on.
[14:42] <smoser> smatzek, well,. to be fair, on a sane cloud.. if you did that, and your new isntance landed on the same "host".
[14:42] <smoser> (or similarly configured host)
[14:42] <smoser> you'd still hope that you'd prvide new "hard drive" serial number to the virtual disk.
[14:42] <smoser> i guess if in fact you'd  handed the guest the same physical disk..
[14:43] <smoser> smatzek, well on the offical published images, we'd clean whatever data is tehre.
[14:43] <smoser> but the ubuntu image build process never invokes cloud-init
[14:43] <claudiupopa> what about windows?
[14:44] <natorious> there could be instances that use vdi chains for image caching who share a common base
[14:44] <smoser> claudiupopa, thats why you're here :)
[14:44] <natorious> but I think the vdi snaps have unique sn's
[14:44] <claudiupopa> First of all, I don't think I know what's HW. :-)
[14:45] <smoser> i'd think they would, natorious . but you're right, they dont necessarily. but you'd think it would be desireable.
[14:46] <smoser> ok..
[14:46] <smoser> so lets say this:
[14:46] <smoser>  * cloud-init should have a cleanly documented way to explicitly disable or explicitly enable per-boot checking for instance id
[14:47] <smoser>  * cloud-init may provide a "auto" mode for that that does some heuristics based checking or other quick checking
[14:48] <smoser>    the auto mode shoudl generally be *very* quick and not be skewed to not have false negatives (when it missed a change that it should have seen)
[14:48] <smoser> does that seem sane ?
[14:48] <natorious> * cloud-init cares not re v1 configdrive
[14:49] <smoser> unless natorious makes it care, which is ok
[14:49] <natorious> yea
[14:49] <smoser> one example i'd like to give of a very sane and quick check would be on lxd.
[14:49] <smoser> lxd will expose its datasource via a socket /dev/lxd.  it seems a sane "quick check" to do the unix-socket query 'get-instance-id' if /dev/lxd is present.
[14:50] <smoser> that suggests that the quick check should have access to the datasource that was used last... so that it woudl know it was lxd, and if previous was lxd and there is no /dev/lxd, then probably a change occurred.
[14:50] <natorious> interesting, I'd have to look into that and see about setting up a test env too
[14:51] <natorious> being socket I take it means not listed under block devs
[14:51] <smoser> yeah. its just a unix socket that lxd exposes an api on from outside.
[14:52] <smoser> i think that vmware has a similar thing.
[14:52] <smoser> did you have other question, natorious ?
[14:52] <natorious> think thats it
[14:54] <natorious> got what I need to get another request in.  its going to depend on the previous but should be alright
[14:56] <smoser> natorious, cool
[14:58] <smoser> claudiupopa, you going to stick around for a while ?
[14:58] <smoser> or are you EOD
[14:58] <claudiupopa> I'll be here for some time.
[14:59] <smoser> ok. i'll ping in a bit
[21:01] <stanguturi> Hi, I am working on cloud-init 0.7.6. I was able to execute './packages/bddeb' command and successfully build the debian package. I installed the final debian package in Ubuntu machine. Can anyone provide some instructions to test the changes. I mean, are there any log files which say that the package has been run, etc.
[21:22] <natorious> hi stanguturi!
[21:22] <natorious> cloud-init --version should print out the installed version
[21:22] <stanguturi> hi natorious
[21:22] <natorious> if your looking for some specific source change you made prior to building the pkg
[21:22] <natorious> you can check the installed source too
[21:23] <natorious> typically in /usr/lib64/pythonX.X/site-packages/cloudinit etc
[21:23] <natorious> X.X being 2.7 or 3.4 and whatnot etc
[21:24] <natorious> depending on the targetted init system specified when building the pkg would depend on where what init scripts or service files get installed too
[21:24] <stanguturi> great. Wher are the log messages that get printed when the cloud-init runs on machine boot
[21:24] <natorious> but like if its not running on boot, perhaps you targetted the incorrect init sys for your distro version
[21:25] <natorious>  /var/log/cloud-init.log or /var/log/cloud-init-output.log
[21:25] <natorious> one of the previous versions had a thing where most log msgs would go to syslog though
[21:27] <natorious> to change that you can comment the log line in /etc/cloud/cloud.cfg.d/05_logging.cfg for it
[21:27] <stanguturi> :x
[21:27] <natorious> like # - [ *log_base, *log_syslog ]
[21:27] <natorious> leaving  - [ *log_base, *log_file ] uncommented etc
[21:28] <natorious> might not be an issue for you.  Thought worthy of a mention though
[21:30] <stanguturi> ok. What is the best approach to test the changes. I am thinking of following 'make changes, build deb, install deb and reboot'.. Is there any other simple way to test the changes/
[21:32] <stanguturi> :x
[21:39] <natorious> what init system are you using?
[21:40] <natorious> after making the change and reinstalling, rm your /var/lib/cloud dir and it'll be like its bran new etc
[21:40] <natorious> don't think you necessarily need to reboot either
[21:41] <natorious> you could probably just fire off the init scripts again


[02:10] <jamesh_> Hey all my wife is loving her new lubuntu installation but is wondering how to change the default font size. Any ideas?
[02:32] <ubuntu> &nickserv identify help
[02:32] <ubuntu> %help
[02:32] <ubuntu> !help
[02:34] <zoomix> how do i resize a partition with disk utility
[05:18] <kaatta> hi, i have installed xcompmgr... now im wondering how to set it up to make my conky and my dock work properly w/out a large black block around the aps
[06:57] <troytop> gotta love live CDs - on IRC and the web *while* installing
[06:58] <MrChrisDruif> Great troytop :)
[07:02] <troytop> we'll see if lubuntu succeeds where ubuntu netbook and edubuntu failed (problem with Unity methinks)
[07:02] <bioterror> troytop, I can live 20mins without them :D
[07:03] <bioterror> I have time to clean kitchen or something else (I'm just lying :)
[16:03] <linuxman410> when i install lubuntu 10.04 resolution works on my video when i upgrade to lubuntu 10.10 resolution quits working
[18:27] <walraven_> exit
[18:27] <walraven_> bye
[18:27] <walraven_> quit
[20:52] <kosaidpo|> hello guys
[20:52] <kosaidpo|> i wanna get ride of my windows how can i do that
[20:53] <kosaidpo|> can i use gparted to resize the partition n thats all ?
[20:53] <Unit193> Resize your main partition to full size
[20:53] <Unit193> You may need to update grub too!
[20:54] <kosaidpo|> Unit193: without any need of the lubuntu cd ??
[20:55] <Unit193> !partition
[20:55] <Unit193> kosaidpo|: I don't remember if you can update the partition if it's mounted...
[22:17] <bonny> how can i make it automatic login