| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === jamesh_ is now known as jamesh | ||
| mwhudson | bah | 03:05 |
|---|---|---|
| mwhudson | second hang today in raring :( | 03:05 |
| pitti | Good morning | 04:49 |
| pitti | infinity: I don't remember that conversation TBH; what would empty ddebs be good for? | 04:50 |
| infinity | pitti: For 1:1 mapping of binaries to ddebs, I suppose. | 05:04 |
| infinity | pitti: How else does apport-retrace magically find debug symbols? | 05:04 |
| pitti | infinity: it tries -dbg, and if that doesn't exist, -dbgsym | 05:05 |
| infinity | pitti: But -dbg is often mapped to source package. It gets that right? Fair enough. | 05:05 |
| infinity | pitti: In that case, we just shouldn't have ddebs at all for sources that produce -dbg, but that doesn't seem to be true either. | 05:05 |
| pitti | takes some binary<->source mapping, but it's mostly working okay | 05:05 |
| pitti | yeah, some more consistency there couldn't hurt | 05:06 |
| infinity | pitti: I still sort of like the ddeb->dbg mapping idea, just because it give you a consistent interface to debug symbols. | 05:07 |
| infinity | pitti: So, if I have libfoo1 installed, I can install libfoo1-dbgsym and not worry about the fact that the debug symbols are actually in foosrc-dbg | 05:07 |
| pitti | yeah, fair enough | 05:07 |
| pitti | that should actually be not too har | 05:07 |
| pitti | d | 05:08 |
| pitti | we already compute that mapping to place the Conflicts:, after all | 05:08 |
| infinity | Exactly. | 05:08 |
| pitti | so we'd just need to swap this around to a Depends:, and make it empty | 05:08 |
| infinity | So, you just flip the Conflict to a Depends and em... That. | 05:08 |
| infinity | pitti: The motivation here was making sure we don't have duplicate gratuitously huge packages stuffed in the librarian, but it also seems vaguely close to an elegant solution, until someone talks Debian into ddebs. | 05:09 |
| pitti | sounds good | 05:10 |
| pitti | infinity: how are things looking wrt. ddebs in the librarian now? | 05:15 |
| infinity | wgrant: ^ | 05:19 |
| === mmrazik is now known as mmrazik|afk | ||
| wgrant | pitti, infinity: There are a couple of override bugs left. Will hopefully sort them out early next week unless more things come up. | 05:20 |
| wgrant | And we need to check with IS that the SAN is prepared to die. | 05:20 |
| infinity | wgrant: Yeahp, leave IS to Pete and I. | 05:21 |
| pitti | ah, thanks for the heads-up | 05:21 |
| infinity | wgrant: That timeline works for me, though. | 05:21 |
| wgrant | Oh, and need to stop them from actually hitting disk, but that's trivial | 05:22 |
| wgrant | The override bugs are the messy bit | 05:22 |
| infinity | pitti: If we could do the empty-ddeb thing before we land wgrant's shiny in production, then we'll never have duplicate debug symbols in the librarian, that'll make elmo happier. | 05:22 |
| wgrant | What empty ddeb thingZ? | 05:22 |
| infinity | wgrant: Scroll back. | 05:22 |
| wgrant | If there's a -dbg then pkgbinarymangler will just produce empty ddebs depending on the -dbg? | 05:22 |
| wgrant | s/pkgbinarymangler/pkg-create-dbgsym/ | 05:23 |
| infinity | *nod* | 05:23 |
| infinity | Whereas, right now, you end up with two massive debug packages. | 05:23 |
| pitti | ok, putting that on my list then | 05:23 |
| wgrant | I think -dbgs should just die instead, but... | 05:23 |
| infinity | wgrant: Carrying that as a delta from Debian would be insanity. | 05:23 |
| wgrant | Certainly | 05:23 |
| infinity | wgrant: So, this is a decent workaround until Debian gets off the pot about their own ddebish thing. | 05:23 |
| wgrant | But we can hope that Debian might adopt something like our 7 year old working solution eventually | 05:24 |
| wgrant | Right | 05:24 |
| * pitti adjusts bug 1003234 | 05:24 | |
| ubottu | bug 1003234 in pkg-create-dbgsym (Ubuntu) "Build dummy -dbgsym for packages which already have a -dbg" [Medium,In progress] https://launchpad.net/bugs/1003234 | 05:24 |
| pitti | in fact, there had been a GSoC Debian project about this already | 05:24 |
| RAOF | I suppose it's too much to expect Debian to actually implement something ddebish in the next (Debian) release cycle, isn't it. :/ | 05:24 |
| pitti | but just like so many of them, it seems to have died | 05:24 |
| infinity | wgrant: There's near unanimous agreement among most DDs that ddebs (or something like) are a Good Thing, just the usual faffing about with implementation concerns. | 05:25 |
| infinity | RAOF: I think the best way for it to happen in Debian will be for someone to just put together a working set of patches to dak and debhelper and let it speak for itself. | 05:26 |
| infinity | RAOF: Our motivation to do so it low, since we have a vaguely working solution (though the debhelper integration could probably be a bit more joeyh-friendly). | 05:26 |
| infinity | RAOF: But maybe one of us should try to bridge that gap anyway. | 05:27 |
| RAOF | Right. And my only motivation would be because someone asked for a colord-dbg package, and I thought that it was goddamed ridiculous that I needed to do that. | 05:27 |
| infinity | pitti: Hah, I knew we'd had this conversation before. | 05:28 |
| infinity | pitti: And there was even a bug to prove it. :P | 05:28 |
| pitti | yeah, LP clearly beats my brain :) | 05:28 |
| pitti | or, my brain forgets things once they are noted down :) | 05:28 |
| infinity | pitti: A sane implementation for Debian might need to be split into two helpers instead of one. | 05:31 |
| infinity | pitti: I just thought of a fun corner case we don't handle. | 05:31 |
| pitti | what would be the second one? | 05:31 |
| pitti | non-debhelper packages? | 05:31 |
| infinity | pitti: dpkg-gencontrol -v | 05:31 |
| infinity | pitti: Your dbgsym depends on the deb with an = relationship to make sure they match (I assume, right?), but that won't be right if people mangle the version after dh_strip. | 05:32 |
| pitti | oh, that | 05:32 |
| pitti | indeed | 05:32 |
| infinity | pitti: So, the Right Way would be to have a strip helper set the bits aside, but build the actual packages at builddeb time. | 05:32 |
| YokoZar | I'm a bit surprised that apt-key update actually does anything (in my case it just made apt-get update work again on a raring system) | 06:17 |
| YokoZar | naively I expected that sort of thing to always be done already | 06:18 |
| bkerensa | pitti: ping | 06:19 |
| pitti | bkerensa: hello | 06:19 |
| bkerensa | pitti: PM maybe? | 06:19 |
| pitti | sure | 06:19 |
| pitti | slangasek, stgraber: fixed udev uploaded for dynamic ACLs; oops! I'll see if I can write an autopkgtest for this | 06:54 |
| === mmrazik|afk is now known as mmrazik | ||
| * hyperair just realized there's a libc6-x32 package | 07:50 | |
| hyperair | do we have anything using it? | 07:50 |
| hyperair | oh, ew, we have libx32foobar | 07:51 |
| hyperair | this reeks of the pre-multiarch days | 07:51 |
| === amitk is now known as amitk-afk | ||
| === zequence_ is now known as zequence | ||
| === chris|| is now known as chris| | ||
| === ubott2 is now known as ubottu | ||
| === henrix_ is now known as henrix | ||
| === weaselTM is now known as weasel | ||
| === mmrazik_ is now known as mmrazik|afk | ||
| === buxy_bak is now known as buxy | ||
| === amitk-afk is now known as amitk | ||
| === ivoks_ is now known as ivoks | ||
| mitya57 | Mirv: around? | 09:46 |
| Mirv | mitya57: here | 09:48 |
| mitya57-mobile | Mirv: I've packaged qttranslations5 | 09:48 |
| mitya57-mobile | github.com/mitya57/qttranslations-pkg | 09:49 |
| Mirv | mitya57-mobile: \o/ awesome! that was indeed the last one missing | 09:49 |
| mitya57-mobile | can you please push it to pkg-kde git? | 09:49 |
| Mirv | mitya57-mobile: will do, thanks a lot! | 09:50 |
| mitya57-mobile | also, svuorela says he'll add me to the team if you ask him, so you may do that instead :) | 09:50 |
| Mirv | mitya57-mobile: http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qttranslations.git;a=summary | 09:51 |
| Mirv | mitya57-mobile: ok, asking :) | 09:51 |
| Mirv | mitya57-mobile: have you applied? | 09:51 |
| mitya57-mobile | not, let me apply | 09:51 |
| mitya57 | done | 09:54 |
| * mitya57 has a terrible wifi connection so has to use 2 devices :) | 09:55 | |
| mitya57 | Mirv: also, do you know what's the status of qtdoc? i.e. is there anything blocking the upload? | 09:58 |
| Mirv | mitya57: I don't know anything blocking as such (after installing it it shows up in qt creator for example) | 09:59 |
| mitya57 | ok, then my last question: when will we sync everything from debian? | 10:00 |
| jtaylor | are our builders still running hardy kernels or have they been updated? | 10:00 |
| mitya57 | (as your blog post says, it's everything except two or three packages) | 10:00 |
| mitya57 | Mirv: or should I file a sync request myself? | 10:05 |
| Mirv | mitya57: I think the order would be a) upload qtbase from lp:~kubuntu-packagers, b) sync those that can be synced (eg. qtxmlpatterns, qtscript, maybe qtjsbackend) / upload those that can't (qtdeclarative, qtwebkit, ..) | 10:08 |
| Mirv | mitya57: but first I'm trying to get all build for saucy at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta-proper once | 10:08 |
| Mirv | I think the uploads/syncs could be started already, but I'd kind of like seeing eg. ubuntu touch image functional on top of that PPA before starting new uploads to saucy | 10:09 |
| Mirv | and that'd be around late next week | 10:10 |
| Mirv | since it's the main Qt5 user at the moment | 10:10 |
| Mirv | there would be also a need to revisit the syncing, both Debian and us have some new changes after the last sync | 10:10 |
| mitya57 | Mirv: the plan looks good to me | 10:11 |
| mitya57 | Mirv: I will now look if we have some delta we have some unforwarded changes | 10:12 |
| mitya57 | *if we have some delta or unforwarded changes | 10:12 |
| * mitya57 looks if there are some build failures in the ppa he can help with | 10:13 | |
| mitya57 | there is a qtwebkit ftbfs in <= quantal | 10:14 |
| Mirv | mitya57: thanks! I'm not immediately thinking of anything else than qtbase's gcc 4.8 fix that may be interesting, but it's mostly just that another pair of eyes looking at the diff wouldn't hurt ever | 10:14 |
| Mirv | (gcc 4.8 is coming early enough to Debian so that the fix does make sense before Qt 5.1 release) | 10:15 |
| Mirv | mitya57: that <= quantal armhf failure appeared with 5.0.2. not sure if it's actually relevant to either Ubuntu or Debian | 10:15 |
| Mirv | we don't use <= quantal on armhf anymore, and Debian sid should be around raring or newer | 10:15 |
| mitya57 | dpkg-deb: building package `libqt5webkit5-dbgsym' in `../libqt5webkit5-dbgsym_5.0.2-0ubuntu1~quantal1~test5_armhf.ddeb'. | 10:15 |
| mitya57 | tar: ./usr/lib/debug/.build-id/63/1c4bc8259068bd755f8ac650310f8e62ac0fad.debug: File shrank by 1077493997 bytes; padding with zeros | 10:15 |
| mitya57 | weird | 10:15 |
| Mirv | yeah, those also sound like random arm builder failures which have happened before. pretty weird anyhow. | 10:16 |
| === mmrazik|afk is now known as mmrazik | ||
| mitya57 | Mirv: in Debian qttools is missing add_license_files.patch | 10:24 |
| mitya57 | (ah, a similar patch should also be applied to qttranslations, will do it later today) | 10:25 |
| mitya57 | the same for qtxmlpatterns, plus the d/copyright doesn't have an entry for *.qdoc | 10:30 |
| Mirv | mitya57: they should be now all in 5.0.2, as I submitted them upstream to all modules | 10:32 |
| Mirv | mitya57: debian's qtxmlpatterns does also have *.qdoc entry, I think it just changed places | 10:33 |
| Mirv | mitya57: are you up-to-date on the branches, I removed the license patch already from qttools? | 10:33 |
| mitya57 | right, ignore that | 10:34 |
| mitya57 | I'm reading commit messages, not files :) | 10:34 |
| Mirv | :=) | 10:34 |
| Mirv | what I've done is just pure manual diff -urN debian/qtxmlpatterns/debian/ ubuntu/qtxmlpatterns/debian/ | 10:35 |
| Mirv | if there's only changelog, maintainer and vcs-bzr changes, then there's nothing to consider | 10:35 |
| mitya57 | Mirv: this is definitely missing from Debian: https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/qtjsbackend-opensource-src/saucy/revision/3/debian/control | 10:36 |
| Mirv | mitya57: true, and there are some other packages with similar arch defs and those are not in Debian yet | 10:37 |
| mitya57 | I can fix that myself if I get commit rights :) | 10:38 |
| mitya57 | Mirv: "they should be now all in 5.0.2, as I submitted them upstream to all modules" — qttranslations 5.0.2 doesn't have any license file :( | 10:39 |
| Mirv | mitya57: oh? :( it was merged, but maybe it's in 5.1 only https://codereview.qt-project.org/#change,47243 | 10:40 |
| Mirv | right, it took some time over there, longer than with some others | 10:40 |
| mitya57 | Mirv: I've DEP5-ified your patch and pushed to my github branch | 10:51 |
| mitya57 | ok, I don't see any delta in !base !webkit except for the Architecture: one | 10:56 |
| mitya57-mobile2 | doko_: someone in gnome bug 697475 asks me to ping you debian #675008 | 11:19 |
| ubottu | Gnome bug 697475 in general "New tab is not opened in same directory as previous tab" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=697475 | 11:19 |
| ubottu | Debian bug 675008 in bash "bash: should handle /etc/bashrc.d (or similar) for non-login interactive shell" [Wishlist,Open] http://bugs.debian.org/675008 | 11:19 |
| === tkamppeter__ is now known as tkamppeter | ||
| mitya57-mobile2 | s/someone/gnome-terminal upstream developer/ | 11:27 |
| === pete-woods1 is now known as pete-woods | ||
| === _salem is now known as salem_ | ||
| === zyga_ is now known as zyga | ||
| === pete-woods1 is now known as pete-woods | ||
| === francisco is now known as Guest3991 | ||
| zyga | rsalveti: ping | 12:48 |
| zyga | pitti: around? | 12:49 |
| pitti | zyga: hey | 12:49 |
| zyga | pitti: we need a second opinion on debian packaging question, would you mind looking at something? | 12:49 |
| pitti | just ask :) | 12:50 |
| zyga | pitti: http://bazaar.launchpad.net/~sylvain-pineau/checkbox/plainbox-packaging-policy/revision/11 | 12:50 |
| zyga | pitti: two packages provide one file | 12:50 |
| zyga | pitti: both provide a virtual package | 12:50 |
| zyga | pitti: how should Conflicts/Replaces look like | 12:50 |
| pitti | Usually Conflicts:/Provides:/Replaces: virtual-package-name | 12:51 |
| zyga | pitti: according to http://www.debian.org/doc/debian-policy/ch-relationships.html (7.6.2) it looks okay | 12:51 |
| zyga | pitti: ok thanks, that's all I wanted to know | 12:51 |
| pitti | that means "you can only install one of the "providers" at a time | 12:51 |
| zyga | exactly | 12:52 |
| pitti | zyga: you need those on plainbox-secure-policy too, though | 12:52 |
| zyga | oh | 12:52 |
| pitti | i. e. the C/R | 12:52 |
| pitti | maybe apt can figure out that direction from the other direction, but it's best to just keep it completely symmetric | 12:53 |
| === greyback is now known as greyback|lunch | ||
| ogra_ | is plainbox the new name ? | 12:53 |
| zyga | ogra_: plainbox is a core library for new checkbox | 12:53 |
| zyga | ogra_: and a development tool for test authors | 12:53 |
| ogra_ | ah, nice | 12:53 |
| * ogra_ thought you were renaming ... and it sends you cash instead of cheques now :) | 12:54 | |
| zyga | ogra_: we also have jobbox and cloudbox :) | 12:55 |
| ogra_ | haha | 12:55 |
| zyga | ogra_: so jobbox has the data for checkbox which is using plainbox insternally | 12:55 |
| zyga | ogra_: and cloudbox is up up in the sky^Hcloud | 12:55 |
| ogra_ | neat | 12:56 |
| Mirv | mitya57: can you be at OFTC network as well and join #debian-qt-kde? | 13:04 |
| mitya57 | Mirv: I'm on #debian-kde, didn't know that there are two channels :) | 13:05 |
| mitya57 | joined | 13:05 |
| stgraber | pitti: thanks! | 13:11 |
| === doko_ is now known as doko | ||
| === greyback|lunch is now known as greyback | ||
| mitya57 | Mirv: what's happening there? are they going to add me? :P | 13:25 |
| Mirv | mitya57: if I read correctly, since they don't know yet (before yesterday) they prefer if you continue to commit via me for now. so I guess let's continue so that I review and push your git changes, and we'll ask later about approving. | 13:32 |
| mitya57 | Mirv: ok, then please push my updated qttranslations branch | 13:32 |
| ScottK | pitti: Did the retracers die again? 1176464 is waiting several days for retrace. | 13:33 |
| pitti | slangasek, cjwatson: I'm currently packaging/testing a current udev (working well so far, just two remaining patches to port, but I got all the other bits sorted out) | 13:33 |
| pitti | ScottK: checking.. | 13:33 |
| Mirv | mitya57: done | 13:33 |
| pitti | slangasek, cjwatson: by default, it now uses the BIOS/vendor/slot based network interface naming, e. g. in qemu you get "ens3" (cf. biosdevname) | 13:33 |
| ScottK | Thanks | 13:34 |
| pitti | slangasek, cjwatson: right now I set it up so that on upgrades that is disabled, i. e. you still get "ethN", with possibly a 70-persistent-network.rules; but on new installs I'd like to enable the new names, as they are more persistant and also easier to remember; opinions? | 13:34 |
| pitti | ScottK: so it did, restarting | 13:35 |
| pitti | argh unreliable cron mail | 13:35 |
| ScottK | Great. | 13:35 |
| pitti | slangasek, cjwatson: also, the generator for 70-persistent-net.rules doesn't exist any more (an existing file still works, of course) | 13:51 |
| === kentb-out is now known as kentb | ||
| stgraber | pitti: I'd be very very careful about that kind of new interface naming. We did something similar on a very limited subset of servers a while back with biosdevname and that resulted in quite a few bugs | 13:57 |
| stgraber | don't underestimate the number of tools that look for eth* | 13:58 |
| ogra_ | whats the new interface name ? | 14:02 |
| * ogra_ found ethX always quite descriptive) | 14:03 | |
| pitti | it's derived from ACPI/BIOS/vendor properties, i. e. it's named like the product name and the slot | 14:03 |
| ogra_ | describing an ethernet interface at least :) | 14:03 |
| pitti | therefor it's easier to see what is what, and the numbering is persistant | 14:03 |
| ogra_ | but you wont know which media it uses now | 14:03 |
| pitti | there has been a discussion about this on u-devel@ quite some time ago ("biosdevname") | 14:03 |
| ogra_ | which the old name told you | 14:03 |
| pitti | well, it still starts with "e" or "w" AFAIK | 14:04 |
| ogra_ | ah | 14:04 |
| ogra_ | so how would that work on arm ? | 14:04 |
| ogra_ | :) | 14:04 |
| pitti | it wouldn't | 14:05 |
| pitti | it would just continue to be called ethN | 14:05 |
| ogra_ | it could | 14:05 |
| pitti | this only works if the acpi/bios actually defines a name | 14:05 |
| ogra_ | you would just have to pull it out of the platform data | 14:05 |
| pitti | ah, sure | 14:05 |
| ogra_ | (which you could possibly also do for x86 and had a consistent arch independent interface) | 14:06 |
| pitti | well, I don't know which interface it currently uses | 14:06 |
| mitya57 | does anybody here know how britney works? | 14:06 |
| pitti | perhaps this already works | 14:06 |
| ogra_ | heh | 14:06 |
| mitya57 | if I have a package that is "Architecture: i386, amd64, armhf", change it to "any", and it will FTBFS, will britney allow it to -release? | 14:06 |
| ogra_ | we'd see if we had any arm builds that used a recent kernel :) | 14:07 |
| ogra_ | oh, wait, server might have one | 14:07 |
| mitya57 | (the case is qtjsbackend-opensource-src, where the Architecture line is the only diff with Debian, and Debian maintainers refuse to add it) | 14:08 |
| stgraber | mitya57: britney will prevent the migration of any package that has one or more FTBFS | 14:10 |
| mitya57 | stgraber: it will be more logical if it prevented only packages with regressions | 14:11 |
| mitya57 | (i.e. previous version built, but current doesn't) | 14:11 |
| mitya57 | <mitya57> I think we need it in Ubuntu, because if package FTBFS on powerpc, it won't migrate from -proposed to -release | 14:12 |
| mitya57 | <pinotree> fix the ubuntu architecture then | 14:12 |
| mitya57 | <mitya57> it's pretty normal to not release a package if it FTBFSes, isn't it? | 14:12 |
| mitya57 | <pinotree> if it doesn't build and it never did, on debian is not a RC bug | 14:12 |
| stgraber | well, just keep the delta with Debian then, a one line change like this won't cost us much to merge | 14:13 |
| pitti | we could also P-a-s it? | 14:19 |
| pitti | or doesn't that exist any more? | 14:19 |
| debfx | are you sure it won't migrate such packages to release? when you look at the ftbfs page you see lots of packages that migrated even though there are build failures. | 14:19 |
| ogra_ | i think it still does (iirc it also defines sync exclusions) | 14:19 |
| === mmrazik is now known as mmrazik|afk | ||
| stgraber | I believe we have/had an exception for powerpc because of build slowness (though not that relevant anymore thanks to sagari), we've also been pushing some stuff from proposed to release even though one arch FTBFSed | 14:22 |
| stgraber | cjwatson would know for sure but he's out till Monday | 14:22 |
| mitya57 | ok, we'll sync with Debian, and if something goes wrong, reintroduce the delta | 14:25 |
| mitya57 | Mirv: ^ | 14:25 |
| Mirv | mitya57: ok, sounds god | 14:49 |
| Mirv | +o | 14:50 |
| mitya57 | ok, I have to go now | 14:50 |
| === wedgwood_away is now known as wedgwood | ||
| jwp | Hi there! I want to build a SW package with a newer version than the existing one Ubuntu 12.10 default distro, and make it available through an Ubuntu repository. Newer versions of this package already exist in Ubuntu 13.04 and the latest on Debian. Can any one help doing this? I was trying to follow this HOWTO : https://wiki.ubuntu.com/MeetingLogs/devweek1107/MergingFromDebian | 15:38 |
| jtaylor | jwp: if it is already packaged in 13.04 backport is the way to go | 15:39 |
| jtaylor | https://wiki.ubuntu.com/UbuntuBackports | 15:39 |
| jwp | Ok, I will try that, but the latest is only available in Debian... | 15:40 |
| jtaylor | jwp: it will go into 13.10 then soon | 15:41 |
| jtaylor | from there it can be backported too | 15:41 |
| apw | doko, do i remember correctly when i remember you saying that gcc-4.8 should be ok for my arm builds now ? | 15:59 |
| doko | apw, I did say, that the warning issue was addressed | 15:59 |
| apw | doko, ahh now that makes more sense than what i was remembering, thanks | 16:00 |
| apw | doko, are the crosscompilers updated too? as i was hitting that one there as well i believe | 16:00 |
| doko | apw, I think it would be better to check if a recent 3.9 kernel works on arm when built with 4.8 | 16:01 |
| doko | then see, what probably needs backporting to 3.4 | 16:01 |
| apw | doko, yep that is meant to be being test, but has not yet | 16:01 |
| === mmrazik|afk is now known as mmrazik | ||
| jtaylor | are builders still running hardy kernels or have all been updated? | 16:07 |
| ScottK | IIRC, except for powerpc, they were all updated to lucid and then precise after they were released. | 16:09 |
| bdmurray | ubuntu-release-upgrader requires some free space in /tmp for dkms. Does 5M seem like enough? I'm not very familiar with how much space dkms modules need to build. | 16:09 |
| jtaylor | so powerpc still has hardy? | 16:10 |
| jtaylor | need to know for zeromq, they have some ugly compile time kernel feature check | 16:12 |
| jtaylor | SOCKCLOEXEC, which is not there on hardy | 16:12 |
| ScottK | jtaylor: No, I think ppc is on precise now too, but they ran dapper until close to when it EOLed. | 16:16 |
| ScottK | I don't think they ever ran hardy. | 16:16 |
| jtaylor | k then I can drop the runtime detection patch (upstream never accepted it) | 16:17 |
| jtaylor | thx | 16:17 |
| === masACC is now known as maswan | ||
| * mdeslaur hugs barry for PEP 435 | 16:52 | |
| jdstrand | tedg: hey, so I was playing with http://gould.cx/ted/blog/Application_Centric_User_Experience | 17:00 |
| jdstrand | tedg: specifically with: | 17:01 |
| jdstrand | $ start application APP_ID=gedit | 17:01 |
| jdstrand | $ stop application APP_ID=gedit | 17:01 |
| jdstrand | and those work great | 17:01 |
| jdstrand | tedg: however, if I do: | 17:01 |
| jdstrand | $ start application APP_ID=gedit | 17:01 |
| jdstrand | then close gedit without using 'stop', upstart gets cranky | 17:01 |
| tedg | jdstrand, Yeah, that's a known bug right now. I switched it to desktop files, and apparently the glib function there does 9 forks, which confuses upstart. | 17:02 |
| jdstrand | tedg: this is because of: http://upstart.ubuntu.com/cookbook/#expect | 17:02 |
| tedg | jdstrand, I need to make it so that we just do it the simple way and don't fork'ing fork so much. | 17:02 |
| jdstrand | tedg: ok, yeah, it was 7 here, but glad you know | 17:02 |
| tedg | Yeah, the best laid plans to clean things up :-) | 17:03 |
| jdstrand | I adjusted desktop-exec to use raise(SIGSTOP) so I could do 'expect stop', but then 'stop application APP_ID=gedit' didn't work | 17:03 |
| jdstrand | which, makes sense | 17:03 |
| jdstrand | anyhoo, it's known, so I'm good for now :) | 17:04 |
| tedg | Hmm, yeah. Good idea. | 17:04 |
| jdstrand | 7-9 forks feels excessive btw | 17:04 |
| jdstrand | :) | 17:04 |
| jdstrand | maybe we need 'expect 7-9 forks' :P | 17:05 |
| === wedgwood is now known as wedgwood_away | ||
| barry | mdeslaur: :) | 17:30 |
| psusi | so can we finally kill hal this cycle? ;) | 17:41 |
| psusi | it's only been 4 years ;) | 17:42 |
| infinity | psusi: I beleive that's one of pitti's big goals this cycle, yeah. | 17:51 |
| psusi | thank god. | 17:51 |
| === wedgwood_away is now known as wedgwood | ||
| === ewindisch_ is now known as ewindisch | ||
| === directhe` is now known as directhex | ||
| === ricotz_ is now known as ricotz | ||
| === lool- is now known as lool | ||
| === wedgwood is now known as wedgwood_away | ||
| geser | is it intended to have/keep "fglrx-legacy-driver" in multiverse? (it got synced from non-free into saucy) | 19:40 |
| === jono is now known as Guest28737 | ||
| === wedgwood_away is now known as wedgwood | ||
| === salem_ is now known as _salem | ||
| === kentb is now known as kentb-out | ||
| slangasek | pitti: thanks for the udev fix :) | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!