| === L3top is now known as WhiteDynamite | ||
| === WhiteDynamite is now known as L3top | ||
| slangasek | broder: blast, follow-up to bug #858122 shows that I missed /etc/rc6.d/S35networking... not sure how important that is | 02:18 |
|---|---|---|
| ubottu | Launchpad bug 858122 in insserv (Ubuntu Oneiric) "incomplete migration to /run (shutdown script order has been demolished)" [High,Fix committed] https://launchpad.net/bugs/858122 | 02:18 |
| === dendro-afk is now known as dendrobates | ||
| === pp7 is now known as malkauns | ||
| L3top | anyone got an explanation why deb mirror://mirrors.ubuntu.com/mirrors.txt lucid main restricted universe multiverse might throw CD-ROM errors? | 03:45 |
| L3top | no cd references in the sources.list | 03:46 |
| L3top | nm... nothing to do with the mirrors. | 04:10 |
| broder | slangasek: i bet there are unfortunate nfs interactions | 05:38 |
| pitti | Good morning | 06:07 |
| ajmitch | morning pitti | 06:17 |
| hrw | hi | 07:00 |
| hrw | can we change one thing related to compatibility with lts? Lucid has libmpfr1ldbl package which is present in all next releases up to oneiric (which lacks it). This way packages built for lucid (aka 'last LTS') work on maverick/natty but fail to install on oneiric ;( | 07:22 |
| hrw | would be nice to have such compatibility for all <(lts+1) releases | 07:23 |
| micahg | hrw: the source was removed | 07:23 |
| micahg | not in Debian either | 07:23 |
| hrw | micahg: Debian has longer release time | 07:24 |
| hrw | micahg: to provide binaries for oneiric I need now bump 8 packages versions, build them in order - with ppa builders queue it will take another 3 days | 07:25 |
| micahg | hrw: it's not in squeeze | 07:25 |
| hrw | or will grab older mprf from lucid and recompile under oneiric and check will it work | 07:25 |
| hrw | ok | 07:26 |
| micahg | hrw: ah, was migrated to mpfr4 | 07:26 |
| hrw | micahg: maverick migrated to mpfr4 but kept old version. | 07:27 |
| hrw | in oneiric it got dropped | 07:27 |
| micahg | right, until the migration was complete | 07:27 |
| micahg | hrw: if there are specific LTS -> LTS upgrade issues, we can address those, but we won't add back the old source | 07:28 |
| hrw | micahg: I am fine with lack of old library in new lts. I complain about lack of in in lts-1 | 07:28 |
| micahg | hrw: we remove libraries basically when Debian does unless we need them for something, it was removed for squeeze, so we removed it for oneiric | 07:29 |
| micahg | hrw: is something specific broken in oneiric because of this? | 07:29 |
| micahg | the only thing we try to guarantee between upgrades is a stable upgrade path, not that a specific version of something is available | 07:31 |
| infinity | hrw: Keeping libraries around just so people only need to build a binary once for 4 releases isn't sane. | 07:31 |
| infinity | hrw: There's a reason the PPAs build for all releases. | 07:31 |
| infinity | hrw: If you want to provide oneiric packages, build them on oneiric. | 07:31 |
| micahg | I'm wondering why the packages are needed in the first place unless something outside the archive was using it | 07:32 |
| infinity | micahg: That's what he's saying. He wants to build on lucid and have it work on lucid->oneiric, so yes, not archive packages. | 07:33 |
| micahg | well, we generally don't advise that anyways AIUI, each release usually brings toolchain improvements and extra security hardening | 07:34 |
| hrw | micahg, infinity: if package build for lucid works under next releases then why bother with rebuilding? | 07:36 |
| hrw | and toolchain improvements are not something important for cross toolchain backport | 07:36 |
| infinity | hrw: No one's saying you must rebuild it if it works. We don't rebuild things "just cause" either. | 07:37 |
| infinity | (There are still packages in precise that were built on natty) | 07:37 |
| hrw | yep | 07:37 |
| micahg | although in the above case we probably should to pick up --as-needed :) | 07:37 |
| infinity | But we're not going to guarantee compatibility like you're asking for, that's all. | 07:37 |
| hrw | infinity: ok | 07:37 |
| infinity | micahg: It'll all get rebuilt in time. *shrug* | 07:38 |
| infinity | micahg: Most of us don't like gratuitous archive/mirror churn for tiny gains. | 07:38 |
| micahg | well, we still have packages from warty :) | 07:38 |
| hrw | building mpfr under oneiric now - will provide it in ppa | 07:38 |
| infinity | hrw: Why would you do that? | 07:38 |
| infinity | hrw: Why not just build your package against the new library? | 07:39 |
| micahg | sure, not for gratuitous purposes, but some packages can really simplify the dependency change | 07:39 |
| micahg | infinity: you just answered that question when I asked it :) | 07:39 |
| hrw | infinity: it took me 3 days of building for lucid | 07:39 |
| hrw | infinity: with 21h queues I prefer to build one instead of 8 | 07:40 |
| infinity | (The PPA queues are empty right now) | 07:40 |
| hrw | ok, worth try | 07:40 |
| hrw | be back in 1h | 07:44 |
| === smb` is now known as smb | ||
| dholbach | @pilot in | 08:48 |
| === udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect. 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: dholbach | ||
| dholbach | can somebody please reject https://code.launchpad.net/~l3on/ubuntu/precise/rawstudio/fix-ftbfs/+merge/94701 - the bug in question was solved differently already | 09:03 |
| === doko_ is now known as doko | ||
| pitti | done | 09:21 |
| === tkamppeter_ is now known as tkamppeter | ||
| dholbach | thanks pitti | 09:35 |
| hrw | can someone push vwstreams to archive to get it built on armel/armhf? This will make wvdial buildable on armhf. I built both on mx53/armel in armhf chroot. | 09:54 |
| Sweetshark | dholbach: Hey! If I forget to say that to jono when he is back online, please say a big thanks to jono for his kudos to LibreOffice. | 10:00 |
| dholbach | Sweetshark, you could comment on his blog post! ;-) | 10:01 |
| dholbach | but yeah I have a call with him later on and if I don't forget it, I'll let him know :) | 10:01 |
| pitti | hrw: what do you mean by "push to archive"? | 10:01 |
| dholbach | Sweetshark, how is your upload rights application coming together? | 10:01 |
| mpt | mvo, I got "Not all updates can be installed" and "Do you want to start the upgrade?" dialogs opening at the same time. Does that mean I should upgrade, or not? :-) | 10:02 |
| dholbach | pitti, could it be it never built for armel/armhf? | 10:02 |
| pitti | https://launchpad.net/ubuntu/+source/wvstreams/4.6.1-2build1 | 10:02 |
| pitti | it didn't | 10:02 |
| pitti | but even doko's rebuild didn't | 10:02 |
| pitti | so a mere rebuild won't help; not sure why | 10:03 |
| micahg | pitti: http://bazaar.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu/view/head:/Packages-arch-specific#L276 | 10:03 |
| doko | hrw, pitti: needs porting, and now it's in P-a-S. do you volunteer? | 10:04 |
| pitti | right, was just looking there | 10:04 |
| pitti | doko: hrw says it's working for him? | 10:04 |
| micahg | Debian seems to be building wvdial on armhf at least | 10:05 |
| hrw | p-a-s? | 10:05 |
| Sweetshark | dholbach: I google+ shared his blog with a big thanks already. | 10:05 |
| pitti | hrw: it's an architecture blacklist for packages which don't limit the architectures in debian/control | 10:05 |
| dholbach | Sweetshark, ah cool | 10:05 |
| hrw | pitti: thx | 10:05 |
| pitti | infinity: can we just change Packages-arch-specific, or is this still fully in sync with Debian? | 10:06 |
| mvo | mpt: *urgh* could you make a screenshot please and show it to me? | 10:06 |
| Sweetshark | dholbach: not much happening with the application. but didrocks did a upload for me, so he might comment on that too, once he finished answering "where is my workspace switcher?" questions ... | 10:07 |
| micahg | if someone's rebuilding wvstreams, can you drop the Qt package, it's unused and built against qt3 | 10:07 |
| hrw | I never owned normal modem so have no knowledge of wvdial and how to use/test it. Just saw that it is in ftfbs queue for armhf so decided to take a look | 10:07 |
| dholbach | Sweetshark, all the best with the application then :) | 10:07 |
| mpt | mvo, http://i.imgur.com/oBotI.png | 10:10 |
| mvo | mpt: this is indeed pretty ugly | 10:12 |
| mpt | mvo, anything you want me to capture before I click "Cancel"? | 10:12 |
| mvo | mpt: no, thanks. but if you could run "apt-get dist-upgrade --simulate -o Debug::pkgProblemResolver=true" and paste/mail me the output, that would be nice | 10:13 |
| seb128 | mvo, mpt: hey, while you are around, small question, is the fact the update-manager standard "install upgrades" dialog keep resizing according to the package name length, known/going to be worked this cycle? | 10:14 |
| mpt | mvo, nothing informative: http://paste.ubuntu.com/858969/ | 10:15 |
| mpt | seb128, I doubt it -- mvo is pretty busy, :-) and update-manager doesn't attract volunteers for reasons I haven't figured out yet | 10:16 |
| seb128 | mpt, what would be the fix for that? just ellipsize the package names...? | 10:17 |
| mvo | mpt: that is confusing, its giving a error that it can not install all updates first, but apt-get does not show any trace of this :/ | 10:17 |
| mvo | seb128: the download/install dialog? in the release upgrader ? or for regular updates? | 10:17 |
| seb128 | mvo, regular updates | 10:17 |
| seb128 | mvo, the one which makes "downloading <package>" | 10:18 |
| mpt | seb128, I think you're right, just ellipsizing the name | 10:18 |
| seb128 | mvo, it's width change with the <package> string length | 10:18 |
| seb128 | mvo, which makes lot of bouncing, especially on the "unpackaging" steps | 10:18 |
| seb128 | unpacking | 10:18 |
| seb128 | mpt, thanks, that seems trivial enough, I might have a look if mvo doesn't ;-) | 10:19 |
| mvo | seb128: ok, that should be straightforward indeed, aptdaemon is the package | 10:19 |
| mvo | seb128: maybe a gtk3 regression | 10:19 |
| seb128 | mvo, ...!!! | 10:20 |
| mvo | seb128: self.set_ellipsize(Pango.EllipsizeMode.END) is in the code | 10:20 |
| seb128 | mvo, I will have a look, thanks | 10:20 |
| seb128 | mvo, mpt: sorry I didn't mean to hijack your discussion | 10:20 |
| mvo | seb128: thanks, look at lp:aptdaemon and there aptdaemon/gtk3widgets.py in AptProgressBar | 10:22 |
| pitti | ev: hm, bug 901675 seems to be from introducing threading into the GTK GUI :/ | 10:22 |
| ubottu | Launchpad bug 901675 in apport (Ubuntu) "apport-gtk assert failure: python: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed." [Medium,Confirmed] https://launchpad.net/bugs/901675 | 10:22 |
| seb128 | mvo, thanks | 10:22 |
| pitti | ev: can we avoid using GTK from more than one thread? | 10:22 |
| mvo | seb128: maybe something missing there | 10:22 |
| mpt | mvo, unfortunately it's not reproducible -- second time I tried it I just got the "Do you want to start the upgrade?" | 10:23 |
| mvo | mpt: there must be a law or something that bugs are 10x harder to reproduce for developers or something :/ but thanks a bunch for letting me know about it | 10:24 |
| mpt | mvo, if all three of those windows were a single window, the bug would be fixed one way or another :-) | 10:25 |
| seb128 | ups | 10:26 |
| seb128 | mvo, I wonder if that's because you don't force any max geometry on the dialog, so rather than ellipsizing it just shows to resize | 10:29 |
| seb128 | mvo, i.e you " self.progress.set_size_request(350, -1)" but I don't think set_size_request block it to upscale | 10:29 |
| dholbach | pitti, regarding bug 940566 it seems like libquvi-scripts will need a MIR :-/ | 10:33 |
| ubottu | Launchpad bug 940566 in libquvi (Ubuntu) "FFe: Sync libquvi 0.4.0-1 (main) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/940566 | 10:33 |
| mvo | seb128: oh, that could well be it | 10:34 |
| pitti | dholbach: was this a splitout like "quvi", or a new build dep? | 10:34 |
| ansgar | pitti: Also splitout. | 10:35 |
| pitti | that's fine then | 10:35 |
| dholbach | ok | 10:35 |
| dholbach | then I'll go ahead with the sync and everything around it | 10:35 |
| dholbach | thanks pitti, thanks ansgar | 10:35 |
| pitti | mvo: do you see what apt complains about in https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-oneiric-universe/lastFailedBuild/ARCH=amd64,LTS=non-lts,PROFILE=universe,label=upgrade-test/artifact/universe-amd64/apt.log ? | 10:37 |
| pitti | mvo: libcv-dev was split into several packages, which breaks:/replaces: the older versions; this seems not unusual to me | 10:37 |
| dholbach | seb128, didrocks, did you have a chance to talk to mhall119 about the quicklist additions? | 10:39 |
| seb128 | dholbach, yes | 10:39 |
| seb128 | dholbach, and to jono | 10:39 |
| dholbach | I'm on duty as patch pilot today and wonder what to do about the merge proposals | 10:39 |
| seb128 | dholbach, which ones ? | 10:40 |
| seb128 | dholbach, if that's universe we agreed to postpone those to next cycle and discuss at UDS | 10:40 |
| dholbach | http://reqorts.qa.ubuntu.com/reports/sponsoring/ ← all the ones saying "add_quicklist" | 10:40 |
| pitti | mvo: in general, what do you look out for first in these logs? "Holding back" lines? | 10:40 |
| seb128 | dholbach, let me review those | 10:41 |
| pitti | Riddell, mvo: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-oneiric-universe/lastFailedBuild/ARCH=amd64,LTS=non-lts,PROFILE=universe,label=upgrade-test/artifact/universe-amd64/apt.log also seems to have trouble with replacing koffice-data (which has zero rdepends left) wit calligra-data; would it help to move "Conflicts: kformula, koffice-data" to "Breaks: kformula, koffice-data"? | 10:42 |
| pitti | I still don't understand why apt is so hesitant to remove a package which doesn't even exist any more and has no rdepends | 10:43 |
| mvo | pitti: I usually start by looking at the last few lines and walk my way backwards to figure out what exactly is going on | 10:43 |
| pitti | and holds it back instead of replacing it with the superseding pacakge | 10:43 |
| Riddell | pitti, mvo: or should we just make transitional packages? | 10:43 |
| pitti | Riddell: seems a little exaggerated for -data packages to me; but perhaps Breaks: will help | 10:43 |
| Riddell | yes | 10:44 |
| pitti | but still, it seems to me that apt is overly picky here | 10:44 |
| smb | pitti, Hm, apport retracer just marked a crash I had this morning as a duplicate of a bug expired two months ago and then got rid of all the evidence... That seems a bit unhelpful to me... :/ | 10:44 |
| mvo | transitional will fix it for sure, the log shows that the "score" of koffice-data is 4 but calligra-data:amd64 only 3 - if its a 1-to-1 exchange of the name the score should be equal and if koffice-data is no longer in the archive it gets a penality | 10:45 |
| pitti | smb: can you please file a bug against apport for this and assign to me? I guess it doesn't handle the "Expired" state, it's relatively new | 10:45 |
| mvo | pitti: its a tradeoff, its hard for apt to know what is important to the user but yeah, in this case its not doing the right thing | 10:45 |
| mvo | Installing koffice-data as Depends of koffice-libs | 10:46 |
| mvo | looks odd | 10:46 |
| pitti | mvo: oh, where do you see the score? | 10:46 |
| smb | pitti, Ok, will do. thanks | 10:46 |
| mvo | pitti: its the integer in the following lines: | 10:46 |
| mvo | Considering koffice-data:amd64 4 as a solution to calligra-data:amd64 3 | 10:46 |
| mvo | eh, line | 10:46 |
| mvo | sorry, I know that the output is really hard to read | 10:46 |
| pitti | mvo: koffice-libs is also gone, hmm | 10:46 |
| mvo | Installing koffice-libs as Depends of kpresenter | 10:47 |
| mvo | was the transition still in progress when this happend maybe? | 10:47 |
| pitti | hm, I think kpresenter and friends should have a transitional package | 10:47 |
| pitti | it went away as well | 10:47 |
| pitti | which probably causes the upgrade confusion | 10:48 |
| pitti | mvo: no, that test upgrade is very recent | 10:48 |
| mvo | pitti: odd, if its just a transitional package, why would it cause the libs to get installed | 10:48 |
| pitti | Riddell: so it should help to add transitional packages for the applications like kpresenter | 10:48 |
| pitti | mvo: it's not; kpresenter was also dropped apparently | 10:48 |
| pitti | so the existing kpresenter package keeps koffice-{libs,data} | 10:49 |
| pitti | Riddell: hm, is there a calligra equivalent for kpresenter? | 10:50 |
| Riddell | yes | 10:50 |
| Riddell | calligrastage | 10:50 |
| pitti | Riddell: so we'll need a transitional package for at least that one | 10:51 |
| Riddell | ok, can do | 10:51 |
| pitti | for kspread apparently as well | 10:51 |
| Riddell | pitti: why that one? | 10:51 |
| pitti | and kword | 10:51 |
| Riddell | all the apps? | 10:51 |
| pitti | Riddell: these are top-level application packages that users have installed | 10:51 |
| pitti | which need to be transitioned to their equivalent of calligra | 10:51 |
| pitti | otherwise apt woudln't know what to do and just keep them instead of upgrading | 10:52 |
| pitti | Riddell: want a bug report for it? | 10:52 |
| Riddell | pitti: a bug is handy yes | 10:53 |
| Riddell | pitti: but there are other applications in koffice, don't they need transitionals too? | 10:53 |
| pitti | Riddell: yes | 10:53 |
| pitti | ah, bug 915431 | 10:53 |
| ubottu | Launchpad bug 915431 in calligra (Ubuntu) "kexi can not be dist-upgraded" [Undecided,New] https://launchpad.net/bugs/915431 | 10:53 |
| pitti | I'll generalize this | 10:53 |
| Riddell | thanks | 10:54 |
| pitti | mvo: ok, that covers calligra; I'm still baffled whaht's going on with the opencv stuff | 10:54 |
| mvo | Considering libopencv-features2d-dev:amd64 8 as a solution to libcv-dev:amd64 1 | 10:55 |
| dholbach | rickspencer3, hey - how are you doing? | 10:56 |
| mvo | that seems to be the crucial bit | 10:56 |
| rickspencer3 | hi dholbach | 10:56 |
| rickspencer3 | doing well | 10:56 |
| dholbach | rickspencer3, I noticed the quickly patches in the sponsoring queue (929417, 929572, 929420) - how do you want to go about them? | 10:56 |
| rickspencer3 | hi dholbach funny you should mention tat | 10:57 |
| rickspencer3 | I'm working on 929417 at this very moment | 10:57 |
| rickspencer3 | dholbach_, for the others, could you please ask didrocks/mterry in #quickly? | 10:57 |
| dholbach_ | sorry, just had the network kick me out | 10:58 |
| mvo | pitti: hm, no, actually "Broken libopencv-features2d-dev:amd64 Depends on libopencv-highgui-dev [ amd64 ] < none -> 2.3.1-7 > ( universe/libdevel ) (= 2.3.1-7)" | 10:58 |
| dholbach_ | rickspencer3, I noticed the quickly patches in the sponsoring queue (929417, 929572, 929420) - how do you want to go about them? | 10:58 |
| dholbach_ | rickspencer3, merge them upstream, roll a release, then get it in precise? | 10:58 |
| dholbach_ | sure | 10:58 |
| dholbach_ | thanks | 10:58 |
| didrocks | rickspencer3: dholbach_: I'm piloting on wednesday, I planned to review them by then | 10:58 |
| rickspencer3 | thanks didrocks | 10:58 |
| rickspencer3 | didrocks, I'll strive to get the tutorial updated by then | 10:59 |
| didrocks | thanks rickspencer3 ;) | 10:59 |
| mvo | pitti: and that leads to "Broken libopencv-highgui-dev:amd64 Depends on libjpeg-dev [ amd64 ] < none > ( none )" and that to "Broken r-base-dev:amd64 Depends on libjpeg-dev [ amd64 ] < none > ( none )" which seems to be the root of it | 11:00 |
| pitti | Riddell: I updated bug 915431, and added a list of all (hopefully) missing transitionals | 11:00 |
| ubottu | Launchpad bug 915431 in calligra (Ubuntu Precise) "needs transitional packages for old koffice application names" [High,Triaged] https://launchpad.net/bugs/915431 | 11:00 |
| pitti | jibel: ^ FYI (I think I tagged it as you do) | 11:00 |
| === dholbach_ is now known as dholbach | ||
| pitti | mvo: we so much need to graphviz-ize this :) | 11:01 |
| mvo | pitti: oh yes! | 11:01 |
| jibel | pitti, excellent. thanks! | 11:02 |
| pitti | mvo: oh, thanks! so if we just fix that dependency, it shoudl be better | 11:02 |
| pitti | mvo: odd, I thought that libjpeg62-dev and libjpeg8-dev ought to Provide: libjpeg-dev, but seems they don't | 11:02 |
| mvo | pitti: there is some fishy stuff here "Broken libjpeg-turbo8-dev:amd64 Conflicts on libjpeg62-dev [ amd64 ] < 6b1-1ubuntu2 -> 6b1-2ubuntu1 > ( libdevel )" too | 11:02 |
| micahg | pitti: no, having both libjpeg*-dev packages provide libjpeg-dev creates depwaits | 11:03 |
| mvo | pitti: it maybe enough to have a addition "provides: libjpeg62-dev" in libjpeg-utrbo8-dev" - but I don't know why we have the two different ones and why they conflict etc | 11:05 |
| smb | pitti, bug 941854 | 11:05 |
| soren | Uh oh.. | 11:05 |
| ubottu | Launchpad bug 941854 in apport (Ubuntu) "Apport retraces marks bug report a duplicate of an expired bug" [Undecided,New] https://launchpad.net/bugs/941854 | 11:05 |
| pitti | smb: thanks | 11:05 |
| soren | http://archive.ubuntu.com/ubuntu/dists/oneiric/Release has checksums for Packages and Sources files (uncompressed ones), but they're missing for at least Oneiric. | 11:06 |
| soren | It makes my sbuild really unhappy and my tiny brain really confused. | 11:06 |
| micahg | mvo: that would be wrong though as libjpeg-turbo8-dev doesn't provide libjpeg62-dev | 11:06 |
| pitti | mvo: oh, indeed -- libjpeg-turbo8-dev provides our libjpeg-dev, so I wonder why it's not just installing that one | 11:06 |
| soren | Could they have gone missing or were they never there? | 11:06 |
| mvo | micahg: hm, good point - so " Installing libjpeg-turbo8-dev as Depends of libopencv-highgui-dev" - does that really need this paritcular jpeg lib or could it just pick libjpeg-dev instead? | 11:08 |
| micahg | mvo: it's asking for libjpeg-dev | 11:08 |
| micahg | which is provided by libjpeg-turbo8-dev | 11:09 |
| pitti | so we should fix all remaining reverse dependencies of libjpeg62-dev? | 11:10 |
| pitti | we even have three packages in main which b-dep on libjpeg62-dev, | 11:11 |
| mvo | micahg: aha, that explains it and libjpeg62-dev does not provide libjpeg-dev so it picks the other one. | 11:11 |
| pitti | such as compiz-plugins-main | 11:11 |
| pitti | didrocks: ^ is that an oversight, or does it really fail with libjpeg8? | 11:11 |
| mvo | so the new libjpeg-dev is libjpeg-turbo8-dev is that the summary? | 11:12 |
| micahg | for precise, yes | 11:12 |
| mvo | ta | 11:12 |
| didrocks | pitti: i think this dep comes from 0.8 area | 11:13 |
| micahg | pitti: it's just the dev packages that aren't co-installable, the binaries are fine, maybe we just need to make the upgrader smarter about this | 11:13 |
| mvo | so that is the root of the problem then: " Considering libjpeg62-dev:amd64 0 as a solution to libjpeg-turbo8-dev:amd64 -1 | 11:14 |
| mvo | Holding Back libjpeg-turbo8-dev:amd64 rather than change libjpeg62-dev:amd64" this transition is not working and that causes the other havoc | 11:14 |
| didrocks | so can probably be tried with a newer one, care to open a bug and assign me so that I test? (we will have soon a new compiz upload) | 11:14 |
| soren | mvo: Any idea why "apt-get update" would attempt to fetch uncompressed Packages and Sources files? | 11:14 |
| pitti | micahg: hm, the only package which explicitly depends: (not build-deps) on libjpeg62-dev is libspandsp-dev | 11:14 |
| pitti | and that doesn't even appear on https://launchpadlibrarian.net/94128035/apt.log | 11:14 |
| mvo | soren: it might to that as a fallback if it can not find any compressed ones or any compressor (but the later is really odd) | 11:15 |
| pitti | micahg: nevertheless, if people have it installed, then it breaks upgrades | 11:15 |
| soren | mvo: In the former case, I should see it trying to fetch the compressed ones and failing somehow? | 11:15 |
| micahg | pitti: right, so maybe we should just make the upgrader smarter and remove it or replace it (perhaps even with a warning) | 11:16 |
| mvo | one thing we could do is to play with the priority, e.g. libjpeg62-dev becoming extra will be one less point for it | 11:16 |
| pitti | but there's > 20 universe packages with Depends: libjpeg-dev, and as this isn't actually wrong, moving them all to libjpeg8-dev sounds just wrong to me | 11:16 |
| mvo | soren: yeah, you should see in the apache logs that it tries to hit the compressed ones first | 11:16 |
| micahg | pitti: right, we want the build-depends to be libjpeg-dev to make transitions easier (like Debian) | 11:17 |
| pitti | micahg: no, binary depends I mean | 11:17 |
| pitti | micahg: i. e. foo-dev depends: libjpeg-dev | 11:17 |
| pitti | which still looks right to me | 11:17 |
| micahg | yeah, that's right too :) | 11:17 |
| mvo | yeah, we should not change them if possible, it looks like the score code in apt is not taking the fact into account that the provides changes between the two packages | 11:17 |
| pitti | Broken libmng-dev:amd64 Depends on libjpeg-dev [ amd64 ] < none > ( none ) | 11:17 |
| pitti | Considering libjpeg62-dev:amd64 235 as a solution to libmng-dev:amd64 4 | 11:18 |
| pitti | Removing libmng-dev:amd64 rather than change libjpeg-dev:amd64 | 11:18 |
| pitti | mvo: ^ with a score like that (235), one more or less hardly seems to make a difference? | 11:18 |
| pitti | oh, hang on | 11:18 |
| pitti | Considering libjpeg62-dev:amd64 0 as a solution to libjpeg-turbo8-dev:amd64 -1 | 11:18 |
| mvo | pitti: yeah, that was the line I was looking at | 11:19 |
| pitti | there the difference is -1, but would "extra" help here? | 11:19 |
| soren | mvo: Awesome, thanks. | 11:19 |
| mvo | yeah, that might help then but apt will still prefer installed packages over new ones, so it may not be good enough | 11:19 |
| soren | mvo: Turns out I had a screwed up approx cache. | 11:19 |
| mvo | soren: ok | 11:20 |
| pitti | it seems feasible to drop all remaining explicit libjpeg62-dev dependencies; would that help, if we remove it from the archive? or doesn't the upgrader look at thaht anyway? | 11:21 |
| tkamppeter | pitti, hi | 11:21 |
| pitti | hello tkamppeter | 11:21 |
| tkamppeter | pitti, it is about bug 938669. | 11:22 |
| ubottu | Launchpad bug 938669 in upstart (Ubuntu) "Can not increase MaxClients in cups (Max clients reached, holding new connections...)" [Undecided,New] https://launchpad.net/bugs/938669 | 11:22 |
| pitti | mvo: would it help if libjpeg-turbo built a real libjpeg-dev package? | 11:23 |
| pitti | these purely virtual dependencies are prone to failure anyway | 11:23 |
| tkamppeter | pitti, should we do as the user suggested, adding the line "limit nofile 4096 4096" to /etc/init/cups.conf or should there be fixed something on upstart, for example supporting /etc/security/limits.conf? | 11:23 |
| mvo | pitti: yeah, I think that should work | 11:24 |
| pitti | tkamppeter: this doesn't sound like an upstart bug | 11:24 |
| pitti | tkamppeter: the default limit is set by pam | 11:24 |
| apw | jodh, i have a report of a machine which is hanging during boot, after upstart has started, now --debug is puking too much so i loose output. any suggestions on how to debug ? | 11:25 |
| pitti | doko: are you ok with me adding a real libjpeg-dev package to libjpeg-turbo, to unbreak upgrades? | 11:25 |
| doko | pitti: maybe in the libjepg-empty source? | 11:27 |
| pitti | doko: libjpeg-empty doesn't seem to exist? | 11:27 |
| doko | libjpeg8-empty | 11:27 |
| pitti | ah, got it | 11:27 |
| pitti | doko: yep, fine for me | 11:28 |
| pitti | doko: it would then get a much higher version number then, though | 11:29 |
| pitti | doko: but I guess that's ok? | 11:29 |
| jodh | apw: What's the last message it displays? You could try '--verbose' for less spew. What version of | 11:29 |
| jodh | Upstart is it? Is the hang repeatable? Any new jobs installed recently? | 11:29 |
| jodh | 11:29 | |
| apw | i believe this is latest precise, but not confirmed as they are resisting filing a bug as usual | 11:29 |
| apw | yes its repeatable, hard to tell what might have started recent as the console is a mess of mixed messages | 11:29 |
| tkamppeter | pitti, does this mean that the bug needs to get assigned to PAM? | 11:29 |
| pitti | tkamppeter: I'm still not sure it is a bug | 11:30 |
| pitti | tkamppeter: the default limits are quite sensible | 11:30 |
| pitti | tkamppeter: if you have a special case where thousands of connections are made, then the admin can set this locally | 11:30 |
| jodh | apw: can you get a dump/screenshot of the console though? | 11:30 |
| apw | jodh, what was the nolog option, --no-log or --nolog ? | 11:30 |
| jodh | apw: '--no-log' | 11:30 |
| pitti | doko: I see, I agree that -empty makes more sense | 11:30 |
| micahg | pitti: it needs to go in libjpeg8-empty or it won't be a viable upgrade from version 6ubuntu* or libjpeg62 (which I assume is the same conclusion you just came to) | 11:31 |
| pitti | micahg: it doesn't matter for that as the package has always been virtual, and thus lower than any real package | 11:32 |
| pitti | micahg: but conceptually -turbo is just an implementation detail | 11:32 |
| pitti | I think -empty shoudl build a libjpeg-dev that (currently) depends on libjpeg8-dev | 11:32 |
| pitti | mvo: thanks muchly for your help! I uploaded a fix now | 11:34 |
| mvo | pitti: awsome, thank you | 11:35 |
| mvo | pitti: I get some lunch now | 11:35 |
| apw | jodh, ok here is the log they have with --verbose: http://sprunge.us/BiSi | 11:35 |
| apw | jodh, see anyting indicative ? | 11:35 |
| apw | jodh, am i right in thinking that procps is stuck in 'post-start' | 11:38 |
| jodh | apw: actually, probably not - procps doesn't have a post-start by | 11:41 |
| jodh | default (although check to see if someone added this to the system in | 11:41 |
| jodh | question). I'm wondering if sysctl is hanging here. Try "echo | 11:41 |
| jodh | manual|sudo tee /etc/init/procps.override" and reboot. | 11:41 |
| * doko is staring at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661424 ... | 11:45 | |
| ubottu | Debian bug 661424 in icedtea-netx "icedtea-netx: warning on upgrade - binary operator expected" [Normal,Open] | 11:45 |
| === _salem is now known as salem_ | ||
| ansgar | doko: Maybe the `...` returns something including whitespace? | 11:51 |
| ansgar | doko: [ -z foo bar ] -> bash: [: foo: binary operator expected | 11:52 |
| pitti | dholbach: hm, you didn't sync quvi and libquvi-scripts and cclive, right? or did I look into the wrong queue? | 11:52 |
| micahg | doko: does the shell | 11:52 |
| micahg | doko: does the shell's return output need to be quoted | 11:52 |
| dholbach | pitti, I'm happy to do it - I thought I'd wait for libquvi to get in first, no? :) | 11:53 |
| pitti | dholbach: sounds fine, as long as it doesn't need the others for building | 11:54 |
| dholbach | pitti, libquvi-scripts is the most recent - cclive I can sync as it will likely DEPWAIT | 11:55 |
| pitti | dholbach: ah, then it sounds you could as well sync it now | 11:55 |
| dholbach | pitti, cclive and quvi synced now too - thanks for looking it up and letting me know | 11:59 |
| * pitti hugs dholbach, danke | 11:59 | |
| * dholbach hugs pitti back | 11:59 | |
| fraviofii | hello, Is it possible to have an ubuntu-core for arm-v4? Can I prepare it myself? | 12:02 |
| tkamppeter | pitti, can you comment on bug 938669? | 12:12 |
| ubottu | Launchpad bug 938669 in upstart (Ubuntu) "Can not increase MaxClients in cups (Max clients reached, holding new connections...)" [Undecided,New] https://launchpad.net/bugs/938669 | 12:12 |
| pitti | tkamppeter: will do after lunch | 12:13 |
| === zimmerle` is now known as zimmerle | ||
| === MacSlow is now known as MacSlow|lunch | ||
| mpt | "One or more running instances of xscreensaver or xlockmore have been detected on this system. Because of incompatible library changes, the upgrade of the GNU libc library will leave you unable to authenticate to these programs. You should arrange for these programs to be restarted or stopped before continuing this upgrade, to avoid locking your users out of their current sessions." | 12:44 |
| mpt | How do I restart/stop xscreensaver without being logged out and therefore cancelling the upgrade? :-) | 12:45 |
| tjaalton | mpt: killing the screensaver shouldn't log you out | 12:51 |
| dholbach | @pilot out | 12:53 |
| === udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect. 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: | ||
| tjaalton | uh, ppa build queue 6h? | 13:03 |
| pitti | some of the PPA builders were taken offline to do other things apparently | 13:25 |
| tjaalton | yeah | 13:26 |
| jelmer | hi tjaalton | 13:35 |
| tjaalton | jelmer: hi | 13:36 |
| zul | mterry: ping | 13:54 |
| mterry | zul, hi | 13:55 |
| zul | mterry: i have a couple of MIR that i just filed that is blocking nova from buidling s bug #941920, bug #941916, and bug #941913 can we get them taken care of today? they are pretty easy they are just python modules and they should all be ready | 13:56 |
| ubottu | Launchpad bug 941920 in python-iso8601 (Ubuntu) "[MIR] python-iso8601" [Undecided,New] https://launchpad.net/bugs/941920 | 13:56 |
| ubottu | Launchpad bug 941916 in python-tz (Ubuntu) "[MIR] python-tz" [Undecided,New] https://launchpad.net/bugs/941916 | 13:56 |
| ubottu | Launchpad bug 941913 in python-babel (Ubuntu) "[MIR] python-babel" [Undecided,New] https://launchpad.net/bugs/941913 | 13:56 |
| mterry | zul, will look | 13:58 |
| zul | mterry: thanks! | 13:58 |
| mpt | tjaalton, you were right, thanks :-) | 14:05 |
| tjaalton | mpt: np :) | 14:06 |
| === MacSlow|lunch is now known as MacSlow | ||
| === bladernr_afk is now known as bladernr_ | ||
| === dendrobates is now known as dendro-afk | ||
| Daviey | mterry: for info, these are beta release critical issues. :/ Thanks | 14:22 |
| geser | pitti: is there a (good) reason to keep postgresql-9.0 (universe) in the archive while we have postgresql-9.1 in the archive too? | 14:23 |
| pitti | geser: uh, no; I thought I already removed it ages ago | 14:23 |
| pitti | geser: thanks for pointing out, I'll remove | 14:23 |
| pitti | there are 4 rdepends left in Debian | 14:24 |
| pitti | I'll sync them when/if they update to 9.1 | 14:24 |
| mterry | Daviey, k, am in the middle of doing them. | 14:24 |
| === dendro-afk is now known as dendrobates | ||
| mterry | zul, FYI, I generally find it easier to have one bug for a chain of dependencies like this (python-babel and below) and adding tasks for the separate packages. No big deal to have them separate, but you may find it easier too, for keeping track | 14:25 |
| zul | mterry: ill do that in the future | 14:26 |
| === yofel_ is now known as yofel | ||
| === zyga is now known as zyga-food | ||
| pitti | ev: you saw the whoopsie FTBFS? | 14:41 |
| pitti | geser: thanks, removed | 14:44 |
| Sweetshark | pitti: any good idea about Bug #938582 ? | 14:48 |
| ubottu | Launchpad bug 938582 in libexttextcat (Ubuntu) "[MIR] libexttextcat" [Undecided,Fix released] https://launchpad.net/bugs/938582 | 14:48 |
| Sweetshark | chrisccoulson: ping? | 14:49 |
| pitti | Sweetshark: sorry, I don't understand -- which package depends on which? | 14:49 |
| pitti | Sweetshark: libexttextcat0's dependencies look fine to me | 14:50 |
| Sweetshark | pitti: libexttextcat0-dev*ubuntu1 depended on libtextcat0-dev*ubuntu1 (although that one isnt ubuntufied) IIRC from my pbuilder failures. | 14:52 |
| mterry | zul, question for you in bug 941916 | 14:52 |
| ubottu | Launchpad bug 941916 in python-tz (Ubuntu) "[MIR] python-tz" [Undecided,Incomplete] https://launchpad.net/bugs/941916 | 14:52 |
| * Sweetshark rechecks | 14:52 | |
| zul | mterry: yep | 14:52 |
| Sweetshark | pitti: libexttextcat-dev : Depends: libexttextcat0 (= 3.2.0-1ubuntu1) but it is not going to be installed <- from my pbuilder log. | 14:52 |
| pitti | Sweetshark: hm, no idea why that would be; the versions are identical | 14:53 |
| pitti | libexttextcat0 | 3.2.0-1ubuntu1 | precise | amd64, armel, armhf, i386, powerpc | 14:53 |
| pitti | libexttextcat-dev | 3.2.0-1ubuntu1 | precise | amd64, armel, armhf, i386, powerpc | 14:53 |
| Sweetshark | pitti: does libexttextcat0 3.2.0-1ubuntu1 depend on libtextcat0 3.2.0-1ubuntu1 by chance? | 14:55 |
| pitti | Depends: libc6 (>= 2.14), libexttextcat-data (= 3.2.0-1ubuntu1) | 14:55 |
| pitti | Sweetshark: no, should it? | 14:55 |
| pitti | and libexttextcat-data is built by the libexttextcat source, so all seems fine | 14:55 |
| Sweetshark | pitti: hmmm, so what is wrong my pbuilder? | 14:56 |
| * Sweetshark goes hunting there. | 14:56 | |
| zul | mterry: i think it might be feasable to look at it after ff | 14:56 |
| mterry | zul, you mean after Beta1? We're after FF | 14:57 |
| zul | mterry: sorry beta1 | 14:57 |
| mterry | zul, this (and the tests, see my new comment) are normally MIR blockers. What's the story with the urgency here? | 15:01 |
| zul | mterry: pretty urgent | 15:01 |
| zul | its a blocker right now | 15:01 |
| mterry | zul, for the nova stack? | 15:01 |
| zul | mterry: correct | 15:02 |
| mterry | zul, well, as a MIR reviewer, it's not approved until those get fixed. But I'll subscribe ubuntu-release (who has to sign off anyway post-FF) if they want to promote it anyway/temporarily for the beta | 15:04 |
| zul | this is babel right? | 15:05 |
| Daviey | mterry: sorry, what is the blocker? | 15:05 |
| mterry | zul, -tz | 15:05 |
| mterry | Daviey, bug 941916 | 15:06 |
| ubottu | Launchpad bug 941916 in python-tz (Ubuntu) "[MIR] python-tz" [Undecided,Incomplete] https://launchpad.net/bugs/941916 | 15:06 |
| mterry | Daviey, tests and a hardcoded timezone list | 15:06 |
| zul | Daviey: er..http://paste.ubuntu.com/859292/ | 15:07 |
| mterry | zul, the tests can be run manually, but not sure how they are intended to be run, because yeah, setup.py doesn't call 'em | 15:08 |
| Daviey | mterry: ah, i wrote a patch to enable the test suite at runtime. | 15:10 |
| Daviey | err build time | 15:10 |
| Daviey | oh, that was for python-iso8601. | 15:12 |
| Daviey | mterry: Can i suggest that, if nothing inherently scares you, that they get promoted, with open bug tasks to resolve the niggles? | 15:12 |
| mterry | Daviey, ah yeah, I was going to file a bug for that one with Debian. It's test suite seemed awkward to run, so wasn't going to block on it. But that patch would be super welcome too! :) | 15:12 |
| dholbach | hey mterry - did seb128 ping you about the lightdm sponsoring item? :) | 15:13 |
| mterry | dholbach, no? | 15:13 |
| dholbach | hang out, let me dig it out | 15:13 |
| dholbach | ah no, sorry - unity-greeter | 15:14 |
| dholbach | bug 884366 | 15:14 |
| ubottu | Launchpad bug 884366 in unity-greeter (Ubuntu) "Theme is not customizable by downstream (derivative) distros" [Undecided,Confirmed] https://launchpad.net/bugs/884366 | 15:14 |
| zul | mterry: k tz is running the tests now | 15:17 |
| mterry | Daviey, it's just a matter of process. Issues of release schedule timing aside, these would be blockers. ubuntu-release will probably take your stance too (pitti?), in which case I'm on board | 15:18 |
| pitti | we could also revert to the previous nova | 15:18 |
| pitti | as it was uploaded a bit hastily anyway | 15:18 |
| * pitti needs to run out for a bit, bbl | 15:18 | |
| zul | previous version of nova had a big nasty memory bug i rather not revert it either | 15:20 |
| mterry | dholbach, ah, we made it easier for derivatives by moving to gsettings instead of an /etc/ config file. So they can just ship gsettings overrides | 15:25 |
| mterry | dholbach, I'll comment in bug and close out | 15:25 |
| dholbach | mterry, excellent | 15:25 |
| dholbach | thanks a lot | 15:25 |
| dholbach | seb128, ^ | 15:25 |
| soren | zul: Memory bug? | 15:25 |
| zul | soren: scheduler bug | 15:25 |
| zul | soren: that just sucks alot of memory from nova-compute | 15:26 |
| soren | zul: Do you have a bug ref? | 15:26 |
| zul | soren: yeah gimme a sec | 15:26 |
| seb128 | dholbach, mterry: thanks | 15:26 |
| === zyga-food is now known as zyga | ||
| ogzy | i am trying to pack libaudiere-1.9.4 for oneiric, i tried to use te source files from hardy and downloaded the dsc, diff.gz and tar.gz files and run sudo pbuilder build *.dsc here is what i got as error: Dependency is not satisfiable: libdumb1-dev but i have this package installed, any idea? | 15:45 |
| ogra_ | inside your pbiulder chroot ? | 15:45 |
| ogzy | ogra_: yes | 15:46 |
| ogra_ | might it be that there is a versioned dep on the package ? | 15:46 |
| ogzy | i checked the control file after i dpkg-source -x *.dsc, it only says the package name, no version | 15:47 |
| goganchic | hi2all | 15:47 |
| mterry | zul, I'm looking at python-babel now and it includes a bunch of binary info about locales. So what does nova even use python-babel for? Is it anything it could just use python-pyicu for instead, since it's already in main and has a boat-load of included locale info? | 15:48 |
| zul | mterry: i nor probably wasnt aware of it...its something that i will definently have to look at | 15:49 |
| goganchic | can anybody tell me where can I find code of hiding/showing global menu? I want to show it always. There are no settings for this function in unity interface and no code in indicator-appmenu package | 15:49 |
| mterry | zul, I can't even find where nova is importing babel | 15:50 |
| zul | mterry: are you looking at the package in the archive? | 15:50 |
| mterry | zul, yeah | 15:51 |
| zul | mterry: yeah youll have to look at the upstream source | 15:51 |
| mterry | zul, ok. we are depending on python-babel in anticipation then? | 15:52 |
| zul | mterry: yes | 15:52 |
| zul | mterry: its a dependency of the nova waiting to build in the buildds | 15:53 |
| chrisccoulson | hi Sweetshark | 15:54 |
| goganchic | is indicator-appmenu the package which display menu in the top panel in unity? | 15:54 |
| mterry | zul, all I see in nova trunk is a babel.cfg | 16:02 |
| zul | mterry: https://github.com/openstack/nova/commit/4a4c274c834728a03bce7e5384c562321821eaf8 | 16:02 |
| mterry | zul, ah... babel is a build tool as well as a library | 16:04 |
| mterry | zul, missed that bit | 16:04 |
| mterry | So not so easy to replace with pyicu | 16:06 |
| mterry | goganchic, yes | 16:19 |
| goganchic | merry, and what about code for hiding/showing global menu? Is this code in indicator-appmenu package too? Or this code belongs to main unity package (libunity or smith like this)& | 16:20 |
| goganchic | mterry, and what about code for hiding/showing global menu? Is this code in indicator-appmenu package too? Or this code belongs to main unity package (libunity or smith like this)? | 16:22 |
| stgraber | mvo: any thought on bug 937196? | 16:22 |
| ubottu | Launchpad bug 937196 in ifupdown (Ubuntu) "10.04 LTS -> 12.04 upgrade failed: ifupdown depends on upstart and initscripts but they are not configured" [High,Confirmed] https://launchpad.net/bugs/937196 | 16:22 |
| mterry | goganchic, well, that gets a bit complicated. unity hosts the appmenu indicator, sure. But appmenu-gtk which is a gtk+ module that all client apps load is responsible for sometimes showing it (like when user holds down ALT I believe) | 16:23 |
| mterry | goganchic, what's your goal? | 16:24 |
| mterry | goganchic, this might be better fodder for #ubuntu-unity? | 16:24 |
| goganchic | merry, my goal is to show global menu by default, always, not only when mouse pointer is over it. I'll try #ubuntu-unity channel, thanks | 16:25 |
| goganchic | mterry, my goal is to show global menu by default, always, not only when mouse pointer is over it. I'll try #ubuntu-unity channel, thanks | 16:25 |
| pitti | jibel: would it take much effort to re-run precise-upgrade-lucid-universe, now that we have the libjpeg-dev fix? | 16:32 |
| pitti | jibel: ah, nevermind | 16:33 |
| pitti | jibel: we need calligra fixed first | 16:33 |
| mpt | ev, hi, can we kill the bubbles that say "An application has crashed on your system (now or in the past). Click on the notification icon to display details."? | 16:45 |
| jml | my precise install is being ground to a halt, I think by dconf-settings | 16:53 |
| === deryck is now known as deryck[lunch] | ||
| jml | can I just kill it, please? | 16:55 |
| seb128 | jml, don't blame the messenger | 16:58 |
| infinity | pitti: Oh, checking scrollback, our P-a-s is forked from Debian's and we can change it, but wvstreams (and thus wvdial) just plain didn't work on ARM last time anyone checked. | 16:59 |
| seb128 | jml, it probably means something loop write to gsettings | 16:59 |
| infinity | pitti: Not from a building POV, but from a runtime one. | 16:59 |
| seb128 | jml, strace it maybe to figure what key is being written? | 16:59 |
| infinity | pitti: If that's no longer true, I'm happy to build them again. | 16:59 |
| pitti | infinity: right; I saw that you already PaSed wvdial, but http://qa.ubuntuwire.org/ftbfs/ doesn't take that into account | 16:59 |
| pitti | infinity: thanks | 16:59 |
| infinity | pitti: (If you're just trying to get wvdial out of the yellow block on the qa report, that's an LP bug, and would be resolved by uploading the source again). :P | 16:59 |
| pitti | infinity: *nod* | 17:01 |
| jml | seb128: what am I looking for in the strace output? | 17:01 |
| infinity | pitti: Alternately, fix qa/ftbfs to parse P-a-s, so it can ignore builds that LP shouldn't have. ;) | 17:02 |
| infinity | pitti: (Which seems saner than re-uploading source just to remove a build record) | 17:02 |
| jml | write(12, "GVariant\0\0\0\0\0\0\0\0\30\0\0\0\20\31\0\0\0\0\0(\344\0\0\0"..., 12288) = 12288 | 17:05 |
| jml | write(12, "elay\0\0\0\0\350\3\0\0\0imaximized\0\1\0bcache"..., 348) = 348 | 17:05 |
| jml | to .config/dconf/user.DF597V, which then gets renamed to .config/dconf/user | 17:05 |
| seb128 | jml, maybe try to gsettings list-recursively > log and diff the logs | 17:05 |
| seb128 | i.e 2 calls to those | 17:05 |
| bluefoxicy | so | 17:05 |
| bluefoxicy | I asked Ubuntu to upgrade yesterday | 17:05 |
| bluefoxicy | it hasn't. | 17:05 |
| bluefoxicy | It got one package in, then asked me about which services to restart for a glibc upgrade and waited. | 17:06 |
| bluefoxicy | might I suggest making apt a bit more intelligent, such that it can look at packages which will pause apt and defer them until later in the process (i.e. when things can't be installed without the offending package first) | 17:07 |
| bluefoxicy | and also, marking such packages where you can install and defer any such questions until later so that it simply doesn't ask until later in the process | 17:07 |
| jml | -org.gnome.settings-daemon.peripherals.keyboard numlock-state 'on' | 17:08 |
| jml | +org.gnome.settings-daemon.peripherals.keyboard numlock-state 'off' | 17:08 |
| * bluefoxicy hates babysitting things. Would rather come back to a stalled process when it's almost done than when it's just started. | 17:08 | |
| seb128 | jml, it seems g-s-d is spammed gsettings with numlock status changes | 17:09 |
| jml | hmm. | 17:09 |
| jml | I've seen some people mention issues with apple keyboard & numlock... | 17:09 |
| seb128 | jml, do you have any service or anything dealin with numlock status for you? | 17:09 |
| jml | but I haven't paid attention to details | 17:09 |
| seb128 | jml, when did that start? | 17:09 |
| jml | seb128: I don't think so. | 17:09 |
| jml | seb128: within the last hour | 17:10 |
| seb128 | jml, you can probably "gsettings set org.gnome.settings-daemon.peripherals.keyboard remember-numlock-state false" | 17:10 |
| seb128 | or kill gnome-settings-daemon | 17:10 |
| seb128 | it seems stuff fight over your numlock status | 17:10 |
| jml | seb128: setting remember-numlock-state off seemed to stop the spinning. | 17:12 |
| jml | seb128: thanks. | 17:12 |
| seb128 | jml, yw, still weird that stuff keep changing the status of numlock and a bug somewhere | 17:12 |
| seb128 | could be xorg or virtualbox or something | 17:12 |
| seb128 | jml, the gsettings stuff was only a side effect, g-s-d only stores the status | 17:13 |
| seb128 | it seems something keeps changing the status though | 17:13 |
| seb128 | jml, oh, and no, I've no idea how to debug what is the something ;-) | 17:13 |
| jml | seb128: heh | 17:15 |
| jml | seb128: well, tbh, I'd rather get on with other things than spend time debugging OS issues :) | 17:15 |
| jdstrand | @pilot in | 17:15 |
| === udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect. 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: jdstrand | ||
| seb128 | jdstrand, hey, please ignore merge request about unity_quicklists, those have issue and are being sorted | 17:18 |
| jdstrand | seb128: ok | 17:19 |
| hrw | tkamppeter: thx for activity in bug 932882 | 17:21 |
| ubottu | Launchpad bug 932882 in gutenprint (Ubuntu) "The PPD version (5.2.7) is not compatible with Gutenprint 5.2.8-pre1." [Undecided,Opinion] https://launchpad.net/bugs/932882 | 17:21 |
| hrw | have a nice rest of day | 17:24 |
| broder | can somebody on ~ubuntu-branches set https://code.launchpad.net/~pali/ubuntu/natty/plymouth/plymouth/+merge/61897 back to work in progress? | 17:40 |
| === deryck[lunch] is now known as deryck | ||
| broder | hmm, is it deliberate or accidental that packages that were removed still have udd branches? | 18:09 |
| slangasek | broder: I think it's deliberate | 18:14 |
| slangasek | we don't want to lose the history; so the question is how do you want to represent a package removal | 18:14 |
| broder | backports just got a bug from a user checking out a package that was removed several releases ago | 18:14 |
| broder | which is clearly confused on several levels | 18:14 |
| slangasek | heh | 18:15 |
| slangasek | foreports | 18:15 |
| broder | but possibly indicates some real potential problems, especially with things like developer.ubuntu.com now pointing at udd | 18:15 |
| * slangasek suggests filing a bug on udd | 18:16 | |
| * broder nods | 18:16 | |
| broder | slangasek: what do you want to do about insserv, by the way? based on my experience with afs, i'm suspicious that stopping networking before umountnfs.sh will cause nfs to hang on shutdown, but i haven't used nfs so i don't know | 18:23 |
| infinity | broder: Why would you stop networking before umounting network filesystems? | 18:24 |
| infinity | (I mean, why should that be discussed instead of just fixed?) | 18:25 |
| ogra_ | more excitement ! | 18:25 |
| micahg | maybe the lp:ubuntu/foo branch "symlink" can be removed for packages that have been removed from the dev release? | 18:26 |
| mterry | zul, do we even need python-babel if all it does is manage gettext files? Won't those be managed by the langpacks? | 18:27 |
| === kentb-out is now known as kentb | ||
| zul | mterry: im not sure its something we need to look at | 18:27 |
| broder | micahg: yeah, maybe. i don't feel like i understand the relevant issues well enough to do much more than raise it with the udd team and let them figure it out | 18:28 |
| broder | but i went ahead and filed bug #942138 | 18:28 |
| ubottu | Launchpad bug 942138 in Ubuntu Distributed Development "Removed packages still have udd branches" [Undecided,New] https://launchpad.net/bugs/942138 | 18:29 |
| * micahg comments on the bug | 18:29 | |
| mterry | zul, ok, well added comment to python-babel bug with review there, including that question | 18:29 |
| bdmurray | zyga: have you put the command-not-found change for bug 938992 on to Launchpad yet? | 18:34 |
| ubottu | Launchpad bug 938992 in command-not-found (Ubuntu) "crash_guard routine should be changed" [Medium,Confirmed] https://launchpad.net/bugs/938992 | 18:34 |
| === jjohansen is now known as creckets | ||
| === creckets is now known as crickets | ||
| === crickets is now known as jjohansen | ||
| infinity | TheMuso: *pokity poke* | 19:00 |
| infinity | TheMuso: When you're around, can you add me (adconrad) to ~ubuntustudio-dev? Kthx. | 19:01 |
| smoser | slangasek, ping | 19:05 |
| zyga | bdmurray: nope | 19:05 |
| slangasek | smoser: hey there | 19:05 |
| zyga | bdmurray: let me find that branch | 19:05 |
| smoser | i'm looking at bug 937352 | 19:06 |
| slangasek | SpamapS: say, do you have any packages using wait-for-state in the wild? | 19:06 |
| ubottu | Launchpad bug 937352 in cloud-initramfs-tools (Ubuntu) "root partition in may not be grown" [Undecided,Fix released] https://launchpad.net/bugs/937352 | 19:06 |
| smoser | and wondering if you have some insite | 19:06 |
| bluefoxicy | question. | 19:06 |
| slangasek | smoser: that one's marked fix released, is that the one you mean? | 19:06 |
| smoser | slangasek, yeah, it wasn't fixed. i need to change that. | 19:07 |
| bluefoxicy | By convention in init scripts, if you have multiple things to turn on | 19:07 |
| bluefoxicy | is it preferred to have settings like "NETWORK0={0,1}", "NETWORK0={on,off}", or "NETWORK0={enabled,disabled}"? | 19:07 |
| smoser | slangasek, so basically what happens: | 19:07 |
| smoser | 1.) normal initramfs mount of / | 19:07 |
| bluefoxicy | or, you know. y/n | 19:07 |
| smoser | 2.) growpart initramfs plugin (in local-bottom) umounts / | 19:08 |
| smoser | 3.) calls growpart , which runs 'sfdisk' which calls BLKRPART | 19:08 |
| smoser | 4.) sometimes, blkrrpart gets device or resource busy | 19:09 |
| smoser | slangasek, at http://paste.ubuntu.com/859573/, i've modified the initramfs to collect 'ps -w' output before and after the sfdisk command | 19:10 |
| slangasek | bluefoxicy: I wouldn't consider any of these things to be best practice, really | 19:10 |
| smoser | i'mi wondering what could be causing the busy. smb was fairly certain the only thing he could think of was udev events, so we added a 'udevadm settle' before running growpart (to make sure any initial events from the normal boot had finished) | 19:11 |
| slangasek | smoser: what's this 'blkid' call in the ps output? | 19:11 |
| slangasek | smoser: remember that "udevadm settle" doesn't mean "no more events will happen", it means "the event queue is currently empty". | 19:12 |
| slangasek | (empty, and all events that were in it have been processed) | 19:12 |
| smoser | slangasek, yeah, that is probably the thing that is the issue. | 19:13 |
| smoser | i'm assuming it jsut came from udev seeing the vda1 event. | 19:14 |
| SpamapS | slangasek: I don't believe there are any using it yet no | 19:14 |
| SpamapS | slangasek: I've been meaning to write up how to use it at some point. :p | 19:14 |
| smoser | right, obviously it doesn't mean "no more events will happen". but i had assumed that in that point in the boot, where / had already been mounted (on /dev/vda1), that such events would have already occurred. | 19:15 |
| SpamapS | slangasek: I've recommended its use on askubuntu.com a few times | 19:15 |
| smoser | but one way or another , I need to block until or somehow assert that nothing will have /dev/vda open in the initramfs. | 19:15 |
| slangasek | smoser: can I see the udev log from this system? I want to see what attributes are on /dev/vda1 | 19:15 |
| smoser | slangasek, can i get that from the booted system ? | 19:16 |
| slangasek | smoser: /var/log/udev.log | 19:16 |
| smoser | i can give you access to the system just as easily | 19:16 |
| slangasek | (thanks to coldplugging) | 19:16 |
| slangasek | either way then :) | 19:16 |
| slangasek | SpamapS: do you have a pointer handy to one of those recommendations? I'm specifically interested at the moment in the context of bug #569757 | 19:16 |
| ubottu | Launchpad bug 569757 in nis (Ubuntu) "NIS upstart dependency broken for lucid" [High,Triaged] https://launchpad.net/bugs/569757 | 19:16 |
| slangasek | SpamapS: dunno if you're following the debian-devel upstart thread? | 19:17 |
| smoser | udev log is at http://paste.ubuntu.com/859585/ | 19:17 |
| smoser | and, slangasek you can get to ubuntu@10.55.60.153 via chinstrap | 19:17 |
| slangasek | smoser: ok; so it's line 75 of /lib/udev/rules.d/60-persistent-storage.rules | 19:18 |
| slangasek | which seems legitimate here | 19:18 |
| slangasek | smoser: I think the problem is your initramfs script is not event driven, and hasn't waited for the kernel to say the disk is ready | 19:18 |
| slangasek | sorry, for udev to say | 19:18 |
| SpamapS | slangasek: no, I am woefully behind on debian-devel.. ;) | 19:19 |
| smoser | slangasek, i dont know. | 19:19 |
| smoser | it runs at local-bttom | 19:19 |
| smoser | after rootfs has been mounted once already | 19:19 |
| smoser | and mounted via LABEL also | 19:20 |
| slangasek | smoser: hmm! | 19:20 |
| smoser | so i would have thought that that would have already occurred | 19:20 |
| slangasek | yes | 19:20 |
| slangasek | except the main mounting script is also not event driven AFAIK :) | 19:20 |
| smoser | slangasek, well it uses wait-for-root | 19:20 |
| smoser | which is linked to udev i think | 19:20 |
| smoser | (verified it is linked to udev) | 19:21 |
| SpamapS | slangasek: probably the best example of how it can be used is bug #643289 .. recommended it in comment 14 | 19:22 |
| ubottu | Launchpad bug 643289 in nfs-utils (Ubuntu Lucid) "idmapd does not starts to work after system reboot" [High,Triaged] https://launchpad.net/bugs/643289 | 19:22 |
| slangasek | SpamapS: so the nis case is interesting, because what we need to implement here is the equivalent of an LSB "Should-Start" rule | 19:22 |
| slangasek | SpamapS: wait-for-state doesn't DT"R"T for non-existent jobs | 19:22 |
| === fisted_ is now known as fisted | ||
| slangasek | so I can't just call start wait-for-state WAITER=autofs WAIT_FOR=ypbind in the autofs pre-start | 19:23 |
| infinity | smoser: Wait, why are you growing root in local-bottom? | 19:23 |
| slangasek | infinity: clouuuud | 19:23 |
| infinity | smoser: That would be where your code differs from jasper, we do it in local-premount. | 19:23 |
| slangasek | SpamapS: I *can* create a job in the nis package called start-ypbind that's 'start on starting autofs' and calls 'start wait-for-state', but that's kinda the wrong place for it to live | 19:24 |
| infinity | smoser: Doing it post-mount just seems to be asking for this sort of trouble. | 19:24 |
| slangasek | infinity: why? I'm not seeing why unmounting the partition should generate new udev events | 19:24 |
| infinity | slangasek: No, but why mount/umount/resize/remount? | 19:25 |
| smoser | infinity, i chose post-mount because i could guarantee that at that point the device was available | 19:25 |
| smoser | othe rthan that , i'd have to do the wait-for-root before the real wait-for-root | 19:25 |
| smoser | but... same problem would occur i think. | 19:25 |
| slangasek | smoser: 'premount' is called from /usr/share/initramfs-tools/scripts/local right before it's about to mount the device. | 19:25 |
| slangasek | smoser: so you don't need to wait-for-root because the script's already done it for you | 19:26 |
| smoser | slangasek, right. i dont at *that* point | 19:26 |
| smoser | but i do have to afterwards | 19:26 |
| smoser | as the sfdisk generates events that might delete it temporarily | 19:26 |
| smoser | slangasek, well, i forget why i did premount | 19:27 |
| infinity | Do you go straight from resizing into mounting and starting? | 19:27 |
| smoser | er... why i did not do premount | 19:27 |
| smoser | but really, why would that be any different | 19:27 |
| infinity | We do premount-resize, then trigger a reboot in bottom. | 19:27 |
| smoser | mount and umount should not create events to udev, and the one that runs earlier just seems *more* prone to errors. | 19:27 |
| smoser | infinity, i dont want to reboot | 19:27 |
| infinity | Fair enough. | 19:27 |
| infinity | But there's a solution for that too. | 19:28 |
| slangasek | smoser: I don't see any reason for errors in either case, but if you do it in premount, you're doing it at precisely the point that initramfs-tools says the device is ready for use | 19:28 |
| infinity | Your resize script (if it were in premount) could re-scan for partitions/devices before exiting. | 19:28 |
| slangasek | infinity: does that, that's why we're getting the error ;) | 19:28 |
| smoser | slangasek, i can try the local-premount (or look into why i didn't use that originally) | 19:29 |
| smoser | but i don tthink its going to change much really. | 19:29 |
| SpamapS | slangasek: roger. I think we can make it react more appropriately for a job that does not exist. | 19:29 |
| SpamapS | slangasek: have to work on some other stuff for a while today.. will return to this later | 19:30 |
| slangasek | smoser: well, it reduces complexity a little bit, you don't have to umount / remount... you just have to resize, reread, probably call wait-for-root again for the benefit of the local script, and exit | 19:30 |
| slangasek | smoser: this may fix the bug in which case it's an easy win, and if it doesn't it gives us less to search through | 19:30 |
| slangasek | SpamapS: ok - mostly wanted to check that you agree it should be done by adjusting wait-for-state | 19:31 |
| slangasek | SpamapS: if so, I'll go ahead with uploading nis | 19:31 |
| infinity | slangasek: The error may be coming from the partition scan, but that's only because the device was previously busy anyway (it threw an error on resize too). | 19:32 |
| infinity | slangasek / smoser: My gut feeling is that growing and rescanning in premount will Just Work (and I don't see why you'd need to retrigger wait-for-root after the rescan, we already know the device is there). | 19:33 |
| === Ursinha_ is now known as Guest34384 | ||
| slangasek | infinity: we know the device was there before fiddling with the partitions again; I don't know if we get new events for the partitions when resized | 19:33 |
| slangasek | infinity: and the resize failed only in that it failed to reread the partition table afterwards | 19:34 |
| slangasek | the actual resizing succeeded (as it should) | 19:34 |
| smoser | slangasek, i'm reading init from the initramfs | 19:34 |
| smoser | and it seems to me that local-premount is before wait-for-root | 19:35 |
| slangasek | smoser: no, local-premount isn't called from init at all. *local*-premount, not *init*-premount | 19:35 |
| slangasek | smoser: the difference is critical here :) | 19:35 |
| slangasek | local-foo are "the set of scripts run when the root filesystem is a local filesystem" | 19:36 |
| slangasek | and are all run from scripts/local | 19:36 |
| infinity | local does, basically, wait-for-root && premount && mount | 19:37 |
| smoser | yeah, i see that. | 19:37 |
| slangasek | well, it does top && wait-for-root && premount && mount | 19:37 |
| slangasek | && bottom :P | 19:37 |
| infinity | Still, if premount successfully re-rereads the table, I don't see need for a second wait-for-root. | 19:38 |
| * infinity shrugs. | 19:38 | |
| slangasek | because the ioctl for the table reread is not going to wait for udev before returning | 19:38 |
| slangasek | (because it a) can't, b) shouldn't) | 19:38 |
| infinity | Oh, there's that. | 19:38 |
| infinity | Fair enough. | 19:38 |
| slangasek | so if udev goes mucking about in /dev afterwards, it's racy | 19:38 |
| infinity | Not onerous to add a wait-for-root to the premount mucking script anyway. | 19:39 |
| slangasek | yes; there's already one in there as it is | 19:39 |
| slangasek | just the umount/mount need to be dropped | 19:39 |
| bdmurray | ScottK: Do you think bug 940789 is a duplicate of bug 927855? | 19:40 |
| ubottu | Launchpad bug 940789 in update-manager (Ubuntu) ""Obsolete packages will be removed" dialogue is too tall for netbook screen with KDE front end" [Undecided,New] https://launchpad.net/bugs/940789 | 19:40 |
| ubottu | Launchpad bug 927855 in update-manager (Ubuntu) "window size too large to see buttons after expanding details" [Undecided,Confirmed] https://launchpad.net/bugs/927855 | 19:40 |
| smoser | hm.. | 19:42 |
| smoser | i really think this is a goose chase | 19:43 |
| smoser | but i will oblige and try in local-premount, making necessary changes. | 19:43 |
| infinity | smoser: I'm not sure it's a goose chase at all. Not mounting the FS certainly leads to one less possible way that the device could be busy, right? | 19:44 |
| bluefoxicy | so | 19:44 |
| slangasek | smoser: even if it doesn't fix it, infinity is right that this is the better and simpler way to do what you're doing | 19:44 |
| bluefoxicy | I am playing with zram | 19:44 |
| infinity | smoser: (And umounting doesn't guarantee a device isn't busy) | 19:44 |
| bluefoxicy | is there any interest in this? | 19:45 |
| infinity | bluefoxicy: We use it on the ac100 images. | 19:45 |
| slangasek | so if it doesn't fix it, we have less of an area remaining to search for the bug in :) | 19:45 |
| bluefoxicy | infinity: I think it's appropriate roughly "everywhere" to use compressed memory because of the CPU/swap trade-off inequality. | 19:45 |
| bluefoxicy | in other words I think my desktop doesn't give a crap that it's squeezing 4, 8, 16 kilobytes of data into a compressed swap area, but it sure takes a beating thrashing disk | 19:46 |
| infinity | bluefoxicy: Except that most modern desktops really don't swap often at all. | 19:46 |
| smoser | slangasek, infinity ah. | 19:46 |
| smoser | i see at least one reason i used post-mount | 19:46 |
| bluefoxicy | infinity: servers? | 19:46 |
| infinity | bluefoxicy: The reason we use it on the ac100 is a combination of limited RAM and slow/fagile storage. | 19:47 |
| smoser | i check some files in the mount that may indicate "do not grow this" | 19:47 |
| smoser | (ie, to be configurable) | 19:47 |
| bluefoxicy | infinity: the real problem with all this to me is no hibernate file | 19:47 |
| infinity | bluefoxicy: I'd contend that any server that swaps frequently has admins that need to look at fixing it. :P | 19:47 |
| bluefoxicy | your desktop has 16 gigs of RAM, you don't have to swap, good for you. You can't hibernate :P | 19:47 |
| bluefoxicy | infinity: I'd contend that a software fix that extends performance without requiring additional money sunk into additional hardware is a fix :) | 19:48 |
| slangasek | smoser: oh, ok :/ | 19:48 |
| smoser | its also something i would like to not lose. | 19:48 |
| infinity | bluefoxicy: But it doesn't extend performance on a system with an appropriate amount of RAM for the workload, it degrades it. | 19:48 |
| bluefoxicy | Only if it gets used. | 19:49 |
| infinity | smoser: What's the use-case for that? | 19:49 |
| smoser | but... if i have to in order to acutally have functional code in the default case i'd drop it. | 19:49 |
| bluefoxicy | That's the thing: if you don't extend past the end of memory, you never use any of this | 19:49 |
| infinity | bluefoxicy: But your zram swap is more likely to be hit if you, say, have 1/2 your RAM configured as zram swap. | 19:49 |
| infinity | bluefoxicy: zram doesn't come from thin air. | 19:49 |
| slangasek | smoser: well, shot in the dark - how about another wait-for-root call after your umount and before your growpart? | 19:49 |
| smoser | infinity, i'm not really sure, othe rthan to allow this code to be disabled without re-building the image | 19:49 |
| infinity | bluefoxicy: If you use part of RAM for zram, you lose it as RAM. | 19:49 |
| bluefoxicy | infinity: not true. If you have 4GB of RAM and set 2GB as zram swap, you can use 3.5GB of physical RAM without swapping to zram. | 19:50 |
| infinity | smoser: boot argument? | 19:50 |
| slangasek | smoser: if you had to lose that config code, I guess you could offer configuration via kernel ^^ infinity fast | 19:50 |
| smoser | initially, the idea was that we would only run this once per "instance", but then we ended up changing that because on ec2, you can 'start instance', 'stop instance', 'grow volunme', 'start instance' | 19:50 |
| bluefoxicy | infinity: zram doesn't preallocate memory; it dynamically allocates it in the same way as tmpfs. So if you're storing nothing on the device, it doesn't use any RAM. | 19:50 |
| bluefoxicy | bluefox@icebox:~$ cat /sys/block/zram0/disksize | 19:51 |
| bluefoxicy | 1073741824 [In bytes] | 19:51 |
| bluefoxicy | bluefox@icebox:~$ cat /sys/block/zram0/mem_used_total | 19:51 |
| bluefoxicy | 270336 | 19:51 |
| ScottK | bdmurray: It could be. I'm not sure if the code that drives window size is -common or front end unique. | 19:52 |
| smoser | yeah, slangasek infinity kernel command line update is actually significantly more difficult in many ways that adding a file | 19:52 |
| slangasek | yeah, I was afraid of that | 19:53 |
| infinity | It is? | 19:53 |
| infinity | Mmkay. | 19:53 |
| smoser | well, at very least it means updating grub config rather than touching a file | 19:53 |
| broder | smoser: how are people supposed to create that flagfile? publishing their own ami? | 19:53 |
| broder | oh wait, right, you still can't customize the initrd. nvm | 19:54 |
| smoser | broder, yeah, that is really the only way. you're right, thats not terribly easy. | 19:54 |
| smoser | you can customize the initramfs now, broder, it is read and loaded via pv-grub | 19:54 |
| smoser | but yeah, that is possibly one reason i did it that way... | 19:54 |
| smoser | history | 19:54 |
| smoser | i'll try this now and see. | 19:54 |
| broder | smoser: oh, ok. so then, if people already have to publish their own ami, could they disable the expansion at initrd-build time? | 19:54 |
| slangasek | you can simply omit the cloud-initramfs-tools package then? | 19:55 |
| smoser | broder, yeah, its definitely doable. i'm surprised i didn't actually add anything that would allow you to do that. | 19:56 |
| smoser | but yeah, just removing woudl do it. | 19:56 |
| exarkun | Anyone want to talk about https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/668955 https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/788965 https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/810405 https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/814933 https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/815130 https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/627654 ? | 19:56 |
| ubottu | Launchpad bug 668955 in twisted (Ubuntu) "package python-twisted-core 10.1.0-2 failed to install/upgrade: el subproceso script post-installation instalado devolvió el código de salida de error 2" [Undecided,New] | 19:56 |
| ubottu | Launchpad bug 788965 in twisted (Ubuntu) "package python-twisted-core 10.2.0-1 failed to install/upgrade: ErrorMessage: subproces installed post-installation script gaf een foutwaarde 1 terug" [Undecided,New] | 19:56 |
| ubottu | Launchpad bug 810405 in twisted (Ubuntu) "package python-twisted-core 10.2.0-1 failed to install/upgrade: subproces installed post-installation script gaf een foutwaarde 1 terug" [Undecided,New] | 19:56 |
| ubottu | Launchpad bug 814933 in twisted (Ubuntu) "package python-twisted-core 10.0.0-2ubuntu2 [modified: usr/share/pyshared/twisted/python/dxprofile.py] failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] | 19:56 |
| ubottu | Launchpad bug 815130 in twisted (Ubuntu) "package python-twisted-core 10.2.0-1 failed to install/upgrade: ErrorMessage: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück" [Undecided,New] | 19:56 |
| slangasek | would perhaps be nice to have it configurable, since c-i-t ships two scripts (growroot + rescuevol) | 19:57 |
| smoser | slangasek, well they're thir own packages. | 19:57 |
| smoser | each could be deleted | 19:57 |
| slangasek | oh | 19:57 |
| slangasek | well there you go then | 19:57 |
| smoser | yea. | 19:57 |
| slangasek | seems sufficient to me | 19:57 |
| seb128 | could some buildds admin bump the score for https://launchpad.net/~sil2100/+archive/ppa/+build/3244412 https://launchpad.net/~sil2100/+archive/ppa/+build/3244413 | 19:58 |
| smoser | but, same as grub config, removing a package is obviosly more diffiicult than touchign a file. | 19:58 |
| smoser | but i'll go down this route | 19:58 |
| smoser | hoping that it will allow us to undertsand what is going wrong. | 19:58 |
| stgraber | seb128: done | 19:58 |
| seb128 | thanks | 19:58 |
| slangasek | exarkun: what specifically would you like to talk about? | 20:03 |
| exarkun | slangasek: whether I should mark them all as duplicates. which I just did, because I'm not always very patient. | 20:04 |
| slangasek | exarkun: they're not duplicates at all, please undo this | 20:04 |
| slangasek | one of them doesn't even have the same exit code as the others, and aside from two from the same user, they each have different error messages in the log | 20:04 |
| exarkun | slangasek: They're all caused by failing hardware corrupting package data, and then the failure being incorrectly handled by the installation tools. | 20:05 |
| slangasek | exarkun: please don't consider "post-installation script returned error exit status 1" sufficient reason to dupe bugs | 20:05 |
| exarkun | Packages can be corrupted in a lot of different ways, I'm sure | 20:05 |
| slangasek | no | 20:05 |
| slangasek | where do you see evidence of hardware corruption in each of these? | 20:05 |
| exarkun | lack of evidence to the contrary, behavior unreproducable by anyone else | 20:06 |
| exarkun | "Illegal Instruction" from an executable | 20:06 |
| exarkun | Looks pretty hardware-faily to me. Actually I didn't link to that one, sorry: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/941269 | 20:07 |
| ubottu | Launchpad bug 941269 in software-center (Ubuntu) "package software-center 5.1.9 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,Confirmed] | 20:07 |
| slangasek | exarkun: there has been no analysis at all on bug #788965 that supports this theory that it's hardware corruption. | 20:09 |
| ubottu | Launchpad bug 941269 in software-center (Ubuntu) "duplicate for #788965 package software-center 5.1.9 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,Confirmed] https://launchpad.net/bugs/941269 | 20:09 |
| exarkun | slangasek: I offered my analysis. | 20:09 |
| slangasek | Sorry: TypeError: ('compile() expected string without null bytes',) | 20:09 |
| slangasek | there's no evidence that anyone even tried to reproduce the bug with the set of packages the user had installed | 20:10 |
| slangasek | jumping to the conclusion that it's filesystem corruption just because there are other bugs reported against this package which are caused by filesystem corruption isn't logical | 20:10 |
| exarkun | Okay, I'm sure you're right. I'll go back to ignoring these bug reports. | 20:11 |
| exarkun | (so they can sit for years with no comment) | 20:11 |
| infinity | geser: Did you decide not to resurrect vim's changelog history, or did someone else sponsor your upload before you could? :P | 20:27 |
| infinity | geser: I was entirely serious about that particular changelog having sentimental value to a lot of developers. I think I'll just reject that upload and re-sponsor it with the changelog intact. ;) | 20:30 |
| slangasek | SpamapS: I'm having second thoughts about putting the wait-for-state check in autofs, because that means running extra scripts at boot time that are *only* useful when nis is installed | 20:35 |
| slangasek | if you don't have nis installed, they just slow the boot down for no reason | 20:35 |
| slangasek | so blah | 20:35 |
| SpamapS | slangasek: yeah, seems like nis should have that script | 20:36 |
| SpamapS | slangasek: you can always cancel a starting job and take it over with start on starting... | 20:36 |
| SpamapS | slangasek: though I haven't thought this through, and I need caffeine/food so ignore me ;) | 20:37 |
| slangasek | :) | 20:37 |
| slangasek | SpamapS: my current thoughts: http://paste.ubuntu.com/859688/ | 20:39 |
| slangasek | the "cron" part should maybe go away though, because cron is smart enough now to detect when names become resolvable | 20:40 |
| slangasek | broder: can I easily get access to the lintian lab? | 20:41 |
| broder | slangasek: uh, i don't have anything setup for it at the moment. if you'd like to wait 20-30 minutes, i can get off my rear and finally set something up. otherwise, i can run things for you | 20:44 |
| slangasek | broder: I'm looking for 'grep -l 'Should-Start:.*ypbind' /etc/init.d/*' | 20:46 |
| slangasek | but I may have another way to run it that's nearly as fast | 20:46 |
| smoser | slangasek, well, in so far 3 tries, i've yet to make the it fail at local-premount | 20:46 |
| smoser | i'm running some more... as 3 isn't very definitive | 20:47 |
| slangasek | smoser: sure :) | 20:47 |
| smoser | can you come up with any reason why that blkid would have been running though? | 20:47 |
| broder | slangasek: running now | 20:48 |
| smoser | i'm really not interested in changing code without a reason, as | 20:49 |
| smoser | a.) i already did that once for this bug :) | 20:49 |
| slangasek | smoser: sure, something generating a change event on the kernel device | 20:49 |
| smoser | b.) it seems that 11.10, 11.04, 10.10 are also vulnerable to this | 20:49 |
| slangasek | smoser: as part of the blkrrpart ioctl | 20:49 |
| smoser | but what would have done that? | 20:49 |
| slangasek | some aspect of the kernel driver | 20:50 |
| smoser | and why would we think that prior to mount of root anything would be different for *that* | 20:50 |
| slangasek | oh no, sorry | 20:50 |
| slangasek | this is blkid running *while* we're trying to call blkrrpart | 20:50 |
| smoser | right. | 20:51 |
| slangasek | so what would cause the event, hmm | 20:51 |
| slangasek | you can probably argue that it's a kernel bug | 20:51 |
| smoser | because if we dont know what would have done it, then i have a hard time coming up with a reason it can't happen during premount either. | 20:51 |
| smoser | s/either/also/ | 20:51 |
| slangasek | well, the only thing going on here that *could* do it, AFAICS, is the mount/umount | 20:52 |
| slangasek | and if it is, I think that's a kernel bug | 20:53 |
| slangasek | but of a sort that's probably hard to isolate and fix | 20:53 |
| smoser | slangasek, well, i can't seem to trigger the mount/umount in a loop in user space | 20:55 |
| smoser | (unfortunately i cant reproduce any of this cleanly outside of first boot) | 20:55 |
| smoser | and it only started showing up withen we upgraded to precise kvm and openstack | 20:55 |
| smoser | which obviously changed a bunch of timings | 20:55 |
| smoser | slangasek, if it were triggered by mount/umount, you would think that it could be triggeref by somethin glike: | 20:56 |
| smoser | while : ; do mount ext4-dev /mnt && umount ext4-dev /mnt ; done | 20:57 |
| smoser | and watching udev | 20:57 |
| smoser | and i think that nothing happens | 20:57 |
| smoser | (i can test that, but basically ou'r asserting that some udev event would fire based on that) | 20:57 |
| smoser | (i think) | 20:57 |
| smoser | unless you have some reason that that mount/umount early in boot would trigger something that subsequent mount/umount wouldnt | 20:59 |
| slangasek | smoser: nope | 21:00 |
| smoser | so then at this point, the best justification for a change from local-bottom to local-premount is that "it seems simpler" | 21:02 |
| smoser | (and testing seems to change the race conditions) | 21:02 |
| slangasek | no, it's that the *only possible* thing we've found that could be racing is something triggered off by the mount/umount | 21:03 |
| slangasek | even if we don't understand it | 21:03 |
| smoser | do udev events have timestamps on them? | 21:04 |
| smoser | ie, when the kenrel fired this event, could i get a timestamp of when it did it ? | 21:04 |
| smoser | because then, if i could, and verify that no events came from the kernel *after* mount/umount, then i'd know that it wasn't during that | 21:04 |
| slangasek | smoser: what you see in /var/log/udev is what you get | 21:05 |
| slangasek | so there's a "time since boot" in the header line | 21:05 |
| smoser | but is that udev recieved ? | 21:06 |
| smoser | or kernel generated | 21:06 |
| slangasek | udev received | 21:07 |
| smoser | well, at least its something | 21:07 |
| slangasek | broder: so on second thought, I think I actually want this scan done against Debian unstable anyway :-) | 21:07 |
| smoser | i'll add some 'cat /proc/uptime' and see if i cant dgrock anything from it. | 21:07 |
| smoser | slangasek, thank you for your help, btw | 21:07 |
| broder | slangasek: ah, can't help you there | 21:08 |
| slangasek | broder: yep - no worries | 21:09 |
| TheMuso | infinity: Done. | 21:13 |
| infinity | TheMuso: \o/ | 21:13 |
| smoser | slangasek, http://paste.ubuntu.com/859728/ | 21:14 |
| smoser | thats pastebin of console output of this instance at | 21:14 |
| slangasek | smoser: doesn't let me in | 21:15 |
| smoser | ubuntu@10.55.60.167 | 21:16 |
| smoser | (sorry, was slow) | 21:16 |
| smoser | slangasek, ^ | 21:16 |
| smoser | but that one didn't catch the blkid in 'ps' | 21:17 |
| slangasek | pulled the IP from the log :) | 21:17 |
| slangasek | but it's still not letting me ssh in | 21:17 |
| smoser | slangasek, vorlon@dario.dodds.net as your ssh id ? | 21:31 |
| smoser | slangasek, and i did get a failed resize | 21:32 |
| smoser | after move to pre-mount | 21:32 |
| smoser | 2 out of 29 | 21:32 |
| slangasek | smoser: yes - it lets me in now where it didn't before | 21:32 |
| slangasek | hmm, curiouser and curiouser | 21:33 |
| smoser | unfortunately, that ami doesn't have the 'ps -w' in it | 21:34 |
| smoser | so i dont have ps output | 21:34 |
| smoser | hm.. | 21:36 |
| smoser | slangasek, one thing. | 21:36 |
| smoser | i did not 'udevadm settle' before sfdisk in pre-mount | 21:36 |
| ricotz | slangasek, hello | 21:52 |
| ricotz | slangasek, do you know why libpst wasnt updated since karmic? https://launchpad.net/ubuntu/+source/libpst | 21:52 |
| ricotz | i am pinging you because you are one who touched it ;) | 21:53 |
| seb128 | ricotz, because nobod maintains it in Ubuntu and Debian doesn't have a newer version so most likely nobody noticed it was outdated | 21:55 |
| slangasek | smoser: just a hunch... can you call sfdisk with --no-reread? | 21:56 |
| seb128 | ricotz, there is no bug open asking for an update either | 21:56 |
| smoser | we had another bug on that. | 21:56 |
| slangasek | ricotz: what seb128 said; the only thing I touched on the package was to fix a build failure | 21:56 |
| infinity | slangasek: Oh hey, jasper does that too. | 21:56 |
| ricotz | seb128, i see, i guess this is worth an update | 21:56 |
| infinity | slangasek: I wonder if there may have been a reason. :P | 21:56 |
| seb128 | ricotz, you are welcome to work on that, I would be happy to review,sponsor your update ;-) | 21:57 |
| seb128 | ricotz, it might require a ffe if the update is not only bug fix though | 21:57 |
| smoser | https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/906722 slangasek <-- | 21:57 |
| ricotz | seb128, alright, this version is from karmic ;) | 21:57 |
| ubottu | Launchpad bug 906722 in cloud-initramfs-tools (Ubuntu) "root partition is not being grown" [High,Fix released] | 21:57 |
| ricotz | seb128, fta updated it for some testbuilds of evolution 3.3 which requires this newer version | 21:58 |
| seb128 | ok | 21:58 |
| slangasek | smoser, infinity: by default, sfdisk calls ioctl(BLKRRPART) before it edits things, and again *after*... and if the ioctl is itself triggering a udev change, then there's nowhere in your script to intercept it because it's happening while a single sfdisk command is running | 21:59 |
| ricotz | seb128, alright, i have a look | 21:59 |
| seb128 | ricotz, thanks | 21:59 |
| smoser | slangasek, oh. yuck. | 21:59 |
| smoser | i didn't realize that. | 21:59 |
| smoser | that sucks. | 21:59 |
| smoser | so that is a general issue with sfdisk then | 22:00 |
| smoser | that will fail at other times also | 22:00 |
| smoser | as the first will *cause* the second to fail | 22:00 |
| smoser | slangasek, so i'm guessing you're looking at code | 22:01 |
| slangasek | smoser: again, if there haven't been any geometry changes, and the ioctl causes this problem, I think you're looking at a kernel bug | 22:01 |
| slangasek | (and the first time we call the ioctl, there shouldn't be any geometry changes) | 22:01 |
| slangasek | yep | 22:02 |
| smoser | slangasek, actually i'm almost certain that it does cause udev events | 22:02 |
| smoser | hold on. thats easy to check | 22:02 |
| slangasek | it shouldn't, because nothing has changed | 22:02 |
| slangasek | you only want change events when the geometry has actually changed; the kernel should be smarter about that | 22:02 |
| slangasek | anyway, --no-reread is correct for what you're doing | 22:03 |
| slangasek | the extra reread is pointless here because you know the state of the system in the initramfs | 22:03 |
| smoser | yeah. | 22:03 |
| smoser | and it doesn't seem to. | 22:03 |
| smoser | slangasek, so your theory here is that if i add '--no-reread', and that fixes it | 22:05 |
| smoser | then all we're doing is masking a kernel bug | 22:05 |
| slangasek | well, we're fixing a minor bug in the invocation of sfdisk, and confirming a bug in the kernel | 22:05 |
| smoser | ok. so, i'll poke at this a bit later. | 22:06 |
| smoser | you think 'growpart' should generically pass that ? | 22:07 |
| slangasek | yes | 22:07 |
| smoser | as it is accounting for failure, and replacing it | 22:07 |
| smoser | (ie, growpart wont always only be called from initramfs, or at least that was a goal in writing it) | 22:07 |
| slangasek | well | 22:08 |
| slangasek | I think I would assume that the disks are in a sane state before someone's called growpart on them anyway | 22:08 |
| slangasek | but if you think that's not a safe assumption, growpart can grow an option itself | 22:08 |
| smoser | right. i think probably sane, or maybe add a '--no-no-reread' | 22:09 |
| smoser | :) | 22:09 |
| broder | jdstrand: ah, sorry bug #884402 got left in the queue - i've been meaning to deal based on russ's feedbac | 22:11 |
| ubottu | Launchpad bug 884402 in shibboleth-sp2 (Ubuntu) "package libapache2-mod-shib2 2.4.3+dfsg-1ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [Undecided,Triaged] https://launchpad.net/bugs/884402 | 22:11 |
| broder | (we managed to convince him that his postinst was wrong, but we can't just sync it because there are significant pending changes on the debian side) | 22:11 |
| geser | infinity: it got sponsored before I could add a debdiff with a complete changelog, so I didn't replace the debdiff afterwards | 22:25 |
| geser | infinity: I'll update the debdiff if you reject the current upload | 22:26 |
| infinity | geser: I already fixed it. | 22:26 |
| geser | thx | 22:27 |
| geser | will remember on future merges to keep old changelog entries forever | 22:39 |
| seb128 | geser, why so? | 22:41 |
| geser | seb128: I dropped old changelog entries (800 lines of Ubuntu changelog entries from lucid back to warty) in my last vim merge which infinity prefers to keep | 22:43 |
| seb128 | ok, we drop those for desktop and I do the same for other stuff I merge usually | 22:43 |
| seb128 | so I take a not to not merge stuff infinity's maintains ;-) | 22:43 |
| infinity | geser: I'm not sure that's necessary (or even desirable) for most packages/mergs, but vim's a special and weird case. ;) | 22:43 |
| infinity | seb128: Surely, you remember the upload wars to all get in in the same 5-minute window and see whose vim would get accepted? :P | 22:44 |
| seb128 | lol | 22:44 |
| infinity | geser: Anyhow, yeah. Not a big deal, and not a policy, per se, to retain changelogs for ever (unless they actually still reference our delta in some meaningful way), but there's some old skool project nostalgia with vim specifically. | 22:45 |
| infinity | geser: And possibly base-files. ;) | 22:45 |
| === salem_ is now known as _salem | ||
| geser | infinity: I would have expected setting background=dark for vim by default would cause more discussion than my trimming of old changelog entries | 22:48 |
| infinity | geser: Nah, because background=dark is the One True Way. | 22:49 |
| infinity | geser: People with white terminals are wrong. Full stop. | 22:49 |
| infinity | geser: (And as this is clearly a religious argument, not a scientific one, there's no need for me to back up that assertion with evidence, and it's protected by various constitutions!) | 22:50 |
| infinity | geser: Of course, it could also be that it's still sitting in the unapproved queue. | 22:51 |
| geser | infinity: so no objections for background=light for gvim either (or do you don't care about gvim)? | 22:54 |
| infinity | geser: That seems reasonable as a default, but I don't use gvim, which is probably why I don't care. ;) | 22:56 |
| slangasek | infinity: can you think of a way offhand to get dash to read contents from a file and pass the contents to another command on the commandline, without forking to get the file contents? | 23:07 |
| slangasek | ( $(< /path/to/file) is a bashism ) | 23:08 |
| broder | slangasek: doesn't $(< /path/to/file) fork? | 23:11 |
| slangasek | broder: shouldn't | 23:12 |
| broder | oh i see. i didn't realize that was special-cased syntax | 23:12 |
| slangasek | there's no command | 23:12 |
| slangasek | you're just asking for the contents of the file | 23:13 |
| broder | i figured it was a shortcut for $(exec </path/to/file) or something | 23:13 |
| slangasek | broder: I don't suppose you can think of a more posix-y way to do this? :) | 23:14 |
| broder | i assume the lack of forking is important? | 23:14 |
| slangasek | broder: upstart :/ | 23:16 |
| broder | expect daemon and add another fork somewhere? :) | 23:18 |
| slangasek | it already needs to be expect daemon | 23:18 |
| jdstrand | @pilot out | 23:18 |
| === udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect. 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: | ||
| broder | aren't you good, then? i thought upstart was fine with several forks before the actual double-fork happened | 23:19 |
| slangasek | broder: no, it counts forks | 23:21 |
| SpamapS | broder: nope, 1 or 2.. or 'tis broken | 23:21 |
| SpamapS | I really wish we could just trust daemons to tell us what their main pid is (i.e., pidfiles) | 23:22 |
| broder | err, i wasn't clear. i meant rather that you could fork off stuff in the script section as long as none of them forked again | 23:22 |
| infinity | slangasek: Of the top of my head, I can't think of a way to do that without forking. :/ | 23:28 |
| * slangasek nods | 23:29 | |
| infinity | slangasek: http://paste.ubuntu.com/859877/ ? | 23:39 |
| infinity | slangasek: Or is FD manipulation out too? | 23:39 |
| slangasek | infinity: no, that's acceptable as long as it doesn't trigger a fork :) | 23:40 |
| slangasek | let's see, can I just do while read ... do done < $FILE without generating a subshell? | 23:41 |
| infinity | slangasek: Maybe? | 23:42 |
| infinity | strace doesn't look forky to me. | 23:44 |
| slangasek | yep, that does the trick | 23:45 |
| slangasek | evil | 23:45 |
| slangasek | infinity: thanks :) | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
