[00:13] <jelmer> mwhudson: hey
[00:13] <jelmer> mwhudson: yep (-:
[02:37] <wgrant> Is there a way to invoke the 'bzr up' with local commits semantics without being bound?
[02:38] <wgrant> ie. pull trunk and merge your current branch into it, in the one branch.
[02:43] <Peng> I'm sure you could do something involving "bzr log -r -1 --show-ids", "bzr pull --overwrite" and "bzr merge . -r revid:...", but...
[02:44] <wgrant> Right, that's what it would have to do.
[02:44] <idnar> bzr rebase?
[02:44] <idnar> maybe not
[02:44] <james_w> wgrant: I often want the same thing, but haven't wanted it enough to write the plugin to do it yet
[02:46] <wgrant> It'd be a trivial plugin, but it would be nice to have it easily available for everyone. Since Git people tend to do the 'merge trunk into branch, push branch over trunk' thing, because AIUI git parents are unordered.
[02:47] <wgrant> And it would be nice to have a very similar bzr workflow which works unbound, and doesn't replace the mainline history.
[03:11] <NfNitLoop> wgrant: Yeah, I do that workflow, but I do it by always having a clean mirror of upstream handy to merge onto.
[03:12] <wgrant> So do I.
[03:12] <wgrant> But others don't like that requirement.
[03:24] <jelmer> wgrant: git parents are ordered
[03:25] <jelmer> wgrant: that'd be roughly equivalent to just bzr merge .../trunk  && bzr ci -m "Merge trunk" && bzr push .../trunk, no?
[03:31] <wgrant> jelmer: But that changes the LHS history.
[03:32] <wgrant> If I bzr up on a bound branch, trunk's tip replaces mine, and my local commits show up as a pending merg.re
[03:40] <Kraln> So I have a crazy question. Why does a 150 line change cause more than 360mb of transfer? (repacking texts)
[03:40] <Kraln> (- 371561KB   114KB/s | Fetching revisions:Inserting stream:repacking texts:texts 6235/7200)
[03:44] <jelmer> wgrant: it also changes the LHS history in Git, except Git folks don't seem to care about LHS history..
[03:44] <jelmer> Kraln: it would only take so much data every so often (bzr was repacking your repository apparnetly)
[03:44] <Kraln> this was a tiny commit!
[03:45] <Kraln> it's up to 400mb of transfer for 100 lines of changes, if that
[03:45] <wgrant> jelmer: Ah, I see.
[03:46] <jelmer> Kraln: Repacking happens every X commits or so
[03:46] <Kraln> can I disable that? this is a *large* repo
[03:46] <jelmer> Kraln: another 100line change right now won't require that much data to be transferred
[03:46] <jelmer> Kraln I think you can disable it but it'll slow down your repository access in the long run
[03:47] <Kraln> 400mb of transfer on a dsl line means it's been hours to make this commit
[03:47] <jelmer> Kraln: an alternative is to use the smart server rather than sftp, in which case the repacking will happen on the server side
[03:47] <Kraln> how do I set that up?
[03:47] <jelmer> use bzr+ssh rather than sftp
[03:47] <Kraln> that's it?
[03:47] <jelmer> Kraln: I think so
[03:47] <wgrant> As long as you have a recent bzr on the server.
[03:47] <Kraln> it's 2.1 or whatever
[03:47] <jelmer> wgrant: that said, I'm sure we'd welcome a patch to use the merge revision as the first parent rather than the previous local head
[03:48] <wgrant> jelmer: Oh, so we could just switch the parents at commit time?
[03:50] <jelmer> wgrant: yeah
[03:50] <wgrant> jelmer: True. That sounds much easier.
[03:51] <Kraln> http://dpb.pastebin.com/LaiDv5U1
[03:53] <Kraln> :|
[03:54] <Kraln> hmm, the folder on the server is empty
[03:55] <Kraln> not feeling too peachy-keen happy with bzr at the moment
[03:59] <NfNitLoop> try pushing with just sftp?
[04:12] <mgiuca> Hello,
[04:12] <mgiuca> wgrant just sent me a recent chat snippet from here, about replacing the LHS history with bzr merge / push
[04:12] <mgiuca> Versus Git.
[04:13] <wgrant> Hi mgiuca.
[04:13] <mgiuca> "< jelmer> wgrant: it also changes the LHS history in Git, except Git folks don't seem to care about LHS history.."
[04:13] <mgiuca> I didn't know Git had LHS history at all.
[04:15] <mgiuca> Just thinking that in Bzr, if you have a local mirror of a branch, which has diverged, there's no simple way to 1. Merge, then 2. Push your changes up to the branch (eg on Launchpad) without reordering the LHS history on Launchpad.
[04:15] <mgiuca> Except if you were bound, you could do an update.
[04:16] <mgiuca> Maybe wgrant already discussed this before.
[14:37] <A4Tech> All greetings. A bit strange question: I can host on the local machine to deploy the system bzr only without web?
[18:18] <bendj> Hi.  I'm trying to get my head around repos-in-repos ...  Iiuc, I can pull an external branch into my local repo, e.g.: bzr init myrepo; bzr branch myrepo/extrepo.
[18:18] <bendj> Am i then supposed to 'ignore' the extrepo dir, managing it separately?
[18:20] <Kilroo> That sounds like it would work, but I've never done it.
[18:21] <Kilroo> Inside the extrepo directory it will find the extrepo/.bzr directory first and go by that, and outside that directory it's been told to ignore it so it doesn't care that it's there.
[18:24] <bendj> Kilroo: Ok, sounds reasonable.  Now, can it be further extended to 'nest' another branch under /myrepo/extrepo/YArepo, and manage *it* from the top/parent, myrepo?  I'm pretty sure I'm confused by this ;-)
[18:24] <bendj> Kilroo:  More context might help ... what I'm trying to do it this -> https://lists.ubuntu.com/archives/bazaar/2010q1/067904.html
[18:24] <bendj> Has to do with, eventually, managing/staging Drupal sites ...
[18:25] <bendj> Kilroo: I suspect that I maybe approaching this wrong in the first place :-/
[18:25] <Kilroo> Ah.
[18:25] <Kilroo> Step 1: avoid Drupal.
[18:25] <bendj> :-p
[18:25] <Kilroo> That's just my personal experience.
[18:25] <bendj> Kilroo: Actually, I'm using Pressflow ... that anybetter?
[18:25] <Kilroo> No idea.
[18:26] <bendj> Kilroo: Fair enough.  Ignore that fact, then ....back to the bzr question :-)
[18:26] <Kilroo> right, reading
[18:26] <bendj> hehe ...
[18:26] <Kilroo> item the first: I think it's .bzrignore, you seem to have omitted the r
[18:27] <Kilroo> not sure I've ever ignored anything without doing it through bzreclipse though so I may be wrong
[18:28] <Kilroo> Ah.
[18:28] <bendj> Kilroo: sure, just a typo on my part for the post ... good catch
[18:28] <Kilroo> I'm pretty sure the answer is no.
[18:30] <Kilroo> I am not sure what would happen if you explicitly said to bzr add core/data/test.txt from /repos/site, but I'm fairly certain that once you've ignored core from in site, it never bothers to look at core or anything in it unless you specifically tell it otherwise.
[18:30] <Kilroo> I guess I'd just test it, if I were you.
[18:31] <bendj> Kilroo: Sound reasonable, too. So, likely that /myrepo/extrepo/YArepo would have to be 'bzr init'-ed as it's OWN standalon repo, and managed separately?
[18:34] <Kilroo> I honestly don't know. You're beyond my level of experience here. I haven't ever needed to deal with a nested repository or a nested tree or anything...I usually have something along the lines of /foo/bar as a no-trees shared repository, containing /foor/bar/trunk and /foo/bar/feature/{baz,wiz,woz}
[18:34] <Kilroo> and then /foo/checkouts/bar, which I switch among the relevant branches
[18:36] <bendj> Kilroo: Thanks, then. This all mostly (made) sense to me, until I was faced with this nesting bit ... then got a bit murky.  Like you said, testing/monkeying probably a good-thing.
[18:36] <Kilroo> Good luck.
[18:39] <bendj> ta!
[20:51] <mwhudson> hazmat: yay for https://code.edge.launchpad.net/~hazmat/loggerhead/speed-rules
[20:59] <rniamo> hi
[21:00] <rniamo> is there a web interface for bzr which is better than loggerhead and lighter than redmine or trac ?
[21:00] <rniamo> (better = you can download folder for example and having color syntax)
[21:01] <mwhudson> rniamo: loggerhead has coloured syntax if you have pygments installed
[21:01] <mwhudson> and there's a patch for downloading a folder somewhere i think
[21:01] <rniamo> mwhudson : ok ill try, thanks,
[21:01] <rniamo> i didn't succeed to install the patch correctly
[21:01] <mwhudson> ah :/
[21:02] <rniamo> when i click on download i had an error, something like loggerhead/static/projectxxx.tgz doesn't exist
[21:04] <Peng> ..../static/? That sounds totally wrong.
[21:04] <rniamo> mwhudson : i've installed pigments and i have no coloured syntax, where should i have to active it ?
[21:05] <rniamo> Peng : yes, totally but i merge manually so i can have forgotten something. I installed loggerhead from ubuntu packages
[21:06] <Peng> rniamo: You don't have to activate it. Um, what version of Loggerhead?
[21:07] <rniamo> Peng : 1.17
[21:08] <Peng> Yeah, that should support it.
[21:08] <rniamo> :(
[21:09] <rniamo> do i have to set language somewhere ?
[21:11] <Peng> It auto-detects it, which usually succeeds, unless the file is non-tiny, but the alternative would be risking exponential runtime by Pygments, so...
[21:15] <rniamo> Peng : ok, coloured syntax is ok, maybe the file was too tiny
[21:15] <rniamo> or maybe i had to restart loggerhead
[21:15] <rniamo> is there a simple solution to download a folder as tar/zip or anything else from loggerhead ?
[21:27] <rniamo> how to install the "download" patch on loggerhead ?
[21:32] <rniamo> i have this erreor when i want to install the download as tar patch : http://www.friendpaste.com/28UailBMDogGgC6q9AHuFm
[21:32] <Peng> rniamo: Yes, you had to restart Loggerhead.
[21:32] <rniamo> Peng : it's ok for coloured syntax, thanks
[23:18] <jelmer> how do I recursively ignore everything under a directory?
[23:18] <mwhudson> jelmer: hello
[23:21] <Meths> Something like this I believe: 'bzr ignore "dir/**/*"'
[23:23] <jelmer> mwhudson: moin
[23:24] <mwhudson> jelmer: some interesting seeming bzr-git commits over the weekend :)
[23:24] <mwhudson> jelmer: did you basically drop the trees table from the git.db file?
[23:24] <jelmer> mwhudson: yeah
[23:25] <mwhudson> (bah)
[23:25] <mwhudson> jelmer: cool
[23:25] <mwhudson> jelmer: have you tested it with the kernel?
[23:25] <jelmer> mwhudson: not yet, there's still some issues to work out
[23:25] <mwhudson> jelmer: what's the migration plan?  is the file still called 'git.db'?
[23:25] <mwhudson> ah ok
[23:25] <mwhudson> i guess we shouldn't try to sneak a bzr-git update into the next launchpad release then :)
[23:26] <mwhudson> grr^2
[23:26] <jelmer> mwhudson: the file is still called git.db, but I've also worked on a BTreeIndex-based map
[23:26] <jelmer> which is significantly faster
[23:27] <mwhudson> jelmer: ah ok
[23:43] <jelmer> mwhudson: do you know the pydoctor maintainer for Debian/Ubuntu?
[23:43] <jelmer> it seems it's out of date for python2.6..
[23:49] <mwhudson> jelmer: no
[23:49] <mwhudson> i guess i could make a release or something and try and sneak that into lucid
[23:50] <jelmer> mwhudson: that'd be great
[23:54] <mwhudson> jelmer: can you upload it to debian, or do we need to try to find the maintainer?
[23:55] <jelmer> mwhudson: we need to find the maintainer, but it seems it's team maintained and I know the maintainer who's done most of the uploads so far
[23:56] <jelmer> mwhudson: if you can get a proper release out I'd be happy to take care of getting it packaged and into debian
[23:56] <mwhudson> jelmer: http://people.canonical.com/~mwh/pydoctor-0.3.tgz ?
[23:56] <mwhudson> -?
[23:57] <mwhudson> sha1 5fb79e1d84cc729e5731ff5a69275e5087b3e59c fwiw
[23:57] <Tak> is there a quick way to determine at what bzr version a method got added? (specifically diff.get_trees_and_branches_to_diff)
[23:57] <jelmer> mwhudson: wow, that was quick :-)
[23:58] <Tak> also, is anyone seeing issues using bzr with python2.6? (I'm seeing what appears to be filehandle leaks)
[23:58] <mwhudson> sdist doesn't take too long


[06:57] <DanaG> http://pastebin.com/BFjBG4Ms
[06:57] <DanaG> vlc segfaults.
[06:59] <DanaG> er, sorry for the long command line. =þ
[07:00] <DanaG> interesting... mplayer is UNAVAILABLE
[07:07] <DanaG> alsaplayer works, though.  once I add myself to "audio" group.
[09:10] <asac> hi folks
[09:13]  * ogra gets more coffee
[09:13] <ogra> morning asac
[09:14] <ogra> grmbl ... /me curses having to port uboot patches to redboot ...
[09:26] <ogra> heh, fun ... the change i should revert in redboot-imx doesnt seem to exist in our version at all
[09:30] <asac> hi ogra
[09:34] <nosse1> My company are about to make a product based on TI AM3517 (ARM Cortex-A8) and we're going to run linux. We are considering putting Debian or Ubuntu on it because we want a package system/distro.
[09:35] <nosse1> I forgot to say that I have a TI AM3517 ZOOM development kit
[09:38] <nosse1> I have to admit that I'm quite new to Ubuntu build-system, so you'll have to excuse me for stuptid questions
[09:40] <amitk> nosse1: welcome
[09:40] <nosse1> The first one is linked to the choice of distro: When I have a Cortex-A8, wouldn't it then be most efficient (space and cpu) to use binaries for ARMv7? Which would implicate Lucid right?
[09:40] <amitk> we've just started supporting OMAP3 kernels in the next release of Ubuntu
[09:41] <amitk> nosse1: Lucid is guilty as charged
[09:43] <nosse1> I started rootstock, and when it spawns qemu, it locks up my CPU at 100%. Is this familiar?
[09:44] <amitk> ogra <--- blame him
[09:45] <nosse1> I have no kind of feedback, so I don
[09:45] <nosse1> ...don't know if it has locked up or doing something sensible...
[09:46] <nosse1> (I'm running amd64 Karmic, and I've seen apps not working because I'm running 64-bit. Don't know if it's it, though)
[09:47] <amitk> no, i use rootstock on 64-bit successfully
[09:48] <nosse1> BTW: Are there a seed for ubuntu which is even more minimal than ubuntu-minimal? There's a lot of apps in minimal which is not applicable in my embedded target
[09:50] <asac> nosse1: yes, the CPU issue is known
[09:50] <asac> e.g. for qemu
[09:50] <asac> investigation ongoing
[09:50] <asac> seems its triggered by apt
[09:50] <asac> or rather dpkg somehow
[09:50] <nosse1> asac: But is it dead or processing something?
[09:51] <nosse1> asac: Can I cat into its output somewhere?
[09:52] <asac> nosse1: its dead. we think its qemu being broken
[09:52] <asac> ogra: why is the bug not filed against rootstock nor qemu-kvm?
[09:53] <nosse1> asac: Thanks
[09:54] <asac> its bug 532733
[09:54] <ubot4> Launchpad bug 532733 in qemu-kvm (Ubuntu) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 1)" [Medium,Incomplete] https://launchpad.net/bugs/532733
[09:54] <asac> nosse1: ^
[09:57] <nosse1> I running Karmic on my host. Would it (not for this specific thing, but generally) be better to run lucid?
[09:57] <asac> host system seems to make no difference afaict
[09:58] <asac> its lucid vm that causes this
[09:59] <nosse1> So when I'm using rootstock it also pulls down a lucid vm? I'm also pulling ubuntu-minimal and not ubuntu-netbook as noted in the bug report
[09:59] <asac> interesting
[09:59] <asac> but you are installing lucid?
[09:59] <nosse1> yes
[09:59] <asac> e.g. in the vm?
[09:59] <asac> i suspect this to be a racy thing
[09:59] <asac> the biggere the task is the more likely you hit it
[09:59] <asac> for us ubuntu-minimal works usually, but netbook triggeres this
[10:00] <asac> but i dontsee why ubuntu-minimal wouldnt cause this for some
[10:00] <nosse1> I can probably strace it, but I'll have to leave for a meeting first...
[10:00] <asac> what are your host specs?
[10:00] <asac> e.g. what system is this running on?
[10:00] <amitk> wouldn't it depend on the system specs too?
[10:00] <amitk> aah, exactly
[10:00] <nosse1> Ubuntu Karmic amd64
[10:00] <amitk> nosse1: your HW spec
[10:00] <asac> well. cpu mem etc.
[10:01] <asac> maybe also disk speed etc.
[10:01] <nosse1> Where can I find disk speed?
[10:02] <asac> hdparams?
[10:02] <asac> hdparm ;)
[10:02] <nosse1> Intel C2Duo T9900, 3.06GHz, 8Gb RAM, Disk: 101MB/sec
[10:02] <asac> well, but you could say: 5400 / 7200 / SSD etc.
[10:03] <nosse1> 7200 for my case
[10:03] <nosse1> I'm sorry, but I have to leave. I'll be back. Thanks guys
[10:03] <asac> yeah. so from our findings it did go away if you slow down the system, so maybe your system is faster than ours (at least than mine it is)
[10:04] <asac> so makes some sense that you see it earlier
[10:13] <asac> ogra: your instructions dont work
[10:13] <asac> e.g. the saved qemu image isnt good
[10:13] <asac> getting unable to mount rootfs
[10:13] <asac> sure root=/dev/sda?
[10:13] <asac> I: Mounting temporary Image
[10:13] <asac> I: ARM rootfs created as /tmp/qemu/armel-rootfs-201003181055.tgz
[10:13] <asac> I: Qemu image saved as /tmp/qemu/qemu-armel-201003181055.img
[10:14] <asac> i use that img
[10:14] <asac> ogra: ^^
[10:18] <asac> ok manually creating .img works it seems
[10:18] <asac> why is the kept img broken?
[10:24] <asac> hmm
[10:24] <asac> "When no option is specified QEMU uses a non privileged user mode network stack that gives the emulated machine access to the world. "
[10:24] <asac> that doesnt work for me
[10:24] <asac> ogra: ^^
[10:24] <asac> i can get an ip with dhclient
[10:24] <asac> but not ping out
[10:24] <asac> or wget
[10:25] <lool> asac: ping is special though
[10:25] <lool> asac: Which network type did you use?
[10:25] <lool> telnet should work
[10:25] <asac> lool: wget doesnt work
[10:25] <lool> that's bad
[10:26] <asac> next wanted to try a tap device
[10:26] <asac> but hoped i didnt need that
[10:26] <ogra> asac, what are the permissions of the img file (i havent uploaded the permission fix yet)
[10:26] <asac> let me run again
[10:26] <lool> asac: You don't
[10:26] <asac> ogra: permissions flag?
[10:26] <asac> what should be there?
[10:26] <asac> ogra: oh thats about rootfs not working?
[10:26] <lool> asac: ownership of the file needs to be the same as the user you're running the vm with
[10:26] <ogra> well, chown the img file
[10:26] <lool> and u+rw obviously
[10:26] <asac> right
[10:27] <asac> let me check
[10:27] <asac> but i could boot it now
[10:27] <ogra> the recent version saves the img as 666
[10:27] <asac> ls -l ubuntu-arm.img
[10:27] <asac> -rw-r--r-- 1 asac asac<PHONE_NUMBER> 2010-03-18 11:22 ubuntu-arm.img
[10:27] <ogra> that should work for the asac user at least
[10:27] <asac> ogra: it boots
[10:28] <asac> i doubt that permission has to do something with network
[10:28] <ogra> so what exactly doesnt work
[10:28] <asac> wget
[10:28] <asac> after running dhclient
[10:28] <asac> and getting ip ;)
[10:28] <ogra> sudo dhclient eth0 ;)
[10:28] <asac> apt-get update -> errors
[10:28] <asac> ogra: well. read two lines above
[10:28] <ogra> weird, works here
[10:28] <asac> let me check host iptables
[10:29] <lool> ogra: 666 uh
[10:29] <asac> all open
[10:29] <asac> 644
[10:29] <lool> ogra: I seriously hope it's not 666, that'd be a major security issue
[10:29] <asac> yeah. 666 seems overly open ;)
[10:29] <ogra> sigh
[10:29] <ogra> 644 *doesnt boot*
[10:29] <lool> 666 it is   :-(
[10:30] <ogra> and i have no way to make sure to know which user will use it in the end
[10:30] <lool> Of course you do
[10:30] <ogra> since you removed all references to run qemu with sudo
[10:30] <ogra> lool, how, there are many people that use rootstock with cron
[10:30] <asac> now network works ;)
[10:30] <ogra> for daily local builds
[10:30] <lool> ogra: I've been running qemu all this time without sudo; kees setup the same thing yesterday, and didn't use sudo either or had any permissions issues
[10:30]  * asac likes things going away ;)
[10:31] <ogra> lool, with a 644 img owned by root.root and no initramfs ?
[10:31] <asac> ogra: why not chown to the user that called rootstock?
[10:31] <asac> oh
[10:31] <ogra> that would be cron for people doing daily builds
[10:31] <asac> well, maybe rootstock should call sudo on its own to figure the real owner
[10:32] <lool> ogra: Why would you want to own it by root?
[10:32] <ogra> lool, because it was loop mounterd and created as root it gets the systems default permissions
[10:32] <ogra> wich is 644 for the creating user
[10:32] <lool> ogra: I personally create the image as myself, and sudo loop-mnt it
[10:32] <asac> there is SUDO_USER ... so yeah. not sure why its a problem
[10:32] <asac> you could add an option to command line for cron folks
[10:32] <lool> Well either use SUDO_USER or actually only call sudo when you need to
[10:33] <asac> so they can say: --image-user=USER
[10:33] <lool> that's what I typically do in my scripts; they work as root or non-root, and call sudo when needed
[10:33] <lool> (We actually already had this discussion)
[10:33]  * ogra goes for asac's suggestion
[10:33] <lool> asac: Let's have a cp --user option too!  :-)
[10:34] <ogra> though i would prefer a more general fix ...
[10:34] <lool> Anyway, I filed a bug on the usage of 666; please never do that
[10:34] <ogra> its only in bzr yet, not in the archive
[10:34] <lool> I filed a bug upstream
[10:34] <ogra> fine, still, its a dev tree
[10:42] <asac> it all depends on the common use case
[10:42] <asac> i think using SUDO_USER makes sense
[10:42] <asac> --image-user might make sense, but you can also write a wrapper script in cron that does that i would think
[10:43] <asac> hmm
[10:43] <asac> printf ... how do i just flush stdout?
[10:44]  * asac tries
[10:44] <asac> ok that worked ;)(
[10:44] <asac> fflush stdout
[10:44] <lool> Oh I thought you were asking in shell and was puzzled
[10:45] <asac> heh
[10:45] <asac> no
[10:48] <ogra> hmm
[10:48]  * ogra ponders how to package x-loader
[10:49] <ogra> it sadly needs a fully configured uboot tree since the headers it relies on are generated by uboot configuration :/
[10:50] <asac> punch it into uboot? ;)
[10:50] <asac> or make uboot produce a -dev
[10:50] <ogra> then i would need to merge the upstream tarballs
[10:51] <ogra> -dev seems overly complicated ... especially in the light that we will need a -dev for each uboot flavour in the future then
[10:52] <asac> right
[10:52] <ogra> effectively i would like to have one uboot package based on upstream with lucid+1 (i.e. merge imx, omap and whatever else can use plain upstream or plain upstream with patches)
[10:52] <asac> if its soo tightly coupled upstream then it belongs together for now
[10:52] <lool> ogra: Really?
[10:52] <lool> I don't remember building xloader against uboot
[10:52] <ogra> so i dont want to bind to closely to the architecture for the omap package now, thats supposed to be the base for the merge
[10:53] <ogra> lool, well, i tried for zoom and beagle, both look in the boot tree for headers
[10:53] <lool> ogra: Which tree are you using?
[10:53] <lool> I just git clone gitorious:x-load-omap3/mainline.git and then:
[10:53] <lool> make CROSS_COMPILE=arm-none-eabi- distclean
[10:53] <lool> make CROSS_COMPILE=arm-none-eabi- omap3530beagle_config
[10:53] <lool> make CROSS_COMPILE=arm-none-eabi-
[10:53] <lool> and that's all
[10:54] <lool> I couldn't get the signed stuff to work
[10:55] <lool> well not the gpsign one but signGP.c worked
[10:55] <ogra> hmm, i pulled from the zoom tree, but that should essentially be the same (just with 3630 patches added)
[10:56] <ogra> the zoom tree expected to find ../u-boot/....*.h for building the ift image
[10:57] <ogra> (which you need for SD)
[10:57] <lool> http://code.google.com/p/beagleboard/wiki/BeagleSoftCompile doesn't mention building uboot first either
[10:57] <lool> ogra: What are you trying to build, the MMC version?  MLO?
[10:57] <ogra> both
[10:57] <lool> Err that's the same thing
[10:57] <ogra> i want a binary with a NAND and a MLO version
[10:57] <ogra> MOL has a dos header
[10:57] <ogra> *MLO
[10:58] <lool> MLO is the file which you write on your vfat
[10:58] <ogra> right
[10:58] <ogra> x-load.bin.ift is MLO
[10:58] <ogra> x-load.bin is for NAND
[10:58] <ogra> i need both
[10:59] <ogra> and for creating the ift version the build uses the uboot header files for some reason
[10:59] <lool> I'm not sure what the ift version is; I don't think I used that
[10:59] <ogra> at least in the zoom tree, i'll try the mainliune one
[10:59] <ogra> you cp .ift to MLO and cp it to your vfat to boot
[10:59] <lool> Oh that's just the signed one
[11:00] <lool> I know what you're trying to do now
[11:00] <ogra> its essentially a dos command.com after the signing
[11:00] <lool> You're trying to sign it with gpsign
[11:00] <ogra> right
[11:00] <lool> Which needs u-boot's headers
[11:00] <ogra> right :)
[11:00] <lool> Try signGP instead
[11:00] <lool> it doens't need anything
[11:00] <lool> and signGP didn't work for me anyway
[11:00] <lool> http://beagleboard.googlecode.com/files/signGP.c
[11:00] <ogra> well gpsign did
[11:01] <asac> ogra: when you hang in qemu is qemu completely dead?
[11:01] <asac> or can you ssh into it?
[11:01] <lool> err gpsign didn't work for me rather, typo
[11:01] <ogra> asac, i never tried to ssh, i use the graphical qemu version and switch to tty2
[11:01] <asac> ogra: so you can still log in?
[11:01] <ogra> yes
[11:01] <ogra> thats how i can see top ps etc
[11:02] <asac> send a signal to generate a core dump then please
[11:02] <ogra> to see the defunct dpkg --unpack passing by
[11:02] <ogra> what do you gain from a coredump without dbgsym ?
[11:02] <asac> ogra: you generate a core dump
[11:02] <asac> then install dbgsym to analyze
[11:02] <lool> you can load a core dump with dbgsyms from another system
[11:02] <ogra> right, but there are no symbols
[11:03] <ogra> oh
[11:03] <asac> first generate core dump
[11:03] <lool> it doesn't matter, it's just a memory image
[11:03] <asac> then install symbols and use gdb
[11:03] <asac> right
[11:03] <ogra> i'll try that later ... atm i want to get x-loader and uboot ready
[11:03] <asac> sure
[11:03] <asac> how do i start graphical qemu?
[11:04] <ogra> use the command from rootfsfromscratch
[11:04] <ogra> it fires up the SDL version by default
[11:04] <asac> i am using qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda arm-rootfs.img -m 256 -append "root=/dev/sda mem=256M devtmpfs.mount=0 rw"
[11:05] <ogra> with alt-2 you get insto command mode and use send-key ctrl-alt-f2
[11:05] <asac> how do i switch to tty2 ?
[11:05] <asac> ah
[11:05] <asac> ok
[11:05] <ogra> to get back just send-key ctrl-alt-f1
[11:05] <asac> alt-2 == alt gr?
[11:05] <ogra> its annoying ... but the only way
[11:05] <ogra> alt and 2
[11:05] <ogra> alt-1 gets you back to the VM
[11:07] <asac> ogra its alt+f2 here :)
[11:07] <ogra> weird, alt f2 gets me the gnome exec dialog here
[11:08] <asac> you first have to click in the window ... so it grabs the input
[11:08] <asac> then alt+f2345 etc works as usual
[11:08] <asac> cool :)
[11:08] <ogra> heh, i always did it through the command console
[11:08] <ogra> because i'm annoyed if qemu grabs my mouse
[11:09]  * asac runs bzip2 to preserve state before installing netbook
[11:10] <asac> lets see how big it gets
[11:10] <ogra> heh. yeah
[11:16] <ogra> ./signGP x-load.bin 0x40208800
[11:16] <ogra> make: *** [x-load.bin.ift] Error 36
[11:16] <ogra> bah
[11:16] <ogra> funnily it produces x-load.bin.ift
[11:17] <asac> 100M
[11:17] <asac> ;)
[11:17] <ogra> sweet
[11:17] <asac> me uploads
[11:25] <asac> JamieBennett: all fine wfor the localization of .desktop?
[11:25] <asac> e..g did you get the answers from pitti?
[11:25] <asac> (or persia)
[11:26] <JamieBennett> asac: working on it. Its a lot more involved that first thought after I talked with persia
[11:26] <JamieBennett> and I'm learning how to do it for the first time
[11:26] <asac> so dh7 isnt ready for that?
[11:26] <asac> what a crap thing ;)
[11:26] <JamieBennett> asac: no
[11:27] <JamieBennett> I considered switching to CDBS
[11:27] <asac> ok
[11:27] <ogra> dont you just have to set gettext domain ?
[11:27] <asac> dh7 really isnt ready? wow
[11:27] <JamieBennett> but I have something that should be ready tomorrow
[11:27] <ogra> i thought LP cares for the rest
[11:27] <asac> ogra: we have cdbs langpack.mk
[11:27] <asac> seems we have no equiv. for dh7
[11:27] <JamieBennett> ogra: it was a simple wrapper script
[11:28] <lool> langpack.mk is mostly useful to desktop packages which used cdbs so far; no pressure to port it to dh basically
[11:28] <lool> but it should be done
[11:28] <JamieBennett> now it needs a build system (setup.py)
[11:28] <JamieBennett> and .po support
[11:28] <ogra> bah
[11:28] <JamieBennett> and gettext support
[11:28] <JamieBennett> e.t.c
[11:28] <lool> JamieBennett: which package is this?
[11:29] <JamieBennett> lool: webservice-office-zoho (my package)
[11:29] <lool> Truth is, the CDBS snippet should be a separate tool, perhaps a dh_langpack
[11:30] <JamieBennett> lool: I'm looking through doc, web pages, snippets of code trying to learn it too which doesn't help
[11:30] <lool> JamieBennett: You could copy what you need to some dh override
[11:31] <lool> JamieBennett: e.g. override dh_gencontrol
[11:31] <JamieBennett> lool: but would that be 'the proper way' ;)
[11:31] <lool> JamieBennett: Best way would be to add support to dh to do that automatically
[11:32] <lool> JamieBennett: But we have packages where we call intltool-update by hand because they are not CDBS based
[11:33] <lool> e.g. http://paste.ubuntu.com/397186/
[11:34] <lool> perhaps not very good examples actually
[11:39] <asac> current cdbs does stuff in binary-predeb
[11:42] <asac> ogra: http://people.canonical.com/~asac/tmp/ubuntu-arm-lucid-minimal.bz2 ;)
[11:42] <ogra> great
[11:43] <ogra> i have several of these around though ;)
[11:43] <asac> then why didnt you give them to me ;)
[11:43] <asac> thought you didnt have that online
[11:43] <ogra> i dont have them online
[11:44] <ogra> and we only discussed the compressing yesterday :)
[11:45] <asac> ah
[11:45] <asac> right. so now we have it ;)
[11:45] <ogra> yeah
[11:46] <asac> sigh ... i used 2G onlz
[11:46] <asac> thats not enough for netbook i think
[11:46] <lool> asac: You can grow it
[11:46] <asac> lool: command?
[11:46] <lool> asac: dd if=/dev/zero bs=1M count=200 >> lucid.img; e2fsck -f lucid.img; resize2fs -p lucid.img
[11:47] <lool> that's for a raw image
[11:47] <lool> (not sure whether you're using qcow or something)
[11:47] <asac> i use raw image with ext4
[11:47] <lool> no part table?
[11:47] <lool> then the above should work
[11:47] <asac> let me try
[11:47] <asac> not much to loose
[11:47] <ogra> rootstock doesnt create partitions
[11:47] <lool> Yeah, worst case you have 200MB of zeroes at the end
[11:47] <ogra> but creates ext3 by default
[11:48] <ogra> (or did i change that ?)
[11:48] <asac> ogra: i didnt use the img from rootstock, but made my own and untarred ;)
[11:49] <ogra> ah, but you used rootstock to create the tarball ?
[11:49] <asac> yes
[11:49] <asac> ok booting with new size
[11:49] <ogra> (i just wnt to be sure we're not to far away from the rootstock creation here when we try to debug)
[11:49] <ogra> thought its still weird that lool never saw that issue
[11:50] <asac> ok it worked
[11:50] <asac> now have 3g
[11:50] <ogra> that should suffice
[11:50] <ogra> i think even 2 would for armel netbook
[11:50] <asac> wasnt enough
[11:50] <ogra> (we dont have oo.o in the task)
[11:51] <asac> it wanted to install 1.8G after ubuntu-minimal
[11:51] <asac> and i only had 1.6G left or something
[11:53] <ogra> hmm, the task never wants to install that much for me
[11:53] <asac> its 1835MB
[11:53] <asac> so less than 1.8G ... but not much
[11:53] <asac> ^ubuntu-netbook
[11:53]  * ogra wonders if there is a size difference between task and metapackage
[11:54] <ogra> doesnt the caret need to be at the end ?
[11:54] <lool> asac: Are you trying to reproduce the problem or just analyze the core file?
[11:54] <asac> lool: want to reproduce and produce core files for now
[11:54] <asac> yes.
[11:54] <asac> lool: i already reproduced it here at some point
[11:55] <asac> furhter above there was someone who saw this even for ubuntu-minimal
[11:55] <asac> i think the faster the system is the easier you get it (race)
[11:55] <asac> as we dont see it with dbgsym installed according to ogra
[11:55] <ogra> right
[11:55] <ogra> installing dbgsym just makes it pass
[11:55] <lool> That's odd
[11:55] <ogra> i have never seen it in -minimal though
[11:56] <ogra> and i havent tried -desktop since we do -netbook
[11:58] <ogra> rcn-ee, you see the hang in rootstock too, right ?
[11:59] <rcn-ee> ogra, ah maybe, it's still halting at "|: Extracting zlib1g..." for me.. ;) debian qemu.. http://rcn-ee.homeip.net:81/dl/daily/ubuntu-lucid.log  but it worked just fine yesterday on karmic...
[12:00] <ogra> yes, its a lucid issue
[12:00] <ogra> though that is something different i think
[12:00] <rcn-ee> yeah i was guessing that, i need to setup a karmic chroot on my server...
[12:00] <ogra> do you have a full log too ? (the one that rootstock spits out if you ctrl-c)
[12:01] <rcn-ee> so you guys have fun building xloader/uboot for omap?
[12:01] <ogra> the prob is when building lucid ... not with lucid on the host
[12:01] <ogra> rcn-ee, well, fun is something different :) but yes, i'm fddling with that
[12:01] <rcn-ee> sorry, nope, it's a cron job, no terminal, and it doesn't occur when run from the command line...
[12:02] <ogra> ah
[12:03] <amitk> rcn-ee: I've seen the hang at zlib1g on karmic too
[12:03] <amitk> oops, ogra ^^
[12:03] <ogra> well, this hang is clearly not the same one
[12:03] <asac> why?
[12:04] <rcn-ee> ogra, under what conditions is it hanging now?
[12:04] <asac> i thought we hang in unpack too
[12:04] <ogra> unpacking of zlib happens in debootstrap which is run in the qemu-arm-static chroot
[12:04] <ogra> while the task installation hangs in a VM
[12:05] <asac> hmm. but why wouldnt an io issue in qemu never show up in qemu? maybe its just less easy to trigger because its a fresh process for every command?
[12:05] <rcn-ee> and what's weird, i had the same issue when building google's x86 os where it would hang on the same file, only x86.. ;)
[12:05] <asac> err second qemu==qemu-static
[12:05] <ogra> well, i have never seen it hang in karmic builds at all ... thats very new
[12:06] <asac> ogra: they install lucid .... didnt you say the host qemu doesnt matter?
[12:06] <ogra> but i definately can reproduce the netbook task install hang reliably in lucid
[12:06] <ogra> asac, right
[12:06] <ogra> host doesnt matter
[12:07] <rcn-ee> yeah no luck on netbook here either.. ;)
[12:07] <asac> so that they see something like this in karmic qemu when trying lucid doesnt feel that off based on that
[12:07] <ogra> but target lrelease of the build does
[12:07] <asac> right. armv7+thumb2
[12:07] <asac> in lucid
[12:07] <ogra> xactly my suspicion
[12:07] <asac> lool: why are you sure that armv7+thumb2 is working perfect in qemu?
[12:08] <asac> or arent you sure?
[12:08] <ogra> asac, you mean kernel wise
[12:08] <ogra> ?
[12:08] <asac> no ... qemu in general for now
[12:08] <asac> as rcn-ee sees it in static
[12:08] <ogra> i dont think qemu matters here
[12:09] <ogra> asac, but building a karmic image (unless i misunderstood)
[12:09] <asac> ogra: the log is named lucid from above: http://rcn-ee.homeip.net:81/dl/daily/ubuntu-lucid.log
[12:09] <ogra> i could imagine that the verstile kernel we use doesnt properly support thumb2
[12:09] <ogra> asac, oh
[12:10] <ogra> " but it worked just fine yesterday on karmic..."
[12:10] <asac> its probably a karmic qemu trying to run armv7/thumb2 code
[12:10] <ogra> that confused me :)
[12:10] <asac> hmm
[12:10] <asac> rcn-ee: so what are you doing?
[12:10] <asac> host = karmic + target == lucid?
[12:10] <asac> or both karmic / lucid ?
[12:10] <rcn-ee> ah crap, my naming confused everyone... host debian squeeze, running latest rootstock building ubuntu-netbook for lucid target... ;)
[12:10] <asac> yeah
[12:10] <ogra> debian squeeze ?
[12:11] <asac> so target is lucid
[12:11] <ogra> aww
[12:11] <ogra> thats a totally differend qemu then i think
[12:11] <asac> didnt lool land some arv7 stuff here?
[12:11] <asac> and not in debian? or are we in sync?
[12:11] <rcn-ee> just checking on that, it's qemu 0.11.1...
[12:11] <ogra> well, lool usually does his qemu stuff upstream
[12:11] <ogra> but we pull from a different upstream afaik
[12:11] <ogra> because of kvm
[12:12] <rcn-ee> and the opteron server i have is too old for kvm...
[12:12] <ogra> 0.12.3-0ubuntu15
[12:12] <ogra> thats what we have in lucid atm
[12:12] <ogra> but pulled from qemu-kvm since karmic
[12:13] <ogra> rcn-ee, well, kvm doesnt gain you anything for armel emu ... but the point is that we use a different upstream
[12:13] <asac> rigt. thats wat busted ftas images and he lost everything ;)
[12:14] <ogra> the question is how much difference there is
[12:14] <ogra> especially for armel
[12:14] <rcn-ee> correct... i just use it to verify nightly builds.. it was working early in lucid's cycle, maybe stoped in the last two months.. otherwise i build on karmic exclusively at work.. ;)
[12:15] <ogra> yeah, i dont test on debian ... so i dont really know if it would work or not
[12:16] <asac> ok hangs in iputils-tracepath here
[12:16] <ogra> minimal should work if you build on ubuntu host for all releases we support
[12:16] <ogra> asac, right, same here
[12:16] <ogra> that pretty reproducable
[12:16] <ogra> not 100% though ... there is another package it sometimes hangs ...
[12:17] <ogra> iso-codes iirc
[12:17] <nosse1> hi, guys. Back in business!
[12:17] <ogra> but i have only seeing it hang on either of these two yet
[12:17] <lool> asac: Sorry, I dont understand your question?
[12:17] <lool> asac: There might be qemu bugs
[12:17] <asac> ok
[12:17] <rcn-ee> it's been a toss up between iputils-tracepath and iso-codes for me..
[12:18] <lool> I wonder whether a FS benchmark would show a similar issue
[12:18] <nosse1> Have you come any closer to investigating the qemu hang? Is there anything I can assist with?
[12:18] <asac> lool: i ran a read/write testcase here today for 1h
[12:18] <asac> e.g. just reading and writing all the time
[12:18] <asac> that didnt have issues
[12:18] <ogra> lool, but are you sure that just telling the versatile kernel that it is a v7 CPU also enables all features properly (thumb2 etc)
[12:18] <asac> lool: which fs benchmark would you suggest?
[12:19] <asac> ok so now ... which process should i core dumb ;)?
[12:19] <asac> probably all dpkg/apt ones
[12:19] <ogra> i mean i see them in cpuinfo  ... but is it sure they actually work by just telling the kernel it is v7 ?
[12:19] <asac> not sure if i get the core from all though at the same time
[12:19] <lool> ogra: Uh the whole userspace works
[12:19] <ogra> well, apt is the one that hangs
[12:20] <lool> ogra: All our programs are running in thumb 2 mode aren't they
[12:20] <ogra> lool, yes
[12:20] <ogra> so you think other SW would expose issues too ?
[12:20] <lool> asac: Dunno, some kernel fs benchmark to cause high IO
[12:20] <lool> ogra: other SW?
[12:20] <ogra> (if it was kernel side)
[12:20] <ogra> other apps
[12:21] <lool> ogra, asac: One thing you folks could try to workaround the issue are different disk emulation in qemu; e.g. cache=none, cache=writeback, etc.
[12:21] <rcn-ee> aren't some packages, still in arm mode?
[12:21] <ogra> rcn-ee, very very few
[12:21] <lool> ogra: Well it might be a dpkg / apt bug exposed by our testing conditions or a qemu bug which triggers under high IO circunstances, perhaps a race
[12:21] <lool> ogra: I can't tell
[12:21] <ogra> yeah
[12:22] <asac> its definitly racish
[12:22] <asac> ok i have a core ... not sure if it was the apt or dpkg core though
[12:22] <ogra> i'm close to say its a race ... apt hanging in read() and the issue going away with dbgsym installed point very much to it
[12:23] <ogra> also the I/O isnt blocked if you work from another tty
[12:23] <ogra> while the hang occurs
[12:23] <nosse1> Is there a way I can circumvent the qemu-lockup from rootstock, so that I can build my ubuntu-minimal image?
[12:24] <ogra> nosse1, juts ubuntu-minimal should actually work
[12:24] <asac> nosse1: is the hang in second stage?
[12:24] <asac> then try another disk emulation as lool suggested above
[12:24] <nosse1> asac: Yes. "Switching to Virtual Machine for second stage processing"
[12:24] <ogra> nosse1, do you have a full log ?
[12:24] <asac> nosse1: then try to do that
[12:25] <lool> Another way might be to have a while sync; do sleep 1; done loop on another vt while doing the install
[12:25] <nosse1> ogra: Where can I find the log? Is it the rootstock-xxx.log file?
[12:25]  * lool lunch &
[12:25] <ogra> nosse1, right, rootstock should have told you it created the file when you stopped it (or it successfully finised)
[12:26] <ogra> can you put it somewhere so i can take a look where exactly it hangs
[12:27] <nosse1> The log files doesnt actuall tell anyting.. It shows the output from a wget session. Then "I: Killed ..."
[12:27] <ogra> whats your host os ?
[12:27] <nosse1> Karmic amd64
[12:27] <ogra> hmm, amd64
[12:28] <ogra> do you use the rootstock package from the archive ?
[12:28] <nosse1> yes
[12:28] <ogra> and you try to build lucid ?
[12:28] <nosse1> yes
[12:28] <ogra> ah
[12:28] <ogra> thats fixed but not backported to karmic
[12:28] <nosse1> should I up my host to lucid then?
[12:29] <ogra> http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/revision/31
[12:29] <ogra> the rootstock scrip needs this fix
[12:30] <ogra> (currently karmic can only build karmic)
[12:30] <ogra> (without this fix)
[12:31]  * ogra tries to find some food
[12:39] <nosse1> The ultimate goal of this is to throw Ubuntu into an embedded product which will go into mass production. What is the state of Ubuntu Lucid for ARM?
[12:39] <nosse1> The product is at least 12-14 mnths away from release
[12:39] <asac> nosse1: lucid for arm is quite good. we release beta today
[12:39] <asac> rootstock is busted though ;)
[12:40] <asac> there are a few ftbfs and thumb2 porting issues outstanding
[12:40] <nosse1> Since we're using a Zoom TI AM3517 evaluation kit as a base, is there something I can do to contribute for support for that exact kit?
[12:41] <nosse1> Pardon my silly questions, I'm quite new to the development flows of Ubuntu :o
[12:45] <asac> nosse1: yes, testing like you do now is good. also checking if there is software for that that isnt in the archive would help (besides the kernel/bootloader)
[12:45] <nosse1> I see from the topic that "no, we do not cross compile"? What do you mean? That all packages are built natively on some target/emu?
[12:45] <asac> nosse1: we build natively on real machines
[12:46] <asac> nosse1: if there are particular software you need to cross compile let me know which software that is
[12:46] <asac> currently collecting the main use cases we should support in some way
[12:47] <asac> nosse1: here you can see our build farm: https://edge.launchpad.net/builders
[12:47] <nosse1> we will have Qt (>=4.6) running, but if it need cross compile I'm not sure yet
[12:47] <asac> nosse1: is that newer than in ubuntu?
[12:47] <nosse1> than karmic, yes. I havent checked lucid yet
[12:47] <asac> we have Version: 4:4.6.2-0ubuntu
[12:47] <asac> in lucid
[12:48] <asac> at least thats the version for libqt4-dev
[12:48] <asac> so thats already precompiled in lucid for you
[12:48] <nosse1> Thats latest release from Qt
[12:48] <asac> if you have fixes for that that you need to get in and that are general issues we can try to get that patched
[12:48] <rcn-ee> * heads off to work, needs to stop playing with the xm board and send amit some usb/musb patches for omap..
[12:49] <ynezz> how's xm? :)
[12:49] <rcn-ee> i like it. ;)
[12:49] <nosse1> I'm a little uncertain how the rendering system should be done in Qt and/or X11. Because the SDK to access the HW GFX accelerators are not open source
[12:50] <asac> nosse1: so to get unbut-minimal all you need to do is to create it from lucid (not debian)
[12:50] <asac> that definitly works for everyone here
[12:57] <nosse1> Yes! The patch to rootstock worked!
[13:01] <nosse1> How can I install or sign up for a builder in the build farm?
[13:02] <nosse1> I mean, the process from making a source package up until it ends up in a apt tree is really unknown to me
[13:02] <nosse1> Because we will have to make our own apt tree for the closed applications and such
[16:18] <ogra> ogra@osiris:~/Devel/branches/omap$ sudo build-arm-chroot lucid /mnt http://<IP_ADDRESS>:9999/ubuntu-ports
[16:18] <ogra> W: Target architecture is the same as host architecture; disabling QEMU support
[16:18] <ogra> lool, that seems broken
[16:19] <ogra> either drop build-arm-chroot or make it set --arch armel
[16:20] <amitk> ogra: omap image? :-p
[16:21]  * amitk hides
[16:21]  * ogra hits amitk with a rootstock
[16:21] <ogra> :)
[16:22] <amitk> :)
[16:22] <amitk> the kernel should the archive tomorrow
[16:22] <amitk> *hit the archive
[16:22] <ogra> great, i'll make sure x-loader and uboot are uploaded before end of day tomorrow
[16:23] <ogra> and will work on cdimage scripts on the weekend
[16:25] <armin76> you guys doing omap support now?
[16:30] <DanaG> OOooh.
[16:31] <DanaG> heh, every time I try to compile a "newer" u-boot (u-boot-omap) for my beagleboard, I find it mistakenly detects it as Board Revision Ax/Bx (instead of C4, as it should be).
[16:31] <DanaG> hmm, what benefit do a newer u-boot and/or x-loader give?
[16:33] <DanaG> http://pastebin.com/BFjBG4Ms --  vlc segfaults.
[16:33] <DanaG> er, sorry for the long command line. =þ   Oh, and mplayer is UNAVAILABLE.
[16:34] <DanaG> heh, I left in my sd card with Angstrom (ew) on it, and grub on my host "Found unknown Linux distribution on /dev/mmcblk0p2
[16:37] <ogra> DanaG, mplayer is availabel in multiverse
[16:38] <DanaG> hmm, I'll check sources.list.
[16:38] <ogra> for vlc, please file a bug
[16:38] <ogra> (and hope that someone from the community puts some work into it)
[16:39] <DanaG> How do I trigger apport via CLI?
[16:39] <ogra> ubuntu-bug vlc
[16:39] <ogra> should work
[16:39] <DanaG> Will it get the gdb output?
[16:40] <ogra> if there was a crash file file created it will just attach it
[16:40] <DanaG> Cool.
[16:40] <ogra> check /var/crash/
[16:41] <DanaG> nope, no vlc .crash file.
[16:43] <DanaG> also, when trying to run amttool on the beagle:
[16:43] <DanaG> Can't locate SOAP/Lite.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/bin/amttool line 4.
[16:43] <DanaG> BEGIN failed--compilation aborted at /usr/bin/amttool line 4.
[16:44] <ogra> looks like a missing dependency ...
[16:44] <ogra> a bug as well
[16:45] <ogra> the community support for apps in universe under armel isnt that great yet
[16:45] <ogra> (any help appreciated :) )
[16:46] <DanaG> hah, nvidia-kernel-common exists on ARM restricted.
[16:54] <DanaG> heh, and so do things like virtualbox-guest-additions.
[17:04] <KingMuty> yo
[17:09] <DanaG> weird... ssh into beagleboard and run mplayer... it outputs LOCALLY to pulseaudio on the ssh client.
[17:10] <DanaG> ah, had to un-export DISPLAY=
[17:12] <lool> ogra: build-arm-chroot does set arch == armel
[17:13] <ogra> lool, didnt for me
[17:13] <lool> ogra: But you're running this on arm, right?
[17:13] <ogra> no
[17:13] <ogra> i just tried to quickly build an arm chroot
[17:13]  * DanaG wishes he had a spare DVI display.
[17:13] <lool> ogra: Ah I know what happened
[17:13] <DanaG> Right now, my beagleboard is entirely headless.
[17:13] <ogra> lool, it also doesnt throw the deprecation warning
[17:15] <lool> ogra: uploaded
[17:15] <lool> ogra: http://paste.ubuntu.com/397356/
[17:16] <ogra> lool, hmm
[17:16] <ogra> lool, i didnt run build-arm-chroot with a path
[17:16] <lool> ogra: sudo added one
[17:17] <ogra> oh
[17:17] <ogra> indeed :)
[17:17] <KingMuty> yo
[17:17] <ogra> ghurt
[17:18] <KingMuty> juje
[17:19] <KingMuty> http://blokker1999.info/andromnia/README.txt
[17:19] <KingMuty> dis ewe do?
[17:21] <KingMuty> ewe no talk?
[17:25] <ogra> KingMuty, try #andromnia
[17:25] <KingMuty> ok thx
[17:29] <KingMuty> dey iz dead! :'(
[17:47] <DanaG> interesting... so, if I wanted to have pulseaudio run as my local user... how would I make it auto-start on a headless thingy?
[17:48] <DanaG> now, here's something funny to do:
[17:49] <DanaG> screen /dev/ttyUSB0 115200 on host, to beagleboard serial port.
[17:49] <DanaG> now run byobu within that.
[17:49] <DanaG> And then within byobu... use amtterm to go back to the host.
[17:49] <DanaG> ... and then run another byobu there.
[17:50] <DanaG> or even better... make the first "screen" a byobu, too.


