| === freeflying_away is now known as freeflying | ||
| === freeflying is now known as freeflying_away | ||
| stgraber | hallyn: oh, sorry, wasn't obvious when I reviewed. I'll make sure to re-review tomorrow and get it in (I'll restore it from Rejected, no need to re-upload) | 03:26 |
|---|---|---|
| pitti | Good morning | 03:26 |
| pitti | slangasek, stgraber: I was going to create an UDS blueprint for P → S (and also R → S) upgrade testing, which scenarios we need, how to revive automatic testing, how to make it palatable for CI, etc. | 04:09 |
| pitti | AFAICS we don't have one yet; is that ok to put into the foundations track? (we don't have a QA track) | 04:09 |
| James_Epp | I do not know whether this was intentional, but for some reason, 12.04 does what 12.04.3 don't. This is in regards to network booting the live disc environment. More here: http://askubuntu.com/questions/359150/what-nfs-export-settings-do-i-need-to-boot-the-ubuntu-live-discs-over-a-network . This was a bit more than frustrating, to say the least. | 04:13 |
| stgraber | pitti: foundations sounds appropriate for that, yes. | 04:14 |
| stgraber | pitti: can you make sure I'm subscribed to this too? | 04:14 |
| pitti | stgraber: yes, absolutely; for your "testing in LXC" experience :) | 04:15 |
| stgraber | pitti: yep, I've some of that still running daily without much trouble, so definitely worth mentioning and looking into (now that people are getting used to using LXC for testing and QA) | 04:15 |
| pitti | stgraber: last week I did a 12.04.3 to saucy upgrade, and it was ... well, anything but "catastrophe" doesn't accurately describe it | 04:16 |
| pitti | that reminded me of that idea :) | 04:16 |
| stgraber | I'd have to check the timing again with saucy, but back with Q, I'd get an upgrade test down to 5min or so on LXC with tmpfs vs 30-40min with KVM | 04:16 |
| stgraber | pitti: yeah, lts to lts is a pain, it took me and the 12.04.1 team 3 months after the 12.04 release to get stuff back to working order | 04:17 |
| stgraber | would be nice if we could avoid getting in the same situation this time around and be proactive | 04:17 |
| stgraber | (SRUing all the lts-to-lts fixes wasn't much fun) | 04:17 |
| pitti | yeah, with all those different LTS enablement stack backports it's going to be interesting to get back to a clean slate | 04:17 |
| pitti | https://blueprints.launchpad.net/ubuntu/+spec/foundations-1311-lts-upgrade-testing | 04:21 |
| pitti | slangasek: ^ it went straight in, apparently because I'm in ~uds-organizers | 04:22 |
| pitti | stgraber: added a few subscribers (mostly you, plars, jibel) | 04:23 |
| stgraber | pitti: cool, thanks | 04:25 |
| slangasek | pitti: +1 :) | 04:39 |
| slangasek | pitti: fwiw I would expect most upgrade testing to just use chroots, neither containers nor kvm | 04:39 |
| pitti | slangasek: I think with all those rather complicated scenarios there should at least be some post-upgrade testing; containers shouldn't add too much overhead? | 04:40 |
| slangasek | pitti: I think they also don't add much value. But I guess we can discuss in the session. | 04:42 |
| pitti | tests like "is the current kernel installed and does grub point to it" certainly work in schroot, too | 04:43 |
| dholbach | lool, happy birthday! :) | 04:52 |
| jibel | pitti, thanks. I talked about upgrade testing to jfunk during our last call, and this is definitely a project QA should work on early this cycle. | 05:02 |
| jibel | and it didn't receive lot of attention since Q | 05:03 |
| hyperair | does the applications master scope not work for anyone here? | 06:17 |
| hyperair | for some reason, super+a doesn't give me any results apart from dash plugins, but super seems to be able to find the results pretty quickly | 06:18 |
| RAOF | hyperair: Works for me. | 06:21 |
| hyperair | hmmmm weird. | 06:22 |
| hyperair | maybe i should just restart my entire session and see if that helps matters. | 06:24 |
| hyperair | it seems to work in the guest account. | 06:24 |
| erle- | why don't you change your upgrade, that it first upgrades only essential packages (kernel, grub, X, desktop) and cleans up before it upgrades peripheral ones? | 06:40 |
| erle- | some error in a latex packages screwed my whole installation again | 06:40 |
| hyperair | heh actually you can complete it by just running apt-get dist-upgrade and apt-get install -f until no more upgrades remain | 06:44 |
| hyperair | and wherever appropriate, dpkg --configure -a | 06:44 |
| erle- | i did this | 06:46 |
| erle- | apt think everything is fine | 06:46 |
| erle- | but i dont come from lightdm into desktop | 06:46 |
| erle- | neither gnome-panel nor gnome-shell nor unitz | 06:46 |
| erle- | and cant see what packages to reinstall | 06:47 |
| erle- | i reinstalled video drivers manually which gave me at least the chance to see the login screen | 06:47 |
| erle- | i get an apport dialogue window btw, but even that does not work | 06:48 |
| pitti | erle-: do you perhaps not have the ubuntu-desktop metapacakge installed? that should pull in everything that's required | 06:49 |
| hyperair | erle-: did you just get a black screen with a pointer? | 06:49 |
| hyperair | erle-: if so, try removing ~/.cache/upstart and ~/.config/upstart | 06:50 |
| erle- | i get login screen | 06:50 |
| hyperair | for some reason, those two directories were root-owned on my machine | 06:50 |
| hyperair | i mean after logging in | 06:50 |
| erle- | when i log in i get black screen with pointer and crash-report-dialogs | 06:50 |
| hyperair | after logging in, what do you see? | 06:50 |
| erle- | ok, i will clean upstart | 06:50 |
| erle- | did not fix it hyperair | 06:51 |
| hyperair | er okay, different bug then | 06:52 |
| erle- | problem is that i cant see what actually is broken in detail | 06:52 |
| hyperair | could you log into a tty and run ps -u `whoami`? | 06:52 |
| erle- | pitti, it is installed | 06:54 |
| erle- | hyperair, looks like a working session, many processes like indicator and unity panel runing | 06:55 |
| erle- | i cant even click on the apport dialog, it does not show me the name of the failed process or anything | 06:55 |
| hyperair | then it's not an upstart issue i guess | 06:56 |
| hyperair | my guess would be that unity crashed somehow | 06:56 |
| erle- | i will remove all gnome stuff and reinstall | 06:57 |
| erle- | hyperair, bit i have exactly the same with gnome panel and gnome shell | 06:57 |
| erle- | in fact i primarily use gnome panel | 06:57 |
| erle- | i just use unity now because i guess you can support it better | 06:57 |
| erle- | the crash dialogs seem to be update-notification rather than apport | 07:04 |
| erle- | *update-notifier | 07:04 |
| erle- | the crash seems to be xorg-related | 07:10 |
| erle- | i removed crashreports and after loggin in again a xorg crash report appeared | 07:10 |
| erle- | maybe it ist just fglrx's fail | 07:11 |
| hyperair | probably | 07:12 |
| erle- | i installed gdm, which does not even get to the login screen | 07:13 |
| erle- | fortunately i have a second computer that does not get any proprietary blobs installed :) | 07:14 |
| erle- | i reinstalled fglrx again | 07:19 |
| erle- | now it works | 07:19 |
| erle- | thank you for your assistence | 07:19 |
| erle- | now i have to tell fglrx not to underscan my lcd screen ... :D | 07:20 |
| hyperair | underscan? | 07:20 |
| erle- | >the crashed program seems to use third party libraries | 07:22 |
| erle- | >libgpg | 07:22 |
| erle- | what? | 07:22 |
| hyperair | where do you see that? | 07:22 |
| erle- | hyperair, with hdmi connected, amd thinks it is a tv and scales the screen down | 07:22 |
| erle- | hyperair, it was a crash report dialogue | 07:22 |
| hyperair | mm i think it means that it's using a library that's not shipped by ubuntu? | 07:22 |
| erle- | oh wait, i compiled some gpg stuff myself one day, maybe thats the reason | 07:22 |
| hyperair | there we go | 07:23 |
| hyperair | bleargh proprietary blobs | 07:23 |
| Saviq | hyperair, hey, I managed to get banshee 2.9.0 to build - lp:~saviq/ubuntu/saucy/banshee/new-upstream-290 | 07:24 |
| hyperair | woot | 07:24 |
| hyperair | bleargh bzr | 07:24 |
| hyperair | can you give me a patch instead please? | 07:24 |
| Saviq | hyperair, diff for debian/ probably enough? | 07:25 |
| hyperair | yeah should be | 07:25 |
| hyperair | i'd filterdiff it anyway | 07:25 |
| hyperair | and shoot you if i spot anything that's not inside debian/patches. ;-) | 07:25 |
| === tkamppeter_ is now known as tkamppeter | ||
| Saviq | ;) | 07:26 |
| hyperair | Saviq: banshee's maintained in debian git, fyi | 07:26 |
| Saviq | hyperair, had to disable meego and soundmenu extensions - they're not ported to gtk3 / something's wrong with notify-sharp | 07:26 |
| hyperair | uh that's not good | 07:26 |
| Saviq | hyperair, k, will know next time | 07:26 |
| hyperair | soundmenu's important. | 07:26 |
| Saviq | hyperair, https://bugzilla.gnome.org/show_bug.cgi?id=710423 | 07:26 |
| ubottu | Gnome bug 710423 in Other Extensions "SoundMenu extension fails to build" [Normal,Unconfirmed] | 07:26 |
| hyperair | if you'd like to help out with banshee maintenance on the long term, do come over to #debian-cli on irc.oftc.net | 07:27 |
| Saviq | and https://bugzilla.gnome.org/show_bug.cgi?id=710418 | 07:27 |
| ubottu | Gnome bug 710418 in Other Extensions "MeeGo extension not ported to GTK3" [Normal,Unconfirmed] | 07:27 |
| hyperair | hmm. | 07:27 |
| hyperair | i'm not sure we use meego these days | 07:27 |
| hyperair | maybe i should just toss it | 07:27 |
| hyperair | afair it was for UNR | 07:27 |
| Saviq | hyperair, I've completely no idea about C# so might be tricky - I was doing this thing blind ;D | 07:27 |
| hyperair | and didrocks did the patches. | 07:27 |
| hyperair | haha, my C# knowledge is also rather patchy | 07:28 |
| Saviq | hyperair, ah btw, the Homepage link in gudev-sharp should probably be updated - points at launchpad which is rather old | 07:28 |
| lool | dholbach: thanks! | 07:28 |
| hyperair | i mean i know how to get around with the packaging stuff, but the actual C# code i can only handle where it looks like java and C++ | 07:28 |
| * dholbach hugs lool | 07:28 | |
| lool | release for my birthday eh! | 07:28 |
| Saviq | hyperair, the Vcs links didn't work either, but I assume that will fix itself after NEWing? | 07:28 |
| hyperair | Saviq: yeah that's in the new upload of gudev-sharp stuck in incoming.debian.org | 07:28 |
| hyperair | (i think) | 07:28 |
| * Saviq preps the patch | 07:29 | |
| hyperair | Saviq: series of patches would be nice too. | 07:29 |
| didrocks | Saviq: hyperair: yeah, I think the meego extension is completly abandonned, so feel free to drop it :) | 07:29 |
| hyperair | didrocks: yay. that means half the patches we carry can go too | 07:30 |
| didrocks | happy birthday lool! (weren't you supposed to not work today? :p) | 07:30 |
| hyperair | \o/ | 07:30 |
| didrocks | hyperair: yeah ;) | 07:30 |
| hyperair | \o/ | 07:30 |
| pitti | hey lool, bonjour ! bon anniversaire ! | 07:30 |
| lool | didrocks: Indeed! | 07:30 |
| lool | didrocks: just sent a message saying I'm not ;-) | 07:30 |
| Saviq | hyperair, there's actually just two small patches to the code, the rest is debian/ | 07:30 |
| lool | pitti: merci ! | 07:30 |
| hyperair | Saviq: actually hang on, how did you get 2.9.0 to work without gudev-sharp? | 07:30 |
| hyperair | and is this on saucy? | 07:30 |
| Saviq | hyperair, built from your NEW | 07:30 |
| hyperair | knocte was saying yesterday that banshee 2.9.0 was crashing with the mono in saucy.. | 07:31 |
| didrocks | lool: don't connect to IRC! ;) | 07:31 |
| Saviq | hyperair, and btw, I did not say it *worked* ;D | 07:31 |
| hyperair | aha | 07:31 |
| hyperair | it built. | 07:31 |
| hyperair | got it. | 07:31 |
| hyperair | well there's progress i guess | 07:31 |
| Saviq | yeah, crashed on startup | 07:31 |
| sil2100 | Oh, lool has birthday?! lool happy birthday! | 07:31 |
| sil2100 | I would opt for lool not working more than just today, as I saw him even at 3 AM at night working this week | 07:32 |
| lool | thanks! yeah even *I* have a birthday ;-) I thought I would never age | 07:32 |
| lool | sil2100: I'm off til thursday with some leave days tacked | 07:32 |
| sil2100 | lool: awesome! Have a nice rest, this was a great release ;) | 07:33 |
| Saviq | hyperair, here's the debian/ diff between my branch (based on ubuntu packaging) and debian git | 07:34 |
| Saviq | hyperair, http://paste.ubuntu.com/6255584/ | 07:34 |
| Saviq | hyperair, there's some crap, but hopefully you'll be able to fish the interesting things out easily | 07:35 |
| Saviq | hyperair, if you need me to, I can "rebase" onto the debian version | 07:39 |
| hyperair | oh hmm, this is the merged version. | 07:39 |
| hyperair | i think i should be able to apply this onto the ubuntu branch and see waht's different from there... | 07:40 |
| hyperair | why does paste.ubuntu.com still require launchpad authentication to download as text? | 07:40 |
| hyperair | =\ | 07:40 |
| hyperair | this is dumb. the stuff is public already. | 07:41 |
| hyperair | why is dumping a paste as raw text something that requires authentication? | 07:41 |
| wgrant | It discourages spammers, from what I recall. | 07:41 |
| hyperair | spammers? | 07:41 |
| hyperair | seriously?! | 07:41 |
| hyperair | i'd understand if you require authentication to *post* | 07:41 |
| hyperair | but to *get*? | 07:41 |
| pitti | it's to avoid abusing this to store mp3s or videos, etc. | 07:42 |
| hyperair | now i can't even wget the damned raw url. | 07:42 |
| hyperair | bleargh | 07:42 |
| pitti | (AFAIUI) | 07:42 |
| hyperair | why is this not a problem with paste.debian.net and other public pastebins? | 07:42 |
| pitti | so that you don't have an anonymous online storage space for anything | 07:42 |
| pitti | hyperair: in principle it is; but I don't know, I'm just saying why it is like that | 07:43 |
| hyperair | what's to stop me from opening the mp3 inside pastebin and ctrl+s'ing in firefox or chrome to get it? | 07:43 |
| * hyperair sighs | 07:43 | |
| pitti | because you need to auth to LP, and thus you can be tracked down | 07:43 |
| pitti | s/LP/oauth/, but whatever | 07:43 |
| hyperair | ah, right. | 07:43 |
| pitti | I agree that it's terribly inconvenient | 07:43 |
| cjwatson | My understanding is that it was a real practical problem before .../plain/ started requiring auth | 07:44 |
| * hyperair recalls complaining about this some years ago, but not knowing who to complain to. | 07:44 | |
| hyperair | and then i just configured my pastebinit to use paste.debian.net | 07:44 |
| cjwatson | paste.debian.net expires pastes very quickly, which might have the effect of defending against this but is also very annoying in its own way | 07:45 |
| hyperair | i see. | 07:45 |
| cjwatson | I often run across Debian IRC logs with paste references that are now useless | 07:45 |
| Saviq | hyperair, sorry about that :) | 07:45 |
| hyperair | nevermind. | 07:45 |
| Saviq | hyperair, I just got used to c+p into the terminal ;) | 07:45 |
| hyperair | even with patches? =\ | 07:48 |
| hyperair | okay, i guess i could just use xsel | 07:49 |
| === tvoss|eod is now known as tvoss | ||
| === gusch is now known as gusch|brb | ||
| fishor | hello devs. i hunt currently crash on empathy-call which seems to be platform specific. May be you can help me here. This crash can be reproduset even with "gst-launch-1.0 -v v4l2src ! x264enc ! fakesink" | 09:45 |
| fishor | only on platforms supporting sse4.1 | 09:45 |
| fishor | last command on which it will crash is __memcmp_sse4_1() at sysdeps/x86_64/multiarch/memcmp-sse4.S | 09:47 |
| fishor | is it known issue? | 09:48 |
| === gusch|brb is now known as gusch | ||
| fishor | i use libx264-123, version 2:0.123.2189+git35cf912-1. same version works on i5-3317U but fail i7-2677M | 09:54 |
| jdrab | fishor: is this the same bug ? https://bugzilla.redhat.com/show_bug.cgi?id=957397 | 09:55 |
| ubottu | bugzilla.redhat.com bug 957397 in empathy "[abrt] empathy-3.8.1-1.fc19: __memcmp_sse4_1: Process /usr/libexec/empathy-call was killed by signal 11 (SIGSEGV)" [Unspecified,New] | 09:55 |
| fishor | jdrab, yea... looks like it is | 09:56 |
| Dark_light | Empathy can't show facebook accounts I think it's related to: https://bugzilla.gnome.org/show_bug.cgi?id=710363 | 09:56 |
| ubottu | Gnome bug 710363 in general "Adapt to changes in the redirect URI requested by Facebook" [Normal,Unconfirmed] | 09:56 |
| Dark_light | I tested the patches there on gnome and they work fine | 09:57 |
| fishor | jdrab, then this bug is probably in libx264-123 | 09:57 |
| jdrab | fishor: if i was you i would report it to launchpad as a bug and paste the link from redhat bugzilla | 09:58 |
| Dark_light | If I wanted to open a bug for that shuld I open it for empathy or something else ? | 10:04 |
| fishor | jdrab, ok, i reported it. https://bugs.launchpad.net/x264/+bug/1241486 | 10:26 |
| ubottu | Ubuntu bug 1241486 in x264 (Ubuntu) "empathy __memcmp_sse4_1: empathy-call was killed by signal 11 (SIGSEGV)" [Undecided,New] | 10:26 |
| fishor | most probably this bug will add more troubles, for example with totem and other apps using gstreamer | 10:26 |
| fishor | or apps using libx264-123 directly | 10:27 |
| === sil2100_ is now known as sil2100 | ||
| === _salem is now known as salem_ | ||
| === Sweetsha1k is now known as Sweetshark | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === nick1 is now known as Guest98333 | ||
| jibel | bdmurray, slangasek I suspect a problem with the upgrade of unity between raring and saucy | 13:18 |
| jibel | bdmurray, slangasek we receive lot of reports where the upgrader prefers to keep the old libunity-common rather than upgrading libunity-core-6.0-8 | 13:19 |
| jibel | for example bug 1241485 or bug 1241243 | 13:19 |
| ubottu | bug 1241420 in ubuntu-release-upgrader (Ubuntu) "duplicate for #1241485 Unable to upgrade to 13.10 ( Could not calculate the upgrade)" [Undecided,Confirmed] https://launchpad.net/bugs/1241420 | 13:20 |
| ubottu | bug 1241420 in ubuntu-release-upgrader (Ubuntu) "duplicate for #1241243 Unable to upgrade to 13.10 ( Could not calculate the upgrade)" [Undecided,Confirmed] https://launchpad.net/bugs/1241420 | 13:20 |
| jibel | bdmurray, slangasek could you have a look and see if there is really a problem or it is a false alarm | 13:21 |
| jibel | unity-common not libunity-common | 13:22 |
| === doko_ is now known as doko | ||
| bdmurray | jibel: I'll have a look in a bit | 13:28 |
| === freeflying_away is now known as freeflying | ||
| mdeslaur | welcome trusty tahr | 13:55 |
| tvoss | mdeslaur, +1 | 13:57 |
| ogra_ | \o/ | 13:57 |
| mitya57 | http://trusty-tahr.jpg.to/ | 14:01 |
| smartboyhw | New codename? | 14:02 |
| mitya57 | yeah, check sabdfl's blog | 14:03 |
| jibel | bdmurray, so, it seems that upgrade fails when unity is installed but not ubuntu-desktop ie people who installed unity on a flavor of ubuntu | 14:03 |
| smartboyhw | Yay | 14:03 |
| smartboyhw | It's too short though-.- | 14:03 |
| Cimi | hey kenvandine :) | 14:06 |
| Cimi | I'm sure you can help me | 14:06 |
| jibel | bdmurray, confirmed, do a minimal install of raring + apt-get install unity => cannot upgrade to saucy | 14:09 |
| tumbleweed | bdrung_: around? | 14:09 |
| kenvandine | hey Cimi | 14:10 |
| === jono is now known as Guest69907 | ||
| jibel | bdmurray, I completed bug 1241420 | 14:14 |
| ubottu | bug 1241420 in ubuntu-release-upgrader (Ubuntu) "unity held back if ubuntu-desktop is not installed during upgrade from raring to saucy (upgrade fails)" [Critical,Triaged] https://launchpad.net/bugs/1241420 | 14:14 |
| tumbleweed | xnox: how is your change to distro-info-data supposed to work? | 14:20 |
| xnox | tumbleweed: what do you mean? it will start returning "devel" as the in-development release. | 14:21 |
| tumbleweed | xnox: so, tools that currently use this information (e.g. dch) should be using devel instead of the codename? | 14:22 |
| xnox | tumbleweed: and there is a tweak in lpapi cache in ubuntu-dev-tools for the cases where requested codename != series.name (a one liner extra cache) | 14:22 |
| tumbleweed | that seems wrong | 14:22 |
| tumbleweed | shoudn't we handle devel specially, like we do for Debian aliases? | 14:23 |
| tumbleweed | it isn't a release | 14:23 |
| xnox | tumbleweed: uploads to devel work in launchpad and get redirected to the "current_series" in lp-api speak. | 14:23 |
| xnox | tumbleweed: no, it's special. In debian "sid" and "unstable" are both special. As sid will never release, and unstable is permament alias. | 14:24 |
| xnox | tumbleweed: in ubuntu "trusty" will release and "devel" alias will be moved to next one. | 14:24 |
| xnox | so semantics are very different. | 14:24 |
| tumbleweed | xnox: right, and devel is an alias, not a release | 14:24 |
| tumbleweed | xnox: yes, so this should be handled in distro-info, not distro-info-data | 14:24 |
| xnox | i don't see how to specify alias in distro-info-data. | 14:24 |
| tumbleweed | you can't | 14:25 |
| xnox | tumbleweed: no, i explicitely do not want it to be handled in distro-info, as "devel" is valid series on release date, and even when there is no new codename. | 14:25 |
| * xnox says works like a charm here on my machine =) | 14:26 | |
| tumbleweed | that might be useful to do, but I think tehy way you've done it is rubbish | 14:26 |
| tumbleweed | now the order of the CSV entries matters | 14:26 |
| xnox | it does in debian.csv case as well. | 14:27 |
| xnox | especially sid vs experimental. | 14:27 |
| tumbleweed | they are special cased in distro-info | 14:27 |
| xnox | tumbleweed: distro-info is broken by definitions, it should never print "release-data out of date" and instead pick the most recent one it knows on the release date, instead of giving a fizzy fit ;-) | 14:28 |
| tumbleweed | xnox: that would be broken behavior for a library | 14:28 |
| tumbleweed | anyway, I'm reverting your change, and uploading with trusty. Shall we take the discussion of how to add devel to a bug? | 14:29 |
| === freeflying is now known as freeflying_away | ||
| xnox | tumbleweed: why? | 14:32 |
| xnox | tumbleweed: bdrung_ liked the change. | 14:32 |
| tumbleweed | because I'd like to upload something that works | 14:32 |
| tumbleweed | and Ic an't see how to make this work sanely | 14:32 |
| xnox | tumbleweed: then don't upload. | 14:32 |
| tumbleweed | what sohuld ubuntu-distro-info --devel return? | 14:32 |
| xnox | tumbleweed: uploading incomplete behaviour is also wrong imho. | 14:33 |
| tumbleweed | it's the status quo | 14:33 |
| xnox | tumbleweed: no, it's just your prerogative. | 14:33 |
| tumbleweed | EPARSE | 14:33 |
| xnox | tumbleweed: given that both ubuntu & debian now have aliases, distro-info should encode them. | 14:34 |
| tumbleweed | agreed | 14:34 |
| cjwatson | That suggests they should be done in the same way, though, and this isn't | 14:34 |
| xnox | tumbleweed: or have a new file-format to encode the rules of the aliases, given that "it's the last N" anyway. | 14:34 |
| cjwatson | (sid isn't an alias) | 14:34 |
| xnox | cjwatson: i think tumbleweed's argument is that "devel" should be handled the same way as "testing" is. | 14:35 |
| xnox | (or well "unstable")( | 14:35 |
| cjwatson | Yes - and I agree | 14:35 |
| tumbleweed | it should, yes, it's an alias | 14:35 |
| xnox | cjwatson: at the moment alias support in distro-info is #ifdef DEBIAN | 14:35 |
| cjwatson | Except that we need to ensure that it continues to refer to the last thing in the list if there isn't something after it | 14:35 |
| cjwatson | Sure, I know | 14:36 |
| xnox | let me look how testing/stable aliases are defined. | 14:36 |
| tumbleweed | xnox: special casing distro-info to return "devel" if there's no known development release would be very sensible | 14:36 |
| tumbleweed | and yes, in general, ubuntu will need to gain alias support | 14:36 |
| xnox | tumbleweed: no it should imho always return devel for development uploads in ubuntu. | 14:37 |
| tumbleweed | xnox: it's used for things besides uploads | 14:37 |
| xnox | tumbleweed: same way we upload to unstable, and not sid. | 14:37 |
| tumbleweed | I don't want my QA databases to suddendly be considuring devel to be a release | 14:37 |
| tumbleweed | xnox: has the ubuntu community decided that we want devel in our changelogs? I haven't seen any discussion on that | 14:38 |
| cjwatson | xnox: Actually always returning devel is dangerous | 14:38 |
| cjwatson | xnox: LP operations (e.g. syncs) require a concrete series name not an alias | 14:38 |
| cjwatson | And that was deliberate | 14:38 |
| xnox | tumbleweed: devel, is meant for people to track latest development series and use them in their apt sources. | 14:38 |
| cjwatson | It's meant for that but it's too early to actually use in apt sources given that apt complains in odd ways when you do and it doesn't work right for all the pockets yet | 14:39 |
| xnox | cjwatson: "deliberate" ok, interesting. Because getSeries(name_or_version="devel") returns me a series object in the api. | 14:39 |
| cjwatson | xnox: that's different | 14:39 |
| cjwatson | xnox: if you copyPackage(to_series="devel") it will fail | 14:39 |
| wgrant | cjwatson: Hm, I thought I tried to push back on that, but the aliases ended up working for copyPackages in the end. | 14:41 |
| cjwatson | Though admittedly syncpackage gets that directly from the API. Still, I think distro-info should return concrete series names. | 14:41 |
| === salem_ is now known as _salem | ||
| cjwatson | wgrant: You did and I was fairly sure I'd incorporated your suggestion | 14:41 |
| cjwatson | If they work then it's by mistake | 14:41 |
| wgrant | _text_to_series seems to follow aliases. | 14:41 |
| xnox | cjwatson: then "dch" is broken without updated distro-info, which is imho wrong & it should use "devel". | 14:42 |
| xnox | cjwatson: unless we make a way to explicetely request alias. | 14:42 |
| cjwatson | xnox: I think dch should be special-cased for Ubuntu as it is for Debian | 14:42 |
| xnox | tumbleweed: debian-distro-info --alias --devel -> doesn't work, and i would have expected it to. | 14:43 |
| cjwatson | wgrant: Maybe I misremember the discussion ... | 14:43 |
| tumbleweed | xnox: wat | 14:43 |
| tumbleweed | --alias takes an argument | 14:43 |
| tumbleweed | yes, we need a reverse --alias | 14:43 |
| xnox | tumbleweed: sure but `debian-distro-info --alias `debian-distro-info --devel`` is ugly UI =) | 14:44 |
| tumbleweed | xnox: totally agreed | 14:44 |
| xnox | if i want hte "devel" alias, for e.g. dch and stuff _I_ care about =)))) | 14:44 |
| tumbleweed | right, and I keep telling you that you are doing this in the wrong place | 14:44 |
| xnox | tumbleweed: anyway, yeah add trusty to ubuntu.csv and upload without devel in there. | 14:44 |
| xnox | tumbleweed: and we'll work out the alias semantics later. | 14:45 |
| tumbleweed | if you want devel in dch, then dch doesn't need to use distro-info | 14:45 |
| erle- | are logs from /var/crash save to upload from a privacy perspective? | 14:45 |
| tumbleweed | devel is forever | 14:45 |
| xnox | tumbleweed: but like "update-maintainer" and things like that should learn that "devel" is ubuntu. | 14:46 |
| tumbleweed | yes | 14:46 |
| xnox | cjwatson: hm.... will DEB_VENDOR trip up on "devel" at all? | 14:46 |
| xnox | oh, it's per vendor, nor per vendor release, so shouldn't. | 14:47 |
| cjwatson | I don't think there's a great rush to sort out devel; it can be done at leisure | 14:47 |
| cjwatson | There are several things to adjust | 14:47 |
| xnox | ok. | 14:51 |
| tumbleweed | so, does this look right? 14.04 LTS,Trusty Tahr,trusty,2013-10-17,2014-04-17,2019-04-17 | 14:51 |
| xnox | tumbleweed: it's been created on 2013-10-18. | 14:57 |
| xnox | =)))) (me ponders if created date should encode when sabdfl gave us the codename ;-) ) | 14:57 |
| tumbleweed | xnox: yeah, I'd rather not have the discontinuity | 14:57 |
| xnox | tumbleweed: yeah, due to distro-info brokeness. that's fine. I am half joking at this point =) | 14:58 |
| tumbleweed | historically, there used to be very long archive opening delays, we don't encode that | 14:58 |
| xnox | ah, true true. | 14:58 |
| shadeslayer_ | I'm using the UbuntuDrivers Python 3 API to write a driver manager for Kubuntu but it seems like the API isn't returning the currently active driver for me | 15:23 |
| shadeslayer_ | see http://pastebin.kde.org/ppbk8vvv9 | 15:24 |
| === ryukafalz_ is now known as ryukafalz | ||
| tseliot | shadeslayer_: if you send me an email about that I can probably help | 15:36 |
| shadeslayer_ | tseliot AT youboontoo dot com ? | 15:36 |
| bdmurray | slangasek: do you have any ideas on bug 1241420? | 15:37 |
| ubottu | bug 1241420 in ubuntu-release-upgrader (Ubuntu) "unity held back if ubuntu-desktop is not installed during upgrade from raring to saucy (upgrade fails)" [Critical,Triaged] https://launchpad.net/bugs/1241420 | 15:37 |
| tseliot | shadeslayer_: you'll find my address here: https://launchpad.net/~albertomilone | 15:37 |
| shadeslayer_ | ack | 15:37 |
| bdmurray | I think I ended up with a similar problem after fiddling with the lubuntu-desktop PostUpgradeRemove | 15:38 |
| slangasek | bdmurray: in the process of wrapping my brain around it. unity-common being obsolete means it should get removed, but apparently it hasn't been hinted hard enough | 15:38 |
| slangasek | oh? | 15:38 |
| bdmurray | Well the PostUpradeRemove change wasn't enough at any rate | 15:39 |
| slangasek | hmm | 15:39 |
| stgraber | hallyn: libvirt accepted into precise-proposed | 16:21 |
| hallyn | stgraber: great, thanks. i'm a little confused as to why the builds succeeded on arm tbh... guess the testcases didn't run there or something | 16:21 |
| === seb128_ is now known as seb128 | ||
| === _salem is now known as salem_ | ||
| slangasek | bdmurray: so I can certainly reproduce the problem, but I'm not yet seeing why apt gets wedged this way | 17:09 |
| bdmurray | slangasek: is it odd that libunity-core-6.0-8 provides and conflicts with unity-common? | 17:10 |
| slangasek | bdmurray: nah, Provides/Conflicts/Replaces is a standard method of taking over from another package | 17:10 |
| slangasek | bdmurray: reproducible with apt-get dist-upgrade, that's helpful | 17:13 |
| === salem_ is now known as _salem | ||
| slangasek | bdmurray: so the problem may be related to libunity-core-6.0-8 Conflicts: unity-common recursively breaking libunity-core-6.0-5 and unity, and apt not following this all the way around; I guess that having libunity-core-6.0-8 declare Breaks: against the old version of unity and libunity-core-6.0-5 will help here, let me try that locally | 17:22 |
| bdmurray | slangasek: ah earlier I see a Holding Back libunity-core-6.0-8:i386 rather than change unity-common:i386 | 17:25 |
| bdmurray | slangasek: how will you try that locally? | 17:26 |
| slangasek | bdmurray: hacking /var/lib/apt/lists/*Packages :) | 17:27 |
| slangasek | didn't help | 17:27 |
| slangasek | 'apt-get -o Debug::pkgProblemResolver=yes purge unity-common', with raring packages installed and sources pointing to saucy, is instructive | 17:27 |
| bdmurray | slangasek: that's a lot to read through. Have you looked at libwayland-client0 yet? | 17:47 |
| slangasek | bdmurray: I haven't; I actually decided that the 'purge unity-common' was probably not going to be the shortest path and am looking at dist-upgrade output again | 17:47 |
| slangasek | bdmurray: anyway, I'm permuting the upgrade options by editing the Packages files and running 'sudo apt-get check' to force a cache update | 17:48 |
| slangasek | bdmurray: hmm, apt is mocking me, 'apt-get check' isn't actually honoring my changes | 17:57 |
| slangasek | bdmurray: oh, because I have multiple sources, whoops | 17:57 |
| smoser | hey.. per my apt-cache, swift is universe | 18:03 |
| smoser | http://paste.ubuntu.com/6258843/ | 18:03 |
| smoser | i do not believe that to be the intention | 18:03 |
| smoser | and it disagrees with https://launchpad.net/ubuntu/+source/swift | 18:03 |
| slangasek | bdmurray: ok, adding libunity9 Breaks: unity-common (<< 7.1.2) is sufficient to get apt to DTRT | 18:04 |
| slangasek | smoser: the source package is in main; most of the binaries are in main; the swift binary is not because nobody seeded it or depended on it | 18:05 |
| bdmurray | slangasek: great, so what is next? | 18:06 |
| slangasek | bdmurray: SRU of libunity | 18:06 |
| smoser | slangasek, thanks. | 18:07 |
| slangasek | bdmurray: unless you think it would be better to quirk this in ubuntu-release-upgrader, which is also possible but not strictly necessary | 18:07 |
| slangasek | well, theoretically possible | 18:07 |
| slangasek | I think it'd be easier to address it in libunity, in this case :) | 18:07 |
| bdmurray | And also help being using apt to dist upgrade | 18:08 |
| bdmurray | s/being/people/ | 18:08 |
| slangasek | yep | 18:08 |
| bdmurray | so you'll upload it? | 18:09 |
| slangasek | sure, can do | 18:09 |
| bdmurray | How did you arrive at libunity9? | 18:11 |
| slangasek | bdmurray: I looked at the set of unity packages in the apt-get dist-upgrade output that were being upgraded instead of removed, and picked one | 18:12 |
| slangasek | unity-services might be a better choice conceptually since it's from the same source, but libunity* are more likely to get the right result from apt since they're lower in the stack | 18:12 |
| slangasek | bdmurray: ok, uploaded | 18:17 |
| infinity | smoser: It's always been in universe. | 18:18 |
| smoser | infinity, thats fine. | 18:18 |
| infinity | smoser: For future reference, what you probably want here is "rmadison -S swift" to tell the whole story. | 18:19 |
| === Nisstyre-laptop is now known as nisstyre | ||
| brainwash | it looks like bug 1205384 is still present, can anyone else confirm this? | 18:48 |
| ubottu | bug 1205384 in lxsession (Ubuntu) "Lock can be circumvented by switching to console" [Undecided,Confirmed] https://launchpad.net/bugs/1205384 | 18:49 |
| === _salem is now known as salem_ | ||
| mdeslaur | brainwash: you need to lock the screensaver before you switch to the greeter lock mode | 19:02 |
| brainwash | mdeslaur: yes, I know that, but all the lubuntu 13.10 users don't I guess | 19:02 |
| mdeslaur | brainwash: well, not manually, I mean whatever lxsession is doing has to lock the screensaver | 19:03 |
| mdeslaur | brainwash: what's calling dm-tool? | 19:03 |
| brainwash | it's just switching to the lightdm greeter, didn't see it calling a locker | 19:03 |
| brainwash | the lxlock script | 19:04 |
| brainwash | part of the lxsession package | 19:04 |
| mdeslaur | brainwash: ah, yeah, that script is wrong | 19:05 |
| brainwash | mdeslaur: yeah, needs to fixed asap I think | 19:06 |
| brainwash | and they already removed xscreensaver | 19:07 |
| mdeslaur | brainwash: what's the default screensaver in lxde? | 19:07 |
| brainwash | I'm not that familiar with lubuntu/lxde | 19:08 |
| brainwash | I was just curious about the lightdm locker mechanism | 19:08 |
| mdeslaur | brainwash: lightdm doesn't actually lock the screen, something else has to | 19:09 |
| brainwash | yea, I'm informed | 19:10 |
| brainwash | there is a working solution, light-locker, but it's not yet available in the official repository | 19:10 |
| brainwash | just want to make sure that someone verifies this (security) issue and informs the right people to fix it | 19:13 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === cmagina_ is now known as cmagina | ||
| chiluk | yay 64-bit default.... I see pigs flying... | 19:47 |
| slangasek | chiluk: duck, those things pack quite a wallop when they hit you | 19:49 |
| chiluk | slangasek, see it wasn't that hard. | 19:49 |
| bdmurray | slangasek: there is still the lubuntu-desktop postupgraderemove change which I'll upload today. I want to see if there are any other upgrade issues. | 20:13 |
| slangasek | bdmurray: sounds good | 20:30 |
| kirkland | I have a strange build failure on 13.10... | 20:35 |
| kirkland | cp: cannot stat ‘/usr/share/automake-1.11/INSTALL’: No such file or directory | 20:35 |
| kirkland | that file does not exist, as it's in ‘/usr/share/automake-1.13/INSTALL’: | 20:36 |
| kirkland | why on earth does automake use a 1.11 path? | 20:36 |
| kirkland | doh | 20:37 |
| kirkland | nevermind | 20:37 |
| brainwash | mdeslaur: any new information regarding bug 1205384? nothing has been done during the development cycle to fix this, so I'm not sure if anything will happen any time soon | 21:33 |
| ubottu | bug 1205384 in lxsession (Ubuntu) "Lock can be circumvented by switching to console" [Undecided,Confirmed] https://launchpad.net/bugs/1205384 | 21:33 |
| mdeslaur | brainwash: I don't have any information...perhaps contact the lxde team? I'm not sure who's on it | 21:48 |
| brainwash | mdeslaur: I'll do that, thanks | 21:52 |
| bdmurray | slangasek: bug 1241487 looks like an issue with gdm and libgdm | 22:08 |
| ubottu | bug 1241487 in ubuntu-release-upgrader (Ubuntu) "Release upgrade aborts with error message" [Undecided,New] https://launchpad.net/bugs/1241487 | 22:08 |
| === salem_ is now known as _salem | ||
| === ximion1 is now known as ximion | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
