| === _salem is now known as salem_ | ||
| === ming is now known as Guest12249 | ||
| === beisner- is now known as beisner | ||
| === FJKong is now known as FJKong_lunch | ||
| pitti | hallyn: thanks for teh lxc patch reviews; for those which you "acked-by"'ed, is there anything further for me to do, or will you just git am them to trunk? (they don't have particular dependencies on each other) | 04:57 |
|---|---|---|
| === JanC_ is now known as JanC | ||
| === salem_ is now known as _salem | ||
| === FJKong_lunch is now known as FJKong | ||
| pitti | hallyn: cgmanager uploaded to Debian, thanks! But I have a question about integrating the remaining Ubuntu delta in https://mentors.debian.net/package/cgmanager | 05:48 |
| pitti | @pilot in | 05:52 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti | ||
| pitti | halfie: I also uploaded an Ubuntu merge | 05:53 |
| pitti | halfie: sorry, tab error; I meant hallyn | 05:54 |
| === doko_ is now known as doko | ||
| dholbach | good morning | 06:36 |
| ptman | Hi! Is there a reason why http://changelogs.ubuntu.com/meta-release-lts doesn't advertise trusty? I thought do-release-upgrade should suggest trusty after 14.04.1 is released | 06:37 |
| ptman | I can't view the bug reports related to https://code.launchpad.net/~ubuntu-core-dev/meta-release/ubuntu | 06:37 |
| sarnold | ptman: I heard there was a pretty severe upgrade bug ... | 06:37 |
| pitti | hey dholbach | 06:37 |
| pitti | infinity: does this make sense? https://code.launchpad.net/~braiampe/ubuntu/trusty/overlay-scrollbar/fix-for-1262022/+merge/218899 | 06:38 |
| ptman | sarnold, that would be a valid reason. Where should I be able to find out more? | 06:38 |
| pitti | infinity: i. e. does an Arch: all package really need to be marked as M-A: foreign to satisfy non-native arch dependencies? | 06:38 |
| pitti | infinity: that sounds wrong for arch: all, that should be implicit? | 06:38 |
| dholbach | hey pitti | 06:38 |
| sarnold | ptman: hmmm, this says 'fix released', maybe this wasn't the reason after all: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1347964 | 06:38 |
| ubottu | Ubuntu bug 1347964 in ubuntu-release-upgrader (Ubuntu Trusty) "Precise w/Trusty HWE -> Trusty release upgrade fails : ubuntu-desktop fails to configure" [High,Fix released] | 06:39 |
| dholbach | Noskcaj, looks like doko fixed jquery | 06:39 |
| dholbach | Noskcaj, did you have a chance to look at python-wsme or libgtop2? | 06:39 |
| Tribaal | Hi all, silly question - my updated pacakge was pushed into trusty-proposed a while back (good), but I don't understand what it takes to land in the "real" archives. Could somebody shed light on the process? | 07:07 |
| sarnold | Tribaal: you might find it on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 07:08 |
| Tribaal | sarnold: nope, not on there | 07:08 |
| sarnold | oh, trusty, not utopic.. probably wrong place.. | 07:09 |
| RAOF | Tribaal: It needs to be tested to work, marked as such, and then one of the SRU team will release it on the regular sweeps. | 07:09 |
| Tribaal | oh no sorry | 07:09 |
| * Tribaal blames coffee | 07:09 | |
| Tribaal | I tested trusty, but it should have landed in *utopic* | 07:10 |
| Tribaal | nevermind :/ | 07:10 |
| LocutusOfBorg1 | pitti, | 07:22 |
| LocutusOfBorg1 | sorry for bothering | 07:22 |
| pitti | hey LocutusOfBorg1 | 07:22 |
| Tribaal | RAOF: so, it might actually make sense to backport the package that is in utopic now to trusty. Where should I start for an SRU? | 07:22 |
| LocutusOfBorg1 | Hi, did you notice the build failure of libvncserver? | 07:22 |
| RAOF | Tribaal: https://wiki.ubuntu.com/StableReleaseUpdates ? | 07:22 |
| LocutusOfBorg1 | thanks for the other merges BTW | 07:22 |
| pitti | LocutusOfBorg1: err yes, just saw the FTBFS mail coming in; apparently some uninstallability in -proposed? | 07:23 |
| Tribaal | RAOF: thanks :) | 07:23 |
| LocutusOfBorg1 | pitti, the new package build-conflicts with libpng12 | 07:23 |
| LocutusOfBorg1 | because it wrongly links png stuff when available | 07:23 |
| LocutusOfBorg1 | the problem is that I cannot reproduce on a clean pbuilder-dist utopic environment | 07:24 |
| Tribaal | ah, maybe I should target trusty-proposed instead | 07:24 |
| * Tribaal is a bit confused as to where the bits should ideally go | 07:24 | |
| LocutusOfBorg1 | BTW I don't know why the hell the debian people but a build conflict on png instead of a simple "--without-png" in rules | 07:24 |
| pitti | LocutusOfBorg1: so perhaps we should do that ^ ? | 07:25 |
| LocutusOfBorg1 | don't know pitti | 07:26 |
| LocutusOfBorg1 | I should talk with jcristau and luca about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725480 | 07:26 |
| ubottu | Debian bug 725480 in libvncserver "libvncserver: don't link against libpng" [Normal,Fixed] | 07:26 |
| LocutusOfBorg1 | I'm working on the package, will report back | 07:27 |
| pitti | LocutusOfBorg1: right, so if there's a --without-png and that works, that seems better than a build-conflicts | 07:28 |
| pitti | LocutusOfBorg1: cheers! | 07:28 |
| pitti | LocutusOfBorg1: should be easy to check, it shouldn't generate a libpng dependency | 07:28 |
| LocutusOfBorg1 | yes I'm already doing that ;) | 07:29 |
| LocutusOfBorg1 | I removed the conflict, rebuilding | 07:29 |
| LocutusOfBorg1 | yes, ldd shows a libjpeg | 07:31 |
| LocutusOfBorg1 | rebuilding with the autoconf flag | 07:31 |
| Tribaal | RAOF: so apparently an SRU is not what is appropriate in this case. Is it possible to put a package in -proposed instead? What is the policy there? (Sorry, I'm a new contributor as you can tell) | 07:32 |
| RAOF | Tribaal: -proposed is the staging ground that we test things to go into -updates. You might be looking for backports? | 07:33 |
| Tribaal | RAOF: ah, yes, probably | 07:33 |
| infinity | pitti: It's not implicit for arch:all, no. arch:all is implicitly mapped to the native arch for sane backward compatibility. | 07:53 |
| pitti | infinity: hm; strange; why wouldn't it satisfy a dependency of e. g. an :i386 on amd64 to an arch:all package? | 07:53 |
| pitti | it seems weird having to change all arch:all packages for that | 07:53 |
| infinity | pitti: There were Good Reasons, but I can't think of that they are right now. | 07:54 |
| infinity | pitti: slangasek probably remembers better, he drove a lot of this. | 07:54 |
| pitti | infinity: ok, thanks; so this is good to sponsor (to utopic for now) | 07:55 |
| infinity | pitti: I didn't read the MP, but if the reasoning otherwise makes sense, and the syntax is correct, sure. If there's an all->any->all sort of chain in play, one needs to make sure that whatever combinations can be installed will actually make sense and work. | 07:56 |
| pitti | ah, https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages | 07:56 |
| pitti | infinity: argh, can't sponsor; daily PS landing.. | 07:58 |
| Noskcaj | dholbach, I can't get wsme to work locally still, and i think it's best to wait for debian for libgtop2 | 08:07 |
| dholbach | Noskcaj, can't get to work in which way? | 08:07 |
| Noskcaj | dholbach, http://paste.ubuntu.com/7921912/ | 08:23 |
| === popey_ is now known as popey | ||
| dholbach | Noskcaj, as I said yesterday: install all the build deps first, then start with -3 - it should work | 08:25 |
| dholbach | if you don't have the build-deps, it'll try to download them | 08:25 |
| dholbach | which will then look like a diff to be applied | 08:25 |
| === zdoch is now known as lubko | ||
| Laney | pitti: hey, can you moderate u-d-a? | 08:58 |
| pitti | Laney: doing | 08:58 |
| doko | ricotz, https://launchpad.net/ubuntu/+source/cogl/1.18.2-1/+build/6176965 please fix, this is a regression, please use dh-autoreconf | 08:58 |
| pitti | Laney: congrats for alpha-2! | 08:59 |
| Laney | cheers | 08:59 |
| Laney | I hacked $TZ to make it happen on the correct day. ;-) | 08:59 |
| doko | LocutusOfBorg1, libvncserver ftbfs on all archs | 09:03 |
| pitti | see IRC scrollback 1.5 hours ago, he's on it | 09:03 |
| pitti | Laney: yup, blame it on me for slow moderation :) | 09:05 |
| LocutusOfBorg1 | doko, ready above | 09:05 |
| LocutusOfBorg1 | :) | 09:05 |
| LocutusOfBorg1 | s/ready/read | 09:06 |
| doko | ahh, thanks | 09:06 |
| LocutusOfBorg1 | I subscribed you to lp 1349386 | 09:08 |
| ubottu | Launchpad bug 1349386 in libvncserver (Ubuntu) "please merge libvncserver from debian" [Undecided,Fix committed] https://launchpad.net/bugs/1349386 | 09:08 |
| LocutusOfBorg1 | since it is your patch :) | 09:08 |
| LocutusOfBorg1 | you can still take the first one and upload if you care ;) | 09:08 |
| LocutusOfBorg1 | there is also a git commit waiting for upload on debian, so maybe fixing first there is better, but I don't know, it is up to you | 09:09 |
| pitti | LocutusOfBorg1: ah, https://bugs.launchpad.net/ubuntu/+source/libvncserver/+bug/1349386/comments/6 looks good, thanks; will upload | 09:09 |
| ubottu | Ubuntu bug 1349386 in libvncserver (Ubuntu) "please merge libvncserver from debian" [Undecided,Fix committed] | 09:09 |
| pitti | LocutusOfBorg1: we can still sync later (much appreciated) | 09:09 |
| pitti | LocutusOfBorg1: err, shouldn't --without-png be appended to dh_auto_configure insted of to dh? | 09:10 |
| * pitti does that | 09:11 | |
| pitti | LocutusOfBorg1: uploaded with that change, thanks! | 09:14 |
| LocutusOfBorg1 | yes pitti that was a mistake | 09:17 |
| LocutusOfBorg1 | damn copy paste | 09:17 |
| doko | pitti, this test result looks ok to me: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-gem2deb/ARCH=amd64,label=adt/ | 09:30 |
| pitti | doko: it's timing out; supposedly the new version is trying to download something from the network, or is just stuck in an infinite loop or something? | 09:31 |
| pitti | doko: the unit tests succeeded, but the first integration test is stuck | 09:31 |
| * pitti runs it locally | 09:32 | |
| pitti | doko: works locally, so I suppose it's trying to download stuff from the internet? | 09:34 |
| doko | ahh | 09:45 |
| doko | well, it's gem2deb ... | 09:45 |
| doko | mitya57, want to have a look at a sphinx issue? https://launchpad.net/ubuntu/+source/heat/2014.2~b2-0ubuntu1/+build/6212253 | 09:53 |
| === ikonia_ is now known as ikonia | ||
| pitti | stgraber: I have a question for you in bug 1346734 | 10:20 |
| ubottu | bug 1346734 in systemd (Ubuntu) "Unprivileged LXC containers don't work under systemd" [Undecided,Triaged] https://launchpad.net/bugs/1346734 | 10:20 |
| darkxst | pitti, hey, what are the systemd plans for this cycle? sticking with 208? | 10:25 |
| pitti | darkxst: no, I hope 214 will land soon in Debian, then I'll update Ubuntu too | 10:27 |
| pitti | darkxst: but I want to stay in sync with Debian | 10:27 |
| pitti | i. e. same version (not literally the same source package) | 10:27 |
| darkxst | pitti, ok that would be good, can't build any gnome until we have 210+ | 10:34 |
| darkxst | I fear everything is just broken again now ;( | 10:34 |
| darkxst | pitti, though I did have 214 running from unit's packages, its pretty broken since the cgmanager/shim changes landed | 10:35 |
| === vila is now known as vila-lunch | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === vila-lunch is now known as vila | ||
| pitti | darkxst: oh, how's that? | 11:30 |
| pitti | darkxst: 208 and 214 shouldn't be fundamentally different wrt. cgroups handling? | 11:30 |
| darkxst | pitti, I see lots of cgroups failed, file not found messages | 11:31 |
| darkxst | and drm fails | 11:31 |
| darkxst | lightdm loads, but not mouse/keyboard ;( | 11:31 |
| pitti | darkxst: oh, wait -- you probably still have cgmanager 0.27-0ubuntu8 | 11:31 |
| pitti | darkxst: try 0.28-3ubuntu1 (landed in utopic today) | 11:32 |
| pitti | darkxst: that stops running cgmanager under systemd (indeed they fight) | 11:32 |
| darkxst | pitti, could be mirror lag | 11:32 |
| pitti | darkxst: yes, it really was just a few hours ago | 11:33 |
| pitti | darkxst: in the meantime, try if "sudo /etc/init.d/cgmanager stop" helps | 11:33 |
| pitti | darkxst: that's needed for e. g. making LXC work, too | 11:33 |
| darkxst | pitti, I can't even get to a working VT or ssh | 11:34 |
| pitti | darkxst: hmm; that sounds more like the symptom of having systemd 204 with cgmanager | 11:34 |
| pitti | i. e. bug 1342586 | 11:34 |
| ubottu | bug 1342586 in systemd (Ubuntu) "[utopic] [proposed] cgmanager breaks lightdm login" [High,Fix released] https://launchpad.net/bugs/1342586 | 11:34 |
| darkxst | pitti, no 204 | 11:34 |
| darkxst | 208 works, 214 breaks | 11:35 |
| darkxst | I see cgmanager update on mirror now, will try that | 11:35 |
| darkxst | pitti, boom! I am in ;) | 11:38 |
| pitti | darkxst: \o/ | 11:38 |
| pitti | @pilot out | 12:10 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| didrocks | stupid question, but with a local sbuild installation, is there any hook to log inside the chroot on build failure? | 12:42 |
| didrocks | google isn't my friend :/ | 12:43 |
| xnox | didrocks: yes. | 12:43 |
| xnox | didrocks: you can set the option to preserve chroot session on build failures, and then use schroot to enter that session id | 12:43 |
| didrocks | xnox: that would be perfect! do you have a handy pointer to that option? | 12:44 |
| xnox | didrocks: --purge-session=purge-mode | 12:44 |
| xnox | Purge the schroot session following a build. This is useful in conjunction with the --purge-build and --purge-deps options when using snapshot chroots, since | 12:44 |
| xnox | by default the snapshot will be deleted. Possible values are always (default), never, and successful. | 12:44 |
| xnox | didrocks: so i think you want "--purge-session=successful", and then list sessions in chroot (and or look up the session UUID from the failed buildlog) and enter it with schroot. | 12:44 |
| didrocks | xnox: let give me it a try :) | 12:45 |
| * xnox assumes you are using snapshots of some kind (overlayfs, lvm, btrfs...) | 12:45 | |
| didrocks | yep | 12:45 |
| xnox | barry`: i've re-ported lazr.authentication to python3, cause i didn't notice your port. I think it's mostly equivalent, apart from your port being more resiliant to accepting either bytes or strings in the middleware. | 12:46 |
| xnox | barry`: or maybe not, cause e.g. i think autorization header is always string, yet in your code it's assumed to be bytes. Not sure. | 12:48 |
| xnox | barry`: and i wouldn't want distribute to be commited =) | 12:48 |
| didrocks | xnox: looking good! thanks a bunch :) | 12:50 |
| pitti | infinity: I'm stunned by bug 1351295 -- I can't see how this makes sense; does that ring a bell per chance? | 12:56 |
| ubottu | bug 1351295 in initramfs-tools (Ubuntu) "Boot fails if /sbin/init is an absolute symlink" [Undecided,In progress] https://launchpad.net/bugs/1351295 | 12:56 |
| === _salem is now known as salem_ | ||
| * dholbach hugs pitti | 13:07 | |
| * pitti hugs dholback | 13:07 | |
| stgraber | pitti: hi | 13:28 |
| pitti | salut stgraber, ça va ? | 13:28 |
| stgraber | pitti: oui, très bien et toi? | 13:28 |
| pitti | stgraber: je vais bien aussi, merci; mais j'attends avec impatience le week-end :) | 13:28 |
| stgraber | :) | 13:29 |
| highvoltage | bon week-end à tous | 13:29 |
| pitti | stgraber: so I have a question for you in bug 1346734 | 13:31 |
| ubottu | bug 1346734 in systemd (Ubuntu) "Unprivileged LXC containers don't work under systemd" [Undecided,Triaged] https://launchpad.net/bugs/1346734 | 13:31 |
| hallyn | pitti: stgraber normally applies the patchset after it's fully acked. | 13:35 |
| pitti | hallyn: ah, thanks; so nothing left to do for me for those | 13:35 |
| pitti | hallyn: I sent a fixed patch for the missing "git add", and had some questions about the first one | 13:35 |
| stgraber | pitti: ah right, I saw your patches but since hallyn asked for some changes I didn't push them yet. I'll look at the mailing-list in a bit and process what's there. | 13:36 |
| stgraber | pitti: I also plan to tag alpha2 early next week (Monday or Tuesday) so unless you're in a big hurry, you'll get the change in the distro then | 13:37 |
| pitti | stgraber: that sounds perfect | 13:37 |
| pitti | stgraber: there's still bug 1350947 (but that has an easy workaround) anyway | 13:37 |
| ubottu | bug 1350947 in lxc (Ubuntu) "apparmor: no working rule to allow making a mount private" [Undecided,Triaged] https://launchpad.net/bugs/1350947 | 13:37 |
| pitti | stgraber: but I'm not in such a hurry; I have my changes to trunk installed locally, so I'm a happy camper :) | 13:37 |
| hallyn | yeah that one has to wait on apparmor iiuc right? | 13:40 |
| pitti | hallyn: not sure whether it's in the parser (appamor) or in the kernel, but either way; jjohansen kindly said he'd look into it | 13:41 |
| pitti | hallyn: but for testing it's an one-line addition to the policy (I put the workaround in the bug) | 13:41 |
| hallyn | pitti: reagrding the apparmor load patch, | 13:41 |
| pitti | so doesn't block development/testing | 13:41 |
| pitti | hallyn: btw, new cgmanager working well; you also made darkxst happy :) | 13:42 |
| hallyn | hm, i guess it's ok. it'll just do nothing if that prog doesn't exist | 13:42 |
| hallyn | pitti: I don't know who that is, but thanks :) | 13:42 |
| pitti | hallyn: ah, if you want to keep that in the distro for now, that's ok for me | 13:42 |
| hallyn | no, it' sok, i just wanted to make sure it won't break fedora etc | 13:42 |
| pitti | hallyn: once we have systemd 210+, we can probably just replace that with an ApparmorProfile= in the .service | 13:42 |
| pitti | hallyn: there's probably a more elegant way for Fedora ^ | 13:43 |
| hallyn | 210+ has apparmor suport built-in? | 13:43 |
| pitti | yes, apparently | 13:43 |
| pitti | profile loading | 13:43 |
| pitti | hallyn: but anyway, it's all protected by test's, and no apparmor (by default at least) on Fedora, so I believe it should be reasonably safe | 13:44 |
| hallyn | so i'm back on my 4 year old sony. it's like an old, i dunno, what do you put on, an old shoe? and old glove? my idioms fail me | 13:46 |
| stgraber | pitti: can you send your sign-off for the batch? | 13:47 |
| stgraber | (unless I missed it) | 13:47 |
| mdeslaur | pitti, hallyn: systemd only has profile _switching_, not loading...we need to create a proper apparmor parser library so we can get systemd to load apparmor profiles properly at boot | 13:48 |
| michagogo | pitti: thanks! | 13:49 |
| xnox | mdeslaur: and upstart? | 13:49 |
| xnox | mdeslaur: is that switching only as well? | 13:49 |
| mdeslaur | xnox: upstart has loading, and switching | 13:49 |
| xnox | mdeslaur: excellent. I wonder if I can do archive wide massacare of /lib/init/apparmor-profile-load usage | 13:50 |
| xnox | =) | 13:50 |
| mdeslaur | xnox: but we call the parser in upstart, and it was made clear on the systemd list that we shouldn't do that, but link to a library | 13:50 |
| hallyn | mdeslaur: and does someone have time to do that? | 13:50 |
| pitti | stgraber: you mean self sign-off all the patches and re-send them all? | 13:50 |
| pitti | mdeslaur: ah, thanks; so we'll still need that script | 13:51 |
| mdeslaur | hallyn: we know we need to do it soon...it's planned, we just haven't gotten to it yet | 13:51 |
| pitti | michagogo: err - you're welcome (for whatever :) ) | 13:51 |
| michagogo | pitti: 1314616 | 13:52 |
| stgraber | pitti: or just reply to Serge's last e-mail asking for a single sign-off for the whole series | 13:55 |
| pitti | michagogo: ah :) | 13:55 |
| pitti | stgraber: ok; I never understood the purpose of Author: having to sign off himself, but sure :) | 13:56 |
| xnox | pitti: it's a declaration that you own copyright, and/or have appropriate permission to open source it. | 13:56 |
| stgraber | pitti: it means that you confirm you have the right to give that to the project (as in, your employer allows you to) | 13:56 |
| xnox | *snap* =) | 13:56 |
| pitti | I'm sure sabdfl doesn't mind me contributing to LXC :) | 13:57 |
| xnox | pitti: without consulting colicitor first?! =)))))) https://code.launchpad.net/~harmoney/upstart/manpage-fixes/+merge/20878 | 13:58 |
| xnox | ( i loved that merge proposal comments ) | 13:59 |
| pitti | hallyn: replied to both now | 14:04 |
| pitti | xnox: colic.. WHAT? get a room! | 14:04 |
| * pitti hugs xnox, TGIF | 14:04 | |
| pitti | xnox: oh argh; yay bureaucracy | 14:05 |
| xnox | pitti: i mean a lawyer =) | 14:05 |
| xnox | pitti: TGIF - T.G.I. Friday's?! | 14:05 |
| xnox | pitti: re: systemd-sysv, can't it just install real files and do dpkg-divert and not conflict with upstart? | 14:06 |
| pitti | hallyn: ooh, sorry, I understand now | 14:06 |
| xnox | pitti: imho, at the moment we want to be able to install systemd-sysv and be able to uninstall it to go back to upstart. | 14:06 |
| pitti | hallyn: git-email converts Author: to the email From:; I'm too used to attaching patches to mails, instead of sending ptaches *as* mails | 14:06 |
| pitti | see, I can even learn stuff on a Friday afternoon! | 14:07 |
| * pitti needs an ice cream now to cool down his brain after this enormous exercise (and also go for some errands) | 14:07 | |
| xnox | pitti: as i new comer to VCS systems - git was my first one ever. And it all made sense until I was asked to setup mta for the first time and somehow learn that the "format-patch" thing it generates doubles up as an email was a complete mystery to me. | 14:08 |
| pitti | wow, you are young! | 14:09 |
| === manjo` is now known as manjo | ||
| hallyn | heh | 14:13 |
| hallyn | pitti: regarding full paths, my point was precisely that by pulling a part of the init script into a script elsewhere on the system, you're encouraging use by something other init, where paths are *not* sanitized. | 14:15 |
| hallyn | of course all setuid-root binaries *should* be sanitiziing paths, but this is a favorite exploit in capture-the-flag contests at least :) | 14:16 |
| tseliot | pitti: thinking of nvidia-persistenced, I think I've found a udev rule that could work to start the nvidia-persistenced daemon. I also have to stop the daemon using udev. Is there a recommended way to do it? | 14:26 |
| === barry` is now known as barry_ | ||
| === barry_ is now known as barry | ||
| barry | bdmurray: ping me when you're online | 14:45 |
| bdmurray | barry: I'm online | 14:47 |
| === gaughen_ is now known as gaughen | ||
| tseliot | pitti: never mind, problem solved | 15:08 |
| jpds | $ sudo apt-get install rtpproxy | 15:34 |
| jpds | $ grep DAEMON /etc/init.d/rtpproxy | 15:34 |
| jpds | DAEMON=/usr/sbin/$NAME | 15:34 |
| jpds | $ ls -l /usr/sbin/rtpproxy | 15:34 |
| jpds | ls: cannot access /usr/sbin/rtpproxy: No such file or directory | 15:34 |
| jpds | Ah, quality. | 15:34 |
| stgraber | barry: system-image-cli is missing a depend on python3-dbus and python3-xdg | 15:36 |
| barry | stgraber: dang. i think both should be added to system-image-common. i can do that for 2.3.2 which is in the citrain now | 15:38 |
| stgraber | barry: do you ever still test system-image-cli without udm? | 15:44 |
| stgraber | barry: I'm testing an ubuntu core image with system-image and it appears to hang on downloading the indices | 15:44 |
| barry | stgraber: no. it's currently non-functional without udm. i have a stalled branch that adds an asyncio internal downloader alternative but haven't had time to finish that yet | 15:48 |
| barry | stgraber: and yes, there are occasional "weird" things happening with udm ;) | 15:49 |
| stgraber | barry: hmm, ok, it's going to become pretty critical seeing how we need this to make progress on the ubuntu core system image stuff | 15:49 |
| stgraber | slangasek, jodh_: ^ | 15:49 |
| stgraber | hmm, hold on, udm is actually installed | 15:50 |
| stgraber | (which we probably don't want in this case, but still, things should kinda work then...) | 15:50 |
| slangasek | yes... using udm for server images may not make the most sense, but it should be functional for a first cut :) | 15:51 |
| stgraber | yeah, trying to figure out why it doesn't... no errors in the log... | 15:52 |
| stgraber | ok, so the target dir didn't exist (we need to set this to something else than /android/cache/recovery ...), creating it and killing udm did the trick | 15:53 |
| barry | stgraber: oh jeez, i just got a crash of udm doing a local test build of si 2.3.2. this is after this morning's dist-upgrade | 15:55 |
| barry | so i think that's a new problem | 15:55 |
| barry | (existing known problems w/o resolution: it occasionally downloads files to the wrong place, and there are intermittent timeouts) | 15:55 |
| barry | looks like the crash was in passing a pause signal to udm | 15:56 |
| slangasek | pitti: fwiw these dependencies on upstart can mostly be dropped not because the packages support systemd as an alternative, but because they're versioned deps that are no-ops post-14.04 | 15:56 |
| jcastro | is `do-release-upgrade` from 12.04 supposed to prompt for 14.04.1 yet? | 16:24 |
| jcastro | aka. did we flip the switch? | 16:24 |
| TJ- | jcastro: I think the update to meta-release-lts has been delayed by a 12.04 update-manager bug-fix in precise-proposed | 16:31 |
| TJ- | jcastro: Not 100% since no-one has admitted responsibility for a finger on the switch :) | 16:31 |
| jcastro | TJ, thanks | 17:46 |
| ventura | i wish to deploy deb packages to my ppa, however i need that during the install processes the 'terms of service' be displayed to the user | 18:18 |
| ventura | how is it done according to ubuntu policies? preinst scripts? | 18:18 |
| dobey | what are you packaging that would require a terms of service be displayed at install time? | 18:19 |
| dobey | and do you have a commercial support contract on launchpad? because its terms do not allow you to put non-redistributable software in a PPA unless you have a commercial agreement and own the rights to that software | 18:22 |
| ventura | for example, a oracle java 7. if i wish to create a debian package of it. | 18:36 |
| ventura | 1. does is respect launchpad terms? | 18:36 |
| rww | Oracle Java isn't allowed in Launchpad. | 18:37 |
| rww | Oracle changed the licensing terms, so... | 18:37 |
| ventura | rww: uhm | 18:37 |
| rww | I think webupd8 has a PPA which packages it similar to Flash where they download it from Oracle's site, though | 18:38 |
| rww | (i.e., there's no actual Oracle property in the PPA) | 18:38 |
| dobey | ventura: yeah, you can't ship the binaries, oracle's license doesn't allow redistribution | 18:39 |
| ventura | dobey, oracle was an example. however the point is extremely valid, thus i have to read if the terms of the binaries i wish to ship allow it too. | 18:40 |
| ventura | rww++ | 18:41 |
| ventura | dobey++ | 18:41 |
| dobey | ventura: if you don't have a commercial agreement with launchpad, and own the rights to the code, you can't put the binaries on launchpad. and there are almost no proprietary things that allow binary redistribution | 18:43 |
| === roadmr is now known as roadmr_afk | ||
| dobey | if you want to make proprietary things installable, you're going to have to do it by writing an open source installer app and shipping that and/or doing an install in the same way that the flash plug-in does | 18:49 |
| ventura | dobey: thx | 19:32 |
| === roadmr_afk is now known as roadmr | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| xnox | ev: slangasek: why do we care about getting the same whoopsie id across re-installs? Full reinstall -> new encornation thus should be new id. | 23:43 |
| xnox | it doesn't affect any stats, as we only count active/relecently seen ids, and reinstalled machine with new id, is one for one trade. | 23:44 |
| xnox | we should use file cache / machine-id, and only if all fails doing the mac/imei guessing. | 23:45 |
| xnox | (i.e. stateless case) | 23:45 |
| xnox | it's not scalable that all launched emulators with same MAC and same IMEI have same whoopsie id. | 23:46 |
| xnox | root vs non-root user has different whoopsie ids =) | 23:48 |
| slangasek | xnox: we do care about being able to identify a device across reinstalls, for associating on errors.ubuntu.com | 23:51 |
| xnox | slangasek: no, we don't. =) | 23:51 |
| xnox | slangasek: i do factory reset, and sell my phone. I don't expect for new user to see my crashes =) | 23:51 |
| xnox | slangasek: and we have changed ID implementation at least 3 times now, and thus broke machine association. | 23:52 |
| xnox | (for typical machines) | 23:52 |
| xnox | using /etc/machine-id or even /var/lib/dbus/machine-id would have preserved association. | 23:53 |
| slangasek | xnox: there are reasons to prefer they not be visible, but for testing, where the device will be regularly reinstalled, not having a persistent id that they can use for locating the device is problematic | 23:53 |
| slangasek | now, if we were to use machine-id as the basis, maybe the answer would be for the test environment to update that id | 23:54 |
| xnox | slangasek: testing things should set CRASH_DB_IDENTIFIER environment variable, which can be passed e.g. on kernel command line. | 23:55 |
| xnox | slangasek: which overrides internal whoopsie identifier generator. | 23:55 |
| xnox | , if that fails and we have a machine-id, i think that should be used. | 23:55 |
| slangasek | editing the kernel commandline is hardly the most convenient interface on the phone | 23:55 |
| xnox | and only last case scenario - completly read-only stateless system -> use the generator. | 23:56 |
| xnox | slangasek: then we should extend both upstart and systemd units to source the /etc/default/whoopsie such that one can specify ID there. | 23:57 |
| xnox | slangasek: is that file RW on the phone? | 23:57 |
| xnox | (i'm not sure the current state of affairs around how to enable/disable it) | 23:57 |
| slangasek | no, it's not, and there's no particular reason to put it in that file | 23:57 |
| xnox | ack. | 23:58 |
| xnox | slangasek: well, i need to introduce a stable / persistant storage for the id, make it world readable, and make sure it's used by default. | 23:58 |
| slangasek | I'd rather we modify /etc/machine-id as part of the provisioning and make whoopsie honor that, than push it anywhere else | 23:59 |
| xnox | IMHO it's redicilous that whoopsie_identifier_generate() call is returning different value for root and non-root user. | 23:59 |
| slangasek | hah, does it? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!