[15:53] <asdaf> Hi all
[15:54] <asdaf> I was wondering if there is any way in upstart to reload a job description from file
[16:02] <Keybuk> yes
[16:02] <Keybuk> just change the file
[16:02] <Keybuk> Upstart will automatically reload it
[16:02] <Keybuk> if the job is running, you will need to stop it - let it stop, and then start it again
[16:11] <asdaf> ok, this works if inotify works, but I have a read-only filesystem and would like to use links for some job files placed in a writable location
[16:12] <asdaf> so if I change the target file of the symlink, inotify is not aware of it
[16:12] <Keybuk> right
[16:14] <asdaf> do you think it would be possible to add an event to force reload, something like 'initctl emit reload myjob'
[16:14] <asdaf> ?
[16:15] <Keybuk> it'll be present in trunk
[16:16] <Keybuk> everything necessary to do it is there
[16:16] <Keybuk> probably just a general "reload" command though to reload all jobs
[16:16] <asdaf> great!
[16:22] <jdong> Keybuk: can Upstart start Upstart? ;-)
[16:22] <Keybuk> jdong: yes
[16:24] <Keybuk> jdong: kill -TERM 1
[16:24]  * jdong doesn't dare figure out what that actually does :D
[16:25] <Keybuk> it makes upstart re-exec itself
[16:25] <jdong> cool
[16:25] <Keybuk> you have to get the running upstart to do it so that the new copy still has pid 1
[16:25] <Keybuk> upstart --replace isn't possible
[16:26] <jdong> ah
[18:29] <brendan_> Keybuk: is that job reloading something that was recently fixed?
[18:30] <brendan_> in 0.3.8 it doesn't seem to ever reload the job description
[18:30] <brendan_> at least, in my environment
[18:31] <Keybuk> it should
[18:31] <Keybuk> 0.3.8 is largely the same as 0.3.9
[19:30] <brendan_> oh, is it using inotify to see that the file changed?
[19:31] <brendan_> that could be my problem, since the /etc filesystem is on nfs and i don't change the files on the host running upstart
[19:52] <Keybuk> it does use inotify, yes
[21:00] <tannewt> are upstart init scripts shutdown and started up upon suspend and resume?
[21:01] <tannewt> in ubuntu?
[21:23] <mbiebl> tannewt: no
[21:24] <tannewt> mbiebl: so I should not write them as upstart init files but legacy init?
[21:24] <mbiebl> tannewt: why should they? suspend/resume != start/shutdown
[21:25] <tannewt> mbiebl: true, but my daemon needs to be restarted on resume
[21:25] <mbiebl> tannewt: hook that up with pm-utils
[21:26] <tannewt> mbiebl: hmm, okay, I was looking in /etc/acpi/{suspend,resume}.d.  are those scripts different than regular init?
[21:27] <mbiebl> yes
[21:28] <tannewt> ok, so I'd write inits for that and upstart for startup/shutdown?
[21:28] <mbiebl> they serve a different purpose
[21:28] <mbiebl> You could set up pm-utils to emit shutdown / resume events
[21:29] <mbiebl> Then your upstart job can react on this.
[21:29] <mbiebl> Or, if your daemon is started via a legacy sysv init script, create a hook for pm-utils and use the restartservice method.
[21:30] <tannewt> mbiebl: oh, all right, sweet that sounds good, thanks


