[07:46] <MartinB> Hey I just installed ubuntu studio 18.10 and cant find the vst for zynaddsubfx. I only find and lv2 version in synaptics. help
[07:46] <MartinB> I need vst for renoise
[07:47] <MartinB> and the old gui


[01:10] <liuxg> I have compiled a .snap file for the java sample app at https://github.com/ubuntu-core/snapcraft/tree/master/examples/java-hello-world, and I have deployed onto my KVM. what is the correct command to run the java? I did "java-hello-world.wrapper", but I got error like "java-hello-world.wrapper" command is not found error.
[01:38] <liuxg> I have compiled a .snap file for the java sample app at https://github.com/ubuntu-core/snapcraft/tree/master/examples/java-hello-world, and I have deployed onto my KVM. what is the correct command to run the java? I did "java-hello-world.wrapper", but I got error like "java-hello-world.wrapper" command is not found error.
[06:51] <woodrowshen> hi, i have a problem about snapcraft, may someone give a hand ?
[07:53] <dholbach> good morning
[08:02] <zyga> good morning :)
[08:04] <fgimenez> good morning zyga and all
[09:27] <longsleep> Good morning snappy
[09:28] <longsleep> Now with snapcraft and snappy on GitHub, do you guys accept and review pull requests there or is that still to be done through launchpad/bzr ?
[09:28]  * longsleep hopes to get rid of git-bzr eventually
[09:43] <mvo> longsleep: we prefer github now
[09:44] <mvo> longsleep: we will stop the bzr repos at some point (once the migration is fully done)
[09:52] <longsleep> mvo: yay i like this!
[09:58] <dholbach> niemeyer, do you know when the snapcraft daily builds will be set up to build from github?
[09:59] <dholbach> can we also set https://launchpad.net/snapcraft up so that bugs are not accepted any more?
[10:04] <woodrowshen> hi, can I ask snapcraft related problems here ? @@a
[10:05] <ogra_> woodrowshen, indeed
[10:05] <ogra_> (not all people that can answer might be awake yet though, so be patient)
[10:06] <woodrowshen> ogra_: thanks. :)
[10:07] <woodrowshen> woodrowshen: i just clear one thing about snapcraft, can the snapcraft build a armhf snap ?
[10:07] <woodrowshen> i just clear one thing about snapcraft, can the snapcraft build a armhf snap ?
[10:07] <ogra_> yes, but it needs an armhf environment
[10:08] <ogra_> (i.e. a native armhf install on a board, or an armhf container or a vm)
[10:08] <ogra_> there is no cross building yet
[10:09] <woodrowshen> ogra_: ok, that's point i'm stuck...
[10:09] <ogra_> what do you want to do ?
[10:10] <woodrowshen> use snapcraft to build grafana snap for armhf
[10:10] <ogra_> well, there are several ways to do that
[10:11] <ogra_> create an armhf chroot on your PC is most likely the easiest but wont work aith all compilers (go and .net/mono definitely have issues)
[10:11] <ogra_> *with
[10:12] <ogra_> assuming you have an arm board for testing your snap, using a chroot on the arm board would then be my second choice
[10:13] <ogra_> and third you can indeed run a full arm VM in which you build, though thats the slowest option
[10:16] <woodrowshen> thanks your suggestion. Fortunately, we have a native arm env on cloud, scaleway :)
[10:17] <woodrowshen> for originally, i just wrote makefile to use cross-toolchain to build it under snapcraft, and gave a armhf in the field of architecture in the snapcraft.yaml
[10:18] <woodrowshen> but i found the output snap filename and package.yaml was still amd64 string. XD
[10:19] <longsleep> woodrowshen: See https://github.com/ubuntu-core/snapcraft/pull/53 - it has instructions in the description how to set the output arch for snapcraft by using environment variables.
[10:21] <woodrowshen> longsleep: cool! so i don't need a arm platform, right ?
[10:21] <longsleep> mvo: Is travis supposed to work for snapcraft? https://travis-ci.org/ubuntu-core/snapcraft/builds/88307476 does not seem to be related to whatever i changed
[10:21] <longsleep> woodrowshen: Not for packaging previously built stuff with snapcraft or for non binary stuff.
[10:24] <longsleep> mvo: found the travis pr, so ignore the question :)
[10:26] <mvo> longsleep: one issue with the integration tests, otherwise its looking good in the PR
[10:34] <svij> I've just tried out snapcraft the first time and found a bug. Should I open a bug report or directly fix it in a PR?
[10:44] <pindonga> so, I managed to successfully build both and amd64 and an armhf snap of flexget, now I'd like to create a snap that works in both architectures... what's the best way to do that right now?
[10:46] <longsleep> pindonga: last time i asked that it was not easily possible - you can do it manually by some wrapper scripting similar to what webdm is doing.
[10:47] <pindonga> so, basically manually combine the contents of both snaps and add a wrapper that runs the arch specific binary ?
[10:48] <longsleep> pindonga: thats how webdm is doing it yes
[10:48] <pindonga> ack, thx
[10:50] <woodrowshen> longsleep: thank you, i think i still needs arm machine because i used plugin: make to build the grafana and there's no deb for armhf.
[10:51] <longsleep> woodrowshen: yeah if you need to compile or use any other plugin than copy (or debs) then you need armhf environment
[10:53] <woodrowshen> longsleep: anyway, i got lots of useful information, thanks your great help
[12:15] <ogra_> ls
[12:15] <ogra_> bah !
[12:23] <ogra_> ogra@anubis:~/Devel/branches/project-rootstock-ng$ time ./rootstock-touch -s xenial -a amd64 -t ubuntu-core -m http://localhost:9999/ubuntu
[12:23] <ogra_> ....
[12:23] <ogra_> real	2m24.491s
[12:23] <ogra_> user	1m40.186s
[12:23] <ogra_> sys	0m44.196s
[12:23] <ogra_> WHEE !
[12:24] <sergiusens> pindonga, thanks
[12:25] <pindonga> sergiusens, thank you :)
[12:25]  * pindonga this > < close to finally submit a snap to the store for real
[12:25] <pindonga> just need to make the snap multi arch
[12:45] <sergiusens> tedg, did you find it
[12:46] <sergiusens> afaik, you don't need plugins bzr fast-export --plain . | git fast-import
[12:46] <zyga> sergiusens: hey, so snapcraft is no longer using bzr?
[12:47] <sergiusens> zyga, don't you read email ;-)
[12:47] <zyga> sergiusens: I have too much, I just hold hoping it will eventually stop ;)
[12:47] <zyga> sergiusens: (still catching up after holidays)
[12:47] <sergiusens> zyga, https://github.com/ubuntu-core/snapcraft
[12:47] <zyga> sergiusens: yeah, I see
[12:47] <zyga> sergiusens: so everything including issues is now on github?
[12:47] <sergiusens> zyga, yes
[12:48] <zyga> sergiusens: nice!
[12:48] <zyga> sergiusens: that's a very interesting move
[12:48] <sergiusens> zyga, I haven't killed the issues on lp yet as there are active conversations I don't want to destroy
[12:48] <zyga> sergiusens: right
[12:49] <zyga> sergiusens: oh, snappy is there too
[12:49] <zyga> mmm, cool
[12:55] <dholbach> sergiusens, tedg: do you know what we're going to do with daily builds and lp bugs of snapcraft after the move to github?
[12:55] <sergiusens> dholbach, I alreday moved the bugs to github issues
[12:56] <sergiusens> dholbach, daily builds I need to sync with mvo
[12:56] <dholbach> ok, cool
[12:57] <dholbach> or well "cool" :)
[12:57] <dholbach> sergiusens, can we close LP bugs for snapcraft completely?
[12:57] <sergiusens> dholbach, I'll be closing bugs today, but not the tracker as conversations are happening there right now
[12:58] <dholbach> ok, thanks
[12:58] <mvo> sergiusens: hi
[12:59] <sergiusens> mvo, hello hello
[12:59] <mvo> sergiusens: I can set them up for you, you will need a code import and update the daily build recipe
[12:59] <sergiusens> mvo, oh, and we need to talk about other things too
[12:59] <sergiusens> mvo, does it support gbp?
[13:00] <mvo> sergiusens: I think it does not matter as long as there is debian/* dir
[13:00] <sergiusens> oh, that works; but it needs to be bzr, right?
[13:00] <mvo> sergiusens: iiirc/afaik bzr-builddeb and the bzr daily builders are different tools
[13:00] <mvo> sergiusens: yes, thats why you need the code import
[13:01] <sergiusens> mvo, right, it could of been a straight git code import too ;-)
[13:01] <sergiusens> mvo, have we seen what stgraber is doing with lxd?
[13:02] <mvo> sergiusens: its easy we do it for snappy
[13:11] <tedg> sergiusens: I just pulled fast-import from LP in the plugins dir
[13:12] <tedg> Worked :-)
[13:19] <sergiusens> tedg, oh, by dir is possible too? nice
[13:19] <sergiusens> mvo, heh, but but I wanted to remove ./debian/ from master and put it in a debian branch ;-)
[13:19] <mvo> sergiusens: if you use full branches, that works as well, just make sure you import the right branch
[13:20] <sergiusens> mvo, it won't be useful for daily builds though as we would have to constantly sync 'master' with 'debian'
[13:25] <mvo> sergiusens: indeed
[13:40] <rickspencer3> so, I am snapping frotz (for "interactive fiction")
[13:41] <rickspencer3> frotz puts the save files next to the data files that it opened
[13:41] <rickspencer3> so, for example, if I have ~/zork/ZORK1.DAT , it will make the save file ~/zork/game1.SAV
[13:42] <rickspencer3> so, where should I put the data files in my snap so the save files work? i.e. in a readable/writable space?
[13:42] <tedg> Could you put a link to the data file in the writable directory and then run it with that as the path to the data?
[13:42] <rickspencer3> can you tell me more about that strategy?
[13:42] <fancycode> finally got u-d-f to cross-build an armhf system image including built-in snaps on my amd64 machine :-) pull-request/proposed branch are ready for review
[13:43] <tedg> So do a ln -s $SNAP_APP_PATH/zork.DAT $SNAP_APP_USER_DATA_PATH/
[13:43] <tedg> Then do a frotz $SNAP_APP_USER_DATA_PATH/zork.DAT
[13:44] <rickspencer3> tedg, will frotz $SNAP_APP_USER_DATA_PATH/zork.DAT work in the binaries declaration of snapcraft?
[13:45] <tedg> rickspencer3: It would, but I think you'll need a shell script to do the link anyway.
[13:45] <tedg> So you'll probably want a wrapper that sets things up and does an exec
[13:46] <rickspencer3> ok
[13:46]  * rickspencer3 tries
[13:47] <mvo> jdstrand: hey, I noticed your security-cleanup branch, is there anything I can help with?
[13:47] <jdstrand> mvo: not just yet. everything seems to work but I need to add a bunch of tests
[13:48] <jdstrand> mvo: actually that isn't true, hw-assign needs work still
[13:49] <jdstrand> anyway, it is a really good start
[13:49] <mvo> jdstrand: I'm exciting if it means the hook is gone afterwards :)
[13:49] <mvo> jdstrand: uh, excited of course
[13:50] <jdstrand> mvo: you could answer me this: what is the *Remote* code expected to do? I've been ignoring it thus far
[13:50] <mvo> jdstrand: remote code?
[13:51] <jdstrand> mvo: oh yes, the hook will be gone, so will sc-filtergen (ie, no python), all the weird directories cleaned up (ie, just /var/lib/snappy/apparmor afterwords) and security-override is getting revamped to be:
[13:51] <jdstrand> binaries:
[13:51] <jdstrand>  - foo
[13:51] <jdstrand>    apparmor:
[13:51] <jdstrand>     read-paths: /path/to/something
[13:52] <jdstrand> (instead of doing the weird json override)
[13:52] <mvo> jdstrand: can I use the branch for testing already? for the squashfs work, the hooks will no longer work because the click manifest can not be generated because at build time the origin is unknown. so having this would make my life a lot easier (even if tests are missing :)
[13:52] <jdstrand> mvo: yes, like, install remote and stuff
[13:52] <jdstrand> mvo: sure, that's fine. most of the code is changed in security.go. obviusly, I had to change the other parts to use the new internal api
[13:53] <mvo> jdstrand: nice, I have a look
[13:53] <jdstrand> mvo: I did rip out aaClickHook, etc where I found it, but I did not remove .click or the manifest
[13:53] <jdstrand> mvo: I figured I'd focus on the security bits and let others do the nail in the coffin for click compat
[13:53] <mvo> jdstrand: so "install remote", I'm probably a bit slow today, but I still don't know exactly what you mean
[13:54] <jdstrand> ok, let me get the function name
[13:54] <mvo> jdstrand: yeah, I will create a branch based on yours and kill the rest of the click compat :)
[13:55] <jdstrand> RemoteSnapPart, RemoteManifest, (s *RemoteSnapPart) Install(), etc, etc
[13:56] <jdstrand> mvo: fyi, I'm going to keep the launcher json .additional file for this branch to reduce the (already massive) changes
[13:56] <mvo> jdstrand: aha, ok. so thats just a snap on the server, to install it, snappy will download it and install it as a SnapPart, i.e. a normal snap
[13:57] <jdstrand> mvo: I would expect someone (could be anyone) to clean that up in a separate step
[13:57] <mvo> jdstrand: can I write some tests for you to get the branch landed earlier :) I'm really keen (and excited) about it, massive win for me
[13:57] <jdstrand> mvo: ok, so that remote stuff I can ignore
[13:57] <jdstrand> mvo: I would love help. I'm sprinting next week and low on resources in general
[13:58] <mvo> jdstrand: hangout or irc so that you can give me hints what needs to be done?
[13:59] <mvo> jdstrand: I will also migrate the branch to git along the way if you don't mind
[13:59] <jdstrand> mvo: it isn't heavily tested. things I know need work are finishing hw-assign, making sure framework-policy updates work as expected and deal with the upgrade path
[13:59] <jdstrand> mvo: re git, that's fine-- I started this right before the announcement
[14:00] <jdstrand> mvo: if you focus on the tests and code reviews outside of hw-assign, I think that would be the best first step
[14:01] <jdstrand> mvo: there is an additional cmd/policygen, that I expect to be used as part of a systemd unit for detecting policy updates when system policy changes
[14:02] <mvo> jdstrand: ok
[14:03] <jdstrand> mvo: my thoughts were: create a ssytemd unit, run something that checks if the system poicy (ie, ubuntu-core-security, apparmor, libseccomp) was changed. if so, see what snaps are affected. for those that are affected, run policygen
[14:03] <jdstrand> mvo: maybe it makes sense to move cmd/policygen into 'snappy policygen'
[14:04] <jdstrand> mvo: I haven't gone that far yet. if you want to think about how all that should work, that would be helpful as well
[14:05] <jdstrand> mvo: or not, I know you're busy, but I figured that would be an area where the snappy core team would definitely want input
[14:05] <jdstrand> mvo: but with this we solve the 'seccomp policy not updated on upgrades' card
[14:06] <jdstrand> (and move apparmor to the new mechanism, since it is currently using aa-clickhook)
[14:07] <jdstrand> anyway, that is probably information overload. thinking about if policygen should be its own command or in snappy is one thing to consider, and thinking about my design thoughts on upgrades is another
[14:09] <mvo> jdstrand: in a meeting right now, but https://github.com/mvo5/snappy/tree/from-bzr/snappy-security-cleanup is the imported branch if you want to continue with that
[14:09] <jdstrand> ok, thanks
[14:10] <jdstrand> mvo: thanks
[14:36] <fgimenez> elopio, we could use build tags, take a look at http://stackoverflow.com/a/28007631
[14:37]  * elopio looks.
[14:37] <elopio> ah, nice!
[14:41] <mvo> jdstrand: thanks, meeting is over, I updated https://github.com/mvo5/snappy/tree/from-bzr/snappy-security-cleanup with master, fixed the imports and its doing fine, I look at the missing tests you mentioned now
[14:42] <jdstrand> mvo: note, the existing framework-policy updates and hw-assign tests need to be gone through and some certainly need to be reworked
[14:49] <mvo> jdstrand: interessting, they don't fail right now
[14:49] <jdstrand> mvo: no, because I stripped out the failing parts. hw-assign isn't done, so iirc, I just removed the failing tests expecting to add new tests
[14:50] <jdstrand> mvo: framework-policy I removed the 'touch' bits since that was only relevant for touching the symlink for aa-clickhook to work
[14:50] <jdstrand> mvo: but, we need to have tests making sure that policy is getting updated if framework-policy does
[14:50] <mvo> jdstrand: indeed, thanks
[14:52] <mvo> jdstrand: I let me know how best to coordindate, my plan is to go over the diff now and tweak if something stands out, add tests and then get back to what you wrote here and in +2h I will stop with the branch. sounds ok?
[14:53] <jdstrand> you plan to write all the tests in 2 hours? wow :)
[14:53] <jdstrand> sure, that sounds fine-- thanks for the help
[14:53] <mvo> jdstrand: nono :) its just that I need to stop in +2h for dinner :)
[14:53] <mvo> jdstrand: if I manage a single test I will consider myself lucky
[14:54] <jdstrand> hehe
[15:02] <longsleep> jdstrand: yesterday you told me about /{dev,run}/shm/snaps/@{APP_PKGNAME}/@{APP_VERSION}/* - that does not seem to exist. Should i add a bug for it?
[15:02] <jdstrand> longsleep: yes. against ubuntu-core-launcher
[15:03] <jdstrand> longsleep: basically, it should do the same thing for that as is being dome in $HOME
[15:03] <jdstrand> done*
[15:03] <longsleep> jdstrand: all right
[15:07] <longsleep> jdstrand: see bug #1511762
[15:16] <jdstrand> longsleep: thanks!
[16:03] <elopio> Hello fancycode.
[16:04] <fancycode> elopio: Hi
[16:05] <elopio> heh, I had a huge lag :)
[16:27] <mvo> jdstrand: quick question about findCaps() - the "template" parameter is only used to test for emptiness. is that intended?
[16:42] <snappy_> ubuntu core not updating on snappy edge.  Any suggestions?
[16:44] <rickspencer3> tedg, so, if I am using your method of sym linking to the app data directory, and execing the sh file ...
[16:44] <rickspencer3> sorry, I mean exec'ing in the sh file
[16:44] <rickspencer3> in snapcraft.yaml, do I exec the sh file?
[16:45] <rickspencer3> i.e. this is in the shell script I put in bin : exec $SNAP_APP_USER_DATA_PATH/frotz $SNAP_APP_USER_DATA_PATH/
[16:45] <rickspencer3> so do I define the binary like this?
[16:45] <rickspencer3>  zork1:
[16:45] <rickspencer3>   exec: bin/zork1
[16:46] <rickspencer3> also, is there reference documentation for the allowable yaml that I could read?
[16:47] <tedg> Yeah, that should work. Make sure to make the script executable.
[16:47] <tedg> Let me find that doc
[16:49] <jdstrand> mvo: yes
[16:49] <jdstrand> mvo: if the template and caps are empty, we set caps to 'network-client'
[16:50] <jdstrand> mvo: that is the only reason why template is needed
[16:51] <mvo> jdstrand: aha, thanks
[16:51] <tedg> rickspencer3: https://developer.ubuntu.com/en/snappy/guides/package-metadata/
[16:51] <rickspencer3> thanks tedg
[16:52] <jdstrand> mvo: when reviewing this, do remember that 'security-override' is revamped
[16:52] <jdstrand> mvo: if you recall, before it would point to a json file that was something aa-clickhook would use
[16:53] <elopio> ogra_: could you check why the latest images don't have the boot fixes by Chipaca?
[16:53] <elopio> snappy_: are you getting an error?
[16:53] <Chipaca> elopio: at a pinch, i'd wager it's because it was built from lp and not from github
[16:53] <jdstrand> mvo: that is rather weird for a compat-less snappy, so I took the important parts out of that json and put it into the yaml directly
[16:53] <mvo> jdstrand: thanks, I started with some tests and tiny refactoring and pushed to git, when you have time I would appreciate if you could fork/remerge. I will stop soon for today
[16:53] <mvo> jdstrand: yeah, thats pretty nice
[16:54] <elopio> ah, so we'll have the daily sync, then the daily release.
[16:54] <jdstrand> mvo: that has a number of nice qualities like, you can use the default template but add a single syscall
[16:54] <mvo> jdstrand: look al lvery nice, I'M super happy about this branch, thanks a lot!
[16:55] <jdstrand> mvo: nice! yw
[16:55] <jdstrand> it was always something I wanted to do, but alas, time
[16:56] <mvo> jdstrand: :)
[16:56] <mvo> jdstrand: a common problem
[16:56] <mvo> jdstrand: hm, looks like I broke something, so please do not merge just yet
[17:07] <snappy_> elopio: no errors.  just stuc in version 117
[17:08] <elopio> snappy_: I don't have 117 and that's too old to download from the server. snappy_ please report a bug.
[17:11] <mvo> jdstrand: ok, unbroke it, tests started and coverage increased etc, still work left of course, let me know if its looking ok and when you have a git repo so that I can merge from there too
[17:18] <snappy_> elopio: it says updated to version 229.  and "reboot to use the new ubuntu-core" when I run update.  But it doesn't update on reboot
[17:20] <elopio> snappy_: ah, you should have some information on the console. Is that kvm?
[17:28] <snappy_> elopio: yes. its kvm
[17:50] <elopio> snappy_: boot your machine with something like kvm -m 512 -redir :8090::80 -redir :8022::22 -snapshot /media/elopio/vms/images/snappy/ubuntu-snappy-rolling-edge-amd64-generic-214.img --serial stdio > out.log
[17:51] <elopio> try to reproduce the problem, and attach the out.log to the bug report.
[17:51] <snappy_> elopio: k
[18:08] <snappy_> elopio: how to download current .img.xz for snappy edge?
[18:11] <elopio> snappy_: I prefer to use u-d-f. Something like:
[18:11] <elopio> sudo ubuntu-device-flash core rolling –channel edge –developer-mode -o ubuntu-snappy-rolling-edge-amd64-generic.img
[18:11] <beuno> (amd64)ubuntu@localhost:~$ sudo snappy update
[18:11] <beuno> another snappy is running, try again later
[18:11] <beuno> snappy has been stuck there for a good 30 minutes
[18:12] <beuno> how can I know what it's doing?
[18:14] <elopio> beuno: try sudo journalctl -u snappy-autopilot.service
[18:14] <elopio> on the next version, that message is improved a little.
[18:14] <beuno> ah
[18:14] <beuno> it answered itself while I was waiting
[18:14] <beuno> snappy autopilot triggered a reboot to boot into an up to date system-- temprorarily disable the reboot by running 'sudo shutdown -c'
[18:14] <beuno> The system is going down for reboot at Fri 2015-10-30 18:24:37 UTC!
[18:15] <elopio> beuno: so it was just a slow download. Sounds like you are in latin america.
[18:16] <beuno> elopio, gathering from the fact that I am wearing flip-flops: yes
[18:16] <ogra_> is that the continent thats connected via a dialup line to europe ?
[18:16] <beuno> mvo, sergiusens, Chipaca, I wonder if we could return a more information-rich message?
[18:16] <beuno> ogra_, it's mostly connected by salt water
[18:16] <ogra_> lol, true
[18:18] <elopio> beuno: the new message says:
[18:18] <elopio> The snappy autopilot is updating your system in the background. This may take some minutes. Will try again in %d seconds...
[18:18] <elopio> Press ctrl-c to cancel.
[18:18] <elopio> how does it sound to you?
[18:18] <beuno> a lot better!
[18:19] <elopio> I agree, mvo makes cool stuff.
[18:19] <beuno> +1000
[18:35] <tetor1> hellow everybody! I have some problem. I tried to create framework type snap named 'cURL for Snappy Core'. It's a wrapper of cURL, the users can use curl command at Snappy Ubuntu.
[18:37] <tetor1> And I can create it and publish but some errors thrown at web register page. I think those problems are permission or setting file is incorrect.
[18:38] <tetor1> But I have no idea to fix it.
[18:38] <tetor1> I create 'ask Ubuntu' question. Can you help me, someone?
[18:39] <tetor1> http://askubuntu.com/questions/690953/lint-control-architecture-valid-contents-error
[18:44] <beuno> tetor, for starters, it won't be accepted in the store as a framework
[18:44] <elopio> tetor: why are you making it a framework?
[18:45] <elopio> tetor: framework need to be manually reviewed before putting them in the store, so you'll have to wait for somebody to take a look
[18:45] <elopio> they will probably tell you that you don't need a framework to make a curl snap.
[18:47] <snappy_> elopio: thx
[18:50] <beuno> I can tell you already, it won't get in
[18:50] <beuno> found binaries for architecture 'all': bin/curl lint_control_architecture_valid_contents
[18:50] <tetor> Oh, year? I thought the cause of reject was setting file (package.yaml) was incorect.
[18:50] <beuno> is because you've specified that it runs on all architectures, but it's compiled so clearly it targets specific architectures
[18:51] <tetor> beuno: yes! it's error message!
[18:56] <tetor> I got it. I'll write target arch e.g. x86_64 and try re publish!
[18:59] <tetor> Why I'm making it is, I want to run some command in Snappy. e.g. curl tmux zsh... Without these, I can't work well.
[19:01] <beuno> tetor, again, note that it won't be approved as a framework
[19:02] <tetor> I have more one question. where is the reference of package.yaml?
[19:03] <tetor> beuno umm.. how can I be the 'not starter'?
[19:40] <ogra_> tetor, "for starters" = "first of all" ...
[19:41] <ogra_> frameworks are for shared system resources that other snaps can use ... for example bluetooth
[19:41] <ogra_> a single app will not be accepted as a framework
[19:44] <tetor> Sorry, English is too difficult for me…
[19:45] <tetor> I see, I'll try to re-create cURL for Snappy as application. Many thanks all!!
[20:26] <elopio> tetor: take a look at snapcraft: https://github.com/ubuntu-core/snapcraft/tree/master/examples/downloader-with-wiki-parts
[20:27] <elopio> it will make things easier.
[20:40] <tetor> elopio: awesome!! Thank you!
[22:44] <snappy_> mir not starting on snappy 1504 edge


[18:00] <yofel> are there any checksums available for http://kernel.ubuntu.com/~kernel-ppa/testing/ ? (or zsync, rsync, whatever...)
[18:12] <AbhiJit> hello
[18:13] <AbhiJit> how to know the latest kernel version in lucid?
[18:13] <AbhiJit> 'how to'?
[18:13] <AbhiJit> hello?
[18:15] <yofel> a) patience please b) linux-image-generic in lucid-updates is <IP_ADDRESS>.25 so it should be 2.6.32-24 -proposed has 32-25
[18:20] <AbhiJit> anyone alive here?


[08:31] <Kilos> morning loco peeps
[18:44] <tsimonq2> o/ Kilos
[18:47] <Kilos> o/ tsimonq2
[23:12] <Guest29980> I want to take the 10 windows and put ubuntu 15:10
[23:13] <wxl> Guest29980: so download an image, burn it to some media, plug it in, reboot, and install away!
[23:15] <Guest29980> thank you so much
[23:15] <wxl> np


[09:07] <FourDollars> Where is the source tree for casper?
[17:39] <Lin-Buo-Ren> Hello, just like @FourDollars previously mentioned, I'd like to know where is the main development source tree of the casper package.
[17:40] <Lin-Buo-Ren> I also created an question on Launchpad Answers at /ubuntu/+source/casper/+question/665742
[17:43] <Lin-Buo-Ren> Currently I assume that it is located at /ubuntu/bionic/+source/casper as it seems to be a native Ubuntu package and likely to be maintained in the ubuntu in-development release


[00:13]  * thumper looks
[00:16] <thumper> mwhudson: first try no, updating source code and download cache now
[00:21] <thumper> mwhudson: can you look at   https://dev.launchpad.net/BuildBranchToArchive/MultipleSeriesBuilds and determine if we know enough to change the model?
[00:23] <mwhudson> thumper: i think we know basically enough
[00:23] <thumper> ok
[00:24] <mwhudson> thumper: i guess it reopens the question of "what namespace do recipes live in"
[00:24] <thumper> mwhudson: can you plan a branch count (1 or more as necessary) to change the model?
[00:24] <thumper> mwhudson: I think we are going to have recipes at ~user/distro/+source/packagename/+recipe/name
[00:24] <mwhudson> thumper: i'd have thought one would be enough
[00:24] <thumper> ok
[00:25] <mwhudson> thumper: ok that makes sense
[00:28] <thumper> mwhudson: the interesting bit is how to make ~user/distro and ~user/distro/+source/packagename (and possibly ~user/distro/distroseries and ~user/distro/distroseries/packagename) useful objects
[00:28] <thumper> mwhudson: consider ~user/project
[00:30] <mwhudson> thumper: 'useful objects' ?
[00:30] <mwhudson> i can see useful pages
[00:30] <thumper> mwhudson: at code.lp.net/~thumper/distribution ?
[00:31] <thumper> mwhudson: PersonDistro c.f. PersonProject
[00:31] <thumper> mwhudson: PersonDistroSeries
[00:31] <thumper> et al
[00:31] <mwhudson> right
[00:31] <mwhudson> maybe i'm unimaginative, but that doesn't seem very interesting
[00:31] <thumper> what useful pages can you see?
[00:31] <mwhudson> it's just work isn't it?
[00:31] <thumper> yes
[00:31] <mwhudson> thumper: i think we're saying the same thing in different ways, ignore my objection
[00:32] <thumper> ok
[00:32] <thumper> jml suggested there may be some multi-object adapter thing that we could use instead of having explicit objects
[00:32] <thumper> so (Person, Product) instead of PersonProduct
[00:32] <mwhudson> oh right
[00:33] <thumper> I'm not so sure there is
[00:33] <thumper> or even if there is that it is a better solution
[00:33] <thumper> simple is better than complex
[00:33] <mwhudson> well
[00:33] <mwhudson> um
[00:33] <thumper> although which is simple is a matter of opinion
[00:33] <mwhudson> i think you have to have something like PersonProduct
[00:33] <mwhudson> that you can hang a view off
[00:34] <thumper> mwhudson: btw, make worked with updated download-cache
[00:34] <mwhudson> it doesn't have to be anything more than just a container object though
[00:34] <mwhudson> thumper: :(
[00:34] <mwhudson> well i guess yay that launchpad isn't broken for _everyone_
[00:34] <thumper> what are your symptoms?
[00:35] <mwhudson> mwh@grond:trunk$ make
[00:35] <mwhudson> utilities/shhh.py PYTHONPATH= ./bin/buildout \
[00:35] <mwhudson>                 configuration:instance_name=development -c buildout.cfg
[00:35] <mwhudson> While:
[00:35] <mwhudson>   Installing.
[00:35] <mwhudson>   Getting section i18n.
[00:35] <mwhudson>   Initializing section i18n.
[00:35] <mwhudson>   Installing recipe z3c.recipe.i18n.
[00:35] <mwhudson> Error: There is a version conflict.
[00:35] <mwhudson> We already have: zope.interface 3.4.0
[00:36] <thumper> hmm..
[00:36] <thumper> my buildout bit isn't running
[00:36] <mwhudson> it seems to be finding the system zope.interface
[00:37] <thumper> and now I'm wondering what'll happen if I remove my eggs
[00:37] <mwhudson> thumper: dpkg -l python-zopeinterface
[00:37] <mwhudson> ?
[00:37] <thumper> un
[00:37] <mwhudson> !
[00:37] <thumper> however in a python shell I can import zope.interface
[00:38] <mwhudson> !!
[00:38] <mwhudson> lots of things seem to depend on it here
[00:38] <thumper> ii  python-zope.interface                   3.5.2-1
[00:38] <mwhudson> hmmm
[00:39] <mwhudson> HMMM
[00:39] <mwhudson> well
[00:39] <mwhudson>  apt-get install python-zope.interface
[00:39] <mwhudson> which replaces the package
[00:39] <mwhudson> and now it works
[00:39] <mwhudson> W
[00:39] <mwhudson> T
[00:39] <mwhudson> F
[00:41] <mwhudson> anyway
[00:43]  * thumper shrugs
[00:43] <thumper> weird
[00:45] <mwhudson> well about four hours later than it should have been, let's test that git import out...
[00:52] <thumper> mwhudson: :)
[00:53] <thumper> mwhudson: I've set my preferred email back to the @c.c one
[00:53] <thumper> mwhudson: we'll see if I get an email this time
[00:53] <thumper> mwhudson: perhaps we should add an --email-from tag too
[00:53] <thumper> mwhudson: that way it might work for the community people too
[00:54] <wgrant> thumper: It works fine if I run it myself, though.
[00:54] <wgrant> Probably because I have no SMTP server configured.
[00:54] <thumper> wgrant: could be
[00:54] <wgrant> And my mail server is not sufficiently SPF-policing.
[00:55] <thumper> wgrant: if the canonical one is set to use the canonical smtp server
[00:55] <thumper> wgrant: it only allows emails from a canonical.com address
[00:55] <thumper> wgrant: and drops others
[00:55] <wgrant> thumper: It doesn't even allow emails to a canonical.com address from a non-Canonical one?
[00:56] <thumper> wgrant: it may not be the general one... not sure
[00:56] <thumper> wgrant: maybe?
[00:57] <wgrant> Yay email.
[00:59] <mwhudson> ec2 test should just drop a letter in the mail
[00:59] <mwhudson> i'm sure there's a printer somewhere in amazon's data centre?
[01:00] <thumper> :)
[01:10] <thumper> mwhudson: an unproductive afternoon just got worse with visitors
[01:10] <thumper> mwhudson: I'm going to get a real coffee
[01:10] <mwhudson> thumper: ok
[01:10] <mwhudson> thumper: i'm going to be finishing a little early today, btw
[01:11] <thumper> mwhudson: ok
[01:11] <thumper> like 4?
[01:11] <mwhudson> thumper: about 4:30
[01:11]  * thumper nods
[01:11] <thumper> ok, sounds fine
[01:12] <mwhudson> cool
[01:20] <mwhudson> ec2 demo seems pretty broken by the openid changes
[01:25] <wgrant> mwhudson: What goes wrong?
[01:25] <wgrant> mwhudson: Does it hardcode hostnames like rocketfuel-setup?
[01:26] <mwhudson> wgrant: i got fed up and didn't really dig
[01:26] <mwhudson> but pages that require you to log in oops
[01:26] <wgrant> Yeah, it's not adding testopenid.dev to /etc/hosts.
[01:31] <mwhudson> oh right
[01:31] <mwhudson> hm it is when creating a new image
[01:32] <mwhudson> maybe a new one is needed
[01:35] <wgrant> Does the image creation use rf-setup?
[01:35] <mwhudson> wgrant: no
[01:35] <mwhudson> rf-setup does rather more than is needed i think
[01:36] <wgrant> Ah, I didn't see the devscripts change in the diff.
[01:36] <wgrant> Ah, because the diff is 5000 lines.
[02:15] <jml> thumper, wrt "simple is better than complex", "simple" is often defined as "fewer interacting entities", in which case a multi-adapter would be simpler
[02:15]  * thumper pokes jml in the eye
[02:15]  * thumper looks around to see who saw that
[02:16] <jml> thumper, entia non sunt multiplicanda praeter necessitatem
[02:16] <thumper> jml: when are you back at work?
[02:16] <jml> thumper, I was back all today.
[02:16] <thumper> ah, home again?
[02:17] <jml> thumper, no, in Massachusetts
[02:17] <lifeless> jml: em or um?
[02:17] <jml> thumper, working w/ cody-somerville & kiko, talking about OEM requirements and things
[02:17] <jml> lifeless, em.
[02:17] <thumper> jml: ok
[02:18] <cody-somerville> s/OEM/NewCore (the new shiny) ;)
[02:18] <cody-somerville> err
[02:18] <lifeless> 'thingy'
[02:18] <thumper> hi cody-somerville
[02:18] <thumper> cody-somerville: still working?
[02:18] <thumper> getting kinda late isn't it?
[02:19] <cody-somerville> It is
[02:19] <cody-somerville> 21:19
[02:19] <cody-somerville> Just got back from dinner.
[02:19] <thumper> and you couldn't wait to see what happened while you were out?
[02:19] <jml> thumper, well, I couldn't
[02:20] <jml> thumper, and also there's nothing like taking a break from my job and doing a spot of document writing and process improvement for an open source project :P
[02:20]  * cody-somerville is an addict to work. :(
[02:21] <thumper> jml: I've got my own pet project now
[02:21] <jml> thumper, does it involve web and dvcs?
[02:23] <thumper> jml: yeah
[02:23] <thumper> jml: looking at mako for templating
[02:23] <thumper> jml: looks more intuitive to me than genshi
[02:23] <thumper> jml: still using twisted.web
[02:23] <jml> thumper, what does django use normally?
[02:24] <thumper> kid I thought
[02:24] <jml> thumper, have you looked at nevow?
[02:24] <thumper> or maybe that was something else
[02:24] <thumper> jml: nope
[02:24] <thumper> mako is super fast
[02:24] <jml> thumper, I'm not suggesting that you _use_ it, mind, just that it's worth a look
[02:24] <thumper> and what the python website uses
[02:24] <thumper> jml: understood
[02:24] <thumper> jml: there are a gazillion different templating systems out there
[02:24] <thumper> I've been playing around with python 3.1 a bit too
[02:25] <jml> thumper, nevow is one that was built to work with twisted.web
[02:25] <wgrant> Django uses its own thing.
[02:25] <wgrant> I like genshi more than mako, I think.
[02:25] <wgrant> but there's not much in it.
[02:25] <thumper> wgrant: why?
[02:26] <thumper> I'm not strongly stuck on any one
[02:26] <wgrant> I'm not sure.
[02:26] <thumper> I just want something that can easily apply a common skin to pages
[02:26] <thumper> I'm not wanting to invest a lot of time into it
[02:26] <thumper> (just yet)
[02:26] <thumper> jml: do you know of a python library that renders moin syntax?
[02:27] <lifeless> thumper: like, oh, moinmoin ?
[02:27] <thumper> lifeless: I heard that it wasn't simple to extract the rendering code from the entire wiki project
[02:27] <jml> thumper, there's a name on the tip of my tongue (other than moinmoin)
[02:27] <thumper> lifeless: but I haven't looked
[02:28] <lifeless> thumper: I'd look; theres been a lot of work done on moin
[02:28] <jml> thumper, also, I humbly suggest that you should use mediawiki formatting
[02:28] <thumper> jml: I was going to have a choice
[02:28] <jml> thumper, good good.
[02:28] <thumper> jml: what is the name of the mediawiki format?
[02:28] <thumper> is there another name?
[02:28] <jml> thumper, no, I don't think so
[02:29] <jml> thumper, there's a wiki interchange library thing that I'm struggling to remember the name of
[02:29] <thumper> jml: I think I did a code import for that ...
[02:31] <thumper> jml: creole?
[02:31] <jml> thumper, yeah, that's it.
[02:31] <thumper> lp:creoleparser
[02:31] <jml> thumper, phew, I'll be able to sleep now.
[02:46] <mwhudson> thumper: is https://dev.launchpad.net/Code/PostThreeDotO much relevant these days?
[02:47] <thumper> mwhudson: I don't think so
[02:47] <thumper> mwhudson: we know about it all
[02:47] <thumper> mwhudson: and they are tracked elsewhere
[02:47] <mwhudson> thumper: right
[02:47] <thumper> mwhudson: so kill it
[02:47] <mwhudson> thumper: delete it? replace with a link to somewhere else?
[02:47] <thumper> umm...
[02:47] <thumper> not sure where to link it to
[02:48] <thumper> is there a general four dot oh page somewhere
[02:48] <thumper> or perhaps link to the dev wiki strategy pages?
[02:49] <mwhudson> https://dev.launchpad.net/VersionFourDotO/Themes ?
[02:50] <thumper> yeah, seems reasonable
[02:56] <thumper> mwhudson: I'm off to go shop for BBQ
[02:56] <thumper> mwhudson: see you monday
[02:56] <mwhudson> thumper: see you monday, have a good weekend
[08:11] <adeuring> good morning
[09:24] <jelmer> mwhudson, hi
[09:27] <jelmer> stub: ping
[09:33] <adeuring> when i run "make build", i get "Error: There is a version conflict.
[09:33] <adeuring> We already have: zope.interface 3.4.0". Any suggestions how to fix this?
[09:33] <wgrant> mwhudson had that this morning.
[09:35] <adeuring> wgrant: tahnks for the hint!
[09:35] <wgrant> adeuring: It looks like he might have fixed it by install the python-zopeinterface package.
[09:36] <wgrant> Er, python-zope.interface
[09:40] <adeuring> wgrant: thanks! that helped indeed
[09:41] <wgrant> Urgh. It shouldn't.
[09:42] <jtv> Did the +login page just stop working in devel?
[09:42] <wgrant> jtv: It's OOPSing?
[09:42] <jtv> wgrant: yup, for me it is
[09:42] <wgrant> jtv: Add testopenid.dev to /etc/hosts.
[09:42] <jtv> wgrant: thanks
[09:42] <wgrant> An email should really have been sent about that.
[09:44] <jtv> wgrant: thanks, that did the trick
[09:44] <wgrant> Great.
[09:56] <stub> jelmer: pong
[09:57] <jelmer> stub: Any chance you can review this patch that changes the db: https://code.edge.launchpad.net/~jelmer/launchpad/bug471148/+merge/20142 ?
[09:57] <allenap> Is it really week 3? I've been out of touch for a while :)
[09:58] <allenap> Yes, yes it is. (Looked at the milestone.)
[10:02] <stub> jelmer: What architectures does an archive get built for if there are no entries in ArchiveArch ?
[10:02] <jelmer> stub: Just the unrestricted architectures
[10:03] <stub> So we add this flag to avoid needing 8 entries in ArchiveArch for every archive. I see.
[10:04] <jelmer> stub: yep
[10:07] <stub> We are assuming we won't need further granularity like 'build hppa in lucid only'
[10:07] <stub> ?
[10:10] <bigjools> stub: that's already handled through distroarchseries
[10:11] <al-maisan> stub: this is not a requirement at present; if needed we could add a DistroSeries FK to ArchiveArch
[10:12] <al-maisan> to put the restricted processor family override into a distro series context
[10:12] <wgrant> How does this work with require_virtualized?
[10:12] <al-maisan> wgrant: the latter is orthogonal to this
[10:14] <bigjools> al-maisan: no FK needed, distroarchseries man :)
[10:14] <al-maisan> je
[10:14] <al-maisan> sorry
[10:15] <al-maisan> bigjools: I guess we're fine for the moment
[10:15] <bigjools> al-maisan: yep
[10:16] <wgrant> Ah, so this is for restricting the architectures of non-virtual PPAs?
[10:16] <jelmer> stub: thanks for the review
[10:16] <stub> np
[10:16] <al-maisan> I don't quite see a use case where we'd want to have a PPA with builds for armel in say karmic but not in lucid
[10:16] <bigjools> wgrant: it's for restricting for any archive
[10:17] <bigjools> virtuality is orthogonal
[10:21] <intellectronica> i can't build after branching from db-devel because of "Couldn't find a distribution for 'lazr.restful==0.9.21'". anyone knows what's going on?
[10:24] <intellectronica> ah, nm, rocketfuel-got it
[10:30] <bigjools> al-maisan: that's a very valid use case actually
[10:30] <bigjools> for example, lpia is not in lucid
[10:31] <al-maisan> the lpia case is not really so pertinent since lucid has no lpia DistroArchSeries anyway
[10:32] <jtv> bdmurray: your branch has landed.  Now you need to Q/A it.  I'm not sure what the process for keeping track of that is in this case; in Translations we've been using an experimental process.
[10:33] <jtv> bdmurray: it needs to be marked as Q/Aed in order to be included in the release.
[10:41] <wgrant> Argh, all the buildds are gone again.
[10:41] <noodles775> gar, the cherry-pick is still waiting to land :/
[10:43] <noodles775> wgrant: the i386 ppa builders are all full?
[10:43] <wgrant> And amd64 :(
[10:44] <noodles775> wgrant: ah, I thought you meant that the buildd manager had died again... *phew* :)
[10:51] <mwhudson> jelmer: incremental imports seem to fail with
[10:51] <mwhudson> AssertionError: Invalid sha for <Commit 8ab9c1e964cd0c36bb79f95fc229e49b7e296684>: 4638aef40ba9ebb9734caeed1f373c24015259fd
[10:51] <mwhudson> type errors sometimes
[10:51] <jelmer> mwhudson: is this just of the kernel or of other branches as well?
[10:52] <mwhudson> (only running locally, staging is still out of date
[10:52] <mwhudson> )
[10:52] <mwhudson> jelmer: kernel and gedit
[10:52] <jelmer> mwhudson: if it is just in the kernel, it might be an unrelated bug
[10:52] <mwhudson> only on the import of revs 3000-4000 too, not very far in
[10:53] <mwhudson> hm, it's not actually during revision fetch
[10:53] <jelmer> mwhudson: The way I usually debug this is to compare the contents of the objects
[10:53] <jelmer> mwhudson: git cat-file <id> and bzr git-object <id>
[10:53] <mwhudson> jelmer: well at 5 to midnight on a friday i'm mostly thinking about bed...
[10:53] <jelmer> mwhudson: ahh, right :-) sorry, I hadn't considered the timezone
[10:54] <jelmer> mwhudson: is there an easy way to reproduce this outside of launchpad, using command-line bzr-git?
[10:54] <mwhudson> jelmer: not sure tbh
[10:54] <jelmer> guess we should get that limit parameter upstream to make testing easier ;-)
[10:54] <mwhudson> jelmer: maybe you can try gedit locally?
[10:55] <jelmer> yeah, sure
[10:55] <mwhudson> https://code.launchpad.dev/+code-imports/+new
[10:55] <mwhudson> then run ./cronscripts/code-import-dispatcher.py as required
[10:55] <mwhudson> with make run_codehosting in another window
[10:55] <jelmer> ah, thanks
[10:57] <mwhudson> if it doesn't work let's not worry too much, i can try to debug it on monday
[10:57] <mwhudson> and if we can't fix it we can always neuter the feature by setting the revision limit really really high
[10:57]  * mwhudson zzzs
[11:04] <deryck> Morning, all.
[11:05] <gmb> Is pushing branches to launchpad being slow for anyone else? I'm getting ~1KB/s, apparently, but my connection seems otherwise quite nippy.
[11:06] <bigjools> morning deryck
[11:06] <bigjools> gmb: bit slower than normal, yeah
[11:07] <gmb> Hrm.
[11:07] <gmb> (This is where my knowledge about how codehosting works ends)
[11:08] <intellectronica> stub: around? got a mo to review my db patch adding a trigger to update max_bug_heat?
[11:08] <stub> k
[11:08] <intellectronica> excellent, just creating an MP
[11:11] <intellectronica> stub: https://code.edge.launchpad.net/~intellectronica/launchpad/update-max-heat/+merge/20204
[11:22] <intellectronica> gmb: did you have any thoughts on how to implement bug #505849 ?
[11:22] <mup> Bug #505849: Bug heat should decay over time <story-bug-heat> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/505849>
[11:23] <gmb> intellectronica: Some. deryck and I chatted about this and our general idea was that heat should decay by 10 points for each week since a bug's last been touched.
[11:23] <stub> Hmm... we don't have max heat for a distroseries?
[11:24] <intellectronica> adeuring: looks like the new flame icons implementation is a bit broken. on a 1024 wide screen they new break and appear on a new line
[11:24] <intellectronica> stub: no, we only use the distro's max_heat
[11:24] <adeuring> intellectronica: sigh...
[11:25] <adeuring> intellectronica: do you mean listings or the icons on a bug index page?
[11:25] <intellectronica> gmb: gotcha. sounds like an easy solution.
[11:26] <gmb> adeuring: See bug 528374
[11:26] <intellectronica> adeuring: let me take a screenshot
[11:26] <mup> Bug #528374: Flames misplaced on bug report page <Launchpad Bugs:New> <https://launchpad.net/bugs/528374>
[11:26] <gmb> intellectronica: mpt already did that for you :)
[11:26] <intellectronica> thanks mpt
[11:26] <stub> intellectronica: I think the distribution max_heat is incorrect, as BugTask's linked to a distroseries are not directly linked to a distribution (Only one of BugTask.distroseries and BugTask.distribution can be set)
[11:27] <intellectronica> stub: oh, good point. didn't realise that.
[11:27] <stub> (I'm sure there was a reason for that, but I doubt it was a good one and hopefully not mine ;) )
[11:28] <stub> intellectronica: Do you want to fix or should I?
[11:29] <intellectronica> stub: go ahead and fix it if you can.
[11:30] <stub> DistributionSourcePackage.max_bug_heat calculation doesn't support multiple distributions yet either, but I guess we don't have to worry about that now :)
[11:31] <intellectronica> :)
[11:35] <adeuring> intellectronica: I can't reproduce this... which browser are you using?
[11:36] <intellectronica> adeuring: chrome
[11:36]  * adeuring nedds to install chrome...
[11:37] <intellectronica> adeuring: oh, and in FF it's even worse. the flames appear to the left of the bug info line instead of to the right
[11:37] <adeuring> intellectronica: I thought that was intended ...
[11:37] <intellectronica> adeuring: oh, i didn't realise that. why did we change the location?
[11:38] <adeuring> intellectronica: i have no idea what changed or when it changed.
[11:39] <intellectronica> adeuring: i thought it was your branch, since it was ok until yesterday, but maybe something else
[11:39] <intellectronica> the light icons do look much better, though
[11:40] <adeuring> intellectronica: well, the icons were in firefox left of "bug #123 reported" even before my change
[11:41] <mup> Bug #123: There's no direct way to see the project info when translating it <Launchpad Translations:Fix Released> <https://launchpad.net/bugs/123>
[11:41] <intellectronica> adeuring: huh. i can't believe we missed that for so long
[11:42] <deryck> adeuring, intellectronica -- the flames aren't orginally left of the reporter info.  See:  https://bugs.staging.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/141613
[11:42] <mup> Bug #141613: npviewer.bin crashed with SIGSEGV <apport-crash> <apport-failed-retrace> <iso-testing> <metabug> <npviewer> <npviewer.bin> <nspluginwrapper> <nspluginwrapper (Ubuntu):Confirmed> <nspluginwrapper (Mandriva):Fix Released> <https://launchpad.net/bugs/141613>
[11:44]  * adeuring is now completely confused...
[11:46] <stub> intellectronica: looks like it all needs refactoring. If a BugTask.product changes for instance, both the old product and the new product need their maximums updated.
[11:47] <stub> oh.. hang on... i'm confusing myself
[11:49] <deryck> heh, "7 out of 4 heat flames"  oops. :-)
[11:50] <stub> Yer - if we do this with triggers, we need triggers on both bug and bugtask, because changes to bugtask link and unlink bugs from stuff and that stuff needs their maximums updated.
[11:50] <stub> And technically on distroseries too incase a distroseries.distribution gets changed, but I think we can ignore that one.
[11:52] <intellectronica> stub: oright. i'll add triggers for the change of target. i guess in that case it would make sense to move most of the code out to a procedure and use the triggers to call that?
[11:55] <stub> If there is enough that can be factored out, sure.
[11:57] <stub> I'd go for the cron job personally :)
[11:57] <wgrant> bigjools: Isn't that branch going to cause all the copy archive binaries to land in universe, so the second run won't actually use them?
[12:05] <henninge> bigjools: Hi ;)
[12:05] <henninge> bigjools: can you help me with build farm jobs or is that somebody else's domain?
[12:05] <adeuring> intellectronica: can you take care of the flame icons buG? I OCR today and have some reviews in the quere...
[12:06] <intellectronica> adeuring: i think i can have a look at it after i finish refactoring my max_heat db patch
[12:06] <henninge> wgrant: Hi :)
[12:07] <adeuring> intellectronica: thanks!
[12:07] <intellectronica> deryck: does that sound like a reasonable plan to you? ^^^^^
[12:07] <wgrant> henninge: Hi.
[12:07] <henninge> wgrant: are you knowlegable on build farm jobs?
[12:07] <wgrant> henninge: Probably.
[12:07] <wgrant> I know most of how it works.
[12:07] <intellectronica> it might mean not getting any other heat bugs done, though :/
[12:07] <henninge> wgrant: I'd like to try out our template generate job in as much the same way as it will be run in real life.
[12:08] <bigjools> wgrant: it's not applying any overrides
[12:08] <stub> Error: There is a version conflict.
[12:08] <stub> We already have: zope.interface 3.4.0
[12:08] <stub> ?
[12:08] <bigjools> maybe it should look in the primary archive
[12:08] <stub> Buildout error
[12:09] <henninge> stub: apt-get install python-zope.interface
[12:09] <wgrant> bigjools: It should.
[12:09] <bigjools> meh
[12:09] <wgrant> I think.
[12:09] <bigjools> I did have a nagging thought about it
[12:09] <wgrant> henninge: Do you have a local buildd set up?
[12:09] <henninge> wgrant: I don't think so. What would that entail?
[12:10] <henninge> I have build the launchpad-buildd package, or I can at least.
[12:11] <wgrant> henninge: So, you'll need to install that. What sort of arguments does your generation job take?
[12:12] <henninge> wgrant: a branch url to fetch the package branch from. That's all.
[12:12] <stub> henninge: Seems to be working. ta.
[12:12] <deryck> intellectronica, looking back
[12:12] <wgrant> henninge: OK, so, you can probably use Python's xmlrpclib to start the job without involving the horrible buildd-manager and Launchpad at all.
[12:12] <henninge> stub: oghers have gone before me ... ;-)
[12:13] <deryck> intellectronica, so the plan being you'll refactor the trigger branch and then fix the icons?
[12:13] <intellectronica> deryck: yes
[12:13] <stub> buildout isn't reporting an error code on failure, which screws things up in the makefile...
[12:13] <deryck> intellectronica, good plan.
[12:14] <henninge> wgrant: in real life the build slaves are ec2instances, right?
[12:14] <bigjools> no
[12:14] <henninge> oh
[12:14] <wgrant> henninge: No. They're mostly Xen machines in the DC.
[12:15] <wgrant> The rest are real machines in the DC.
[12:15] <henninge> ok, but they are like their own machines.
[12:15] <wgrant> Yes.
[12:16] <henninge> but you are saying I should not try and simulate that part, just run it on my machine.
[12:16] <wgrant> Right.
[12:16] <henninge> I mean, "setting up a buildd" is not setting up a xen instance or the like.
[12:17] <henninge> ok
[12:17] <wgrant> No, no. You just need to install the package.
[12:17] <wgrant> It'll run a daemon which makes the Soyuz tests fail, but that's about it.
[12:17] <henninge> good. Which is the top-level script I need to start?
[12:18] <wgrant> Have you installed launchpad-buildd?
[12:18] <wgrant> That should have started it already.
[12:18] <henninge> oh, I see. NOt atm, I had it installed in a pbuilder chroot. I'll try that again and look at it.
[12:19] <wgrant> That's fine too.
[12:19] <wgrant> The daemon just needs to be running somewhere.
[12:19] <henninge> so when it runs I can use xmlrpc to have it start my job.
[12:19] <henninge> ?
[12:20] <wgrant> Right.
[12:20] <henninge> wgrant: ok, thanks. Let me see how far I get with that.
[12:22] <wgrant> import xmlrpclib; xmlrpclib.ServerProxy('http://localhost:8221/rpc').build('1-1', 'translation-templates', 'sha1ofthechrootinyourlibrarian', {}, {'branch_url': 'http://url.to/branch'})
[12:30] <henninge> wgrant: thanks, that'll help a lot ;-)
[12:30] <henninge> wgrant: where do I find 'sha1ofthechrootinyourlibrarian' ?
[12:33] <wgrant> henninge: Grab http://launchpadlibrarian.net/39617064/chroot-ubuntu-lucid-i386.tar.bz2, get it into your librarian, and use f1f10b8402ed686aaf0307676c76f07b45af2a09 as the SHA1.
[12:35] <ricotz> salgado, hello
[12:36] <salgado> hi ricotz
[12:36] <ricotz> salgado, is it possible for you to restart this build https://edge.launchpad.net/~ricotz/+archive/testing/+build/1532157
[12:36] <ricotz> it seems to be jammed
[12:37] <salgado> ricotz, I don't seem to have permission to do that.  should I have?
[12:38] <ricotz> salgado, sorry, thought you have
[12:38] <ricotz> can you delegate this request to someone who can
[12:39] <ricotz> bigjools, hello ^
[12:40] <bigjools> ricotz: let me lookl
[12:40] <ricotz> thank you
[12:40] <bigjools> ricotz: why do you think it's jammed?
[12:41] <ricotz> cause its running for an hour and doesnt show any progress
[12:43] <bigjools> ok I'll investigate
[12:43] <ricotz> this build should take less than 10min like https://edge.launchpad.net/~ricotz/+archive/testing/+build/1532162
[12:50] <bigjools> ricotz: it's reset and on a different builder now
[12:50] <bigjools> see how it goes
[12:50] <ricotz> bigjools, thank you!
[12:53] <wgrant> henninge: Any luck?
[12:55] <techrascal> we are a bunch of undergrads and want set up a launchpad clone for projects we have in our college
[12:55] <techrascal> we have a server access with jailed ssh
[12:56] <techrascal> which doesnt give us sudo access and probably not even yum install kind of operations
[12:56] <techrascal> can anyone help me identify the bare minimum access we need for installing launchpad source code on a server
[13:41] <jml> techrascal, you'll need root, I'm afraid.
[13:41] <jml> techrascal, can you not just use launchpad.net?
[14:56] <deryck> BjornT, ping
[15:06] <jtv-afk> Why doesn't gpgme find my keys when I "make harness"?  (It does when I ./bin/py)
[15:09] <jtv> deryck: on an entirely arbitrary whim, I decide that you sound like the sort of person who would know this.
[15:09] <BjornT> deryck: pong
[15:10] <deryck> Hi BjornT.  So I need to rollout a new lazr-js to update with a change Tom had.  Want to make sure I remember right...
[15:10] <deryck> BjornT, it's just roll an sdist, ci it to download-cache, and update the versions.cfg in an lp branch.  is that right?
[15:12] <gmb> Anyone know how to fix this http://pastebin.ubuntu.com/384423/ when I'm trying to run `make`?
[15:12] <gmb> rocketfuel-get and make clean haven't fixed it.
[15:15] <deryck> gmb, do you need to clean up download-cache by hand, i.e. remove something from it that bzr up is trying to add?
[15:15] <deryck> pure guess that is.
[15:16] <gmb> Hmm.
[15:17] <stub> (19:09:04) henninge: stub: apt-get install python-zope.interface
[15:18] <stub> gmb: ^^ I got a similar error, but zope.interface. That was the solution.
[15:18] <gmb> stub: I'll give that a shot, thanks. (Except with the zope package, obviously)
[15:19] <BjornT> deryck: yes, that's right
[15:20] <deryck> BjornT, thanks
[15:30] <mars> ok, there is something fishy with the Repeat view load times of BugTasks on edge: http://www.webpagetest.org/result/100226_5F6Q/#run3
[15:31] <mars> They have increased a lot since December: http://www.webpagetest.org/result/091221_3RNM/#run2
[15:32] <mars> is the server under load or something?
[15:33] <mars> Dec time to first byte: 0.955s
[15:33] <mars> Feb time to first byte: 2.961s
[15:34] <gmb> Grrrrrrr.
[15:48] <mars> Must be something messed up with the cached view code on webpagetest's end.  The first-view times are still sane across the board.
[15:51] <gmb> gary_poster: I'm running into this whilst running make: http://pastebin.ubuntu.com/384423/. stub suggested apt-get installing zope.testing, but that didn't help. My download-cache is up to date; any suggestions about how I can get past this?
[15:53] <gary_poster> gmb: yes.  As a work-around, manually edit your bin/buildout file to have a " -S" at the end of the shebang line.  I have a (rather invasive, but fully reviewed) branch that I'll land at the beginning of next cycle to address.  If you don't plan to land this until next cycle then you could merge that.  Getting branch...
[15:53] <gmb> gary_poster: This needs to land today, so I'll use the workaround for now.
[15:53] <gary_poster> https://code.edge.launchpad.net/~gary/launchpad/bug491705
[15:54] <gary_poster> gmb: ack
[15:54] <gmb> gary_poster: Thanks, though :)
[15:54] <gary_poster> np :-)
[15:56] <gmb> gary_poster: Er, that -S didn't seem to help any. I'll try merging your branch and see what happens.
[15:57] <gary_poster> gmb: mm, did you run make clean after applying the -S?  If so, it would have been wiped away
[15:57] <gary_poster> gmb: steps would be as follows:
[15:57] <gary_poster> 1) run make
[15:57] <gary_poster> 2) curse at error
[15:57] <gary_poster> 3) edit bin/buildout
[15:57] <gary_poster> 4) run make again
[15:58] <gmb> gary_poster: I don't think I did; let me just try again.
[15:58] <gary_poster> if that doesn't help I'll be surprised and a bit concerned TBH
[16:00] <gmb> gary_poster: Hmm. Same problem. Let me try  a clean branch of db-devel (this branch was fine before I merged db-devel to resolve some conflicts, btw)
[16:00] <gary_poster> gmb: argh.  pastebin your edited bin/buildout for me to make sure we are talking about the same thing?
[16:01] <gmb> gary_poster: http://pastebin.ubuntu.com/384448/
[16:02] <gary_poster> gmb: ok alternate approach, have you infact tried make clean && make?
[16:02] <gmb> gary_poster: Yes. No dice.
[16:02] <gmb> gary_poster: In fact it complains about bin/py not existing when I do that
[16:03] <gmb> Running link-external-sourcecode fixes that though.
[16:04] <gary_poster> gmb: that doesn't make a lot of sense in my world view, so I don't understand something that you are doing. :-/
[16:05] <gary_poster> um
[16:05] <gmb> gary_poster: So, everything was fine until I merged db-devel. Then it broke. I updated my download-cache, ran make clean && make.
[16:05] <gmb> And everything else has revolved around trying to get the latter to work.
[16:05] <gary_poster> gmb, ok, I'll try to dupe.
[16:06] <gmb> gary_poster: The branch is at lp:~gmb/launchpad/processapportblobjob-api-bug-513191, ftr.
[16:06] <gary_poster> ack, on ity
[16:06] <gary_poster> or it
[16:08] <stub> gary_poster: I did notice that buildout must not be reporting an error code on this failure, as the shhh.py ate the output and the Makefile continued (hence the 'no bin/py' error)
[16:09] <gary_poster> stub, huh
[16:15] <gmb> gary_poster: This is also happening in a fresh branch of devel.
[16:15] <gmb> (the no bin/py thing, that is)
[16:15] <gmb> And also the zope.testing thing, too.
[16:16] <gary_poster> gmb, a full make WFM without having to edit bin/buildout (history, for reference: http://pastebin.ubuntu.com/384454/ ).  I did not have zope.testing installed from apt, which is what your showed, so I just added it and will try
[16:16] <gary_poster> retry
[16:17] <gary_poster> gmb, sigh, still, worked for me.  Can you think of anything else I should maybe do to try to supe our environments?  Similarly, can you try merging in the branch I mentioned and see if it makes the problem go away for you?
[16:18] <gary_poster> s/supe/dupe/
[16:18] <gmb> gary_poster: I'll try merging your branch; I can't think of anything else you need to do. I might end up just switching machines for the sake of getting this landed...
[16:18] <gary_poster> :-(
[16:19] <gary_poster> (If my branch doesn't help, then I'll have to try to dig into this later once the release pressure has passed)
[16:19] <gary_poster> (because it is supposed to make this kind of thing go away)
[16:19] <gary_poster> note that your download-cache will need to be up-to-date
[16:22] <deryck> abentley, qa-ready is very nice.  many thanks!
[16:23] <abentley> deryck, you're welcome.
[16:24] <gmb> gary_poster: Same error but with extra messages after your branch is merged: http://pastebin.ubuntu.com/384458/
[16:25] <gmb> gary_poster: I'll switch machines; I don't have time to debug this properly.
[16:25] <gmb> Thanks anyway.
[16:25] <gary_poster> gmb: ack, and sorry.  I'll need your time next week.
[16:25] <gmb> gary_poster: Sure.
[16:25]  * gmb -> switching machines; brb
[16:35] <gmb> gary_poster: Looks like it's all working fine on my laptop; no idea what's up with my desktop machine's environment. Ping me next week when you want to try and debug this.
[16:37] <jtv> bigjools: did you dazzle the crowds?
[16:38] <gary_poster> gmb: glad you are unblocked at least.  Another guess is http://pastebin.ubuntu.com/384463/ combined with my branch, FWIW.  I don't have enough information so far to do much else than guess.  I'll definitely ping you next week, thanks.
[16:40] <bigjools> jtv: I did - the head wants me to install Edubuntu there now
[16:40] <jtv> sinzui, maybe you can help me with this?  I'm trying to get a GPG key out of the current system user's real GPG, and it works if I run it in a plain python, but I see no keys at all in "make harness"
[16:40] <jtv> bigjools: we'd hate to lose you to tech sales
[16:41] <bigjools> jtv: I feel I have missed my calling
[16:41] <bigjools> my true calling
[16:41] <jtv> bigjools: I get missed calls all the time... I'm also using True prepay.
[16:41] <sinzui> jtv: I have no experience with this...
[16:42] <jtv> drat
[16:42] <jtv> darn
[16:42] <jtv> smeg
[16:42] <bigjools> jtv: I watch True Blood
[16:42] <jtv> bigjools: speaking of bleeding hearts, you wouldn't know about this either would you?
[16:42] <henninge> bigjools: I followed wgrant's helpful hints but when I try to initiate the buld I get an error back (on xmlrpc).
[16:42] <jtv> the gpgme problem
[16:43] <sinzui> jtv: I think that tests that work with package uploading may provide a clue how to do this
[16:43] <jtv> sinzui: I'd prefer not to rely on zeca though
[16:43] <henninge> bigjools: what could be wrong here? http://paste.ubuntu.com/384472/
[16:44]  * bigjools looks
[16:45] <bigjools> henninge: there's a chroot checksum mismatch somehow
[16:45] <bigjools> so what the buildmaster told it it was didn't match what it calculated when it unpacked it
[16:46] <henninge> bigjools: when I Iook at the code, though, it does not seem to even try to get the file from the librarian.
[16:46] <bigjools> henninge: it could be cached
[16:47] <bigjools> and the cache doesn't match
[16:47] <bigjools> it's supposed to re-fetch in that case though :/
[16:47] <henninge> bigjools: the cache is empty
[16:47] <bigjools> then I am stumped :(
[16:48] <henninge> bigjools: also, I am a bit confused by this: http://paste.ubuntu.com/384483/
[16:48] <henninge> bigjools: trying to get the file by its sha1 value gives me an empty result.
[16:49] <bigjools> hmm
[16:49] <henninge> but accessing it by its id is possible - the sha1 is correct.
[16:50] <bigjools> henninge: findBySHA1("blah")[0] ... ?
[16:50] <henninge> oh, .... right
[16:50] <bigjools> it's a proxied result set
[16:51] <henninge> yup, that was too obvious for me to see ...
[16:51] <henninge> ok, so it's not an error in the librarian.
[16:54] <henninge> bigjools: does the librarian need to be running in any way for the slave to be able to access it?
[16:54] <bigjools> henninge: yeesssss :)
[16:54] <bigjools> unless it's some magic librarian
[16:54] <henninge> bigjools: I have tried with LP running in another terminal, though.
[16:55] <jtv> henninge: but what you need from the Librarian AFAIK is the chroot, and didn't you get stuck at that point?
[16:55] <henninge> bigjools: what else could keep the slave from being able to access the librarian? I am running it from a chroot.
[16:55] <bigjools> henninge: firewall?
[16:55] <henninge> ;)
[16:55] <bigjools> can you telnet the address/port it's trying to access?
[16:56] <bigjools> as your slave user
[16:56] <henninge> how do I know what it's trying to access
[16:56] <henninge> ?
[16:56] <bigjools> the URL is passed to it from the buildmaster
[16:56] <henninge> lemme try
[16:56] <bigjools> so it might not be passing the right URL
[17:01] <henninge> bigjools: do you mean the librarian url?
[17:01] <bigjools> henninge: the path should be ok, I suspect the domain part isn't
[17:02] <henninge> bigjools: ok, but I am simulating the master by an rpc call that wgrant gave me. So maybe the call is missing something.
[17:02] <bigjools> ah
[17:03] <bigjools> tell me what it was?
[17:03] <henninge> http://paste.ubuntu.com/384472/
[17:03] <henninge> bigjools: ^
[17:03] <bigjools> oh that
[17:04] <bigjools> hmmm
[17:04] <bigjools> I can't remember and honestly I think I'd rather run the b-m locally
[17:05] <henninge> bigjools: np, how do I do that? ;-)
[17:06] <bigjools> henninge: /bin/twistd --python daemons/buildd-manager.tac
[17:06] <bigjools> henninge: assuming you have the builder defined in LP.dev
[17:06] <bigjools> and that your job is ready to dispatch, etc
[17:06] <henninge> not sure if that is assuming too much ....
[17:07] <henninge> bigjools: I'll try something else first.
[17:08] <bigjools> henninge: poking xmlrpc is fine but given that only wgrant has done that then I would be scratching around the code a bit myself to remember what's going on
[17:10] <henninge> that's what I am doing ... ;)
[17:11] <henninge> bigjools: http://paste.ubuntu.com/384494/ ;-)
[17:12] <bigjools> henninge: \o/
[17:12] <bigjools> henninge: awesome, let me know how it goes.  When you get it all working locally we can try it out on dogfood.
[17:16] <henninge> bigjools: "can't find ntp.buildd" What should that be?
[17:17] <bigjools> I need more context
[17:18] <henninge> bigjools: sorry
[17:21] <henninge> bigjools: build log on the slave: http://paste.ubuntu.com/384500/
[17:21] <bigjools> henninge: heh
[17:21] <bigjools> ok
[17:21] <bigjools> easy fix is to define that in /etc/hosts
[17:22] <bigjools> along with the other million .dev ones
[17:22] <bigjools> and point it at ntp.ubuntu.com
[17:23] <henninge> bigjools: oh, that is how the buildd's are synced ...
[17:24] <bigjools> yeah, the DC has that domain defined
[17:39] <sinzui> I think the QA wiki script is behind. I just QAed my changes on staging, but the wiki does not know that they have landed and been deployed to staging
[17:51] <henninge> jtv: are you sure the "doUpdate" step is required?
[17:52] <jtv> henninge: no.  Only if something dramatically breaks intltool I expect.
[17:53] <henninge> jtv: it calls "update-debian-chroot" but that is not included in the chroot.
[17:53] <henninge> so it breaks.
[17:53] <henninge> jtv: also any cleanup fails because it tries to remove proc instead of unmounting it (and dev/pts and sys).
[17:53] <jtv> henninge: I don't think it's supposed to call that from within the chroot
[17:54] <jtv> but it's something I could easily have gotten wrong.
[18:02] <magcius> eeeek!
[18:02] <magcius> Why can't I visit edge.launchpad.net without this new Launchpad Login Service?
[18:04] <sinzui> magcius: because launchpad is going to use that for login from now on.
[18:04] <magcius> sinzui, but why do I need an account to view Edge?
[18:04] <magcius> (Is it just testing Edge?)
[18:04] <magcius> also, I see an +openid in the URL, but there's no place I can put in my existing OpenID
[18:05] <sinzui> magcius: except that the login service will really be Ubuntu.
[18:05] <magcius> sinzui, ? what does that mean?
[18:05] <magcius> (I don't use Ubuntu at all)
[18:05] <sinzui> magcius: I believe next week all launchpad will be using openid for login
[18:06] <magcius> sinzui, um, I still don't follow what you're saying
[18:06] <magcius> Next week when 10.2 releases I'll need to login to do anything?
[18:07] <magcius> also, I don't know who to talk to about this, but your sliding door needs more length
[18:08] <magcius> i.e. right here: http://imgur.com/67fmj.png
[18:08] <sinzui> magcius: Yes. but to be clear, launchpad-login code became the launchpad SSO, but users did not to use it launchpad authentication, so we removed the feature last year. Ubuntu is the real SSO server, we have been running a copy and allowing the old login to continue for about year
[18:08] <deryck> intellectronica, I have some nervous energy about this branch.  This updates in real time with changes, right?
[18:09] <intellectronica> deryck: yes
[18:09] <magcius> sinzui, Launchpad authentication? What was that?
[18:09] <intellectronica> not much different from a trigger, really
[18:09] <sinzui> magcius: login
[18:09] <magcius> sinzui, so there were two ways to log in?
[18:09] <magcius> sinzui, what were they?
[18:10] <intellectronica> deryck: are you worried about timing?
[18:10] <deryck> intellectronica, except this happens in a view, right?  So if it takes a while to complete it timesout a view.  I thought triggers were independent of the view.
[18:10] <deryck> yeah, timing is always my fear :-)
[18:10] <intellectronica> deryck: why in a view?
[18:10] <intellectronica> oh right, when you create a task or change the target it's in a view, you're right
[18:11] <sinzui> Launchpad has not manages user accounts for a year. We allowed users to continue to use the launchpad copy of SSO, but the Ubuntu version is the master. when you login to a page in launchpad, you are really logging into ubuntu's sso
[18:11] <deryck> intellectronica, that's what I meant.  I realize it's model code, but called from a view.
[18:11] <deryck> intellectronica, you could create a job then, but you still need something to process it offline.
[18:12] <deryck> intellectronica, do you feel really confident this won't timeout?
[18:12] <magcius> sinzui, what is the Ubuntu SSO?
[18:12] <intellectronica> deryck: we can remove the code that updates when you touch a bugtask. that will have pretty much the same effect, and wait for the max_heat to get updated when the bug's heat is next updated
[18:12] <sinzui> magcius: https://login.ubuntu.com/
[18:13] <intellectronica> deryck: it's hard for me to guesstimate whether it will timeout. i can't really know without trying this on staging
[18:13] <magcius> sinzui, so if I have a Launchpad account, I can log in there?
[18:13] <deryck> intellectronica, can we just move all of it to update when heat is recalculated?
[18:13] <deryck> or is that what you mean?
[18:13] <magcius> sinzui, what exactly does the Ubuntu SSO allow me to do?
[18:13] <intellectronica> deryck: it will update when heat is calculated anyway
[18:14] <sinzui> magcius: yes, because you really do have an ubuntu account, launchpad only keeps a profile of your hacking activity. For example, Launchpad does not really know your email address.
[18:14] <intellectronica> deryck: it updates all targets whenever setHeat is called on a bug
[18:14] <deryck> intellectronica, which happens offline, right?
[18:14] <intellectronica> yes
[18:14] <magcius> sinzui, okay, what can I use the Ubuntu SSO for?
[18:15] <deryck> intellectronica, so the only live update is when a task is re-targeted?
[18:15] <magcius> sinzui, like, I see my OpenID site in there for "Sites you last authenticated to"
[18:15] <intellectronica> deryck: yes, or when a new task is created
[18:15] <sinzui> magcius: You can use the openid url on your launchpad profile page to login into other openid enabled sites without registration
[18:15] <magcius> sinzui, I already have an OpenID account, I don't need another one
[18:16] <sinzui> magcius: you have had one from launchpad for about 2 years, it is shown on you profile page
[18:16] <deryck> intellectronica, yeah, so I think either remove those bits.  Because those will trigger setHeat anyway, right?
[18:16] <magcius> sinzui, I know, I have had another one from ClaimID.com for about 3 or 4
[18:16] <deryck> s/either//
[18:17] <intellectronica> deryck: i don't see how they will trigger setHeat
[18:18] <intellectronica> deryck: how about, we remove triggering this when touching bugtasks and open a bug for looking at it later?
[18:18] <intellectronica> deryck: my worry with all this stuff that happens offline is that we'll be accumulating inaccurate data
[18:18] <intellectronica> it's very hard to follow what happens when
[18:19] <deryck> intellectronica, yeah, that sounds good.  Also, if we're not adjusting heat with bugtask changes, then maybe we shouldn't do max_bug_heat either then.
[18:19] <intellectronica> so without triggering the calculation directly, we'll probably have reasonable results, but i just don't want to leave it at that
[18:19] <intellectronica> deryck: i'm sorry, i don't really understand your last sentence
[18:21] <deryck> intellectronica, I'm asking why do we even need to recalculate max_bug_heat on bugtask changes?  If we don't change heat on the bug on bugtask changes, then why change max_bug_heat?
[18:22] <intellectronica> deryck: because the bug might already have heat
[18:22] <deryck> intellectronica, ah, but the project of the task might not yet have a max_bug_heat?
[18:22] <intellectronica> deryck: exactly
[18:22] <deryck> hmmmmm
[18:24] <intellectronica> deryck: how screwed are we if this gets so staging and we find it times out? it will be really nice to know whether this is actually a problem
[18:24] <deryck> intellectronica, thinking about that.  is the only time we would call this "live" would be on changing a bugtask?  which is via AJAX?
[18:25] <intellectronica> deryck: also when adding a new task. both are not necessarily ajaxed (changing a target can be ajaxed but there's also a non-ajax interface)
[18:26] <deryck> intellectronica, right, but it's through a new page, which is not as a bad as a bug list or page.  I think this probably isn't a problem in practice.
[18:27] <intellectronica> deryck: right, i wouldn't bet on a timeout. but as always, without testing this on ubuntu on staging it's very hard to tell
[18:28] <deryck> intellectronica, I'm willing to risk it.  allenap has to cowboy a patch to test.  perhaps we could create a combined diff and test both.
[18:28] <intellectronica> great!
[18:28] <intellectronica> worst case, we know exactly what are the bits we need to back-out, so it shouldn't be too much work to recover from it
[18:29] <deryck> right.  but I do want to avoid having to do that.
[18:29] <intellectronica> but if we get to cowboy a patch then even that won't be necessary
[18:31] <deryck> exactly.
[18:31] <deryck> intellectronica, so can you and allenap coordinate about that combined diff when he's available.
[18:31] <intellectronica> sure thing
[18:31] <intellectronica> deryck: apart from that, any comments on the code?
[18:32] <deryck> intellectronica, looks good.  Just doing a careful scan of the sql, and then I'll be ready.
[18:32] <intellectronica> cool
[18:36] <deryck> intellectronica, only comment really is that line 145 has a commented out bit of code, which I assume you don't need anymore.
[18:37] <intellectronica> deryck: whoops, no, of course i don't need that bit.
[18:38] <intellectronica> removed
[18:39] <deryck> intellectronica, cool.  running a couple queries on staging just for paranoia.
[18:41] <deryck> hmmm, it's slow.
[18:42] <deryck> intellectronica, http://pastebin.ubuntu.com/384562/
[18:43] <intellectronica> oh yes, that's too slow
[18:45] <intellectronica> deryck: so, remove the call when touching a bugtask for now? i do think we'll have to revisit this if we want reliable results, but it probably won't be too terrible for now
[18:46] <intellectronica> b.t.w i think it will also be very slow when calculating heat from a script
[18:47] <deryck> intellectronica, just a second more and let me play and then we can decide.  not meaning to delay, I know it's late for you.
[18:47] <intellectronica> deryck: that's oright, i'm working on other heat bugs in the meantime. no rush
[18:48] <intellectronica> and thanks for running these queries. nothing beats real data
[18:48] <deryck> yeah, I'm glad I can do them on staging.
[19:14] <deryck> intellectronica, I may have something.  http://pastebin.ubuntu.com/384585/
[19:14] <deryck> removing the union and doing a limit.  and I get the right result.  it makes sense to me.
[19:15] <intellectronica> deryck: wow. i'm impressed.
[19:15] <intellectronica> not by postgres :)
[19:15] <deryck> my head hurts now.
[19:15] <intellectronica> i'm amazed the difference is so bug
[19:15] <intellectronica> big
[19:15] <deryck> yeah, it's huge.
[19:16] <deryck> because it doesn't have to scan with the limit and order by.
[19:16] <intellectronica> so this is just one of the queries in the union, but even running both and maxing the result in python would be faster than the 4s we got with the union
[19:17] <deryck> intellectronica, no, this can replace the union.
[19:17] <deryck> intellectronica, you just want the highest bug heat for any bug that has a bugtask.distribution or bugtask.distroseries, right?
[19:17] <intellectronica> deryck: right, i missed the OR
[19:18] <intellectronica> it doesn't limit by distribution. don't know if that will make much of a difference
[19:18] <deryck> intellectronica, right.  so we can add a distribution = %s.  Let me check times on that.
[19:18] <intellectronica> deryck: can you run the same with AND  Bugtask.distribution = 1 ?@
[19:21] <deryck> intellectronica, quicker even!
[19:21] <intellectronica> awesome
[19:21] <deryck> intellectronica, http://pastebin.ubuntu.com/384589/
[19:23] <intellectronica> wonderful
[19:23] <intellectronica> and the sql is much more readable too
[19:24] <deryck> intellectronica, cool.  So r=me with something like this to replace each UNION sql statement.  If that seems acceptable to you, too.
[19:24] <intellectronica> i'm still surprised. my guess is that it's not the max() that was making it small, but the nested queries
[19:24] <intellectronica> deryck: for sure. thanks a bunch!
[19:25] <deryck> intellectronica, cool. np!    One day we'll do this everywhere and bring our counts do on the OOPS report.
[19:31] <sinzui> beuno: adeuring: landed his fix for bug advanced search: https://bugs.edge.launchpad.net/launchpad-registry/+bugs?advanced=1
[19:31] <sinzui> ^ You can now see what the default criteria is for searching, and the legends a have enough space so that you can see the parts of the form.
[19:32]  * sinzui thinks the checkboxes at the end are silly though
[19:32] <beuno> sinzui, sure
[19:33] <sinzui> beuno: I wanted them to be radio-button
[19:35] <beuno> so
[19:35] <beuno> almost everything on that page needs vertical spacing
[19:36] <beuno> the sorting drop down is confusing when layed out that way
[19:36] <beuno> the input box as well
[19:36] <beuno> this is advanced search, so you probably want to explain that the input box is optional, and to search for text in X or Y parts of the bug
[19:37] <beuno> the "Doesn’t matter" option for asignee could be named better
[19:37] <sinzui> beuno: I agree. I think Abel has done a good job closing a number of UI issues in one branch. He may hate me for it, but I can finally read that form
[19:37] <beuno> sinzui, YES. It's a million times better now
[19:37] <beuno> the any/all radio buttons on tags should be right next to the tag field
[19:38] <beuno> just "Help" may also suffice there
[19:39] <beuno> and having:
[19:39] <sinzui> In their previous position, they looked like they were subordinate to the item above. The form layour you introduced 9 months places subordinates below, not to the right
[19:39] <beuno>   Show only bugs with linked branches
[19:39] <beuno> Show only bugs without linked branches
[19:39] <beuno> both ticked by default is a bit confusing
[19:39] <beuno> ah
[19:40] <beuno> well, if it can't be easily tweaked to be to the right of the input, at least change the labels to "All tags" or "Any tags"
[19:40] <beuno> all labels on that page could do with .5-1em of padding-top
[19:40] <sinzui> beuno: yes, I was too, as was abel, We and I wanted a radio button show exclusivity or state your do not care. I had to run a search to prove I would get results with that insane condition
[19:42] <sinzui> beuno: yes, padding can fix the radiobutton on right issue.
[19:44] <jml> kfogel, ol buddy ol pal
[19:45] <jml> kfogel, I want an elisp function that behaves like upcase-word but switches from under_score to camelCase, and another one that goes in the other direction.
[19:45] <beuno> sinzui, did all that help?  or where you asking something else?
[19:46] <sinzui> beuno: yes it helped. I wanted your opinion on the improvement.
[19:47] <beuno> sinzui, long overdue, and very nice!
[19:47] <jml> kfogel, It would be great if you could write this, but I say this in a way that has absolutely nothing to do with Canonical, just that it would help my occasional free software LP development
[20:00] <EdwinGrubbs> bac, sinzui: what do you think about this simplified upstream connections portlet? https://chinstrap.canonical.com/~egrubbs/upstream/upstream_simplified.png
[20:01] <sinzui> EdwinGrubbs: I think that can get long
[20:02] <sinzui> EdwinGrubbs: This may be easier if you keep in mind your proposing a change to two pages, not one...
[20:02] <bac> EdwinGrubbs: 'mozilla', 'firefox', and 'blog series' are three different links?
[20:04] <sinzui> EdwinGrubbs: The difference between the packaging listing and the source package page is that the listing does not get the change operations
[20:04] <sinzui> https://edge.launchpad.net/ubuntu/lucid/+packaging
[20:04] <sinzui> https://edge.launchpad.net/ubuntu/lucid/+source/openoffice.org
[20:07] <sinzui> EdwinGrubbs: if we can keep the branch and translations in a separate column, and keep the 3 objects linked, the layout may work for both cases. Your https://chinstrap.canonical.com/~egrubbs/upstream/horizontal_hierarchy.png is more practical for users who want to visit the project or project group
[20:08] <intellectronica> what's a good way to test something time-related?
[20:09] <intellectronica> is there a way to temper with the current time for a test?
[20:10] <EdwinGrubbs> sinzui, bac: I had actually removed the project group entirely after reading Curtis' email. Then I removed the project link, since the user can always make to clicks, and it makes the display cleaner and clearer.
[20:10] <EdwinGrubbs> s/to clicks/two clicks/
[20:11] <sinzui> EdwinGrubbs: I cannot fix the project bug tracker unless I have a link to the project. We need links to projects an series. The project group link is dubious, but needed until the bugs team sorts out their upstream contact contradiction
[20:12] <sinzui> bac: EdwinGrubbs: look at this: https://bugs.edge.launchpad.net/openoffice
[20:13] <sinzui> ^ I need to enable bug tracking to set the value, then disable it again?
[20:17] <EdwinGrubbs> bac, sinzui: I'll use the horizontal layout but with the Branch in a separate column then.
[20:18] <sinzui> EdwinGrubbs: I think that is what is there now (and translations is there too)
[20:19] <EdwinGrubbs> yes
[22:06] <wgrant> Ooh. Somebody fixed the advanced search form.
[22:07] <beuno> wgrant, hug sinzui and adeuring for that
[22:09] <wgrant> Hey, ISD finally got their act together.
[22:09] <lifeless> ?
[22:10] <wgrant> The security fix has finally been rolled out.
[22:17] <bdmurray> make build is failing for me in devel at finding a distribution for lazr-js==0.9.2DEV-r169
[22:18] <wgrant> bdmurray: Run rocketfuel-get lately?
[22:20] <wgrant> How is login.ubuntu.com going to provide the OpenID team data that Launchpad provides?
[22:22] <lifeless> bdmurray: update-sourcecode probably
[22:23] <wgrant> This one needs an updated download-cache.
[22:23] <wgrant> rocketfuel-get updates both.
[22:24] <lifeless> ah
[22:24] <lifeless> wgrant: is there a UEC AMI for doing LP dev?
[22:25] <wgrant> lifeless: No.
[22:28] <bdmurray> wgrant: okay I ran rocketfuel-get and it got the new version of lazr-js but its still failing
[22:29] <wgrant> Hmmm.
[22:31] <bdmurray> oh, that's not quite right
[22:31] <bdmurray> I have 0.9.2DEV not -r169
[22:33]  * bdmurray takes it back
[22:33] <wgrant> I can see it was added to the branch 7 hours ago.
[22:35] <bdmurray> okay I'm all squared away now thanks
[22:42] <lifeless> wgrant: do you know, is the EC2 test AMI suitable for adapting to be a development AMI?
[22:43] <wgrant> lifeless: I considered that. Quite possibly -- it can already do 'ec2 demo'.
[22:44] <wgrant> (although it needs an image update for the OpenID stuff)
[22:45] <lifeless> do you know the size of the AMI?
[22:46] <wgrant> No.
[23:04] <mwhudson> jelmer: any luck with incremental imports?
[23:05] <jelmer> mwhudson: I wrote a small plugin to add --limit to bzr pull - lp:~jelmer/+junk/bzr-pull-limit
[23:08] <jelmer> mwhudson, but I haven't really been able to reproduce the problem yet
[23:08] <wgrant> sinzui: Around?
[23:09] <sinzui> I am
[23:09] <wgrant> sinzui: I'm interested in making the mirror prober less inflexible by converting it to a job-based system.
[23:10] <sinzui> That will make several people happy
[23:16] <sinzui> wgrant: jpds may also be interested in the job system for mirrors. There is a small chance the two of you could step on each other.
[23:17] <jpds> sinzui: We do that all the time. ;)
[23:17] <wgrant> sinzui: Oh, don't worry, I'm talking to him.
[23:17] <mwhudson> jelmer: :/
[23:17] <sinzui> fab.
[23:17] <mwhudson> jelmer: oh well, something for monday then
[23:18] <jelmer> mwhudson: If I have a spare moment on the train I might have a look during the weekend
[23:18] <mwhudson> ooh, staging is updated
[23:19] <mwhudson> let's try it there
[23:19] <mwhudson> jelmer: ok, don't sweat it
[23:22] <lifeless> mwhudson: so a full repo fetch wasn't it ?
[23:25] <wgrant> sinzui: It seems to me that there are two options for doing this: adding a next_probe_time to DistirbutionMirror, or adding a full-blown DistributionMirrorProbeJob.
[23:27] <sinzui> wgrant: In the former to do image a default time and allowing users to choose probe now so that the existing proc will pull all those that are due for a probe?
[23:28] <wgrant> sinzui: Something like that, yes.
[23:30] <wgrant> The former probably makes more sense.
[23:31] <sinzui> I think so to, but I am thinking of reason that might happen in the next year that make us want a job instead
[23:31] <wgrant> Oh?
[23:31] <wgrant> I couldn't think of anything compelling.
[23:32] <sinzui> wgrant: nor me
[23:51] <lifeless> ugh
[23:51] <lifeless> http://lanchpad.net/testresources


[00:28] <Newk> ah well.. gonna try again tomorrow.. have a nice day!
[13:13] <rob0917> what changes are expected in lubuntu 11.04 ?
[16:23] <johnn> Hello everyone, i have a problem. In Ubuntu i can just open a folder and enter the location "ssh://something" to go there. In Lubuntu, when i do the same thing, i get the error "the specified location is not supported". What is going on?
[16:32] <subdee> johnn: PCManFM, which is the default file manager for Lubuntu does not support ssh. You can either install Nautilus which is the file manager in Ubuntu, or find an SSH client, or use sshfs to mount a remote folder
[16:39] <johnn> thank you subdee, it's just that i kind of remember it working in a previous version, but i guess not :)
[16:57] <gilir> natty alpha 1 available
[16:57] <gilir> please use the torrent : http://people.ubuntu.com/~gilir/lubuntu-natty-alpha1.iso.torrent :)
[20:08] <phillw> gilir: I'm grabbing it now., unless bioterror can grab it more quickly and put it onto my server area.
[21:13] <UndiFineD> I am seding as well, at 235% now
[21:20] <rob0917> how do I make the clock show in 12 hour mode
[22:06] <AndrewMC> UndiFineD: torrent link... ill see as well
 please use the torrent : http://people.ubuntu.com/~gilir/lubuntu-natty-alpha1.iso.torrent :)
[22:10] <UndiFineD> > 300% now :D
[22:27] <GaryD> Excuse me...I noticed that on my machine with lubuntu on it the wine menu shows up as wine in the menu...but on a fresh install of lubuntu with wine on a friend's, the wine software shows up under other in the menu. What extra package could have been installed to my machine that would let the menu read the wine menu and not put wine under other?
[22:28] <GaryD> Maybe it is a lib or something?
[22:38] <phillw> GaryD: it is most likely the way the menu structure is set out, you *can* manually edit it, but it's quite involved and, to be honest, not really worth it unless you see it as a MAJOR issue.
[22:40] <phillw> GaryD: I can raise it on the mailing list so the devs are aware of it, else you can do so via https://wiki.ubuntu.com/Lubuntu/GettingInvolved in which case you will get a direct answer from one the team.
[22:41] <GaryD> Thanks...it kind of is major, but not too major...the thing is, my friend is a little "out there" and I know that it will end up confusing her. I have never edited the menu manually on my machine, I noticed this same issue with 10.04, and I thought it had just been fixed with 10.10 when I noticed it on my mach. That is why I asked, because I noticed hers was different.
[22:41] <GaryD> OK...thanks for that!