| bdmurray | slangasek: could you have a look at https://code.launchpad.net/~brian-murray/lightdm/bug-967229/+merge/153958 ? | 00:01 |
|---|---|---|
| roaksoax | slangasek: set_questions prevents dbconfig-common from asking a question to whether we want it to configure the db. | 00:07 |
| roaksoax | slangasek: and does it by default | 00:08 |
| roaksoax | slangasek: and you mean this? if ([ "$1" = "configure" ] && [ -z "$2" ]); then | 00:08 |
| roaksoax | ? | 00:08 |
| roaksoax | as the second if block? | 00:08 |
| roaksoax | slangasek: well that block calls set_question, and those variables dbc_* are for dbconfig common | 00:09 |
| cjwatson | slangasek: db_fget sets RET too | 00:09 |
| cjwatson | Indeed all db_* commands do, but db_fget sets it meaningfully for this purpose | 00:09 |
| cjwatson | RET there (in the second if block within set_question) is the value of the seen flag on $1 | 00:10 |
| cjwatson | That function is an obvious descendant of d-i code, FWIW | 00:10 |
| cjwatson | (Well, obvious to me :) ) | 00:10 |
| cjwatson | I rather suspect that I may have been the vector for it ending up in cloud-related packaging code ... | 00:12 |
| cjwatson | Though I don't see it at a glance through eucalyptus, so perhaps not | 00:14 |
| cjwatson | Oh yeah, there it is | 00:19 |
| cjwatson | https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/eucalyptus/lucid/view/head:/debian/eucalyptus-udeb.postinst | 00:19 |
| cjwatson | set_question is essentially "preseed" - set a question's value in the database even if it was not yet registered | 00:20 |
| cjwatson | but only if it is not marked as already being seen | 00:20 |
| roaksoax | yeah that's it | 00:24 |
| slangasek | cjwatson: hmm, what does it set it to? debconf-devel(7) implies that the only return from fget is the return value | 00:35 |
| cjwatson | "This command returns the value of a flag" | 00:39 |
| cjwatson | where the value is not a numeric result code and hence goes in the extended return value in $RET | 00:40 |
| slangasek | ah | 00:40 |
| cjwatson | (admittedly it is true or false so you *could* cram it into a numeric result code, but debconf doesn't) | 00:40 |
| cjwatson | command_fget is implemented ending with | 00:41 |
| cjwatson | return $codes{success}, $question->flag($flag); | 00:41 |
| xnox | infinity: BenC: i wonder what I have to do to get a P-cubed from servergy =)))) | 00:53 |
| * hyperair wonders if https://wiki.ubuntu.com/Wayland is still relevant. | 02:15 | |
| hyperair | it says that compiz is going to be ported to wayland. | 02:15 |
| RAOF | hyperair: Yeah, much of that is obsolete. | 02:19 |
| hyperair | RAOF: hmm, do you have a /hilight on wayland or something? ;-) | 02:20 |
| sarnold | cjwatson: the symlink vs directory thing feels complicated; it feels to me that making 'current' a directory of symlinks (one per arch / flavor) would be less confusing all around... | 02:24 |
| === salem_ is now known as _salem | ||
| pitti | Good morning | 06:03 |
| AdolfosWeb | Hi | 06:48 |
| AdolfosWeb | Someone in there? | 06:49 |
| pitti | xnox: I'm curious, what's the current state of usb-creator port to udisks2? | 06:49 |
| pitti | AdolfosWeb: just ask your question, don't ask to ask | 06:49 |
| AdolfosWeb | ok... I have problems with the suspend option at my ubuntu 12.10 in my new lenovo i3 | 06:50 |
| AdolfosWeb | someone have this problem? | 06:50 |
| pitti | what kind of problem? suspend generally works, so I think you need to give more details | 06:51 |
| AdolfosWeb | ok, well i had look for a solution by days... but nothing, some people have the same problem. When y press suspend boton or the option in de user menu the screen goes black, but then never enters suspend mode, my desktop appears again | 06:55 |
| AdolfosWeb | hecking the /var/log/pm-suspend.log I find that every time I close or suspend my laptop the log reports:'Running hook /usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend: Having NetworkManager put all interaces to sleep...Failed ' | 06:56 |
| === amitk is now known as amitk-afk | ||
| BenC | infinity: poke…about to do a linux-ppc upload…man the buildd's? | 07:05 |
| infinity | BenC: Mmkay. | 07:07 |
| infinity | BenC: Upload away. | 07:07 |
| BenC | infinity: 15 minutes for the test build to finish... | 07:08 |
| infinity | BenC: Too lazy to babysit, adare and ross are on manual, you'll get sagari when you upload, and I'll fix later. :) | 07:09 |
| BenC | Heh, ok, thanks | 07:09 |
| gema_ | cjwatson: I got your email, this work was going to be done by plars from our side, so he'll be contacting you later today about it | 07:27 |
| gema_ | cjwatson: we've been waiting for someone in the release time to have some time to spend with us on that | 07:27 |
| dholbach | good morning | 07:55 |
| BenC | infinity: uploaded and build started | 08:00 |
| * BenC => Memory Foam Mattresszzzzz | 08:01 | |
| infinity | BenC: And failed. | 08:12 |
| infinity | BenC: /build/buildd/linux-ppc-3.8.0/drivers/tty/serial/8250/8250_dw.c:154:1: error: unknown type name 'acpi_status' | 08:12 |
| infinity | BenC: So much for your test build? | 08:12 |
| === smb` is now known as smb | ||
| === amitk-afk is now known as amitk | ||
| tumbleweed | xnox: (re 2 days ago) trailing commas in debian control files aren't a good idea | 08:21 |
| tumbleweed | they aren't part of the specification, and some tools are known to break on them | 08:22 |
| xnox | tumbleweed: i'd like to know what is broken, and I will fix it. | 09:03 |
| xnox | tumbleweed: there are many packages that have a trailing comma. and I'm sure it's comma separated fields anyway, so one should support trailing comma. | 09:04 |
| xnox | tumbleweed: that option is not enabled by default. | 09:05 |
| tumbleweed | I last investigated this ages ago, let me see if I can find the discussion I had with other people about it | 09:07 |
| xnox | pitti: pushed it here lp:~xnox/usb-creator/udisks2 , It segfaults on tear-down and introduces a dep on the udisks2 gir. And that would be a first one on the cd. I'm thinking to just do it over dbus, without gir. Not sure how to solve segfault. | 09:12 |
| pitti | the gir is like 20 kB? | 09:13 |
| pitti | xnox: from Python it's probably not that much difference to use dbus directly, but if you got it workign using the gir, I don't think it's a problem to pull that in | 09:13 |
| pitti | the segfault sounds weird, though, like a bad ref count somewhere | 09:13 |
| xnox | pitti: fair enough, but segfault on cleanup at the very end is indeed "interesting. | 09:14 |
| xnox | pitti: ref count, sounds plausible. | 09:14 |
| pitti | pygobject (just as python itself) unrefs all objects at the end or during gc | 09:14 |
| pitti | xnox: merely starting and quitting it doesn't segfault; what are the steps to reproduce? | 09:16 |
| pitti | neither does it crash with having an usb stick or mounting one | 09:16 |
| pitti | xnox: so I guess you have to do a full write actually? | 09:16 |
| pitti | xnox: oh, trying to erase my stick fails with "org.freedesktop.UDisks.Error.Failed: No such device" | 09:17 |
| xnox | if one goes to create it, at 100% progress (end of talking to udisks2/helper) it crashes without giving a popup "it's all ready". Oh yeah, and erasing stopped working properly. | 09:17 |
| xnox | pitti: note that there are changes in the common helper as well to port that to udisks2 as well. | 09:18 |
| pitti | oh, maybe it's using the installed helper, not from the checkout path? | 09:20 |
| pitti | I ran "PYTHONPATH=. bin/usb-creator-gtk" | 09:20 |
| * pitti purges udisks and usb-creator | 09:20 | |
| pitti | yeah, it's using the dbus activated helpers | 09:22 |
| pitti | xnox: hah, I built and installed your branch, and deletion now complains about missing udisks (not 2) | 09:23 |
| * pitti runs a write, to see whether he can reproduce the segfault | 09:23 | |
| xnox | pitti: make sure the old helper is killed on dbus, as it can stick around after upgrade. | 09:24 |
| pitti | oh, indeed | 09:25 |
| pitti | xnox: http://paste.ubuntu.com/5630671/ | 09:26 |
| xnox | hmmmm..... | 09:26 |
| pitti | but it actually did remove all the files, so I can restart and write now | 09:27 |
| xnox | this should fix that UnboundLocalError http://paste.ubuntu.com/5630681/ | 09:30 |
| * xnox should ponder at refactoring all the if's in that function. | 09:30 | |
| pitti | hm, the stack trace is not very useful; deep inside a libdbus callback, and tons of unintelligible PyEval_* stuff on top | 09:33 |
| pitti | as if the client side has torn down some dbus proxy which still got a reply from the server or so | 09:35 |
| xnox | pitti: interesting. So new udisks2 supports objectmanager interface, so by default when it's initialised we lookup and get proxies for everything udisks2 exports. I wonder if I should be cleaning up the manager myself. | 09:38 |
| xnox | this is the other part of the reason why I'd like to move away from the gir and do it just with dbus, such that all proxies are a little bit more explicitly created & deleted. | 09:39 |
| cjwatson | sarnold: It will often end up being a directory of symlinks. Any complexity in sometimes collapsing this to a single symlink if all the images are current (which should be the case most of the time, I'd hope) is entirely internal to cdimage, though ... | 09:40 |
| pitti | xnox: but the objectmanager object should also be unreffed automatically | 09:40 |
| pitti | but yeah, that one is quite magic | 09:40 |
| === neunon is now known as snoonan | ||
| xnox | cjwatson: current-proposed, latest-crack, incomming. A few other names to choose from. | 09:43 |
| cjwatson | xnox: I don't want to get into a time-sucking bikeshed argument | 09:47 |
| cjwatson | If there's a single better option, propose it :) | 09:47 |
| cjwatson | Also I refuse to put "crack" in a URL | 09:47 |
| pitti | (or any reference to killing kittens, if possible) | 09:48 |
| cjwatson | In general I don't think such a frequently used URL has any need to be flippant | 09:49 |
| xnox | cjwatson: it's just "latest" sounds more attractive to prospective people who download images over "current". Meh.... it doesn't really matter. | 09:50 |
| pitti | "untested"? | 09:52 |
| xnox | would attract manual cd testers to "untested" which is exactly what we don't want them to test yet. =) | 09:53 |
| xnox | on the other hand manual testers is small enough pool and we can communicate the meaning to them. | 09:54 |
| cjwatson | "current-proposed" has a sensible analogy to raring-proposed | 09:54 |
| xnox | "e.g. use iso tracker urls" | 09:54 |
| mgz | can some ubuntu developer approve the nomination of bug 1054722 for raring? just want to mark it as fixed in that series. | 09:58 |
| ubottu | bug 1054722 in gnome-control-center-signon (Ubuntu) "Newly added account appears at the top of the accounts list" [Undecided,New] https://launchpad.net/bugs/1054722 | 09:58 |
| xnox | mgz: done. any other series....? | 09:59 |
| seb128 | mgz, well, just mark it fixed, by default if a bug is fixed that's in the current serie | 09:59 |
| mgz | xnox: nope, would require an sru for quantal and it's apparently too trivial to be worth fixing there | 10:00 |
| mgz | seb128: this is true, but I like knowing when something was fixed when I look back a series hence | 10:00 |
| xnox | seb128: there was no bug reference in the commit / .changes. hence there is no comment fixed in version 3.2.2.3 in raring. | 10:01 |
| seb128 | xnox, well, nothing stops you to copy manually the changelog of the upload that fixed it when closing the bug | 10:01 |
| seb128 | that's what I usually do | 10:01 |
| seb128 | "the issue was fixed in that version: | 10:02 |
| seb128 | <copy of changelog entry for the version>" | 10:02 |
| mlankhorst | how do I force udev to re-emit all events? | 10:03 |
| cjwatson | that's called "coldplugging", if that helps | 10:03 |
| mlankhorst | yeah I just need to confirm a theory | 10:04 |
| cjwatson | 'udevadm trigger' does it, possibly with some options. May break your system. | 10:04 |
| cjwatson | It'd be wise to limit it to a subsystem if you can | 10:04 |
| mlankhorst | oh that's fine | 10:04 |
| cjwatson | cf. /etc/init/udevtrigger.conf | 10:05 |
| mlankhorst | in fact I want to see if I can make it crash in a similar way as in a bug :P | 10:05 |
| mlankhorst | https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1157614 looks suspiciously like xorg-server is running before coldplug was | 10:07 |
| ubottu | Launchpad bug 1050494 in xserver-xorg-video-nouveau (Ubuntu) "duplicate for #1157614 Xorg crashed with SIGABRT in drmmode_from_scrn()" [High,Triaged] | 10:07 |
| bdrung_ | cjwatson: "current-proposed" is less confusing that "proposed". it tells me that current-proposed will become current after some defined rules | 10:55 |
| cjwatson | could you follow up by mail so this is archived? | 10:57 |
| === ckpringle_ is now known as ckpringle | ||
| xnox | ogra_: snap. | 11:03 |
| ogra_ | heh | 11:03 |
| === Sweetsha1k is now known as Sweetshark | ||
| bdrung_ | xnox: do you have a minute? | 11:24 |
| xnox | bdrung_: yeah. | 11:24 |
| xnox | what's up ? =) | 11:24 |
| bdrung_ | xnox: can you propose one or two sentences for --trailing-comma for the man page? | 11:25 |
| bdrung_ | "add trailing comma" is a little short for the man page. | 11:25 |
| === bdrung_ is now known as bdrung | ||
| bdrung | btw, i found a bug in your patch and fixed it. :) | 11:26 |
| xnox | bdrung: http://paste.ubuntu.com/5630896/ | 11:29 |
| xnox | bdrung: what was it? | 11:29 |
| bdrung | xnox: thanks. "if "Uploaders" in paragraph: self._wrap_field()" misses trailing_comma and therefore the uploaders list were sorted, too | 11:30 |
| xnox | ha, nice one. | 11:31 |
| bdrung | xnox: typo "trailling comma" fixed :) | 11:32 |
| === mmrazik is now known as mmrazik|lunch | ||
| * cjwatson tries not to get distracted into wondering about the rule underlying trail -> trailing but trial -> trialling | 11:33 | |
| cjwatson | (multiple syllables, I expect) | 11:35 |
| bdrung | xnox: http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=commitdiff;h=cbd15890e3ddf7dc6c5f135d3bd4e60903797bb6 | 11:36 |
| bdrung | there will be soon an upload of devscripts | 11:36 |
| xnox | awesome. | 11:37 |
| * xnox case + psu collected for RMA, new case and psu expected on monday \o/ | 11:44 | |
| Laney | skillz | 11:44 |
| xnox | Laney: ebuyer even did free collection for RMA, parcelforce dude showed up to collect. | 11:44 |
| * ogra_ would freak out if building a new machine would take so long | 11:46 | |
| BenC | infinity: my test builds only included one flavor | 11:46 |
| BenC | infinity: and who the hell breaks 8250 in a .y update!? | 11:47 |
| === MacSlow is now known as MacSlow|lunch | ||
| === mmrazik|lunch is now known as mmrazik | ||
| xnox | ogra_: i went with free 5 working day delivery. So 1 week for initial delivery, then 1 week of fiddling and figuring out what's broken (mostly blocked by finding people willing for me to use/test their PSU), then a quick RMA and new purchase. Should be 3 weeks in total. | 12:00 |
| xnox | apperanttly newer i7 CPUs want more stable 12V than usual, hence a lower wattage PSUs work better, or those that claim to support intel's 12v v2.1 (or something like that) | 12:01 |
| hallyn | infinity: hey - i'm confused. openbios-ppc seems to build on arch, but gcc-powerpc-linux-gnu, which openbios-ppc depends on, only exists on amd64+i386 ? | 12:04 |
| xnox | with uber-schenell nachsten tagen delivery it could have been 1.5 weeks in total. | 12:05 |
| hallyn | (analogous packages for sparc seem to build fine on amd64/i386, but not sure what to do about arm) | 12:05 |
| tumbleweed | bdrung: I assume the discussion about trailing commas that I had with someone, was with you (becaues initially -s added a trailing comma, and you talked me out of it) but no idea where that is in my irc logs | 12:06 |
| cjwatson | hallyn: it's arch all - does it really matter whether it builds anywhere other than i386? | 12:12 |
| hallyn | cjwatson: oh is that how that works? sorry :) now, in ppa it actually did fail on i386, but it seemed to complain abou tthe arm pkg missing | 12:13 |
| cjwatson | that is how it works, yes - can I see the ppa build log/ | 12:13 |
| cjwatson | ? | 12:13 |
| hallyn | cjwatson: https://launchpad.net/~serge-hallyn/+archive/crossc/+build/4382596 | 12:14 |
| hallyn | (confused why it's building on arm ppa builder) | 12:14 |
| OdyX | tkamppeter_: 'CUPS 1.6.2 got released on Monday and I have packaged it for Raring.' => I'd appreciate slightly more recognition... | 12:14 |
| xnox | hallyn: it's an odd name. it's not actually arm. | 12:14 |
| hallyn | oh ok | 12:14 |
| cjwatson | hallyn: oh, that's irrelevant :) the "arm ppa builder" can build for any of i386/amd64/armhf depending on config | 12:14 |
| hallyn | gotcha | 12:15 |
| xnox | https://launchpad.net/builders/wani02 "Architecture: Intel 386 (virtual)" | 12:15 |
| cjwatson | hallyn: the arch in the build log url tells you what it was actually doing | 12:15 |
| cjwatson | (you can't rely on the current builder configuration; they're often rebalanced) | 12:15 |
| hallyn | ok so the problem isn't at all what i thoguth it was then | 12:15 |
| xnox | cjwatson: can we rename builders to be less confusing and not include arch name, when the builder is not actually arch-specific. | 12:16 |
| cjwatson | hallyn: so that just means that gcc-sparc-linux-gnu was uninstallable in your PPA at the time when that build happened | 12:16 |
| cjwatson | xnox: -> infinity | 12:16 |
| xnox | infinity: s/arm// on all virtualised builders, as it's confusing to see an "arm ppa builder" picking up i386/amd64 builders. | 12:16 |
| xnox | please =) | 12:16 |
| cjwatson | xnox: definitely not as simple as that because we do need to know which of them are arm-capable. | 12:17 |
| cjwatson | hallyn: I'm not sure where gcc-4.7-multilib-sparc-linux-gnu is meant to come from; it's not in the archive and I don't immediately see it in your PPA | 12:17 |
| hallyn | cjwatson: it should in ppa, built from gcc-defaults-sparc-cross, lemme recheck | 12:17 |
| cjwatson | gcc-defaults-sparc-cross only builds the top-level metapackages, not the compiler itself | 12:17 |
| * xnox universal... flexible... | 12:17 | |
| cjwatson | you need a gcc-4.7-sparc-cross | 12:18 |
| hallyn | well huh. i thought i'd pushed that too. but never started that one. | 12:18 |
| hallyn | sorry. thanks :) | 12:18 |
| cjwatson | np | 12:18 |
| bdrung | tumbleweed: i don't like trailing commas, but having an option to add it is a compromise | 12:21 |
| xnox | stgraber: I added comments / questions to the https://wiki.ubuntu.com/ImageBasedUpgrades/Mobile | 12:23 |
| === _salem is now known as salem_ | ||
| timrc | cjwatson, Throwing my suggestion into the hat for maybe 'tip' or 'current-untested' rather than 'latest' | 12:33 |
| * ogra_ likes "current-untested" | 12:33 | |
| ogra_ | tip is to technical imho | 12:34 |
| timrc | ogra_, I think 'current-untested' is the stronger of the two as well | 12:35 |
| tumbleweed | bdrung: yeah | 12:43 |
| === Pici` is now known as Pici | ||
| cjwatson | timrc: how about current-proposed? | 12:45 |
| cjwatson | I think "current-untested" encourages human testers to have a go, a little more strongly than I'd like | 12:45 |
| cjwatson | (and at some point I have to actually paint this bikeshed) | 12:47 |
| janimo | FWIW kernel team uses 'next' in their WIP master branch | 12:47 |
| rbasak | pre-qa? pre-auto-qa? pending? Focusing on putting off human testers here, so that they can focus on current. | 12:49 |
| ogra_ | "current-untested-not-really-for-human-testers.-but-proposed" | 12:50 |
| * didrocks likes current-proposed | 12:51 | |
| ogra_ | we could then promote http://llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogo.ch/ for link shortening :) | 12:51 |
| cjwatson | I was thinking of pending too | 12:53 |
| cjwatson | or even pending-autotests or something | 12:53 |
| ogra_ | "current-untested-not-really-for-human-testers-but-peding-autotestes-to-become-proposed" | 12:53 |
| cjwatson | but seriously ... | 12:54 |
| ogra_ | (go with current-propsed) | 12:54 |
| rbasak | "proposed" implies that users should test it. Like they do the proposed pockets for SRUs | 12:55 |
| cjwatson | like they don't raring-proposed :) | 12:56 |
| cjwatson | (or shouldn't, anyway) | 12:56 |
| rbasak | :) | 12:56 |
| cjwatson | pending-autotests is fairly descriptive | 12:56 |
| rbasak | +1 | 12:56 |
| cjwatson | although it's confusing for the cases that *don't* have autotesting | 12:56 |
| rbasak | Just "pending" then? | 12:56 |
| ogra_ | pending-testing ? | 12:57 |
| pitti | well, britney also does some installability testing, after all? | 12:57 |
| rbasak | "pending" implies that users should wait for something | 12:57 |
| cjwatson | pending-testing> no, that invites human testing | 12:57 |
| cjwatson | pitti: sure, but no images are built from rarnig-proposed | 12:57 |
| ogra_ | geez english is such a complicated language | 12:57 |
| rbasak | Nobody wants to hit something that says "pending" on its own if they don't know why it's pending, since it's implied that it will change under their feet | 12:57 |
| cjwatson | so that distinction isn't really helpful to draw | 12:57 |
| cjwatson | yeah, rbasak may have nailed it here | 12:57 |
| rbasak | ogra_: steal bits of language from a load of other languages and you end up with a twisted, confusing, unmaintainable mess :) | 12:59 |
| ogra_ | haha yeah | 12:59 |
| ogra_ | i generally find english easier than german though | 12:59 |
| ogra_ | (my fingers often dont ... ) | 12:59 |
| rbasak | German is confusing for entirely different reasons :) | 13:01 |
| ogra_ | not if you grew up with it :) | 13:01 |
| rbasak | True | 13:01 |
| rbasak | (I presume!) | 13:01 |
| rbasak | How about "broken"? Nobody would bother testing that :-) | 13:02 |
| xnox | "maybe-broken" is more descriptive. | 13:03 |
| rbasak | presumed-broken? | 13:03 |
| xnox | "hostly-harmless" | 13:03 |
| xnox | "mostly-harmless" | 13:03 |
| === MacSlow|lunch is now known as MacSlow | ||
| timrc | cjwatson, sorry, I had toddler-duty... While I feel that maybe it will invite human testing, 'untested' is more explicit... if the only difference between 'current' and 'latest' is smoke testing, what about 'current-not-smoke-tested'... it's sort of long, but I like the explicit nature of it | 13:07 |
| === yofel_ is now known as yofel | ||
| timrc | or maybe 'current-pending-autotests' *shrug* | 13:08 |
| timrc | not terribly succinct :( | 13:09 |
| pitti | +1 for "pending-autotests" | 13:16 |
| === wedgwood_away is now known as wedgwood | ||
| tkamppeter_ | OdyX, sorry, I wanted to say that I have synced it into Raring, for the reporter of the bug to test whether his problem is solved. Probably confused it with Ghostscript. | 14:00 |
| === tkamppeter_ is now known as tkamppeter | ||
| tkamppeter | pitti, hi | 14:02 |
| OdyX | tkamppeter: no problem I'm not offended or anything, just surprised. FYI, I'm working on splitting the documentation and common files to cups-server-common to reduce the arch-specific packages' sizes; it'll go through NEW. | 14:14 |
| seiflotfy | tedg: ping | 14:30 |
| tedg | Howdy seiflotfy | 14:30 |
| seiflotfy | tedg: in you new work can you make sure you use libzeitgeist2 | 14:30 |
| seiflotfy | no more dbus roundtrips :D | 14:30 |
| seiflotfy | direct access when reading | 14:30 |
| seiflotfy | only writing goes over dbus | 14:30 |
| seiflotfy | saves a lot ofserializing and time | 14:30 |
| tedg | seiflotfy, Yup, definitely going to do that :-) Only reason I'd consider ZG . | 14:30 |
| tedg | seiflotfy, It's why we didn't use it before. | 14:30 |
| seiflotfy | tedg: sweeeeeeeeeet | 14:31 |
| seiflotfy | tedg: we are discussing something new | 14:31 |
| tedg | Uh, oh. ;-) | 14:31 |
| hyperair | hmm, would porting unity to that fix the horrible unity dash lags? | 14:31 |
| seiflotfy | we might allow applications to host thier own instance of zeitgeist in their process and expose via dbus | 14:31 |
| seiflotfy | distributed logs | 14:31 |
| seiflotfy | basically the idea is to have private logs per application | 14:31 |
| seiflotfy | and if the application wants it can expose itself over dbus :D | 14:32 |
| seiflotfy | hyperair: oh yes | 14:32 |
| seiflotfy | you can count on 100% speed increase | 14:32 |
| hyperair | yay. | 14:33 |
| seiflotfy | hyperair: i could actually do this on the weekend | 14:35 |
| seiflotfy | :D | 14:35 |
| seiflotfy | its just the lenses right? | 14:35 |
| seiflotfy | then i will do it on the weekend guys :D | 14:35 |
| seiflotfy | tedg: r u using a thinkpad | 14:36 |
| seiflotfy | anybody using thinkpad and dealing with wireless issues | 14:36 |
| tedg | seiflotfy, I think that might not work well with sandboxing. | 14:36 |
| tedg | seiflotfy, In general we don't want applications exporting services by default. | 14:37 |
| seiflotfy | tedg: its just an "option" | 14:37 |
| tedg | seiflotfy, Sure, but trying to warn you :-) | 14:37 |
| seiflotfy | :D | 14:37 |
| seiflotfy | ok warning reveived | 14:37 |
| seiflotfy | it was kamstrups idea :D | 14:37 |
| tedg | seiflotfy, Oh, then I know to be *really* scared of it! | 14:38 |
| seiflotfy | LOL | 14:38 |
| seiflotfy | anybody having wireless issues under raring | 14:42 |
| seiflotfy | ? | 14:42 |
| tkamppeter | OdyX, when you are once on CUPS, can you remove the duplicate logrotate (bug 1157758), only cups-daemon should logrotate, not cups. | 14:54 |
| ubottu | bug 1157758 in cups (Ubuntu) ""cups" and "cups-daemon" both logrotate /var/log/cups/*log" [Undecided,New] https://launchpad.net/bugs/1157758 | 14:54 |
| tedg | seiflotfy, It seems the ZG in raring is 0.3.18? Is that right? | 14:56 |
| seiflotfy | that is libzeitgeist | 14:56 |
| seiflotfy | that is the old one | 14:56 |
| seiflotfy | we packaged the new stuff | 14:56 |
| tedg | seiflotfy, Ah, okay. Where's the new stuff? | 14:56 |
| seiflotfy | getting you the ricotzppa | 14:56 |
| seiflotfy | https://launchpad.net/~ricotz/+archive/experimental | 14:58 |
| seiflotfy | tedg: | 14:58 |
| tkamppeter | pitti, around? | 14:58 |
| pitti | tkamppeter: meeting | 14:58 |
| tedg | seiflotfy, Cool, thanks! | 14:59 |
| OdyX | tkamppeter: as I commented, the mv_conffile is there already for migrations in Debian, so I guess it needs a manual hashsum check and rm_conffile again. | 15:08 |
| === racedo` is now known as racedo | ||
| tseliot | infinity: have you investigated the whole "alias $module off" thing? | 15:31 |
| infinity | tseliot: I haven't put any time into it so far this week, no. | 15:36 |
| infinity | tseliot: Just keep things business as usual for now until we come up with some solid answers, I suppose. | 15:36 |
| === kentb-out is now known as kentb-mtg | ||
| tseliot | infinity: ok | 15:38 |
| davlefou | hi, i look for to create an systrait dev under gnome, 2.6 and 3.x | 15:47 |
| === mmrazik is now known as mmrazik|otp | ||
| tkamppeter | OdyX, in Ubuntu the split-out of cups-daemon was done with 1.6.1-0ubuntu14 and the debian/cups.maintscript with mv_conffile for cups-daemon was introduced in -0ubuntu15. What needs to get changed to get a correct transition here? | 16:19 |
| cjohnston | rsalveti: can the milestones be fixed on https://launchpad.net/ubuntu/+spec/client-1303-sound-support-pulse-audioflinger please | 16:21 |
| lool | cjwatson: hey, I'd like to introduce SDK seed(s) to generate meta-packages; there's an ubuntu-sdk package already though; I would naturally use the regular ubuntu.raring seeds for this and corresponding meta; is that ok? I guess I can leave stuff in universe for now despite that | 16:22 |
| cjohnston | rsalveti: since it is 's' it needs to be 13.05 or later | 16:22 |
| rsalveti | cjohnston: fixed how exactly? remove the milestone from the workitems? | 16:22 |
| rsalveti | cjohnston: hm, that's now what was recommended for us | 16:23 |
| rsalveti | lool: ^ | 16:23 |
| lool | rsalveti: it seems this uses a raring milestone while being targeted at s | 16:24 |
| cjohnston | rsalveti: if it series was 'raring' the milestones would be correct | 16:24 |
| cjwatson | lool: is everything involved in main, or intended to reach main by raring? | 16:24 |
| lool | I'm surprized launchpad is ok with tihs actually | 16:24 |
| lool | cjwatson: I am not sure we're ready to put a supported tag on it, so I thought it would stay in universe, but in reality I don't know | 16:25 |
| rsalveti | lool: cjohnston: right, but I want it target for s-series but a milestone as "13.04" | 16:25 |
| cjwatson | lool: then please don't put it in ubuntu.raring; I suggest you use ubuntu-touch.raring for now | 16:25 |
| lool | cjwatson: I'm mostly trying to arrange things so that we use proper seeds and meta-packages in place of manually maintained meta-packages | 16:25 |
| cjwatson | sure | 16:25 |
| rsalveti | and it seems s-series would be 13.05 or later | 16:25 |
| lool | cjwatson: ok | 16:25 |
| cjwatson | you can extend ubuntu-touch-meta to take over the ubuntu-sdk metapackage, I guess | 16:25 |
| rsalveti | so that's why people recommended to use the old raring-based milestone | 16:25 |
| lool | cjwatson: incidentally, this might make it easier to generate a meta from the current source | 16:25 |
| cjohnston | correct... 's' starts with 13.05 rsalveti | 16:26 |
| cjohnston | rsalveti: then target it to raring.. | 16:26 |
| cjohnston | who recommended it? | 16:26 |
| rsalveti | well, I'm doing some work which will land at s, not raring | 16:26 |
| rsalveti | but I'm planning to do that at 13.04 | 16:26 |
| lool | cjwatson: Ah so it'd be ugly to kludge the meta in the same source as current; ok, will do an ubuntu-touch-meta then | 16:26 |
| cjwatson | lool: you miss my point, there's already an ubuntu-touch-meta | 16:26 |
| rsalveti | I know it's confusing, because people are dealing with monthly planning x release/snapshots milestones | 16:26 |
| cjwatson | you can extend it for ubuntu-sdk | 16:26 |
| cjwatson | you can't use ubuntu-meta because (as ogra and I discovered the other day) there are corner cases that make it infeasible to use that for stuff not in main | 16:27 |
| rsalveti | so I'm planning my s-series based work for april | 16:27 |
| OdyX | tkamppeter: rm_conffile in cups.maintscript should be enough I think. | 16:27 |
| rsalveti | :-) | 16:27 |
| lool | cjohnston: Would it make sense to have milestones for march and april in s too? | 16:27 |
| cjwatson | it can always be merged into ubuntu-meta later | 16:27 |
| lool | hmm would be confusing as the milestones wouldn't follow the same pattern | 16:27 |
| cjohnston | lool: outside of my ability to answer | 16:27 |
| rsalveti | cjohnston: who == people planning the work for touch, bfiller and a few others | 16:28 |
| cjwatson | I don't think it's worth changing around r/s milestones for the sake of the next month or two | 16:28 |
| cjohnston | I tend to agree with cjwatson. | 16:28 |
| lool | rsalveti: problem is that milestones have a series attached, so if we were to add new ones with s for march and april they would clash with the march and april one of raring | 16:28 |
| lool | rsalveti: and that would be hugely confusing -- 3 sets of overlaping milestones | 16:28 |
| cjwatson | if you think the current situation is confusing then ... yes, what lool said | 16:28 |
| rsalveti | right, I can change, it's just that with this scheme you cannot plan work before the series is open | 16:28 |
| cjwatson | rsalveti: sure you can, you artificially | 16:29 |
| cjwatson | *you just have to lie and artificially target it at raring | 16:29 |
| rsalveti | right, not using blueprints :-) | 16:29 |
| cjwatson | you can do it with blueprints fine | 16:29 |
| lool | cjwatson: ubuntu-touch-meta >> ah, hadn't noticed, thanks | 16:29 |
| cjohnston | xnox: has a BP for the 's' series targeted to 12.10-beta-1 | 16:29 |
| rsalveti | cjohnston: right, that lie is the tricky part regarding planning | 16:30 |
| cjwatson | it really doesn't desperately matter if a blueprint is targeted at raring but doesn't actually land code until s :) you can always note it in the whiteboard | 16:30 |
| cjwatson | it's not tricky, you just have to not care | 16:30 |
| cjwatson | easy :) | 16:30 |
| cjohnston | :-) | 16:30 |
| lool | then it wont show up in the s tracker | 16:30 |
| cjwatson | just accept that the raring tracker is where work up to April goes ... | 16:30 |
| cjwatson | it would be bad for work in a given month to be spread across two trackers anyway | 16:31 |
| cjwatson | because that would confuse capacity tracking | 16:31 |
| lool | +upcoming-work kind of does away with this whole problem as it ends up piling all work for a specific date rather than splitting by series | 16:31 |
| rsalveti | well, we're using blueprint to track work now based on series x months (instead of kanban or anything related) | 16:31 |
| lool | cjwatson: good point | 16:31 |
| lool | rsalveti: So I guess I need to reword my recommendation | 16:31 |
| lool | I need to note that one needs to split blueprints so that they don't overlap series boundaries and that work done during a series shoudl be targeted at this series | 16:32 |
| rsalveti | lool: yup :-) | 16:33 |
| rsalveti | lool: not the proper planning tool (based on project planning) | 16:33 |
| rsalveti | at least with these constraints | 16:33 |
| cjohnston | I say we create series 'z' and just make a milestone every month from now until eternity and work off that | 16:34 |
| lool | cjwatson: (I wish I had found an overlapping freenode channel with sergiusens and you to discuss this :-) sergiusens just told me the jenkins job doing smoke testing is currently borken and that he will soon fix it, I've asked him to please ping me when it's back up as to figure the best SSH trigger mechanism from jenkins to cdimage to update /pending | 16:34 |
| lool | cjwatson: (BTW while reading the thread I thought of "pending" as a possible name for it too, +1 on it) | 16:34 |
| * ogra_ returns | 16:35 | |
| * lool exits | 16:35 | |
| ogra_ | lool, anything wrong with the meta/seeds ? | 16:35 |
| tkamppeter | OdyX, so cups.maintscript should contain BOTH "mv_conffile /etc/logrotate.d/cups /etc/logrotate.d/cups-daemon 1.6.1~" and "rm_conffile /etc/logrotate.d/cups 1.6.1~"? | 16:35 |
| lool | ogra_: this is about using seeds for SDK; I don't think you were involved there so far, but happy to update you | 16:36 |
| lool | I intend to send a summary RSN | 16:36 |
| ogra_ | ah, k | 16:36 |
| cjwatson | lool: trigger> I think that work item of yours has been overtaken by events; I've been discussing that with the QA team and we have an agreed interface | 16:36 |
| cjwatson | lool: it just needs me to finish the code and then plars can hook it up | 16:36 |
| ogra_ | i just saw my name and ubuntu-touch-meta mentioned above | 16:36 |
| OdyX | tkamppeter: no, rm_conffile … 1.6.2-2~ (so that it first gets moved away, then rm'ed if it's still there) | 16:37 |
| OdyX | tkamppeter: the latter version must be the one (+ "~") in which the rm_conffile addition gets added. | 16:37 |
| cjwatson | lool: (since it's easier to set this all up for the smoke testing jobs that correspond to images already fully handled by cdimage, rather than near-future jobs) | 16:37 |
| lool | cjwatson: Good; I didn't want to block this work any further :-) | 16:37 |
| OdyX | tkamppeter: I think it would work, but I'm not sure, worth testing. | 16:37 |
| cjwatson | it's just tedious filesystem-mangling code at this point | 16:38 |
| lool | cjwatson: so are there triggers from cdimage to QA already then? it seems we have two sets of smoketests now | 16:38 |
| cjwatson | other way round, QA will ssh to cdimage to notify | 16:38 |
| lool | cjwatson: but how does QA discover there's a new image to test? | 16:38 |
| cjwatson | cdimage doesn't trigger QA for smoketesting; QA polls for that | 16:38 |
| lool | right | 16:38 |
| cjwatson | it seems to work responsively enough so I haven't worried about it | 16:39 |
| lool | cjwatson: While I think the jenkins smoke tests were triggered by the jenkins image build job | 16:39 |
| cjwatson | seems like the sort of thing jenkins loves doing | 16:39 |
| lool | fair enough | 16:39 |
| lool | the only thing is that I'm not sure the smoke tests match in any way | 16:39 |
| lool | we ought to run all the ones we have | 16:39 |
| cjwatson | how do you mean? | 16:39 |
| lool | cjwatson: I am not sure the smoke tests run by QA by polling cdimage are the same as the ones that were run by jenkins so far | 16:40 |
| cjwatson | uh - I'm not aware of smoke tests run by QA that aren't in jenkins | 16:40 |
| cjwatson | so I'm not sure what you mean there | 16:41 |
| lool | hmm it might be too jenkinses | 16:41 |
| lool | but perhaps I'm just confused and they are the same one | 16:41 |
| cjwatson | there are various jenkins instances doing different things | 16:41 |
| cjwatson | which reminds me, I only got a firewall hole opened for the PS jenkins (which will do touch images), not for the UE one | 16:41 |
| cjwatson | plars: what's the internal IP address of the jenkins instance that things like the ubuntu desktop smoke tests run on? | 16:42 |
| lool | right, so I think the PS jenkins also does smoke testing | 16:42 |
| plars | lool, cjwatson: there's no reason we couldn't have cdimage trigger the job, but the way it's working now is by watching a url for a change, and I see no reason why we couldn't just move that to look at /pending | 16:42 |
| cjwatson | plars: agreed | 16:42 |
| cjwatson | lool: right, for a different set of images - that's not a problem | 16:42 |
| plars | cjwatson: 10.98.0.1 for most of them, there's another lab that handles some other things but all the iso testing on VMs runs out of that one | 16:43 |
| cjwatson | plars: I did think of one other wart - it's not one single smoke-test job per image on your end, it's several. is there an easy way to say "poke nusakan to update the current symlink once all smoke tests for this image have passed"? | 16:43 |
| lool | cjwatson: so would we have the PS jenkins poll cdimage for touch smoke tests just like the UE one is polling for desktop smoke tests, or would we want to move the touch smoke testing jobs to the UE jenkins? | 16:43 |
| cjwatson | lool: I see no reason to move it | 16:44 |
| plars | cjwatson: I think all we care about for publishing it is the default smoke test, which just looks to see if it's installable and basically sane before kicking the rest off | 16:44 |
| plars | cjwatson: at that point, it's "testable" for both manual and the rest of the automated tests | 16:44 |
| cjwatson | plars: hm, you think? ok, I guess we can cross that bridge when we come to it | 16:44 |
| lool | cjwatson: ok, so we'd have triggers from two locations then | 16:45 |
| cjwatson | lool: that's fine, covered in the design | 16:45 |
| cjwatson | or rather just totally not an issue for the design | 16:45 |
| plars | cjwatson: if we want more testing in that basic smoke run, then we should add the tests there, but I don't think the goal was to do exhaustive testing or anything close to it before publishing the image right? | 16:45 |
| lool | plars: Would you handle the PS jenkins triggers too? | 16:45 |
| cjwatson | plars: the goal is amorphous :) some testing is clearly better than now | 16:45 |
| plars | cjwatson: in my understanding, we just wanted a basic sanity check that the image is in a usable state before putting it out as the current | 16:45 |
| plars | cjwatson: yes | 16:46 |
| plars | lool: not sure what you mean | 16:46 |
| cjwatson | plars: though, if the full set of smoke tests doesn't take too long, I can see the argument that we should just run them all before offering it to human testers | 16:46 |
| lool | plars: smoke testing of the touch images, do you handle that too or just of desktop images? | 16:47 |
| roaksoax | slangasek: howdy!! So I just merged your branches. I'll backport that to precise/quantal and re-upload! Thanks for the review!! | 16:47 |
| cjwatson | plars: ticket reopened for 10.98.0.1 | 16:47 |
| slangasek | roaksoax: great, thanks :) | 16:47 |
| plars | lool: I do some basic testing of the touch images, primarily things like eventstat and smem for now. They do their own testing with autopilot and things like that which I chose not to replicate. | 16:47 |
| plars | lool: there's no reason we can't detect the new images from them the same way on cdimage, that's how I see when there's something new to test now | 16:48 |
| plars | lool: although I'm not sure if we ever expect to run into a situation where the device specific portion and the rootfs get built in different intervals and need to be tracked separately... oh hell it's hwpacks/rootfs all over again :) | 16:49 |
| lool | right, so I came to this conversation assuming we were mainly hooking smoke testing of the touch images as these were the latest images being put on cdimage, but I think cjwatson and plars were mainly thinking of existing desktop smoke test and touch smoke testing living its own life | 16:50 |
| tkamppeter | OdyX, so I will make a package cups 1.6.2-1ubuntu1 with debian/cups.maintscript containing "mv_conffile /etc/logrotate.d/cups /etc/logrotate.d/cups-daemon 1.6.1~" and "rm_conffile /etc/logrotate.d/cups 1.6.2-1ubuntu1~" and upload that to see whether this solves the problem for the reporter of the bug. | 16:50 |
| lool | now it's clear to me with have two parallel systems, with two jenkins and two definitions of "smoke testing" for touch vs. desktop images | 16:50 |
| lool | which isn't hard to handle technically, but I want to make sure we list touch and desktop actions for the /latest plan | 16:51 |
| OdyX | tkamppeter: yeah that'd be great, then I could integrate that in 1.6.2-3, including some testing... | 16:51 |
| lool | and don't just hook up smoke testing for one and not the other | 16:51 |
| plars | lool: so I don't currently have a "smoke test" of the ubuntu touch images other than install, and I use that as a blocker to running things like smem. Also note that this runs out of a separate lab and seems to break frequently at the moment because of changes to phablet-tools | 16:51 |
| lool | plars: but sergiusens has smoke tests for touch images | 16:52 |
| cjwatson | lool: it's the same code either way | 16:52 |
| cjwatson | lool: I really don't think we need to worry about the "duplication" here - it's a non-issue from my perspective | 16:52 |
| lool | plars: see #ubuntu-touch backlog | 16:52 |
| plars | lool: very likely, yes. If we want to do something similar for ubuntu-touch images, I see no reason why we couldn't | 16:52 |
| rsalveti | plars: guess we'd also need a way to hook up the battery, and force a device reboot if needed | 16:52 |
| tkamppeter | OdyX, I have /etc/logrotate.d/cups-daemon and /etc/logrotate.d/cups.dpkg-new. Is /etc/logrotate.d/cups.dpkg-new automatically ignored by logrotate? | 16:52 |
| cjwatson | lool: I'm entirely aware that touch smoke testing is the driving goal for this; using it for desktop smoke testing is merely a convenient ride-along, and means that I can get this work done *now* rather than later | 16:53 |
| lool | cjwatson: I dont worry about duplication, just that both get smoke tested; e.g. poking two holes in the fw instead of one, and not using two different SSH triggers from jenkins if possible | 16:53 |
| plars | rsalveti: that's another sticking point, yes. At the moment, I rely on things not breaking in a terrible way, or the devices could need some manual intervention. Also, ADB flakes out occasionally and has to be restarted | 16:53 |
| cjwatson | lool: two holes in the firewall is a completely trivial issue, and the backend of the ssh trigger will be identical | 16:53 |
| rsalveti | plars: indeed | 16:54 |
| lool | cjwatson: there is no technical challenge here, just would like the right folks to be involved :-) | 16:54 |
| rsalveti | plars: are we driving all the tests via ssh? | 16:54 |
| cjwatson | lool: (the ssh trigger will have a set of parameters for the project/series/image-type/build-id/architecture, or sufficient of those to get the job done) | 16:54 |
| rsalveti | we were discussing about having some sort of adb for ubuntu | 16:54 |
| cjwatson | lool: I e-mailed relevant QA folks last night and have been having a conversation about the details for a good part of today; sorry I forgot to CC you ... | 16:55 |
| plars | cjwatson, rsalveti: so what I like here is that smoke testing is a nice add-on, but if something ever goes crazy with it, we don't actually prevent anyone from seeing/using the images - it's always possible to get at the new/pending images | 16:55 |
| plars | rsalveti: adb/ssh yes | 16:55 |
| cjwatson | I don't think there's anything especially touch-specific about any of it | 16:55 |
| plars | rsalveti: some initial setup needs to be done over adb | 16:55 |
| cjwatson | plars: right, that was always a requirement from my POV | 16:55 |
| plars | rsalveti: I was asking for adb support for ubuntu images in linaro too, from a test automation perspective, it gives us some interesting possibilities | 16:56 |
| rsalveti | plars: yeah | 16:57 |
| rsalveti | plars: it might help deploying apps via sdk as well | 16:57 |
| lool | cjwatson: I probably didn't need to be Cc:ed; is there a blueprint tracking the QA side / smoke test integration efforts outside if https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-cdimage-android-builds? | 16:58 |
| cjwatson | just that | 16:58 |
| lool | ok, will update to list sergiusens somewhere to add a hook for the PS jenkins smoketests | 16:59 |
| === deryck is now known as deryck[lunch] | ||
| === mmrazik|otp is now known as mmrazik | ||
| lool | plars: cjwatson: have updated WIs in https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-cdimage-android-builds to match my understanding | 17:05 |
| lool | will ask sergiusens whether he can join here | 17:05 |
| lool | plars: mind syncing with sergiusens to keep the PS and UE jenkins smoketests vaguely aligned? | 17:06 |
| plars | lool: +1 | 17:13 |
| tvoss | slangasek, ping | 17:14 |
| slangasek | tvoss: hey there | 17:14 |
| stgraber | xnox: I think I answered all your questions | 17:34 |
| xnox | stgraber: thanks. everything is sound. thanks a lot for clarifying. | 17:41 |
| === mmrazik is now known as mmrazik|otp | ||
| * seb128 grrr at powerpc, 2 builders and one is stucked on "cleaning build tree" for over 25 minutes now | 18:03 | |
| seb128 | ok, it's qt, but what sort of disk is that :p | 18:03 |
| sarnold | qt4-x11 took me 1:05 to build on an i7 with ssd and 16 gigs ram... give those poor ppcs a break :) | 18:04 |
| cjwatson | seb128: chasing on #webops | 18:05 |
| seb128 | sarnold, build took 7 hours, that's ok, I'm just wondering if the builder is stucked | 18:05 |
| seb128 | cjwatson, thanks | 18:05 |
| sarnold | seb128: owwww :) | 18:05 |
| cjwatson | seb128: last qt4-x11 build on adare took 9h25m, so I'm not worried yet | 18:06 |
| ogra_ | seb128, you didnt get the memo ? all fast disks are now assigned to ubuntu-touch work, buildds were switched to SD cards | 18:06 |
| cjwatson | (but you can always ask ops if you're concerned) | 18:07 |
| seb128 | cjwatson, no, that's ok, I will just be patient and wait a bit longer, it will eventually be done and pick another build :p | 18:07 |
| cjwatson | should be fine once sagari's back | 18:07 |
| === mmrazik|otp is now known as mmrazik | ||
| seb128 | cjwatson, thanks | 18:08 |
| cjwatson | ... which it is now | 18:08 |
| seb128 | \o/ | 18:08 |
| bdrung | Laney: bug #1156692 | 18:11 |
| ubottu | bug 1156692 in unknown-horizons (Ubuntu) "FFe: Sync unknown-horizons 2013.1b+ds1-2 (universe) from Debian experimental (main)" [Undecided,Fix released] https://launchpad.net/bugs/1156692 | 18:11 |
| Laney | I don't see how. | 18:11 |
| Laney | A release team member saying "OK" and moving the bug to the next stage of the process is unclear? | 18:12 |
| tumbleweed | Laney: better to be explicit | 18:15 |
| Laney | The only reason would be to avoid this pointless conversation | 18:16 |
| tumbleweed | exactly :) | 18:17 |
| roaksoax | slangasek: btw.. the update for the licenses (BSD to BSD-3-Clause) in the case of yui3, the package that came from debian uses BSD instead of BSD-3-Clause | 18:18 |
| roaksoax | slangasek: should I change it even if the actual package in newer releases use BSD instead of BSD-3-Clause? | 18:19 |
| roaksoax | same as for raphael with MIT | 18:19 |
| xnox | Laney: to me it's not clear if you were wearing release team hat or not. =)))))) | 18:20 |
| * xnox is just being pedantic here, I actually did understand what you meant. | 18:20 | |
| slangasek | roaksoax: I don't want to cause you a maintenance headache here, and as I said it's not an SRU blocker at all - they just technically aren't the right values to be used in copyright-format 1.0 | 18:22 |
| * Laney goes to the climbing centre instead :-) | 18:22 | |
| roaksoax | slangasek: ok :) | 18:22 |
| === deryck[lunch] is now known as deryck | ||
| roaksoax | slangasek: ok uploaded to btoh -precise, -quantal | 18:39 |
| roaksoax | err {precise,quantal}-proposed | 18:39 |
| slangasek | roaksoax: great, thanks | 18:40 |
| roaksoax | slangasek: thank to you for the review :) | 18:40 |
| === mmrazik is now known as mmrazik|eod | ||
| === mmrazik|eod is now known as mmrazik | ||
| === JanC_ is now known as JanC | ||
| OdyX | tkamppeter: the libp11-kit-gnome-keyring isn't in Debian yet, I can't add it to Debian's cups. | 19:06 |
| tkamppeter | OdyX, but why does Ubuntu's CUPS need it? The source package is the same for both Debian and Ubuntu. | 19:15 |
| OdyX | tkamppeter: missing depends in Ubuntu's build-depends ? | 19:17 |
| tkamppeter | OdyX, I have already uploaded -1ubuntu2, see bug 1157904. | 19:19 |
| ubottu | bug 1157904 in cups (Ubuntu) "p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory" [Undecided,Fix committed] https://launchpad.net/bugs/1157904 | 19:19 |
| seb128 | hum | 20:10 |
| seb128 | does "Replaces" has any impact on the apt resolver? | 20:10 |
| seb128 | or said different "can using Replaces have an impact on the upgrade solution between "uninstall stuff" and "upgrade the source""? | 20:11 |
| slangasek | seb128: not on its own, only if combined with Conflicts/Breaks | 20:14 |
| seb128 | slangasek, contexts is bug #1157747 | 20:14 |
| ubottu | bug 1157747 in unity-asset-pool (Ubuntu) "package unity-asset-pool 0.8.24daily12.12.05-0ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/icons/hicolor/32x32/apps/facebook.png', which is also in package account-plugin-facebook 0.10bzr13.02.27-0ubuntu1" [Undecided,Fix released] https://launchpad.net/bugs/1157747 | 20:14 |
| seb128 | slangasek, new unity-asset-pool replaces files from the old account-* packages | 20:14 |
| seb128 | kenvandine used a breaks/replaces combo first | 20:15 |
| seb128 | which leads apt to want to remove the account-* rather than install the new unity-asset-pool apparently | 20:15 |
| seb128 | he said that dropping the "Replaces:" and keeping only "Breaks:" seems to work better | 20:15 |
| seb128 | is that right? | 20:15 |
| seb128 | I though "Replaces" was meant as "it's ok to overwrite file from" | 20:16 |
| slangasek | seb128: where did he say that? I don't see it on the bug | 20:16 |
| slangasek | that is what Replaces: means, and we shouldn't be leaving it out | 20:16 |
| seb128 | slangasek, we just discussed it on #ubuntu-desktop and | 20:17 |
| seb128 | https://code.launchpad.net/~ken-vandine/unity-asset-pool/0.8.24daily13.03.20.1-0ubuntu2/+merge/154495 | 20:17 |
| seb128 | the changelog on that mr is wrong | 20:17 |
| seb128 | ups | 20:17 |
| seb128 | ignore the changelog note | 20:17 |
| seb128 | he fixed it :p | 20:17 |
| seb128 | kenvandine, ^ | 20:17 |
| kenvandine | humm | 20:18 |
| kenvandine | si with replaces and breaks dist-upgrade was trying to remove all the account-plugins-* packages | 20:18 |
| kenvandine | s/si/so | 20:19 |
| kenvandine | but | 20:19 |
| kenvandine | not apt-get install unity-asset-pool | 20:19 |
| kenvandine | that did the right thing | 20:19 |
| kenvandine | but dist-upgrade didn't | 20:19 |
| slangasek | kenvandine: would like to see the full dist-upgrade output, and possibly with apt debugging | 20:19 |
| seb128 | kenvandine, dist-upgrade here: | 20:19 |
| seb128 | The following NEW packages will be installed: | 20:19 |
| seb128 | account-plugin-generic-oauth | 20:19 |
| seb128 | The following packages will be upgraded: | 20:19 |
| seb128 | account-plugin-facebook account-plugin-flickr account-plugin-google | 20:19 |
| seb128 | account-plugin-icons account-plugin-identica account-plugin-twitter | 20:19 |
| seb128 | account-plugin-windows-live unity-asset-pool unity-webapps-common | 20:19 |
| seb128 | 9 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. | 20:20 |
| seb128 | seems to do the right thing | 20:20 |
| seb128 | with the current version | 20:20 |
| kenvandine | seb128, odd! | 20:20 |
| kenvandine | ChrisTownsend saw the removal | 20:20 |
| seb128 | what slangasek said otherwise | 20:20 |
| kenvandine | and i tried too and got the same result | 20:20 |
| seb128 | we need a log from something who has the issue | 20:20 |
| seb128 | can you downgrade and try again? | 20:20 |
| slangasek | (apt-get dist-upgrade -oDebug::pkgProblemResolver=1) | 20:20 |
| kenvandine | lets see if christownsend can try still | 20:21 |
| ChrisTownsend | seb128: Ok, here | 20:24 |
| seb128 | ChrisTownsend, thanks | 20:24 |
| seb128 | can you copy the log on pastebin? | 20:24 |
| ChrisTownsend | seb128: I ran the command, should I go ahead and do the upgrade or grab the log as is? | 20:25 |
| slangasek | ChrisTownsend: we just want the log for what apt is showing, no need for the actual upgrade | 20:26 |
| ChrisTownsend | slangasek: Hmm, where is this particular log stashed? /var/log/apt/?? or something else | 20:28 |
| slangasek | ChrisTownsend: ah, the output of the command | 20:28 |
| slangasek | ChrisTownsend: best to do 'apt-get dist-upgrade -oDebug::pkgProblemResolver=1' | 20:28 |
| ChrisTownsend | slangasek: Ah, ok. I did that. I'll get a pastebin soon. | 20:29 |
| seb128 | ChrisTownsend, running with -oDebug... should give you a lot of infos on stdout | 20:29 |
| ChrisTownsend | It really didn't output much more than usual. | 20:29 |
| ChrisTownsend | slangasek: seb128: http://pastebin.ubuntu.com/5632282/ | 20:30 |
| seb128 | ChrisTownsend, that doesn't want to remove anything | 20:31 |
| seb128 | kenvandine, ^ | 20:31 |
| ChrisTownsend | Hmm, my other machine is the one that complained. | 20:31 |
| seb128 | can you get a lot from this one? | 20:31 |
| seb128 | log | 20:31 |
| kenvandine | maybe my new package was published? | 20:31 |
| seb128 | it's in proposed only | 20:31 |
| kenvandine | oh right | 20:32 |
| seb128 | ChrisTownsend, do you have raring-proposed enabled? | 20:32 |
| ChrisTownsend | seb128: Not that I'm aware of, but let me look. | 20:32 |
| ChrisTownsend | I just confirmed my other machine does still complain. I'll get that in a bit. | 20:33 |
| kenvandine | apt-cache policy unity-asset-pool | 20:33 |
| directhex | so... i've been tracking a horrible evolution crash bug today, which is fixed in 3.6.4. there's a 22 line patch to fix said bug. is it too late to get that into raring? or as a fix for quantal, for that matter? | 20:33 |
| ChrisTownsend | Candidate: 0.8.24daily13.03.20.1-0ubuntu1 | 20:33 |
| seb128 | directhex, cyphermox is working on updating evo to 3.6.4 for raring | 20:34 |
| directhex | oh. well, that'd help. | 20:34 |
| seb128 | ChrisTownsend, please get the log from the box which has the issue, using -oDebug::pkgProblemResolver=1 | 20:35 |
| ChrisTownsend | seb128: Yep, working on it. | 20:35 |
| seb128 | thanks | 20:35 |
| ChrisTownsend | http://pastebin.ubuntu.com/5632300/ | 20:37 |
| directhex | cyphermox, is there anything i can do to assist with that? i can commit a debian evolution maintainer's time to making it happen, who already has some 3.6.4 packages for 12.04 going. | 20:38 |
| ChrisTownsend | seb128: slangasek: ^^^ | 20:39 |
| slangasek | ChrisTownsend: so the problem is that there's no newer version of account-plugin-facebook available that satisfies the breaks/replaces | 20:40 |
| slangasek | kenvandine: are account-plugin-* not updated yet? | 20:40 |
| slangasek | these need to be updated as a group | 20:40 |
| kenvandine | they are | 20:40 |
| kenvandine | for me when i tried apt-get install unity-asset-pool | 20:40 |
| slangasek | ChrisTownsend: 'apt-cache policy account-plugin-facebook' please? | 20:40 |
| kenvandine | it said it would install those | 20:41 |
| seb128 | outdated mirror? | 20:41 |
| kenvandine | or upgrade those rather | 20:41 |
| kenvandine | i am not using a mirror | 20:41 |
| seb128 | can you get us a debug log? :p | 20:41 |
| kenvandine | not really... since doing this i have kind of hosed myself... | 20:41 |
| kenvandine | with the scopes testing PPA :) | 20:41 |
| seb128 | :-( | 20:41 |
| seb128 | let's wait for ChrisTownsend | 20:42 |
| kenvandine | but luckily ChrisTownsend still has a reproducer :) | 20:42 |
| ChrisTownsend | Working on it | 20:42 |
| kenvandine | i have since discovered that unity-asset-pool now conflicts with files in some of the new scopes in that prevalidation ppa | 20:42 |
| ChrisTownsend | http://pastebin.ubuntu.com/5632329/ | 20:42 |
| kenvandine | and purging that has done really bad things :) | 20:42 |
| slangasek | kenvandine: er, so isn't the issue that you've published unity-asset-pool using Breaks: to raring, but the account-plugins* are *not* published to raring? | 20:43 |
| kenvandine | oh, you don't have the new one | 20:43 |
| slangasek | kenvandine: you have Breaks/Replaces: account-plugin-facebook (<= 0.10bzr13.02.27-0ubuntu1), and that's the current version of a-p-f in raring | 20:43 |
| * mlankhorst amusedly wonders what makes people think it's a good idea to accept a proposed dist-upgrade that removes the entire i386 arch | 20:43 | |
| seb128 | slangasek, how can that happen? | 20:43 |
| slangasek | this Breaks/Replaces is published in the version of unity-asset-pool /in raring/ | 20:43 |
| seb128 | slangasek, how can u-a-p move to raring with a breaks not fullfiled? | 20:44 |
| ChrisTownsend | I did an update not very long ago. | 20:44 |
| ChrisTownsend | I can try again though | 20:44 |
| kenvandine | i see...it's because of proposed vs raring | 20:44 |
| kenvandine | i can revert that last update and put the replaces back in | 20:44 |
| seb128 | launchpad says the plugin have been moved to raring an hour ago | 20:45 |
| slangasek | seb128: because the requirement for proposed migration is that packages be installable, not that they be co-installable with arbitrary other sets of packages | 20:45 |
| slangasek | seb128: nothing in the archive depends on both u-a-p and a-p-f, so britney doesn't care that they can't be installed at the same time! | 20:46 |
| seb128 | hum, ok, I see | 20:46 |
| seb128 | second bug that goes through today, the first one was a lack of Replaces: | 20:46 |
| seb128 | kenvandine, in any case please put the Replaces: back for the next upload | 20:47 |
| ChrisTownsend | Ok, strange, I did another update just now and now it's good. | 20:47 |
| seb128 | ChrisTownsend, good, and not strange | 20:47 |
| seb128 | it means account-plugins just moved from raring-proposed to raring I guess | 20:48 |
| * kenvandine uploads again :) | 20:48 | |
| slangasek | right | 20:48 |
| ChrisTownsend | seb128: Ok | 20:48 |
| ChrisTownsend | I had wondered what would happen when/if these packages arrived at different times in the archive and I guess I found out:) | 20:49 |
| ChrisTownsend | Thanks seb128, slangasek, kenvandine! | 20:50 |
| seb128 | ChrisTownsend, thanks for helping figuring out the issue! | 20:51 |
| ChrisTownsend | seb128: No problem at all! | 20:51 |
| slangasek | seb128, kenvandine: permanent fix: make something depend on all of these packages so that coinstallability is enforced; currently, a-p-f is a dep of ubuntu-touch and u-a-p is a dep of unity, so nothing tells britney that they need to be coinstallable | 20:56 |
| seb128 | slangasek, well, it's hard to make those *depends*, that's the recommended list of plugins but it's fair enough to uninstall protocols you don't need | 20:58 |
| seb128 | recommends don't enforce things the same way though... | 20:58 |
| slangasek | hmm | 20:58 |
| slangasek | we could conceivably make britney consider Recommends as well | 20:58 |
| slangasek | cjwatson: ^^ should britney be paying attention to Recommends for installability? | 20:58 |
| Laney | directhex: if you want to toss me the patch (ideally a debdiff) in a bug then I can look at sponsoring that to $your_favourite_release tomorrow when I patch pilot | 21:03 |
| Laney | assuming the backported commit fixes it, that is | 21:03 |
| ambroff | Howdy folks. We have an internal apt repository for lucid that we're maintaining with reprepro. We only had packages for lucid in there, and now I'm rebuilding a bunch of packages for precise and naively thought that I could just add a second block to conf/distributions with "precise" as the codename and use the same component. | 21:41 |
| ambroff | but that obviously doesn't work, since the package versions are the same and they will conflict in the pool tree | 21:42 |
| ambroff | so, obviously I'm missunderstanding how this is supposed to work. | 21:42 |
| ambroff | How is this generally done? | 21:42 |
| slangasek | ambroff: by not reusing package versions for distinct builds | 21:44 |
| ambroff | Hrm, OK, I didn't think it would be such a manual process. | 21:44 |
| ambroff | so when the same upstream release is packaged for the next upcoming Ubuntu release, the package version is just bumped? | 21:45 |
| sarnold | ambroff: here's one suggested versioning scheme for building the 'same version' for multiple releases: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging | 21:47 |
| === cheney is now known as calc | ||
| ambroff | awesome thanks sarnold and slangasek | 21:48 |
| ambroff | I'll go over that | 21:48 |
| slangasek | ambroff: we don't as a rule "repackage" software for each Ubuntu release; the binaries are carried forward from one release to the next, and only rebuilt when a) changes are needed to the package, or b) there's a transition to a library it uses | 21:49 |
| * calc got his old nick back :) | 21:49 | |
| ambroff | Yeah I assumed that was true, but I was worried about some unkown changes in debhelpers or sonames so I thought it seemed like the safest thing to do. | 21:50 |
| ambroff | also, how would you even add it to multiple "codenames" in the repo so you could have (in my case) | 21:50 |
| ambroff | deb .... lucid production | 21:50 |
| ambroff | deb ... precise production | 21:50 |
| ambroff | well, I guess you're saying I wouldn't | 21:51 |
| ambroff | because that's stupid | 21:51 |
| ambroff | :) | 21:51 |
| slangasek | ambroff: oh, you can certainly have a .deb referenced by multiple Packages files | 21:52 |
| slangasek | but the tools I know that do this are, er, the big ones used by the Debian and Ubuntu archives | 21:52 |
| slangasek | I don't know if / how reprepro does this | 21:52 |
| ambroff | ah, that makes sense | 21:53 |
| ambroff | because reprepro just panics and bails | 21:53 |
| ambroff | it probably doesn't support that | 21:53 |
| ambroff | OK, thanks guys | 21:53 |
| ambroff | I made the mistake of asking this question in #debian and got pages and pages of hate just because I mentioned that it was for Ubuntu. | 21:55 |
| cjwatson | slangasek: not wild about having it considering Recommends - I have a strong suspicion that they aren't in a sufficiently good state for that, and a weaker suspicion that people have perpetrated hacks involving deliberately unsatisfiable Recommends | 21:56 |
| slangasek | cjwatson: ok | 21:56 |
| cjwatson | I'm pretty amazed reprepro wouldn't support that | 21:56 |
| cjwatson | Not that I use reprepro, but it has a "copy" command documented in its man page ... | 21:58 |
| cjwatson | Or indeed copysrc | 21:58 |
| cjwatson | You should generally (because this is how most modern Debian-based archives actually work) regard a Debian-based archive as a pool of uniquely-versioned packages, with each "suite" (lucid, precise, etc.) being essentially just a set of references into the pool | 21:59 |
| cjwatson | (it's slightly more complex than that in reality but this is a pretty decent first approximation) | 22:00 |
| === salem_ is now known as _salem | ||
| ambroff | hrm, OK, I need to do some research. I've only built simple little repositories, never anything like this. | 22:03 |
| ambroff | OH! I didn't see the copy command. I was using includedeb | 22:03 |
| ambroff | damn, sorry for not RTFM | 22:03 |
| cjwatson | right, I think includedeb injects a whole new build | 22:05 |
| cjwatson | (in general I think you should use just 'include' with a .changes file - it's safer to work in units of entire .changes files, which are the usual master control files for an upload) | 22:05 |
| cjwatson | I'll probably try reprepro for something at some point - speaking as an Ubuntu archive admin, it certainly looks featureful enough for moderate-sized projects | 22:06 |
| ambroff | awesome reprepro is totally working for me now | 22:24 |
| ambroff | thanks again for the help | 22:24 |
| cyphermox | directhex: admittedly it would be faster if the bzr branch for evolution was working | 22:42 |
| cyphermox | directhex: evolution-data-server is ready | 22:43 |
| pedahzur | So, we have hit what we think is a bug in the mellanox driver for our 10GigE card on our 10.04 system. This is probably confirmed by this: http://code.metager.de/source/history/linux/stable/drivers/net/ethernet/mellanox/ Search for the second and third occurrences of "page allocation" which reflects the errors we were getting. Seeing that 10.04 is LTS, how might I go about requesting a back-port of this driver's fixes to 10.04? | 22:49 |
| pedahzur | Or am I better off justing pulling a kernel source deb from 12.04 and compiling it for my system? | 22:49 |
| sarnold | pedahzur: I suggest filing a bug against the kernel, include bits of your dmesg output if you still have them, include those git hashes, and the link to that page. Might as well get it fixed for everyone for the next two-odd years of support... | 22:54 |
| directhex | Laney, https://git.gnome.org/browse/evolution/commit/?h=gnome-3-6&id=881533927325432a0bab7eabea3a1d4008b5bcff - causes evo to recuse itself to death and crash when trying to preview/open a message whose content makes it sad, e.g. http://paste.debian.net/hidden/011db506/ | 22:55 |
| Laney | please to bug and subscribe me | 22:57 |
| chilicui1 | Hi there, I've requested a bzr merge for bug #699861, it appears that the ubuntu-branches team has been suscribed automatically, should I suscribe ubuntu-sponsors as well? | 23:04 |
| ubottu | bug 699861 in slim (Ubuntu) "Slim starts too early" [Undecided,Confirmed] https://launchpad.net/bugs/699861 | 23:04 |
| maxb | My guess would be yes, I'm not sure ~ubuntu-branches exists as anything other than a placeholder owner for autocreated package branches | 23:06 |
| === Ursinha-afk is now known as Ursinha | ||
| chilicui1 | maxb: I've just reassign it, thanks for replying | 23:10 |
| === wedgwood is now known as wedgwood_away | ||
| pedahzur | sarnold: OK. Thanks. Yeah, the stack dumps we're seeing look like the one you see at that above URL at the third occurrence of 'page allocation.' Even the 'order:2, mode:0x4020' is the same. | 23:15 |
| directhex | Laney, er, done, i think. it's a while since i've driven launchpad | 23:17 |
| sarnold | pedahzur: that's definitely encouraging :) | 23:17 |
| pedahzur | sarnold: Submitted: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1158031 I hope I included all relevant information. | 23:46 |
| ubottu | Launchpad bug 1158031 in linux (Ubuntu) "Mellanox ethernet driver causing page allocation failures" [Undecided,New] | 23:46 |
| sarnold | pedahzur: nice :) | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!