[09:47] <gennadiy> hi all, i have question about removing aws security groups: seems juju doesn't remove security group when machine is removed. am i right? and today i have got exception: security groups number limit is reached
[09:48] <gennadiy> do we need to remove security group manually? do you have some specific config field to reuse security groups?
[17:25] <lazypower> gennadiy Juju does have a habit of leaving security groups behind. I use a python script to reset my SEC Groups - https://gist.github.com/chuckbutler/d8a62945ca35b77a8d96
[17:36] <lazypower> gennadiy - however this wipes all sec groups ^
[17:36] <lazypower> so use with caution
[22:21] <ionutbalutoiu> @thedac - Updated both MP that you reviewed earlier. (https://code.launchpad.net/~ionutbalutoiu/charms/trusty/swift-proxy/next/+merge/276218 and https://code.launchpad.net/~ionutbalutoiu/charms/trusty/glance/next/+merge/276285).
[22:21] <thedac> ionutbalutoiu: great. I'll take a look shortly
[22:22] <ionutbalutoiu> @thedac: cool, thanks
[22:36] <thedac> ionutbalutoiu: fyi, we'll have to wait for the automatic testing. Which means I'll be looking at this Monday.
[22:39] <ionutbalutoiu> @thedac: Of course. Thanks and have a great week-end.
[22:39] <thedac> You too


[02:36] <niemeyer> Aaaaand, that's it.. lbox is ready for inline reviews on Launchpad.
[02:36] <niemeyer> Now, package and docs..
[02:46] <hazmat> niemeyer, nice
[03:05] <hazmat> SpamapS, thanks for doing the bug weeding
[11:26] <noodles775> Hi, any reason why I'd start seeing the following on juju units? http://paste.ubuntu.com/741073/
[11:26]  * noodles775 checks the mail list for api changes.
[11:27] <noodles775> seems JUJU_AGENT_SOCKET is no longer set?
[12:17] <hazmat> noodles775, the juju cli api is only setup for automatic usage from a hook or a debug hook terminal.. other uses need to setup variables to connect to the remote end
[12:18] <hazmat> we should probably default these though to their common known values
[12:25] <fwereade> hazmat, may I borrow you for a quick pre-review?
[12:26] <fwereade> hazmat, http://paste.ubuntu.com/741112/ has the changes I've made for upstartification; they're verified but not yet tested and I wanted to check if there were any serious issues before I go too much further
[12:26] <fwereade> hazmat, the first 270 lines are the important ones, the rest are consequential changes to test data
[12:29] <fwereade> bbs lunch
[13:28] <rog> niemeyer: mornin'
[13:29] <mainerror> Hello.
[13:30] <hazmat> fwereade, functionally it looks fine, except the stop handling needs better, i'm still wondering if it wouldn't be better served by a more complete abstraction of upstart config
[13:30] <hazmat> er .. stop needs error handling
[13:31] <fwereade> hazmat, good point re stop
[13:31] <hazmat> some of the use cases are pretty general purpose outside of existing agents, starting containers, zookeeper, webservers.. etc.
[13:32] <fwereade> hazmat, I'm reluctant to do that until those use cases are actually in play
[13:32] <fwereade> hazmat, although that makes me think
[13:32] <hazmat> fwereade, those cases exist now, and could be simplified via upstart
[13:32] <fwereade> hazmat, actually no it doesn't
[13:32] <hazmat> fwereade, much of the local provider code is really just process management stuff that could go away
[13:33] <fwereade> hazmat, ah, ok, I haven't really dug very deep into that
[13:33] <fwereade> hazmat, I'll poke around for further opportunities to use it then, better abstraction should come from that quite naturally
[13:34] <fwereade> hazmat, thanks
[13:35] <hazmat> fwereade, a straight conversion of http://upstart.ubuntu.com/cookbook/#id119 would look alike the bootstrap, with a **kw constructor for convience
[13:35] <hazmat> its not a direct 1-1
[13:36] <hazmat> but it would cover all our use cases
[13:36] <hazmat> maybe
[13:36] <niemeyer> rog: Yo
[13:36] <hazmat> well definitely.. but not clear we really need it
[13:37] <niemeyer> hazmat, fwereade: Mornings as well
[13:37] <hazmat> niemeyer, greetings
[13:37] <niemeyer> fwereade: Well, aft. for you :)
[13:37] <fwereade> hi niemeyer
[13:37] <fwereade> (details, details)
[13:37] <niemeyer> rog: Thanks for the log.. I think there's much better heuristic I can use to find out the proper URLs
[13:37] <niemeyer> rog: I'll try that now
[13:42] <rog> niemeyer: cool.
[14:27] <jcastro> hazmat: nice graphs, <3
[15:18]  * niemeyer => lunch
[15:34]  * mpl <- cookies
[15:34] <mpl> :)
[16:23] <fwereade> hey guys, cath's stuck in the lift and laura is somewhat distraught, back later
[16:26] <niemeyer> fwereade: Ouch
[17:24] <SpamapS> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-juju-charm-testing
[17:24] <SpamapS> This has the juju team as the drafter..
[17:25] <SpamapS> I went ahead and added a few work items that I think will be part of it, but it would be good for somebody from the juju team to review them and change the Definition from Discussion to Review once that is done.
[18:01] <niemeyer> rog: Alright, I think I'm done with lbox..
[18:01] <rog> niemeyer: yay!
[18:01] <niemeyer> Unfortunately codereview seems down for maintenance.. *now* from all times
[18:02] <rog> niemeyer: damn, i remember it was announced.
[18:02] <niemeyer> rog: The heuristics are much better now
[18:02] <niemeyer> Simpler too..
[18:02] <rog> niemeyer: good. nothing like someone actually using some heuristics to sort 'em out...
[18:02] <niemeyer> rog: Yeah, definitely
[18:03] <rog> niemeyer: BTW currently i'm trying to get one of the simplest tests in ec2 to run against my test server.
[18:03] <niemeyer> rog: Cool, that's awesome
[18:04] <rog> niemeyer: it's by no means awesome yet :-)
[18:04] <niemeyer> rog: Ugh :)
[18:04] <rog> niemeyer: and the code is grungy
[18:05] <rog> niemeyer: here's a current snapshot of the server code: http://paste.ubuntu.com/741436/
[18:07] <niemeyer> rog: This is quite involved already
[18:07] <rog> niemeyer: all it does currently is allow a client to induce a failure (FailNow) and to inspect the set of actions afterwards.
[18:07] <rog> niemeyer: i know, i'm not entirely happy
[18:07] <rog> niemeyer: i can't think of a way of making it simpler though, while keeping our current approach
[18:07] <niemeyer> rog: I mean, even in terms of features
[18:08] <niemeyer> rog: We should be able to have a simpler test case that doesn't involve all of those calls
[18:08] <niemeyer> rog: To get started
[18:08] <niemeyer> rog: E.g. whatever call reads the machine state
[18:08] <rog> niemeyer: most of those calls are currently unimplemented
[18:09] <rog> niemeyer: i was after getting instance starting and stopping working
[18:09] <niemeyer> rog: The overall direction looks interesting, though
[18:10] <rog> niemeyer: i need DescribeInstances and then i think i'll have enough for a juju machine
[18:10] <niemeyer> rog: // Address returns the URI of the server.
[18:10] <niemeyer> rog: I wonder about this one
[18:11] <rog> niemeyer: is that a problem?
[18:11] <niemeyer> rog: It feels useful for sure
[18:11] <rog> niemeyer: i don't want to clash with other potential services
[18:11] <niemeyer> rog: But we can't expose that to the tests, otherwise we're binding them to a particular implementation
[18:11] <jcastro> m_3: ~45 minutes until that call
[18:11] <niemeyer> rog: The backend semantics may need multiple URLs, etc
[18:11] <rog> niemeyer: i don't think so - we just make an environments.yaml that includes that string
[18:12] <niemeyer> rog: Right, something like that should be cool
[18:12] <rog> actually, we allow registration of a new region
[18:12] <rog> which includes the url
[18:12] <niemeyer> rog: FailNext may not be enough..
[18:13] <niemeyer> rog: interactions will generally take several roundtrips
[18:13] <rog> niemeyer: yeah, it's just my placeholder for whatever is needed
[18:13] <niemeyer> rog: The first one may not be interesting to fail
[18:13] <rog> niemeyer: it's enough for my first test
[18:13] <niemeyer> rog: Cool
[18:13] <niemeyer> rog: +1
[18:13] <niemeyer> rog: Looks nice overall
[18:13] <rog> niemeyer: but in general it's an interesting question
[18:13] <rog> niemeyer: the testing code can't know how many requests will be generated
[18:13] <niemeyer> rog: Some nastiness will go away when Go is fixed
[18:14] <niemeyer> Go's xml, that is
[18:14] <niemeyer> rog: That's right
[18:14] <niemeyer> rog: We'll need to think through that one a bit
[18:14] <rog> niemeyer: yeah, i think xml could do with a thorough rethink
[18:14] <niemeyer> rog: It sounds like failure scenarios are too bound to the backend
[18:15] <rog> niemeyer: yes
[18:15] <niemeyer> rog: We'll probably need a richer interface on the fake server, and provider-specific tests
[18:15] <niemeyer> rog: Otherwise we'll be spending years on that framework creating something extremely involved
[18:15] <rog> niemeyer: for example ec2 generates errors in a particular form
[18:15] <niemeyer> rog: yeah, and on particular calls, etc
[18:16] <rog> niemeyer: hmm. a possible idea:
[18:16] <rog> niemeyer: given that hardly any code reacts to the actual content of an error
[18:16] <rog> niemeyer: and that most of the stuff we're testing will be single threaded and therefore deterministic
[18:17] <niemeyer> rog: Both of these assumptions don't seem necessarily valid, FWIW
[18:17] <rog> niemeyer: you could have a scheme where you run a test once, record the number of operations, then run it again several times failing at a different place each time
[18:17] <rog> true..
[18:17] <niemeyer> rog: See the "spending years" comment above.. :)
[18:18] <rog> yeah
[18:20] <rog> hmm. anyway,  i think the important thing is the constructive tests.
[18:20] <rog> we can do provider specific tests for provider specific error scenarios
[18:23] <jcastro> yep
[18:25] <niemeyer> rog: Agreed
[19:48] <m_3> petecheslock: great talking to you guys again... I'll get portertech some examples
[19:48] <petecheslock> m_3: sounds great - we're excited to bring sensu to more automation platforms.
[20:21] <hazmat> this is cool http://news.opensuse.org/wp-content/uploads/2011/11/snapper.png
[20:21] <hazmat> btrfs snapshot visualization
[20:22] <hazmat> imagine hooks doing btrfs snapshots, with introspectable  diffs
[20:22] <hazmat> not quite dry run, but a different level of introspection
[20:48] <jrgifford> i do **not** need to do `sudo juju bootstrap`, correct?
[20:48] <jrgifford> just a normal juju boostrap, from my normal user?
[20:57] <m_3> jrgifford: correct, ordinary user
[20:57] <marcoceppi> jrgifford o/
[20:58] <jrgifford> m_3: thanks
[21:00] <jrgifford> marcoceppi: ?
[22:01] <mainerror> He meant that there is no such thing as a normal user since it would imply the existence of an abnormal user which doesn't make sense. :)
[22:51] <portertech> due to being a ruby whore, I require ruby to be present in order to write my hooks in ruby
[22:51] <portertech> is there a common solution in this case, for charms?
[22:52] <portertech> check if installed, if not, install, a ruby charm out in the wild?
[22:53] <portertech> just do an apt-get install then? ;)
[22:54] <brunopereira81> hello, I need some help setting up a install script for a juju charm
[22:59] <jrgifford> portertech: hey, another ruby charmer. :P
[23:00] <jrgifford> i was actually wondering the same thing...
[23:00] <fwereade> portertech, an apt-get install in your install hook should be fine
[23:00] <fwereade> brunopereira81, I'll help if I can, but I know a lot more about the code than about the charms
[23:00] <portertech> jrgifford fwereade: yeah, doing a quick which & $? to determine if it's present, installing if not, then go have a ruby party
[23:01] <fwereade> portertech, perfect
[23:01] <jrgifford> portertech: thanks for the suggestion
[23:01] <brunopereira81> fwereade, I think I got it, thx
[23:01] <fwereade> brunopereira81, cool
[23:04] <portertech> tricky way: [[ ! `which ruby` ]] && apt-get -y install ruby
[23:05] <portertech> so is the install hook the default? what's the standard way to call another hook from it?
[23:10] <brunopereira81> I have a config.yaml file in my charm folder, how can I read an key from it to use in my install hook?
[23:15] <portertech> fwereade: would I "$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"/ruby_hook from within the install hook?
[23:15] <portertech> must be a sexy way of doing it
[23:15] <fwereade> sorry guys, distracted
[23:17] <fwereade> you should be able to get your config stuff via relation-get
[23:18] <fwereade> which is available to all relation-related hooks
[23:20] <brunopereira81> so for instance if I want to get a token string from my config.yaml i just need call 'relation-get token'?
[23:21] <fwereade> brunopereira81, sorry, needed to refamiliarise myself
[23:21] <fwereade> that should be config-get
[23:21] <fwereade> and that should be available in all your hooks including start and install (which aren't anything to do with relations)
[23:22] <brunopereira81> fwereade, thx
[23:22] <fwereade> sorry brainfart :)
[23:22] <brunopereira81> lol, np
[23:23] <fwereade> portertech, my bash-fu is weak :)
[23:24] <fwereade> portertech, as a suggestion, you *probably* don't need to do a great deal of work in the install hook; and if the install hook is just a bunch of "apt-get install"s, subsequent hooks (like start) can just be ruby
[23:25] <portertech> yeah, since install only runs once
[23:25] <portertech> nothing special
[23:25] <fwereade> portertech, indeed, you'll get an "install" and a "start" and then it's all about the relations
[23:26] <fwereade> oh, I think there's a config-changed one as well, let me check
[23:26] <fwereade> yep, it's "config-changed"
[23:29] <portertech> does anyone use facter or ohai w/ there charms? :P
[23:29] <portertech> where a large amount of system info is required
[23:30] <fwereade> portertech, we're very deliberately agnostic about what tools you use within the hooks
[23:30] <fwereade> portertech, I don't know for sure what people are using though
[23:31] <portertech> lots of freedom
[23:31] <portertech> i dig it
[23:31] <fwereade> :D
[23:33]  * hazmat catches up
[23:34] <SpamapS> portertech: yes there are charms that use facter already
[23:34] <brunopereira81> after creating a charm what is the easiest way to test it?
[23:34] <SpamapS> portertech: btw, for the "run another hook" case I use this
[23:34] <SpamapS> home=`dirname $0`
[23:34] <SpamapS> $home/hookname
[23:34] <hazmat> $CHARM_DIR is defined as well
[23:34] <portertech> SpamapS: cool
[23:35]  * SpamapS is all about self reliance :)
[23:36]  * SpamapS heads off to do some of the wife's bidding
[23:36] <brunopereira81> (nvm, found how)
[23:37] <hazmat> most of these formulas use facter.. http://charms.kapilt.com/~negronjl
[23:37] <hazmat> albeit just as a k/v store, which could be done with just about any tool..
[23:39] <_mup_> Bug #891868 was filed: juju cli api should be invokable outside of units  <juju:New> < https://launchpad.net/bugs/891868 >
[23:42] <portertech> hazmat: is $CHARM_DIR the current charm dir absolute path?
[23:43] <portertech> or just a user specified var
[23:49] <m_3> portertech: that's the charm path (/var/lib/juju/units/<unit-name>/charm/ on the deployed nodes)
[23:50] <portertech> m_3: ah, ok, thanks
[23:50] <m_3> and CWD druing hook exec
[23:50] <m_3> I usually just use relative
[23:51] <m_3> portertech: incidentally when debugging... /var/lib/juju/units/<unit-name>/charm.log is useful (along with /var/log/juju/unit-agent.log)
[23:52] <m_3> (from memory, but something like that)
[23:53] <portertech> so if i call another script in the current dir from within install, i could do $CHARM_DIR/script?
[23:53] <portertech> or ./
[23:55] <m_3> I guess I use [[ -f "$(dirname $0)/common.sh" ]] && source "$(dirname $0)/common.sh"
[23:56] <m_3> but that's probably easier with CHARM_DIR now


