=== dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [00:33] * SpamapS has 5Mbit upstream and doesn't know what to do with it. :-P [00:35] seeding movies? =) [00:37] I don't own the copyrights to any movies, so no, that doesn't sound like a good idea. [00:39] u dont need to own the copyright since u'll not being doing profit of it, at least that's how it's here (mexico), I was just suggesting n.n [00:41] I'm pretty confident that's not how it is where SpamapS lives. [00:42] broder: is lintian.ubuntuwire.org stuck? http://lintian.ubuntuwire.org/tags/preinst-uses-dpkg-maintscript-helper-without-predepends.html shows last updated on Saturday [00:49] There are movies you’re free to seed. :-P [00:50] SpamapS: Back up to U1! [00:50] cjwatson: oh yeah, my vm host forgot how to talk to its disks on saturday, and the vm that's running l.uw.o probably didn't come back up. dealing... [00:52] * cjwatson sings the I-hate-threads song [00:52] it goes "la la la I hate threads" [00:52] Sounds more like you hate sucky implementations of threads. [00:52] nope, I hate threads [00:52] unless you mean the "process" implementation [00:53] which hardly counts given the lack of shared data :) [00:53] everybody sings that song, until they deal with twisted, then they start stalking their old crazy lover, threads.. hiding in the bushes.. following threads to work.. [00:53] Not sharing mutable data directly is an impotant part of threads sucking, yes. [00:53] err [00:53] s/threads sucking/a non-sucky implementation/ [00:54] cjwatson: I'm currently singing the I-hate-posix-signals song. I WIN! [00:54] RAOF: I'm dealing with signals *and* threads [00:54] who wins now? [00:54] Ok, you win. [00:54] nobody [00:54] nobody wins [00:55] (I don't even actually want to use threads myself, but somebody wants this library to be thread-safe ...) [00:55] cjwatson: the vm is back up and running an update. new results should be posted within the next couple of hours [00:55] broder: great, thanks [00:55] cjwatson: Isn't the basic premise: {threads, signals} - pick one? [00:55] thanks for mentioning it. i've gone ahead and set this vm to autostart, so maybe it won't happen again [00:56] I think that with extreme care it is possible to make them interoperate in this very specific case [00:56] I thought it was pick none [00:57] specifically use the self-pipe trick to wake up all threads that are sitting in select any time the signal in question is delivered to any of them, and ensure that any of those threads is capable of handling whatever ensues [00:58] you can get away with it if (as a friend pointed out) you *both* block the signal in question and take out a mutex around any manipulation of process-wide state [00:58] but it's hairy as all hell [00:58] cjwatson: is this for libpipeline/SIGCHILD? does something like signalfd make this better? [00:58] yes, and signalfd doesn't really help much [00:59] oh hmm, yeah, i see [00:59] you could avoid self-pipe that way but you still have to do the extreme-care-for-process-wide-state bits [01:00] I think it would be an optimisation at best [01:06] cjwatson: well behaved libraries and threaded programs don't keep much process wide state though. :) [01:07] SpamapS: Yes, but you have no choice when you have to interact with process-directed signals. [01:08] cjwatson: indeed, signals are to threads as bowling balls are to pristine windless lakes early in the morning. [01:12] SpamapS: that's far too poetic :) [01:12] TREllis: gconf 3.2.3-3 merged [01:17] sigstop from upstart, you just want to trace my forks, forever wait for my fork bug 406397 [01:17] Launchpad bug 406397 in upstart "init: job stuck with expect fork/daemon when parent reaps child" [Medium,Triaged] https://launchpad.net/bugs/406397 [01:17] damnit, I meant forever you wait [01:18] sigstop from upstart, you just want to trace my forks, forever you wait bug 406397 [01:18] * SpamapS decides to do haikus only on bugs that are Triaged and > 1 year old from now on [01:20] can we make that a bug filing requirement? i think having all bug titles in the form of haikus would be awesome. or at least interesting [01:21] the changelogs for debconf 0.9.10 and 0.9.11 are such that I've never bothered trying to beat them [01:22] "I updated the / Dutch translation (or rather, / some Dutch guy did -- thanks)." [01:22] those are epic === fenris is now known as Guest65492 === mwhudson_ is now known as mwhudson === salem_ is now known as _salem [05:51] Good morning [06:42] pitti, more beer this morning! [06:42] :-D [06:42] wow, and the smoke tests look good too [06:43] upgrades are still poor, though [06:47] mvo has been making progress on the apt issues there [06:47] I'll have a look into the other issues RSN (kdebase, the opencv breaks) [07:54] good morning [07:56] Morning, dholbach [07:57] hey jalcine === smb` is now known as smb [08:54] slangasek: brilliant! Thanks! === Claudinux_ is now known as Claudinux === tkamppeter_ is now known as tkamppeter [10:02] how would you recommend overriding a setting set in a /usr/share/glib-2.0/schemas/*.gschema.override file? (for example org.gnome.desktop.background) [10:03] i don't like the idea of modifying the file from gsettings-desktop-schemas package, and writing another override file doesn't work === l3on_ is now known as l3on [10:31] lenios, you might want to ask in #ubuntu-desktop [10:59] james_w: I'm intrested in solving bug 830110, can you help me? I'm relatively new to ubuntu contribution [10:59] Launchpad bug 830110 in compiz (Ubuntu) "Horrifically bright "Aero Snap" color (grid plugin?)" [Undecided,Confirmed] https://launchpad.net/bugs/830110 [11:10] mvo: hm, I went through https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/lastFailedBuild/ARCH=amd64,LTS=lts,PROFILE=ubuntu,label=upgrade-test/artifact/lts-ubuntu-amd64/apt.log [11:11] mvo: and I'm still unable to see what it complains about; there seems to be a lot of problems with python:amd64, but I went through all of them, and I don't see a particular reason why it's held back? [11:15] pitti: let me have a look [11:17] * pitti wishes that he could peek into mvo's brain to see what he's looking for [11:20] hi [11:21] mvo: hm, the upgrade succeeded on i386, so perhaps it was just due to i386/amd64 buildd skew and the resulting uninstallability? [11:21] I've reported a bug on the software center: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/947899 [11:21] Launchpad bug 947899 in software-center (Ubuntu) "Empty "cancel" button while installing application" [Undecided,New] [11:21] can someone check if this affects other locale (I've tested this on pl_PL) [11:21] it could be broken translation or some kind of unrelated bug/race (it's not 100% reproducible for me) [11:22] mvo: similar with oneiric-main; so let's wait for the next run for now, and assume it was buildd skew [11:23] mvo: https://launchpadlibrarian.net/95596771/software-center-empty-button-bug.png (if you have the time) [11:27] mvo: so I think somewhere in http://paste.ubuntu.com/871292/ (small except) the reason for update-manager removal is hidden [11:27] mvo: am I right that the first "Broken" block was resolved successfully? (until line 19) [11:28] mvo: so I don't understand the complaint from lines 20 to 22 [11:33] pitti: the catch is "Investigating (3) software-properties-gtk [ amd64 ] < 0.75.10.2 -> 0.82.4 > ( gnome ) [11:33] Broken software-properties-gtk:amd64 Depends on python [ amd64 ] < 2.6.5-0ubuntu1 -> 2.7.2-9ubuntu2 > ( python ) (< 2.7) [11:33] Considering python:amd64 1269 as a solution to software-properties-gtk:amd64 10000 [11:33] Added python:amd64 to the remove list" [11:33] pitti: I think :) [11:34] mvo: hm, s-c-gtk does not look any different than other python stuff [11:34] Depends: python2.7, python (>= 2.7.1-0ubuntu2), python (<< 2.8) [11:34] looks fairly normal? [11:34] mvo: there's a ton of similar messages there [11:35] mvo: wrt. http://paste.ubuntu.com/871292/, I just ran through the log to find why it's refusing to install/update python-gobject, but I don't find anything [11:35] mvo: let's look at the i386 logs (the one I took the paste from), yesterday's GNOME updates broke amd64 installability temporarily [11:36] mvo: i. e. https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/lastFailedBuild/ARCH=i386,LTS=lts,PROFILE=ubuntu,label=upgrade-test/artifact/lts-ubuntu/apt.log [11:36] mvo: but perhaps start with the pastebin, that's only 30-is lines and easier to see? [11:36] ok, I check the i386 one now [11:36] (I might have caught the wrong ones, of course) [11:37] oh, found it [11:37] Considering python-gi:i386 114 as a solution to python-gobject:i386 56 [11:37] Reinst Failed because of libglib2.0-0:i386 [11:37] Reinst Failed because of libgirepository-1.0-1:i386 [11:37] Reinst Failed because of python-gi:i386 [11:37] dholbach: thanks for comment on my MOTU application [11:37] * pitti drills down the chain [11:38] hrw, anytime :-) [11:38] pitti: what is the parent of this ? I look at i386,lts,ubuntu,upgrade,test (precise-upgrade-lucid-desktop) and that is a pass for me [11:39] I mean, it failed becuase of test failures, but the actual upgade was fine [11:39] mvo: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/lastFailedBuild/ [11:39] and then i386 [11:39] aha, thanks! [11:40] indeed, jenkins confused me [11:40] Broken libglib2.0-0:i386 Breaks on gnome-control-center [ i386 ] < 1:2.30.1-0ubuntu2 -> 1:3.3.90-0ubuntu5 > ( gnome ) (< 1:3) [11:40] Considering gnome-control-center:i386 27 as a solution to libglib2.0-0:i386 3189 [11:40] Upgrading gnome-control-center:i386 due to Breaks field in libglib2.0-0:i386 [11:40] mvo: ^ this is a success, right? [11:40] yes [11:41] but further down [11:41] Investigating (2) libglib2.0-0 [ i386 ] < 2.24.1-0ubuntu1 -> 2.31.20-0ubuntu1 > ( libs ) [11:41] Broken libglib2.0-0:i386 Breaks on gnome-control-center [ i386 ] < 1:2.30.1-0ubuntu2 -> 1:3.3.90-0ubuntu5 > ( gnome ) (< 1:3) [11:41] Considering gnome-control-center:i386 10000 as a solution to libglib2.0-0:i386 2690 [11:41] Holding Back libglib2.0-0:i386 rather than change gnome-control-center:i386 [11:41] isn't that the very thing it just looked at, and now decides it's suddenly broken? [11:41] pitti: " Removing aptdaemon:i386 rather than change python-aptdaemon:i386" <- this one looks fishy [11:42] so in that log it holds back a ton of packages due to libglib2.0-0 [11:42] which holds back python-gi, which holds back python-gobject, which probably also cuases the aptdaemon failure? [11:42] mvo: ^ [11:43] aha, ok [11:43] yes, make sense, I'm not that far inth elog yet [11:44] mvo: so I'm currnetly wondering why libglib2.0-0 gets held back [11:44] mvo: especially with above two snippets (the breaks: on control-center) [11:44] which first was happy, and the second time not [11:45] pitti: is this one here: Broken gnome-control-center:i386 Depends on gnome-icon-theme-symbolic [ i386 ] < none -> 3.2.2-1 > ( gnome ) [11:45] Considering gnome-icon-theme-symbolic:i386 2 as a solution to gnome-control-center:i386 27 [11:45] Removing gnome-control-center:i386 rather than change gnome-icon-theme-symbolic:i386 <-ok? [11:45] uh? [11:46] mvo: I don't see why the two would collide; control-center depends on icon-theme-symbolic [11:46] gnome-icon-theme-symbolic:i386 Depends on gnome-icon-theme [ i386 ] < 2.28.0-1ubuntu1 -> 3.3.91-0ubuntu1 > ( gnome ) (< 3.3) can't be satisfied! [11:47] mvo: we updated both to 3.3 today, but yesterday they were both at 3.2 [11:48] pitti: so just a issue that the archive was out-of-sync? [11:48] mvo: it should have been fine at the time when this ran [11:48] mvo: well, icon-theme anyway [11:48] mvo: do you see a reason why it refuses to upgrade libglib2.0-0? [11:49] mvo: especially the weird breaks: to control-center? [11:51] pitti: I think what happens is that the removal of gnome-control-center is tried ot be undone because it would mean that ubuntu-desktop gets removed. so it tries to reinstall it, that does not work, so it keeps it, but because of the keep it needs to keep libglib2.0-0 too and that causes a cascade of error - does that sound plausible? [11:51] why would it remove it instead of upgrade? it's a versioned breaks [11:51] pitti: but the original problem (that triggers this) is that the icons can not be installed and therefore gnome-control-center can not be upgraded [11:52] mvo: ah, so that's the second breaks:? [11:52] pitti: it can't upgrade it because of the icon-theme-symbolic dependency that it can not satisfy [11:52] mvo: ah, I see [11:52] mvo: so first it resolves the breaks with an upgarde, then it complains about icon-theme [11:53] pitti: yes, and appears to be the case (it may even be more complicated, I see a message about libgoa-1.0-0 that I don't know what it is) [11:53] mvo: ooh, indeed that test only started 3 hours ago [11:54] mvo: ok, thanks [11:54] mvo: so let's try this again [11:54] pitti: shall I re-run the test with the current archive just to ensure that its not archive-churn? [11:54] mvo: ah, can you? [11:54] mvo: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/ -> this one [11:54] http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html is currently "Beer" [11:54] so it ought to work [11:54] it did have a lot of stuff this morning indeed [11:54] haha [11:55] pitti, beer at this time? [11:55] maybe we should actually make the tester look at that file before it runs? [11:55] pitti, that might explain why we see some breakages in the afternoons :p [11:55] seb128: our goal is to have beer at all times [11:55] for me it said tea [11:55] mvo: it certainly doesn't make much sense to try and run if ubuntu-desktop is uninstallable [11:55] which is often the case when seb128 upgrades gnome [11:55] he grabs the beer, and swoosh, the archive becomes a mess [11:55] * pitti hugs seb128 [11:55] s/often/everytime/ ;) [11:55] lol [11:55] * seb128 hugs pitti mvo [11:56] * mvo hugs seb128 [11:56] mvo: I was going to ask jibel to restart it, but if you could? [11:56] ok,lets talk after lunch [11:56] I trigger a manual run now and let you know [11:56] mvo: that test hasn't succeeded in 12 days, so I'm eager to get a run on a known-good archive (which is now0 [11:56] mvo: cool, thanks [11:56] mvo: will that appear in jenkins? [11:56] I don't know, jibel will know :) he is the master of the jenkins [11:57] pitti, I was about to restart the test now that icon-theme-symbolic is in the archive. i386 succeeded yesterday [11:58] jibel: ah, merci [11:58] mvo: ok, after lunch we need to talk about another weirdness [11:58] but lunch -> good idea, bbl [11:58] jibel: so I guess mvo already started it now [12:01] pitti, right, i386 is running and upgrading. I'll re-run from jenkins when it's finished to publish the resutls === Amoz is now known as Afougner [12:04] pitti: scour. Currently it only Suggests: python-rsvg, python-cairo. However both of these are needed dependencies for 'cmpsvg' otherwise it shrug and gives up [12:05] pitti: this means that during build scour is run by the exercise is pointless(?) [12:05] pitti: what's your preferred. Move those to Recommends:/Depends: ? [12:05] pitti: or pull in those two as dependenices in indivudal packages? [12:06] pitti: hold on, you've answed this at https://bugs.launchpad.net/ubuntu/+source/ubuntu-mono/+bug/927606 [12:06] Launchpad bug 927606 in ubuntu-mono (Ubuntu) "add python-rsvg build dependency for verifying scour results" [Medium,Fix released] === _salem is now known as salem_ [12:23] pitti, mvo i386 passed, re-running with jenkins now === chrisccoulson_ is now known as chrisccoulson [12:52] slangasek: we can't add them as recommends, it creates recursive build depends loops [12:52] sorry, sladen ^ [12:52] sladen: packages which have a lot of svgs, such as icon themes, need to b-dep on those themselves === MacSlow is now known as MacSlow|lunch === Afougner is now known as Amoz [12:56] jibel: ah, taht seems to be https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/53/ ? [12:56] jibel: or was that mvo's manual job? [12:57] jibel: anyway, amd64 passed, and i386 test failure, nice [12:57] jibel: is the x server test a race condition in the tests? [12:57] I see this quite often [12:59] jibel: I'm filing a bug for the libreoffice-common failure in https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-oneiric-universe/lastFailedBuild/ARCH=i386,LTS=non-lts,PROFILE=universe,label=upgrade-test/artifact/universe-i386/apt-term.log [13:03] pitti, that's bug 916291 Sweetshark fixed yesterday [13:03] Launchpad bug 916291 in libreoffice (Ubuntu Precise) "failed to upgrade from Oneiric to Precise: ERROR: Cannot determine language! - exit status 134" [High,Fix released] https://launchpad.net/bugs/916291 [13:03] jibel: oh, that's why I didn't see it [13:03] jibel: thanks, duplicating [13:03] jibel: ok, so looking forward to the next run :) [13:04] jibel: so I'll trawl through the lucid-universe apt log now; it seems the failures of all other tests are already fixed or in progress [13:11] roaksoax: any progress on bug 840406? [13:11] Launchpad bug 840406 in powernap (Ubuntu Precise) "powerwaked crashed with ImportError in /usr/lib/python2.7/dist-packages/powerwake/monitors/ARPMonitor.py: No module named scapy.all" [High,Triaged] https://launchpad.net/bugs/840406 [13:11] roaksoax: python-scapy is in universe, so at this point the new dependency should probably be dropped? [13:13] mvo: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-main/lastFailedBuild/ARCH=i386,LTS=lts,PROFILE=main-all,label=upgrade-test/artifact/lts-main-all/apt-term.log [13:13] mvo: to my untrained eye this looks like another instance of bug 927993, do you agree? [13:13] Launchpad bug 927993 in apt (Ubuntu Precise) "ordering code may mark a package for configure before its unpacked" [Critical,Triaged] https://launchpad.net/bugs/927993 [13:14] mvo: or perhaps not? it tries to configure kde-runtime before libsmbclient gets unpacked and configured [13:18] is there a way to tell upstart that we want to track a pid file? [13:19] pitti: indeed, this looks like another order failure, let me try to reproduce first [13:20] mvo: oh, so it's not the same bug? [13:20] pitti: I doubt it but lets see === dholbach_ is now known as dholbach [13:21] mvo: I picked up some of your training and now walk through the apt.log of precise-upgrade-lucid-universe :) [13:21] man, the day that this thing goes green I'm so much having a beer [13:21] lol [13:22] * mvo runs with order code debug enabled to see what he can find out [13:22] pitti: haha [13:25] pitti, this was bug 940396 and it was duplicated to 927993 [13:25] Launchpad bug 927993 in apt (Ubuntu Precise) "duplicate for #940396 ordering code may mark a package for configure before its unpacked" [Critical,Triaged] https://launchpad.net/bugs/927993 [13:26] jibel: ah, thanks [13:26] mvo: ^ so maybe undupe it, if appropriate? === jalcine is now known as JackyAlcine_ [13:27] pitti: yes, the first bug is about --configure being call on a package that never saw --unpack, the second one is about a package that is configured before all of its dependencies are configured [13:28] mvo: for the second one, I just discovered bug 892630 and commented on it [13:28] Launchpad bug 892630 in apt (Ubuntu) "package gir1.2-glib-2.0 1.30.0-0ubuntu2 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/892630 [13:28] with an extraction of the log [13:28] mvo: that seems to be an instance of the second one (forgot to configure library before configuring rdep) [13:29] pitti: yes [13:29] * pitti retitles it to something easier [13:29] mvo: so we should undupe bug 940396 and I make 892630 a dupe of it (or the other way round)? [13:29] Launchpad bug 940396 in apt (Ubuntu) "lucid -> precise main all failed to upgrade: dpkg: dependency problems prevent configuration of kde-runtime" [Critical,Confirmed] https://launchpad.net/bugs/940396 [13:29] pitti: but that is not reproducable via some upgrade test run, right? that was a user reported problem? [13:29] mvo: yes, 892630 was a user report [13:30] mvo: 940396 is from jenkins [13:30] pitti: sounds good to me, maybe 940396 as its actually possible to reproduce this error [13:30] mvo: ack [13:30] 940396 as the master I mean [13:30] ta [13:31] done [13:33] ok, I think all current upgrade failures are covered with bug reports then [13:34] and I think it's mostly these two apt bugs now [13:39] I'm attempting to submit a fix for this bug, and following the instructions jbicha gave me have proved... less than fruitful. https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/771375 [13:39] Launchpad bug 771375 in gnome-games (Ubuntu) "No Unity QuickList for gnomine" [Undecided,Confirmed] [13:40] pitti: meh, the main-all takes forever to run :/ [13:41] mvo: :/ 8.5 hours on jenkins :/ [13:42] "fun" === JackyAlcine_ is now known as jalcine === jalcine is now known as JackyAlcine_ === JackyAlcine_ is now known as jalcine_ [13:57] pitti: it looks ike its a dependency loop problem, but it still should not fail like this [14:09] pitti, I ran oneiric universe again and libreoffice 1:3.5.0-2ubuntu1 is still failing to upgrade. same error [14:13] packaging question, I'm trying to copy the config files I have working in the debian/conf/* directory on a package that doesn't have an install file, the rules file looks like this http://pastebin.ubuntu.com/871481/ [14:13] line 22 is the one I added, I know cp is not the right one, I tried install -p -d -D -m 0755 but didn't work, for config files what would be the recommended best way? [14:18] pitti, apw: help on bug #947748 [14:18] Launchpad bug 947748 in gnome-settings-daemon (Ubuntu) "Brightness control not working after latest update" [Undecided,Confirmed] https://launchpad.net/bugs/947748 [14:19] do you know guys know how to debug that? [14:19] is there a known kernel issue? [14:19] angeloc, I'm not sure I know what to do with that bug. Was there a particular reason you asked me? === MacSlow|lunch is now known as MacSlow [14:20] seb128, there might have been something to do with macs in the -18 kernel [14:20] apw, right, those are macs users [14:21] massocists all [14:21] seb128, am discussing on #ubuntu-kernel [14:21] apw, thanks, I'm going to lurk there ;-) [14:22] I noticed that my macbook no longer sleeps if I just shut the lid on the newest kernel [14:22] guess that is part of this. [14:22] * Laney goes to lurk there too [14:26] dpm: could you see if a Chinese translator could review stgraber's suggestion for https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/892386/comments/5 ? [14:26] Launchpad bug 892386 in ubiquity (Ubuntu) "No shortcut available for "forward" button for Chinese during installation / oem-config" [High,Triaged] [14:29] james_w: because you are the one who created the source package, sorry if it was a problem [14:33] cjwatson, pinged translators and I'll follow it up [14:33] thanks for the heads up [14:34] ta [14:40] cjwatson, stgraber, the Chinese translators didn't seem to happy about adding a shortcut on the translation where there isn't one in the original string. I've asked them to comment on the bug [14:42] mvo: what is a dependency loop problem? [14:42] jibel: ah, so we should reopen this? [14:42] I kind of wonder why we don't have a shortcut on that msgstr to match GTK, in some ways [14:42] maybe it's also used in the KDE frontend though? [14:43] pitti, I reopened it. === deryck_ is now known as deryck [14:44] Sweetshark, ^ bug 916291 [14:44] Launchpad bug 916291 in libreoffice (Ubuntu Precise) "failed to upgrade from Oneiric to Precise: ERROR: Cannot determine language! - exit status 134" [High,Triaged] https://launchpad.net/bugs/916291 [14:44] dpm: I can definitely understand that, though the reason for the bug is that they added it for all the other ones in gtk ... [14:44] dpm: so they should either add the shortcut for that one too or remove all of these they added for all the gtk stock buttons [14:44] dpm: otherwise you get an inconsistent installer UI [14:46] stgraber, I'm not sure I quite follow why the shortcut appears in one button and not in the other. Is it because the Back one is stock and thus has a shortcut, and the Continue one is not stock and doesn't have one? [14:47] if so, would it not be better to add a shortcut in the Continue button in the source code? [14:48] stgraber: well, no, the "Continue" string is in ubiquity proper but the others are imported from GTK [14:49] pitti: the one in the bugreport? well, that its not resolved correctly :) I think the loop in itself is ok and is resolvable afaict [14:49] mvo: I mean, if we could break a loop somewhere, that might help, but I didn't see a loop dependency on either glib or libsmbclient [14:50] pitti: its kde-runtime, glib is fine [14:50] dpm,stgraber: yeah, on inspection, this string is shared with KDE which I'm fairly sure has different shortcut conventions [14:50] pitti: and libkrb5 [14:50] so I don't think it can be as simple as adding _, even in the translation [14:51] pitti: well, I'm not sure, we could workaround it, but I prefer to see it be fixed in libapt [14:51] * cjwatson tries to remember why the stock labels weren't good enough [14:52] It would read "Forward" rather than "Continue" [14:52] pitti: Hi! yes I'm going to take care of that bug this week. Thanks for the reminder! [14:52] but it does seem illogical to use stock labels for one thing and not another, in the same button bar [14:52] roaksoax: thank you! [14:52] maybe check with mpt? [14:55] our back/forward button handling doesn't look desperately consistent in general [14:55] @pilot in === udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin [14:55] In ext[4] rootfs, when is the "Last mount time" updated? Will it be updated on umount e.g. shutdown, or just mount/startup? [14:55] dpm, I don't know why the stock string was never changed. Probably because it was inappropriately shared with (for example) the navigation buttons in browsers, where you do want just "Back" and "Forward" [14:58] mpt, what do you think the best way to solve that bug and be consistent should be? Both stock buttons with shortcut, or both non-stock buttons? [15:01] dpm, I think the best way would be to make the keyboard combo for going to the next step Enter, and the keyboard combo for going to the previous step Esc. === chrisccoulson_ is now known as chrisccoulson [15:02] jibel: k, thx [15:04] mpt, cjwatson, that's probably a solution for +1, though, right? ^ Is there anything that can be done at this point in the cycle, or should the bug be wontfix for oneiric and precise? [15:06] pitti: any idea what in http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blob;f=libreoffice-common.postinst.in;h=f2995c1058c96f1ed123ac0d1211a7a75ac8f395;hb=d596b0cbdc3ce6e18ff0201c5dc6b231dfb13a4c could trigger bug 916291? I dont even see anything UNOy being touched there .... [15:06] Launchpad bug 916291 in libreoffice (Ubuntu Precise) "failed to upgrade from Oneiric to Precise: ERROR: Cannot determine language! - exit status 134" [High,Triaged] https://launchpad.net/bugs/916291 [15:07] Sweetshark: what does #INCLUDE_SHELL_LIB# expand to? [15:08] http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blob;f=shell-lib-extensions.sh;h=21dafe32323e261d0943bcb99cb2429b9aab0602;hb=d596b0cbdc3ce6e18ff0201c5dc6b231dfb13a4c [15:08] Sweetshark: btw, that postinst.in is wrong -- dpkg-maintscript-helper MUST NOT be placed within a $1 check [15:09] mpt: I thought that was in general the case anyway, but it's not very discoverable so people missed it [15:09] Sweetshark: well, in postinst you might get away with it, but it's still wrong conceptually [15:09] Sweetshark: as dpkg-maintscript-helper also does stuff on other values of $1 [15:09] Sweetshark: so, presumably it's the dpkg-trigger /@OODIR@/share/extensions [15:09] Sweetshark: which causes an unopkg call [15:09] Sweetshark: there might not be a locale set at this point? [15:10] or one that it doesn't like? [15:11] as for dpkg-maintscript-helper, that was cjwatson IIRC. [15:11] cjwatson, pitti: ubuntu veteran fight! [15:11] uh, no, but on the phone [15:11] cjwatson, if something isn't discoverable, I try to make it more discoverable before adding a second thing :-) [15:11] will get back to you in a bit [15:12] Sweetshark: for dpkg-maintscript-helper it's easiest to use debian/package.maintscript (see man dh_installdeb), that'll remove any remaining doubt; ) [15:12] Sweetshark: but anyway, it's not the cause for this bug, it just caught my eye [15:16] I thought that's what I suggested for LO [15:17] oh, no [15:17] it was a bit awkward I think [15:17] I think there were ordering concerns [15:18] hmm, so its that the share/extensions trigger (which I moved to -core) firing. However in the log provided from the jenkins-qa there does not seem to be any libreoffice-core action happening at all, so how can a trigger by it do any harm (shouldnt be there yet). [15:18] cjwatson: I suppose .maintscript expands into #DEBHELPER#? [15:28] pitti: yes [15:28] so that could just be moved earlier if necessary [15:28] pitti: .maintscript definitely isn't mandatory though - I converted dozens of packages, most of them could be handled with .maintscript, but a handful couldn't and I do think that's OK [15:29] cjwatson: oh, absolutely, I was just pointing out that it makes things easier [15:29] and I think it's better to not use .maintscript if the alternative is moving code around in ways that we aren't entirely certain of [15:29] cjwatson: the thing that is wrong is putting dpkg-maintscript-helper into an if [ $1 = ... ] [15:29] it might be harmless in a postinst (as at that point you can't roll back any more) [15:29] but it is actively breaking stuff in preinst and prerm [15:30] sure [15:30] contrary to what Sweetshark says though, I didn't put it there [15:30] the most you can pin on me is that I failed to move it out of there :) [15:31] my change was to remove 'dpkg-maintscript-helper supports' guards and the like, which do more harm than good [15:31] *nod* [15:31] Sweetshark: so, we violently agree :) [15:31] no fight, sorry [15:32] bah [15:32] * ogra_ puts away the popcorn [15:32] can anyone explain to me how "Select best server" works? Or better yet, just point me to the code. [15:35] * Sweetshark grabs ogra_ s popcorn and runs. [15:35] how can I test upgrade from lucid to precise ? [15:35] haha [15:36] can someone with a nvidia (either free or proprietary) run "python /usr/share/pyshared/debtagshw/opengl.py " and tell me the renderer string please? same for the fglrx driver please :) ? [15:37] (on precise I should add) [15:37] was just gonna say... [15:37] who's the language-selector expert? there are 2 mp's that have been sitting around for a while that i don't know how to evaluate (https://code.launchpad.net/~debfx/ubuntu/precise/language-selector/kubuntu/+merge/92967 and https://code.launchpad.net/~jincreator/ubuntu/precise/language-selector/korean/+merge/93535) [15:39] angeloc, ah, that's an artefact of the way Launchpad reports these things, I don't actually know anything about that package [15:39] angeloc, smspillaz might be a good person to talk to as he commented on the bug [15:39] pitti: what is the canonical way to find out if another package is installed in a postinst script? [15:41] Sweetshark: not sure whether there is THE canonical way, but I believe "dpkg -s coreutils | grep ^Status" should give you the status [15:41] Sweetshark: that'll tell you if it's uninstalled, unpacked, or configured [15:43] jibel: can you tell me if libreoffice-core was installed before this update was run, and if so at which version? [15:46] Sweetshark, from dpkg.log 1:3.4.4-0ubuntu1 was installed [15:47] Sweetshark, correction that's libreoffice-common [15:47] libreoffice-base-core was installed [15:47] 1:3.4.4-0ubuntu1 [15:47] jibel: but no libreoffice-core? [15:47] pitti: please don't use dpkg -s in a postinst [15:48] cjwatson: dpkg-query ok? [15:48] if you must, use dpkg-query instead, but I'm not certain it's reliable in a maintainer script [15:48] Sweetshark, and libreoffice-core 1:3.4.4-0ubuntu1 [15:48] I *think* these days it might be; it used to be that dpkg wasn't re-entrant, in that the status file on disk wasn't necessarily up to date [15:48] but generally if you have to do that it's the sign of a design error anyway [15:49] Sweetshark: does the "cannot determine language" error message correspond to any code in unopkg itself? it might check the locale which might be invalid during the dist-upgrade [15:50] Sweetshark, list of libreoffice-* packages installed before upgrade: http://paste.ubuntu.com/871618/ [15:53] pitti: unopkg uses a _lot_ of libreoffice infra. calling it halfway through the install is icky. [15:53] jibel: thanks. === dendrobates is now known as dendro-afk [15:53] Sweetshark: so perhaps the trigger should be made robust against failures, and the postinst configure then does another call (at a point when all dependencies are configured and unopkg has a better chance of working) [15:54] Sweetshark: in general, triggers can be (and often are) called when packages are unpacked but not configured [15:55] pitti: But I still wonder which trigger is actually called there: -common 3.4.4-0ubuntu1 should be gone, -common 3.5.0-2ubuntu1 has no does not provide a tigger action, it just fires it, -core 3.4.4-0ubuntu1 has no trigger action, -core 3.5.0-2ubuntu1 is not installed yet. so where does the trigger action come from? === dendro-afk is now known as dendrobates [16:00] pitti: so "the trigger should be made robust" *confused* which one? [16:04] mvo: ping [16:04] mvo: did you have a change to look over the edit-patch MP from yesterday? [16:05] mhall119: not yet, I will try to do it next [16:05] pitti: so what I would consider to do: in both -common and -core postinsts, check if we have both a 3.5.X -core and 3.5.0 -common and then and only then trigger the trigger. === dendrobates is now known as dendro-afk [16:06] Is it possible to locally build a package for oneiric from bzr branch on precise, using buildeb plugin ? === dendro-afk is now known as dendrobates [16:07] mvo: thanks, I'm working on a blog to get people using it for their quicklist and keyworkds submissions [16:08] jibel: is there a way to recreate that update scenario easily locally (in a VirtualBox or whatever)? [16:18] Sweetshark, you can restore the clone in a VM and reproduce from there [16:18] Sweetshark, http://10.189.74.2:8080/view/Precise%20Upgrades/job/precise-upgrade-oneiric-universe/ARCH=amd64,LTS=non-lts,PROFILE=universe,label=upgrade-test/44/artifact/universe-amd64/apt-clone_system_state.tar.gz [16:19] Sweetshark, hm, try https://jenkins.qa.ubuntu.com/job/precise-upgrade-oneiric-universe/ARCH=amd64,LTS=non-lts,PROFILE=universe,label=upgrade-test/44/artifact/universe-amd64/apt-clone_system_state.tar.gz instead [16:34] * Sweetshark just recognized again how awesome mutt is. [16:35] when you edit a mail (what I just did in my todo-folder), it marks the old mails as deleted an creates a new one, thus not confusing other clients. [16:40] mterry: ping [16:40] shadeslayer, yo [16:41] mterry: hey hey! [16:41] mterry: https://bugs.launchpad.net/ubuntu/+source/openal-soft/+bug/586324 [16:41] Launchpad bug 586324 in openal-soft (Ubuntu) "[MIR] openal-soft" [Undecided,Incomplete] [16:41] mterry: I'm almost done generating the symbols file and uploading a package to my PPA, could you upload it to the archives? [16:42] ( I don't have upload rights just yet, working on fixing that ;) ) === albrigha is now known as Guest32450 [16:42] mterry: packages should appear here : https://launchpad.net/~rohangarg/+archive/experimental [16:43] shadeslayer, ok. will check back after lunch if they are done building === Guest32450 is now known as albrigha [16:43] mterry: thanks! [16:43] shadeslayer, thanks for patching! :) [16:43] :) [16:43] derp [16:44] that PPA is full [16:47]