| === timrc-afk is now known as timrc | ||
| === Guest33821 is now known as mfisch | ||
| === mfisch is now known as Guest10736 | ||
| Logan_ | the Debian BTS makes me sad | 02:28 |
|---|---|---|
| Noskcaj | Logan_, Where's the problem in a website from the 90's that can only be controlled by email? ;) | 02:59 |
| ScottK | It does it's job well enough and has features that LP for all it's web shininess doesn't. | 03:36 |
| Logan_ | ScottK: it often fails for me | 04:58 |
| ScottK | Do you use bts? | 04:58 |
| Logan_ | no, but I probably should | 04:59 |
| Logan_ | but control@bugs.debian.org is so unpredictable sometimes | 05:00 |
| Logan_ | like, I tried to merge a bug in src:package with a bug in package | 05:00 |
| Logan_ | so first I did: affects bug2 src:package | 05:01 |
| Logan_ | and then I merged | 05:01 |
| Logan_ | but it said that bug2 affects package, not src:package | 05:01 |
| Logan_ | so then I did: affects bug1 package | 05:01 |
| Logan_ | and tried to merge | 05:01 |
| Logan_ | but it said that bug2 affects src:package, not package | 05:01 |
| Logan_ | and then I cried | 05:01 |
| infinity | Logan_: You probably wanted reassign, not affects. | 05:18 |
| Logan_ | fffff | 05:19 |
| Logan_ | I've even used that in the past | 05:19 |
| Logan_ | ugh | 05:19 |
| Logan_ | if there were a GUI, I wouldn't have confused the two :( | 05:19 |
| infinity | One could write a GUI that effectively just pinged commands off the control bot. | 05:20 |
| infinity | But the bts CLI tool is pretty friendly, from what I hear. | 05:20 |
| infinity | (I've been using control@d.o for so long that I don't really care) | 05:20 |
| infinity | @b.d.o, even. | 05:21 |
| udevbot | Error: "b.d.o," is not a valid command. | 05:21 |
| infinity | udevbot: SUPER HELPFUL, THANKS. | 05:21 |
| udevbot | Error: "SUPER" is not a valid command. | 05:21 |
| Logan_ | :3 | 05:21 |
| ScottK | Logan_: Try bts. It makes it a lot easier. Plus man bts is a lot handier documentation then a web page. | 05:23 |
| Logan_ | will do :P | 05:23 |
| * infinity goes to bed at a sensible hour for the second night in a row, and wonders if this will last... | 05:25 | |
| infinity | Fingers crossed. | 05:25 |
| sarnold | for "yes" or for "no"? :) | 05:25 |
| infinity | sarnold: I'm hoping for yes, but history isn't on my side here. | 05:26 |
| sarnold | infinity: aha :) good luck | 05:26 |
| * ScottK notes he's in a later timezone than infinity and figures he's missed sensible. | 05:27 | |
| ScottK | Best go to be at an unreasonable hour then. | 05:27 |
| pitti | Good morning | 06:21 |
| pitti | slangasek: bug 1377698> ack, will fix ASAP | 07:02 |
| ubottu | bug 1377698 in util-linux (Ubuntu) "/etc/default/rcS: UTC=no is being ignored" [High,Triaged] https://launchpad.net/bugs/1377698 | 07:02 |
| zyga | pitti: hey :) | 07:04 |
| pitti | hey zyga, how are you? | 07:07 |
| jdstrand | cjwatson: hey, I'm trying to figure out some corruption that sometimes happens in /var/cache/apparmor and /var/lib/apparmor/profiles and I started thinking about click-system-hooks and apparmor upstart job interactions | 07:17 |
| jdstrand | cjwatson: click-system-hooks.conf has 'start on filesystem' and apparmor.override has 'start on starting lightdm' | 07:19 |
| jdstrand | cjwatson: they are both tasks | 07:19 |
| jdstrand | cjwatson: aiui, both could end up calling aa-clickhook depending on the circumstances (the apparmor upstart job may run aa-clickhook -f) | 07:22 |
| cjwatson | You should probably have a lock or something. | 07:24 |
| jdstrand | cjwatson: so, that is one idea. I also wondered if the upstart jobs should change in some way | 07:32 |
| cjwatson | jdstrand: How would you suggest? I don't think click-system-hooks can safely move later, and I don't think apparmor.override should be waiting for click-system-hooks. I'm also reluctant to try to complicate the Upstart jobs for this because that seems fragile. | 07:35 |
| cjwatson | jdstrand: And also adding anything more that further complicates the impending transition to systemd seems like a bad idea ... | 07:36 |
| jdstrand | cjwatson: I wasn't sure what to suggest, which is why I wanted to ask | 07:36 |
| jdstrand | I'll think about the lockfile | 07:37 |
| jdstrand | cjwatson: how grumpy will click-system-hooks be if apparmor exited non-zero? where would it be logged, in /var/log/upstart/click-system-hooks.log? | 07:50 |
| jdstrand | cjwatson: s/apparmor/the apparmor system hook/ | 07:51 |
| cjwatson | jdstrand: It will exit 1 and log to /var/log/upstart/click-system-hooks.log. Life will otherwise go on. | 08:14 |
| cjwatson | jdstrand: (In particular, a single hook failing doesn't stop it running other hooks.) | 08:14 |
| * jdstrand is trying to decide if it should exit(1) if the lock exists or block | 08:15 | |
| cjwatson | jdstrand: I think you need to block, because the currently-in-progress run may not be operating on up-to-date input information. | 08:15 |
| === doko__ is now known as doko | ||
| cjwatson | And if you exit(1) then nothing else might generate the required profiles until the next boot. | 08:16 |
| jdstrand | right | 08:16 |
| cjwatson | Better to have startup be a bit slower than to be wrong, I think | 08:16 |
| jdstrand | I was leaning towards that | 08:16 |
| jdstrand | ok, thanks for the input | 08:16 |
| cjwatson | np | 08:16 |
| zyga | pitti: hey, quick question | 09:02 |
| zyga | pitti: what is the best way that a process can reliably confine and kill all the children it has forked? | 09:02 |
| zyga | pitti: is the only reliable way to use a control group? | 09:03 |
| zyga | pitti: or can this be done in a less complicated way? | 09:03 |
| zyga | pitti: the only other thing I've considered is a session (setsid) but I think that's pretty easy to escape | 09:04 |
| pitti | zyga: haha | 09:04 |
| pitti | zyga: that's the very question that has kept me up yesterday and last night -- https://plus.google.com/u/0/107564545827215425270/posts/bAm9jiYE3JB | 09:05 |
| pitti | zyga: you can trivially escape both sessions and process groups (most daemons do that) | 09:05 |
| zyga | pitti: I know, I read that :) | 09:05 |
| pitti | zyga: ah :) | 09:05 |
| pitti | zyga: so, without cgroups you can't (reliably) | 09:05 |
| zyga | pitti: right, and I think our focus is the same | 09:05 |
| pitti | zyga: for ssh I kill all processes that have an fd open to ssh's terminal | 09:05 |
| zyga | pitti: my goal is to also kill test payload leftovers | 09:05 |
| pitti | as that's my main concern (stop ssh from hanging) | 09:05 |
| zyga | pitti: hmm, there's more and more overlap between plainbox and adt :) | 09:06 |
| zyga | pitti: is there a way to ask for a control group without being root? | 09:06 |
| pitti | no | 09:06 |
| zyga | pitti: nothing we can ask systemd for? | 09:06 |
| zyga | pitti: via dbus/ | 09:06 |
| pitti | zyga: my hilariously hideous patch for unblocking ssh is http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=3f685f54 (you may vomit now) | 09:07 |
| pitti | it's ugly as hell, but so far the best I could come up with with normal user privs | 09:07 |
| zyga | pitti: interesting | 09:08 |
| zyga | pitti: yes, it's not terribly elegant | 09:09 |
| zyga | pitti: hmm | 09:09 |
| zyga | pitti: sigh, the main target is to reliably test touch but there we don't have systemd at all :/ | 09:09 |
| zyga | pitti: thanks, this is educative, we may be left with something similar | 09:10 |
| zyga | pitti: btw, maybe we could consider merging adt and plainbox later on, we seem to try to do the same thing (setup, execute and teardown a test session) (just a thought) | 09:11 |
| zyga | pitti: I won't be able to go to the sprint but I'd like to talk about that one day | 09:11 |
| pitti | zyga: yeah, with the autopilot tests that I ran through autopkgtest on the phone I haven't seen any hangs -- apparently our tests are well behaved and don't leak processes :) | 09:11 |
| pitti | but in principle this sohuld affect the phone as well; it's an ssh specific problem, not specific to nova or adb | 09:12 |
| * zyga was chasing after a few 'leaking' dbus-launch sessions | 09:12 | |
| zyga | pitti: well, it's not like adb will care but we'd like to make sure that running a session of N tests, we don't stockpile processes around | 09:12 |
| pitti | zyga: I meant autopkgtest's setup script for adb (i. e. running autopilot tests on the phone) vs. nova (running autopkgtests in the cloud) | 09:14 |
| pitti | nevermind, was mostly loud thinking | 09:14 |
| zyga | pitti: thanks, I'll keep an eye out to autopkgtests | 09:15 |
| zyga | pitti: and steal some good ideas you have there :) | 09:15 |
| Saviq | pitti, hey, is there a way to apport-retrace click crashes yet? | 09:22 |
| pitti | Saviq: no, there isn't | 09:23 |
| pitti | Saviq: well, you can manually run apport-retrace on the device of course, but not automatically through LP bugs or errors.u.c. | 09:24 |
| pitti | Saviq: (and manually install all necessary debug pacakges) | 09:24 |
| Saviq | pitti, well, yeah, that manual apport-retrace is what tsdgeos was trying to do | 09:24 |
| Saviq | and got http://paste.ubuntu.com/8513258/ | 09:24 |
| pitti | Saviq: we have zero support for click packages, implicit dependencies, and system-images so far | 09:24 |
| Saviq | Package will never be filled will it? | 09:24 |
| pitti | it also doesn't have a core dump | 09:25 |
| pitti | presumably that's a .crash which has never been sent through apport-cli, but for clicks that doesn't help either | 09:25 |
| tsdgeos | pitti: it does have a core dump | 09:25 |
| tsdgeos | or so apport-cli says | 09:25 |
| pitti | as there is no Package:/Dependencies: for clicks | 09:25 |
| pitti | ah | 09:25 |
| pitti | anyway, apport-retrace (or apport reports) won't help you much for now | 09:25 |
| tsdgeos | pitti: note the error is "doesn't have some of this things" not "doesn't have any of this things" | 09:26 |
| tsdgeos | the only thing missing is actually Package | 09:26 |
| pitti | and Dependencies: | 09:26 |
| pitti | and apport being able to download and unpack clicks or system images | 09:26 |
| pitti | and us not having ddebs for older system images, nor an index for it, etc. | 09:27 |
| pitti | the latter is being worked on, but it's a huge project | 09:27 |
| pitti | and we haven't really talked at all about apport in a click/system-image world yet | 09:27 |
| tsdgeos | ok | 09:30 |
| === Pici` is now known as Guest66735 | ||
| brainwash | pitti: just curious, can I install systemd from unstable? do I have to add the ubuntu delta? | 09:44 |
| brainwash | I assume that there will be some problems with 215 or 216 in utopic | 09:44 |
| === rbasak_ is now known as rbasak | ||
| pitti | brainwash: without the Ubuntu delta you'll most probably create some havoc in /usr/share/doc, introduce unsupported udev config files, and break initramfs | 09:52 |
| brainwash | sounds great :> | 09:53 |
| pitti | brainwash: rather use darkxst's systemd 215 package PPA (not sure where he keeps that) | 09:53 |
| brainwash | tim? | 09:54 |
| brainwash | the gnome guy? | 09:54 |
| brainwash | let me check | 09:54 |
| pitti | brainwash: if you want to boot systemd, that's the only thing you need; for booting with upstart you need to rebuild systemd-shim | 09:54 |
| pitti | yes | 09:54 |
| brainwash | it's a minimal systemd only system | 09:54 |
| pitti | brainwash: if it's a throwaway system without complicated "need to wait for this root partition" setup, you can try the debian package | 09:55 |
| pitti | brainwash: but don't try this on your desktop workstation, it's rather involved to sidegrade back to the ubuntu version as you need to clean up some conffiles | 09:55 |
| darkxst | it's 214 and was unit293's merge who messed up the merge a little, but it works | 09:56 |
| brainwash | I'm aware of that | 09:56 |
| brainwash | ok, thanks for the info | 09:57 |
| brainwash | a ppa with systemd from unstable + ubuntu delta would be quite handy | 09:57 |
| darkxst | brainwash, ppa:darkxst/sd214 | 09:57 |
| brainwash | yep, found that one :) | 09:58 |
| darkxst | its missing some of the ubuntu delta though | 09:58 |
| brainwash | but it should work, right? someone has actually tested it I'd guess | 09:59 |
| darkxst | a few of us have been running it for quite some time without issues, but its never had (nor ever will) get mass testing | 10:02 |
| pitti | brainwash: so, as long as you only install that in a place which doesn't need to survive a dist-upgrade and isn't production, that's fine | 10:03 |
| pitti | I expect to do a merge with Debian at the end of October, after utopic's release | 10:03 |
| pitti | so first thing in V | 10:03 |
| pitti | i. e. git rebase -i'ing the Ubuntu branch and fixing the conflicts | 10:03 |
| * pitti pats proper VCS packaging :) | 10:03 | |
| * darkxst still waiting on sjoerd to move pkg-gnome to git ;) that should make things a lot easier ;) | 10:06 | |
| === MacSlow is now known as MacSlow|lunch | ||
| doko | cjwatson, bdmurray: please subscribe foundations to the babeltrace bug reports | 11:47 |
| cjwatson | doko,bdmurray: done | 11:48 |
| === MacSlow|lunch is now known as MacSlow | ||
| === arges` is now known as arges | ||
| apachelogger | pitti: http://paste.ubuntu.com/8514115/ any objections to this? changes PPA to PPAS, appending multiple --ppa arguments to that and then looping in add_ppas to add multiple ppas to the ubuntu-defaults.list | 12:04 |
| arges | Trevinho: ChrisTownsend: hey i'm reviewing the upload for libindicator/trusty and there isn't any bugnumber associated with that. Can you fix that and re-upload? | 12:13 |
| ChrisTownsend | arges: Hmm, ok. I wasn't involved in this SRU, but I'll follow up w/ Trevinho and bregma. Thanks for pointing that out. | 12:14 |
| arges | ChrisTownsend: cool np | 12:15 |
| bregma | arges, yeah, the ci-train didn't pick up the bug number for some reason, I'll see about fixing it | 12:15 |
| arges | bregma: great : ) | 12:16 |
| pitti | apachelogger: sure, no problem | 12:16 |
| brainwash | darkxst: I've encountered a dependency problem, "systemd-sysv : Depends: systemd (= 208-8ubuntu7) but 214-0ubuntu1~utopic9 is to be installed" | 12:32 |
| LocutusOfBorg1 | hi ubuntu developer, I'm wondering if I can request a sync for a package I maintain directly here rather than filing a bug... | 12:43 |
| LocutusOfBorg1 | I just updated the copyright file and did a little change in cmake, making it cmake 3.0 compatible | 12:43 |
| LocutusOfBorg1 | (I also have some other syncs to request, but I still need to work on them) | 12:44 |
| pitti | brainwash: well, you have to install all of your built binaries :) | 12:44 |
| brainwash | pitti: systemd-sysv is missing in the list of built packages :/ | 12:46 |
| doko | cjwatson, lintian complains about license-problem-gfdl-invariants errors in Ubuntu. can we just remove this check for Ubuntu? | 12:47 |
| brainwash | pitti: it's darkxst's systemd ppa | 12:47 |
| pitti | brainwash: ah, maybe he based this off the trusty version then which indeed didn't yet build -sysv | 12:49 |
| brainwash | pitti: ah, from the changelog: "Don't build the systemd-sysv package for now." | 12:51 |
| === barry` is now known as barry | ||
| cjwatson | doko: It's case-by-case, not a blanket permission, AIUI | 12:55 |
| === Ursinha-afk is now known as Ursinha | ||
| === _salem is now known as salem_ | ||
| mdeslaur | doko: you regressed my bash security update in utopic | 13:51 |
| mdeslaur | doko: oh, wait, no you didn't, sorry | 13:52 |
| doko | mdeslaur, how? | 13:52 |
| mdeslaur | doko: are you planning on going up to patch -30? | 13:52 |
| doko | yes | 13:53 |
| mdeslaur | doko: great, thanks | 13:53 |
| mdeslaur | I'm going to switch the stable releases to the final upstream patches also | 13:54 |
| === and`_ is now known as and` | ||
| tvoss | pitti, hallo :) | 14:31 |
| doko | mdeslaur, uploaded | 14:33 |
| mdeslaur | doko: cool, thanks! | 14:33 |
| Saviq | charles, are calendar reminders supposed to work properly yet? I saw your branch for valarm triggers, but reminders here seem to not take timzone into account, that known? I couldn't find a relevant bug | 14:39 |
| slangasek | pitti: cheers | 14:42 |
| pitti | slangasek: good morning; fix is in -proposed | 14:42 |
| charles | Saviq, wrt timezones, that sounds like what I reported in https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1291225/comments/4 | 14:43 |
| ubottu | Launchpad bug 1291225 in Ubuntu Calendar App "autopilot tests fail when run in UTC+1 timezone" [High,Confirmed] | 14:43 |
| Saviq | charles, hmm wonder if it's only for repeating events then | 14:44 |
| charles | Saviq, would Mihir be the person to assign 1291225 to? | 14:46 |
| charles | that is, dyk how calendar-app is creating those events? | 14:47 |
| Saviq | charles, could be, yeah | 14:47 |
| slangasek | pitti: hmm, is it? I don't see util-linux in proposed | 14:57 |
| pitti | slangasek: https://launchpad.net/ubuntu/+source/util-linux/2.25.1-3ubuntu2 | 15:32 |
| flexiondotorg | If I wanted a package syncing from Debian does it have to be in testing or can it be pulled from unstable? | 15:35 |
| pitti | flexiondotorg: it can be pulled from anywhere (usually unstable) | 15:35 |
| flexiondotorg | OK, I have a few MATE packages that I would really like sycning. | 15:35 |
| flexiondotorg | What is the process? | 15:36 |
| cjwatson | flexiondotorg: requestsync(1) | 15:36 |
| flexiondotorg | cjwatson, Thanks. Installing... | 15:37 |
| tzero | are PPA keys supposed to match personal keys? I thought I was following the packaging guide, but apt gripes about unauthenticated packages after `apt-add-repository`ing. | 15:37 |
| flexiondotorg | cjwatson, pitti Just out of interest is it possible to requestsync for 14.04? | 15:38 |
| pitti | flexiondotorg: no, we don't do that (https://wiki.ubuntu.com/StableReleaseUpdates) | 15:41 |
| flexiondotorg | pitti, Interesting. So if Ubuntu MATE earns it official status during the 15.04 cycle there is not prospect of ever releasing an official 14.04.2 version of Ubuntu MATE? | 15:42 |
| cjwatson | tzero: Launchpad generates a PPA key for each user the first time they create a PPA. It would be inappropriate to have your personal key used by Launchpad to sign archives - you'd be relinquishing control of it | 15:43 |
| pitti | flexiondotorg: oh, we can SRU into stables, but we don't use syncs for that | 15:43 |
| flexiondotorg | SRU? | 15:43 |
| pitti | flexiondotorg: technically it would be possible, but not policy-wise; mostly, the version numbers would collide with the development release, and we also don't do wholesale updates, we backport fixes | 15:43 |
| pitti | flexiondotorg: stable release update, see the wiki page above | 15:43 |
| flexiondotorg | pitti, Thanks. | 15:44 |
| flexiondotorg | So, if I have people crying out for a 14.04 version I should probably provide that based on my "build system"? | 15:44 |
| slangasek | pitti: ah, there it is - thanks | 15:54 |
| slangasek | pitti: so on systemd, is the init script also masked? | 15:54 |
| flexiondotorg | pitti, Can you confirm this is correct before I raise any others? https://bugs.launchpad.net/ubuntu/+source/mate-panel/+bug/1378421 | 15:54 |
| ubottu | Launchpad bug 1378421 in mate-panel (Ubuntu) "Sync mate-panel 1.8.1+dfsg1-1 (universe) from Debian unstable (main)" [Undecided,New] | 15:54 |
| slangasek | pitti: (and does systemd avoid the /etc/adjtime nonsense?) | 15:55 |
| tzero | cjwatson: hmm, the build log on lp says that it couldn't verify signature. Since I had just created and uploaded that key when the package was submitted, maybe the key hadn't propagated yet. Is it correct that I sign the package source, launchpad verifies it, builds binary packages with the PPA key, and then endusers verify their apt-retrieved files against that PPA key? | 16:01 |
| doko | barry, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg the system-image seed is still incomplete, could you work on the remaining MIRs? | 16:05 |
| doko | seb128, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg indicator-datetime should drop the indicator-applet recommendation, or file the appropriate MIRs | 16:06 |
| seb128 | doko, ? | 16:08 |
| doko | seb128, it's an ubuntu-desktop package, so who should I contact instead? | 16:08 |
| seb128 | doko, it's just that component-mismatch seems buggy | 16:08 |
| seb128 | indicator depends didn't change for cycles | 16:09 |
| doko | looking ... | 16:09 |
| seb128 | they depends on indicator-applet | indicator-renderer | 16:09 |
| seb128 | which is provided by unity | 16:09 |
| seb128 | which is in main | 16:09 |
| doko | Recommends: indicator-applet | indicator-renderer | 16:09 |
| seb128 | yeah | 16:10 |
| seb128 | what I just wrote | 16:10 |
| seb128 | unity Provides indicator-renderer | 16:10 |
| seb128 | which is a | in there | 16:10 |
| doko | yes, but then unity needs to be in the first place | 16:10 |
| seb128 | why? | 16:10 |
| doko | err, because the first alternative counts for things like britney, and mismatches, and other stuff | 16:11 |
| seb128 | you are sure? | 16:11 |
| doko | yes | 16:11 |
| seb128 | I think britney e.g try the second one if the first one is not available | 16:11 |
| doko | cjwatson, ^^^ | 16:11 |
| seb128 | as long as one is ok the condition is ok | 16:11 |
| doko | afaiu one real package needs to match | 16:12 |
| seb128 | those indicator-applet | indicator-renderer depends are like that on indicators for cycles iirc | 16:12 |
| seb128 | that has never been an issue | 16:12 |
| doko | no, it was a component mismatch for at least the past two release cycles | 16:12 |
| seb128 | usually when componant mismatch has such output it's because unity become un-installable on some arch | 16:12 |
| doko | jamespage, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg kazoo needs a MIR | 16:14 |
| jamespage | doko, it does and its pending security team review: | 16:14 |
| jamespage | https://bugs.launchpad.net/ubuntu/+source/kazoo/+bug/1296607 | 16:14 |
| ubottu | Launchpad bug 1296607 in kazoo (Ubuntu) "MIR: python-kazoo; new taskflow version needs python-kazoo from universe" [Undecided,New] | 16:14 |
| doko | jamespage, oops, sorry | 16:14 |
| jamespage | doko, np - I think for once server team are actually up-to-date with MIR's | 16:15 |
| doko | jamespage, no, https://bugs.launchpad.net/ubuntu/+source/websockify/+bug/1108935 ;-P | 16:16 |
| ubottu | Launchpad bug 1108935 in websockify (Ubuntu) "[MIR] websockify" [High,Incomplete] | 16:16 |
| jamespage | doko, oh - - that was yesterday - will look | 16:17 |
| jamespage | soooo clooosee | 16:17 |
| cjwatson | tzero: specifically what build log are you talking about? | 16:18 |
| cjwatson | doko: I was working on the indicator-applet mess, please leave it alone :) | 16:18 |
| doko | seb128, ^^^ | 16:18 |
| cjwatson | though I've forgotten what state it's in | 16:18 |
| cjwatson | it was https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/1367719 but I investigated and determined that it's not a germinate bug after all. I'll have to reinvestigate though as I didn't keep notes, sorry. Can't right now as dreadful internet | 16:19 |
| ubottu | Launchpad bug 1367719 in germinate (Ubuntu) "germinate (maybe?) fails to detect a closed loop on a package currently being processed" [Undecided,New] | 16:19 |
| cjwatson | Oh, I remember, it was actually coming in from Recommends of something in supported-hardware-desktop | 16:20 |
| cjwatson | I was considering http://paste.ubuntu.com/8515539/ but infinity wasn't happy with the fragility of that | 16:21 |
| cjwatson | doko,seb128: so really, nothing to do with unity | 16:21 |
| seb128 | cjwatson, ok, thanks, so we can keep the "Recommends: indicator-applet | indicator-renderer", we don't need the first option to be in main? | 16:22 |
| doko | cjwatson, I don't understand the diff. isn't that for another component mismatch? | 16:23 |
| doko | or is this the first chunk? | 16:23 |
| cjwatson | seb128: yes, just leave it | 16:23 |
| seb128 | cjwatson, thanks | 16:23 |
| cjwatson | doko: It's a bit of a "you are not expected to understand this" patch :) | 16:23 |
| cjwatson | doko: Some Recommends chain from supported-hardware-desktop (I forget which) is operating in a context where unity and the Ubuntu desktop's default indicator stack aren't seeded, and so it ends up expanding legitimately to the other possible stack | 16:24 |
| cjwatson | doko: So the first bit of the patch disables recommends for that seed, and the second fills out some things that go missing as a result | 16:25 |
| cjwatson | doko: But this is really a bit too fragile, and I need to figure out a better answer | 16:25 |
| doko | ahh | 16:25 |
| pitti | slangasek: yes, there's /lib/systemd/system/hwclock.service and service strips off .sh suffixes | 16:25 |
| pitti | (that's a no-op just to mask the init.d script) | 16:26 |
| pitti | slangasek: there are references to adjtime in the source, I think timedatectl --adjust-system-clock writes it; but I haven't checked in detail | 16:27 |
| pitti | sorry, need to leave for today | 16:27 |
| pitti | flexiondotorg: LGTM | 16:27 |
| tzero | cjwatson: under Package build summary, there's the "Completed builds" section. For each arch, there's a "see the log" link in the results. The URI is https://launchpad.net/~username/+archive/ubuntu/ppa/+builds?build_state=built | 16:27 |
| cjwatson | tzero: No, I'm not asking for how to find them in general, I'm asking for the URL to a single example build that you're observing failing | 16:37 |
| cjwatson | tzero: I know how to navigate Launchpad in general | 16:37 |
| cjwatson | tzero: You said "the build log on lp says that it couldn't verify signature", and I want to resolve that to a specific message in context | 16:38 |
| tzero | cjwatson: oh, woops. can I /notice it to you? | 16:38 |
| cjwatson | tzero: Can't you just paste the URL here? | 16:38 |
| cjwatson | Presumably it's a public build | 16:38 |
| tzero | sure, http://goo.gl/L2Czjf | 16:39 |
| cjwatson | tzero: Oh, so are you referring to "gpgv: Can't check signature: public key not found"? | 16:40 |
| cjwatson | and the line below | 16:40 |
| tzero | right | 16:41 |
| cjwatson | tzero: OK, so that matters not at all. The signature on the .changes has already been verified by Launchpad well before it gets to that point, and the build doesn't need to separately verify it; that's just code we haven't made any special arrangements to turn off since it doesn't really matter | 16:42 |
| cjwatson | tzero: You sign the upload; Launchpad verifies that signature; the Launchpad build manager dispatches builds from its queue to workers in its build farm and retrieves the results; Launchpad publishes successful builds to archives including PPAs, signing them with the appropriate keys; when end users fetch archive indices they are verified against the appropriate key | 16:49 |
| cjwatson | tzero: Binary packages themselves aren't signed, just the index files | 16:49 |
| cjwatson | tzero: (But the index files contain hashes of the binary packages, so there's a chain of trust all the way down) | 16:49 |
| tvoss | cjwatson, who would be the right person to ask about pkgstriptranslations? | 16:56 |
| tzero | cjwatson: cool, that makes sense | 17:02 |
| cjwatson | tvoss: pitti | 17:07 |
| seb128 | tvoss, pitti might have called it a day, if you ask on the channel others might be able to help you | 17:28 |
| === roadmr is now known as roadmr_afk | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| YokoZar | So I put in a new Wine upload last night and I noticed that the one I put in a few months ago never made it past -proposed. I believe cjwatson once told me that Wine uploads had to be approved manually because the cross-arch dependency confuses the autotest into thinking it's uninstallable. | 18:48 |
| smoser | does this address mean anything special: fe80::5054:ff:fe92:d68 | 18:54 |
| Ajkthx | they are nuclear launch codes | 18:55 |
| sarnold | fe80 is link-local, right? | 18:56 |
| smoser | yeah, its link local. | 18:58 |
| smoser | os i'm trying to boot a cloud image with ipv6 | 18:58 |
| smoser | and setting /etc/network/interfaces like this: | 18:59 |
| smoser | http://paste.ubuntu.com/8516509/ | 18:59 |
| smoser | when the system comes all the way up, it has the above address for eth0 | 18:59 |
| smoser | anyone have theories on that ? | 19:01 |
| smoser | if i log in and | 19:01 |
| smoser | ifdown eth0; ifup eth0 | 19:01 |
| smoser | then it comes up properly | 19:02 |
| geser | smoser: is this the only address on this interface? | 19:02 |
| smoser | yeah. | 19:03 |
| smoser | http://paste.ubuntu.com/8516541/ <-- ip addr output | 19:03 |
| geser | my interfaces file for vmware-image (with trusty) looks similar but also has an ipv4 stance and the ipv6 address gets set up upon boot without problems | 19:07 |
| === yoloswag420 is now known as Ajkthx | ||
| smoser | geser, right. the goal is actually to *not* have ipv4 at all. | 19:20 |
| === salem_ is now known as _salem | ||
| smoser | stgraber, around ? | 19:53 |
| smoser | anyone able to make sense of comment 12 at https://bugs.launchpad.net/cloud-init/+bug/1377005 ? | 20:16 |
| ubottu | Launchpad bug 1377005 in cloud-init "Breaks machine without IPv4: "Route info failed"" [Undecided,New] | 20:16 |
| smoser | it seems that without ipv4, 'auto' isn't working right. | 20:17 |
| === Ursinha is now known as Ursinha-afk | ||
| geser | smoser: see also bug #1352255 | 20:47 |
| ubottu | bug 1352255 in ifupdown (Ubuntu) "Impossible to configure network interface with only IPv6 address" [Undecided,New] https://launchpad.net/bugs/1352255 | 20:47 |
| smoser | geser, thank you. | 20:49 |
| slangasek | right, sounds like a duplicate | 20:50 |
| slangasek | that is, bug #1377005 sounds like a duplicate of this one | 20:50 |
| ubottu | bug 1377005 in cloud-init "Breaks machine without IPv4: "Route info failed"" [Undecided,New] https://launchpad.net/bugs/1377005 | 20:50 |
| smoser | yeah. | 20:50 |
| slangasek | smoser: so, my earlier question: what do you get with 'ifdown eth0 && ifup --allow auto eth0'? | 20:51 |
| slangasek | this is what /etc/init/network-interface.conf does, and is not the same thing as a plain 'ifup eth0' | 20:51 |
| slangasek | this will let us isolate it to ifupdown itself, vs. the boot scripts | 20:52 |
| smoser | slangasek, it comes up | 20:53 |
| smoser | with the desired address | 20:53 |
| slangasek | ok | 20:53 |
| smoser | i have to run. thanks for your help | 20:53 |
| === Ursinha_ is now known as Ursinha | ||
| === _salem is now known as salem_ | ||
| === JanC_ is now known as JanC | ||
| === salem_ is now known as _salem | ||
| tzero | are package.init scripts supposed to be automatically detected and included in a package, or do I have to specify them explicitly? | 21:45 |
| tzero | everything I've read seems to suggest the former | 21:45 |
| === Guest10736 is now known as mfisch | ||
| === mfisch is now known as Guest69465 | ||
| tzero | gpg is also being a PITA | 21:51 |
| === roadmr_afk is now known as roadmr | ||
| === Ajkthx is now known as swagondeezhoes | ||
| tzero | moreover, adding "override_dh_installinit: \n \t dh_installinit" shows that it runs after dh_installchangelogs and before dh_perl; without those lines, nothing | 22:14 |
| === swagondeezhoes is now known as TITTYSWAG420 | ||
| === TITTYSWAG420 is now known as BRINGBACKSLAVERy | ||
| === BRINGBACKSLAVERy is now known as YOLO420KUSH | ||
| slangasek | tzero: what command are you running, and what do you mean by "nothing"? posting your source package and/or your build log would help | 23:28 |
| tzero | slangasek: I added that override to see where dh_installinit was supposed to show up. Build log is here -> http://sprunge.us/NQfE , and only a configuration file, the binary, and the dh_make generated docs are included in the package | 23:37 |
| tzero | ${packagename}.init and ${packagename}.default both exist in the debian/ directory, but neither are included | 23:39 |
| slangasek | tzero: well, I would want to see the whole source package to try to debug this. dh_installinit should be called unconditionally via dh, unless there's something in debian/rules overriding it | 23:43 |
| slangasek | tzero: you might compare with the output of 'dh binary --no-act' | 23:44 |
| tzero | slangasek: hmm, `fakeroot dh binary` added the files. Could it be my override_dh_auto_configure ? that's the only section in rules except for the default % | 23:49 |
| slangasek | well if you posted your debian/rules, I might be able to tell you ;) | 23:50 |
| tzero | slangasek: oops, that's here -> http://sprunge.us/gGAN | 23:51 |
| === timrc is now known as timrc-afk | ||
| tzero | it's not that first hacky sed either :( | 23:53 |
| === timrc-afk is now known as timrc | ||
| slangasek | tzero: ok, so your previous build log certainly shows 'fakeroot debian/rules binary' being called, which should be enough to trigger dh_installinit being called. I'm not sure why your build log doesn't show this; the only reason I know of for commands to be skipped is if they're already seen in the debian/*.debhelper.log, but your build log also includes debian/rules clean | 23:56 |
| slangasek | tzero: if 'fakeroot dh binary' worked for you now, does it also now work end-to-end? | 23:56 |
| slangasek | tzero: oh. this is output from bzr bd, isn't it? | 23:57 |
| slangasek | tzero: in which case, the problem is you haven't added the debian/*.init to the repo | 23:57 |
| tzero | slangasek: the buildlog waz `bzr bd -v -- ` output | 23:57 |
| infinity | Ahh, that wonderfully intuitive behaviour. :) | 23:58 |
| infinity | tzero: For a bit more verbosity to what Steve said, "bzr bd" first does an export of the repo to a clean location before building. Cruft (and something you didn't 'bzr add' is "cruft") won't be included in that. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