[00:13] <enbloc^> some PPA I'm on (studio related in some fashion) upgraded my kernel to 3.0 and broke all kinds of stuff. Ring any bells with folks here?
[00:14] <enbloc^> I do have a 3.0.0 low latency kernel installed today, and I didn't do it manually
[00:14] <enbloc^> natty
[00:46] <FloatingGoat> Hey holstein
[00:46] <FloatingGoat> You like unity?
[01:17] <FloatingGoat> Hi
[02:11] <holstein> FloatingGoat: hello
[02:11] <holstein> i do not use unity
[02:12] <holstein> i like the idea of it, it just seems to be answering a question im not asking
[02:16] <FloatingGoat> Haha
[03:48] <FloatingGoat> Holstein
[03:48] <FloatingGoat> Might be gettin a mxl new for 50
[03:49] <holstein> not bad
[03:49] <FloatingGoat> And then imma look at a shure sm58
[03:49] <holstein> 58 is probably a better first mic
[03:50] <holstein> if you only had one mic... might should be a 58 or a 57
[03:50] <holstein> i like the beta series a lot
[03:50] <holstein> the beta 58 is very nice...
[04:01] <FloatingGoat> Ill see what goes down. But I want to get the mxl and the sshure.
[04:01] <FloatingGoat> I'm glad you like the shure though
[04:02] <holstein> well, the shure 57's and 58's are industry standards
[04:02] <holstein> typically *not* for recording though
[04:02] <holstein> still, if it were my money, i would rather have a 57 than a $50 condenser mic
[04:02] <holstein> but, ive already heard both
[04:02] <holstein> used them
[04:03] <holstein> live and for recording purposes
[04:03] <FloatingGoat> Well a professional I just talked to told me it'd be good so ill check it out.
[04:03] <holstein> FloatingGoat: what would be good?
[04:04] <holstein> a professional what?
[04:04] <holstein> the MXL $50 condenser would be good?
[04:04] <holstein> it will most definitely *not* be good
[04:04] <holstein> it will be tolerable at best
[04:04] <holstein> a 57 is really good at what it does
[04:04] <FloatingGoat> Musiscian. He was reaally good. Well he suggested the shure sm58 that's why I brought it up
[04:04] <holstein> works as advertise
[04:05] <holstein> d
[04:05] <holstein> FloatingGoat: if you have a local recording studio, ask to take a tour
[04:05] <holstein> there are brands you will *not* see in a studio
[04:05] <holstein> mxl is one of those brands
[04:05] <FloatingGoat> And then he told.mw he'd sell.me an mxl
[04:05] <FloatingGoat> I want two mica
[04:06] <holstein> FloatingGoat: lol
[04:06] <holstein> why do you think he's selling that mxl ;0
[04:06] <holstein> anyways.. do what you want
[04:06] <FloatingGoat> In my studio you'll see it! :D
[04:06] <FloatingGoat> And 50 bucks is nothin so id
[04:06] <holstein> im just telling you... i have personally purchased simliar technology
[04:06] <holstein> and all i can say is... dont wast your money
[04:07] <holstein> put that $50 with $50 more and get a 57
[04:07] <FloatingGoat> Itt would bye good for secondary and backup
[04:07] <holstein> FloatingGoat: the only thing that mic is going to be "good" for is a paper weight
[04:07] <holstein> it'll be tolerable at best
[04:07] <FloatingGoat> And add 50 dollars andni got a good mic.with an okay mic
[04:08] <holstein> that at2020 is resonable
[04:08] <holstein> the rodeNT1A too
[04:08] <holstein> anyways..
[04:08] <FloatingGoat> I've heard an mxl and I don't exactly hate it
[04:09] <FloatingGoat> I don't want to sell my kidney for a mic lol
[04:09] <holstein> sure... its better than a sharp stick in the eye
[04:09] <holstein> its just... a rodeNT1a is not *that* much more
[04:09] <holstein> especially if you dont waste that $50
[04:09] <FloatingGoat> How much?
[04:09] <holstein> i can only speak from experince FloatingGoat
[04:10] <holstein> if you dont like your current gear, and want better quality stuff
[04:10] <holstein> get better stuff
[04:10] <FloatingGoat> Yeah I trust you mate
[04:10] <holstein> i purchased a lot of interfaces
[04:10] <holstein> they didnt work out
[04:10] <holstein> same rationale
[04:10] <holstein> "well, its just $80"
[04:10] <holstein> "hey, $250... maybe that'll do"
[04:10] <holstein> nope
[04:11] <holstein> i like the interface i paid $400 for
[04:11] <holstein> but, im not doen shopping
[04:11] <holstein> i feel like the 57 i have, i'll always use for something
[04:11] <holstein> the condenser mic i bought years ago for $150
[04:11] <holstein> some *much* higher end MXL
[04:12] <holstein> i gave to a friend in a trade ASAP
[04:12] <FloatingGoat> What's up with the stars?
[04:12] <holstein> FloatingGoat: if i saw that MXL mic for $20 used, i would get it... maybe
[04:13] <holstein> if i needed a condenser mic... outside or something
[04:13] <holstein> FloatingGoat: stars?
[04:14] <FloatingGoat> Yeah the *stars*
[04:14] <holstein> FloatingGoat: you see the *difference*
[04:14] <holstein> makes it *bold*
[04:14] <holstein> _underlined_
[04:15] <holstein> this is the mic i had
[04:15] <holstein> http://www.mxlmics.com/products/Studio_mics/V67g/v67g.html
[04:15] <holstein> its much cheaper now i see...
[04:16] <FloatingGoat> Naw it doesn't maake it bold.for.me lol
[04:16] <holstein> that was the first and last MXL mic i'll ever own, unless i trip on one going out the door or something
[04:16] <FloatingGoat> I wish I coulld seen I'm on phone
[04:17] <FloatingGoat> J
[04:20] <FloatingGoat> Sorry
[11:19] <nightlingo> hello!
[15:24] <holstein> nightlingo: hey
[15:46] <FloatingGoat> Hi


[11:02] <whiteboardfan> how do I contribute to xubuntu?
[11:04] <brainwash> this site explains how https://xubuntu.org/contribute/
[11:28] <whiteboardfan> hi, I read the xubuntu.com/contrib page and registed on the mailing list and lunchpad.  Now how do I get assigned something to do?  Just send an email to the mailing list?
[11:31] <whiteboardfan> I would like to help in the Documentation area for now
[11:33] <pmjdebruijn> whiteboardfan: usually people contribute changes they find useful themselves
[11:33] <pmjdebruijn> usually starting out with trivial stuff
[11:33] <pmjdebruijn> and building up from there
[11:35] <pmjdebruijn> so if you think some of the documentation is lacking or has errors, you can correct or ammend that
[11:36] <pmjdebruijn> and again, start small, build up a working relationship with the core team, before chewing off something big
[11:37] <whiteboardfan> can you suggest something small that I might start at?
[11:38] <pmjdebruijn> no particularly
[11:38] <pmjdebruijn> participating in an open source project really isn't about getting assigned stuff
[11:38] <pmjdebruijn> this isn't school or business :)
[11:39] <pmjdebruijn> just try to find something that you think is worth your time and attension
[11:39] <pmjdebruijn> and/or stick around, maybe someone else has a suggestion
[11:40] <bluesabre> if you're interested in documentation, maybe review the existing docs and see if there is any outdated info, or something not documented well enough
[11:40] <bluesabre> there's plenty to do, and none of our stuff is really "complete" :)
[11:42] <bluesabre> and definitely stick around on the channel... our team is small but international. Some are asleep, at work, or going to bed. :)
[11:43] <bluesabre> so folks will be around with more info and suggestions
[11:44] <whiteboardfan> ok
[12:12] <brainwash> bluesabre: is this correct? I don't recall the panel icons being so faint https://git.launchpad.net/xubuntu-default-settings/commit/?id=7f1ecefa802f073880024a57e9f440037123b368
[12:13] <brainwash> they used to be white (100%) and not greyish (80%)
[12:37] <TJ-> Grrr; xfce4-terminal ignores the --display= option
[13:05] <brainwash> ali1234: can you confirm that this one is actually a bug or limitation in xfwm? bug 1422626
[13:05] <brainwash> see the last comment
[13:09] <brainwash> just noticed that 18.10 does not have xfwm4 4.13 yet
[16:57] <ali1234> brainwash: i remember that bug but i don't remember what the problem was. we thought it was the terminal grid at first but it was demonstrated that wasn't the problem
[17:02] <brainwash> ali1234: a quick google search gives https://bugzilla.gnome.org/show_bug.cgi?id=751368
[17:03] <brainwash> "This is admittedly a violation of the size increments, but something done for years by most window managers under X11.."
[17:04] <brainwash> well, not by his own xfwm
[17:44] <ali1234> the problem is that tiled wwindows are not maximized
[17:57] <brainwash> half-maximized then? :)
[21:47] <bluesabre> brainwash: yeah, that adapts for the panel's loss of transparency option, speaking of...
[21:47] <bluesabre> ochosi: is that intentional (removing panel transparency), or should greybird theme the panel to 80% opacity by default?
[21:49] <ochosi> bluesabre: the background-alpha setting was removed in the 4.13 panel in favor of gdkrgba colors (previously gdkcolor)
[21:49] <ochosi> greybird never did anything about panel transparency
[21:50] <ochosi> so the expectation with 4.13 is that themes set a default transparency and if the user wants to override that, he/she has to take the panel color with the color picker and make it transparent in the color selector
[21:51] <ochosi> (would have been a bit complicated to keep the opacity setting around while still switching to gdkrgba)
[21:54] <bluesabre> ochosi: alrighty, so to keep a transparent panel, should we make it 80% opaque at all times, or set the rgba?
[21:54] <bluesabre> the first option means everything is 80%, including icons and text
[21:54] <bluesabre> the second means that swapping themes doesn't change the panel
[21:57] <ochosi> enter/leave opacity is a bad idea
[21:57] <ochosi> that way the panel will just have low contrast
[21:57] <ochosi> hardcoding the rgba in our settings package might also not be great, because it would stick if people switch themes...
[21:58] <ochosi> so the best way is probably to set the opacity in greybird
[21:58] <ochosi> that way other themes will still look ok
[22:03] <ochosi> personally i'm not sure if it's a big loss not to have the 80% transparency by default anymore
[22:03] <ochosi> haven't had this setting myself in a long tim
[22:03] <ochosi> e
[22:03] <ochosi> knome: thoughts? ^
[22:03] <ochosi> in any case, the enter/leave stuff should be reverted imo: https://git.launchpad.net/xubuntu-default-settings/commit/?id=7f1ecefa802f073880024a57e9f440037123b368
[22:04] <bluesabre> alrighty, np
[22:05] <ochosi> however now is a good time to decide
[22:05] <ochosi> UIF is only two days away if i'm not mistaken
[22:05] <ochosi> tomorrow in (or after) the meeting i'll tag elementary-xfce and greybird for upload
[22:05] <bluesabre> great :)
[22:05] <ochosi> got a last-minute fix from a contributor for pavucontrol
[22:05] <ochosi> finally it looks normal again...
[22:13] <bluesabre> woohoo


[00:05] <Bashing-om> guiverc: :D
[00:17] -SwissBot:#ubuntu-news- ::Planet:: Alan Pope: Don't Use Proposed @ https://popey.com/blog/2021/02/dont-use-proposed/
[02:48] <guiverc> Bashing-om, sorry a summary irks me for some reason.. suggested a re-word of a sentance  (maybe just the way I speak; localized strangulations of english.. but my 2c is in gdoc)  RADV+ACO one
[02:48]  * guiverc still reading
[02:53] <Bashing-om> guiverc: Still no hurry - :D
[02:54] <guiverc> another comment made (next summary)
[02:55] <guiverc> :)  esp. as my tomato & cheese roll has more of my attention currently
[03:27] <guiverc> Bashing-om, wiki read thru complete, took me ages sorry.. 4 comments made I think
[03:31] <Bashing-om> guiverc: Ho-Kay - I now play catchup on our WIKI work.
[04:11] <Bashing-om> UWN: guiverc: spit on the polish done - any others guys ?
[07:47] -SwissBot:#ubuntu-news- ::Planet:: Full Circle Magazine: Full Circle Weekly News #200 @ https://fullcirclemagazine.org/podcast/full-circle-weekly-news-200/
[11:43] -SwissBot:#ubuntu-news- ::Planet:: Jonathan Riddell: OpenUK Belonging @ https://jriddell.org/2021/02/15/openuk-belonging/
[15:04] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: New Linux 5.11 Released, This is What’s New @ https://www.omgubuntu.co.uk/2021/02/new-linux-5-11-kernel-features (by Joey Sneddon)
[17:00] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Design and Web team summary – 15 February 2021 @ https://ubuntu.com//blog/design-and-web-team-summary-15-february-2021
[17:46] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: PinePhone Devs Finally Decide on a Default Distro @ https://www.omgubuntu.co.uk/2021/02/pinephone-picks-manjaro-with-plasma-mobile-as-default-os (by Joey Sneddon)
[20:59] <Bashing-om> UWN: Pulling "WIP" - checked log and no further edits are known - will push soonest saved.
[21:01] <Bashing-om> UWN: Nope - >> "Internal Server Error" --- trying again.
[21:04] <Bashing-om> UWN: Yup :D Logged onto our WIKI . Pulling "WIP" ATT .
[21:17] <Bashing-om> UWN: ubuntu-news@lists is away - doing the Forum post next.
[21:24] <guiverc> push 670 to fridge?
[21:32] <Bashing-om> guiverc: Yup push to the Fridge - all looks good to me :D
[21:34] <Bashing-om> UWN: Forum post done with abridgements - doing the re-directs.
[21:34] <guiverc> https://fridge.ubuntu.com/2021/02/15/ubuntu-weekly-newsletter-issue-670/
[21:36] <guiverc> tweeted
[21:42] -SwissBot:#ubuntu-news- ::Planet:: Alan Pope: Going Backwards @ https://popey.com/blog/2021/02/going-backwards/
[21:43] <guiverc> fb posted
[21:47] <Bashing-om> guiverc: 670 is now in history - clear now to wipe the evidence ?
[22:01] -SwissBot:#ubuntu-news- ::Planet:: The Fridge: Ubuntu Weekly Newsletter Issue 670 @ https://fridge.ubuntu.com/2021/02/15/ubuntu-weekly-newsletter-issue-670/
[22:14] <guiverc> yep clear away (sorry for delay)
[22:16] <Bashing-om> guiverc: Busy busy busy - wipping away.
[22:18] -SwissBot:#ubuntu-news- ::Planet:: Marcin Juszkiewicz: EBBR on EspressoBin @ https://marcin.juszkiewicz.com.pl/2021/02/15/ebbr-on-espressobin/
[22:22] <Bashing-om> UWN: We do issue 671 :D


[09:51] <FuLgOrE> hi
[09:52] <FuLgOrE> I follow the mailing list for ubuntu touch. the most topics I can see on https://lists.launchpad.net/ubuntu-phone/ but all topics related to Ubuntu Touch on Nexus 5 I cannot see
[09:52] <FuLgOrE> does anybody know the reason for that?
[09:53] <FuLgOrE> furthermore I tried to answer on mailing list. The email topic was "[Ubuntu-phone] Nexus 5". This is also not visible on launchpad
[09:53] <FuLgOrE> Am I doing something wrong? I relied with thunderbird with the "reply on list" (DE: "Liste antworten")
[14:10] <dch> hey, I’m working through the Very Nice http://packaging.ubuntu.com/html/packaging-new-software.html docs, wondering if I can pass custom arguments to configure somehow when it runs?
[14:29] <cjwatson> dch: sure, in debian/rules: override_dh_auto_configure:\n\tdh_auto_configure -- <arguments>
[14:29] <cjwatson> (where \n -> newline, \t -> hard tab)
[14:30] <dch> cjwatson: thanks, you are a miracle worker :-) that just saves me ~ 45 minutes round trip testing  by skipping integration tests :-)
[14:30] <cjwatson> dch: e.g. http://bazaar.launchpad.net/~ubuntu-branches/debian/sid/man-db/sid/view/head:/debian/rules
[16:24] <dch> ok more noob questions. My package builds correctly, passes lintian with a few bleats, but the resulting .deb files are almost completely empty - no /usr/bin or similar files.
[16:26] <dch> more info here https://github.com/dch/couchdb-launchpad/blob/master/debian/rules
[16:27] <dch> I’m assuming this is something very obvious?
[16:30] <dobey> dch: #ubuntu-packaging is a beter channel for packaging questions. but you don't have any install files to specify what files go in what binary packages
[16:43] <dch> dobey: thanks for the channel tip!
[21:57] <karni> Hi guys, I've been pondering the documentation (both 1.0 and devel), can't find how to fetch a list of bugs via launchpad API for a given project. Any hints?
[21:58] <dobey> project.searchBugs()?
[21:58] <karni> dobey: I mean a raw URL
[21:58] <karni> like https://api.launchpad.net/devel/bugs?ws.op=getBugData for a given project
[21:58] <dobey> a URL for the API endpoint?
[21:58] <karni> dobey: exactly :)
[21:59] <karni> dobey: Retrieve a list of bugs for a given project.
[22:00] <dobey> err, searchTasks
[22:00]  * karni looks
[22:01] <dobey> https://api.launchpad.net/1.0/unity-scope-click?ws.op=searchTasks
[22:01] <dobey> for example
[22:01] <dobey> https://launchpad.net/+apidoc/1.0.html#project
[22:02] <karni> dobey: perfect! Thanks so much, Rodney
[22:02] <dobey> you probably want to pass in status= or something to, to filter out ones you don't want to see
[22:02] <dobey> sure


[14:11] <jucbit> hi, someone can help me with video online? i cant watch youtube xD
[14:16] <hateball> jucbit: what happens? no image at all? what browser?
[14:17] <jucbit> firefox, chromium and chrome
[14:17] <jucbit> no sound and skipping images
[14:19] <eagle275> connection slow ?
[14:19] <hateball> what kind of computer? does it have enough performance to play?
[14:20] <jucbit> yes it have enough
[14:21] <jucbit> connection its ok
[14:21] <jucbit> i have lubuntu 18.04
[14:21] <eagle275> same here ..
[14:22] <lubot5> <Dario De La Puente> Check cores of procesador
[14:22] <eagle275> what computer ? RAM / CPU ?
[14:23] <lubot5> <Dario De La Puente> @eagle275, Check cores of cpu
[14:24] <eagle275> its a VM for me .. can vary cores .. video runs fine .. 720p / fullHD
[14:26] <lubot5> <Dario De La Puente> @jucbit, Youtube use html 5 and its use cpu no gpu for post process