| teward | infinity: ping | 00:25 |
|---|---|---|
| xnox | balloons: hey! | 00:28 |
| xnox | balloons: what's up with releasing music app and calendar app? | 00:29 |
| === jackson is now known as Guest1184 | ||
| === broder_ is now known as broder | ||
| === balkamos_ is now known as balkamos | ||
| === yp is now known as ypwong | ||
| === Chipzz_ is now known as Chipzz | ||
| === mwhudson is now known as 5EXAAR2RG | ||
| psusi | whoa... just noticed today at the vuds there was a discussion on switching to systemd... when the heck did this come about? I see nothing on -devel about this and last time it was brought up everyone said we would be sticking with upstart... and debian just decided to go with upstart, so... wtf? | 01:41 |
| psusi | ( and I think their decision was based in large part on our viewpoint on the matter ) | 01:42 |
| sarnold | psusi: http://www.markshuttleworth.com/archives/1316 | 01:42 |
| rww | debian went with systemd... | 01:42 |
| psusi | what? I swear I read last week on lwn they went with upstart | 01:42 |
| rww | good to know if i ever need a contact from an alternate dimension i have one, tho | 01:42 |
| rww | psusi: you didn't :P | 01:43 |
| sarnold | "weekly world news" rather than "linux world news" perhaps? :) | 01:43 |
| psusi | I swear they kept saying upstart was completely expected because we were dead set on it and half the debian tcce was ubuntu developers and that it finally went that way last week | 01:44 |
| psusi | I certainly can't find any mention on ubuntu-devel about going this way lately | 01:44 |
| rww | the other half of the debian tcce, including the one with the casting vote, didn't go upstart. so, systemd. | 01:45 |
| psusi | I'm not opposed to it, I actually have felt for some time that it would probably be better to follow what most other distros are doing in that area, but it feels like a total shocking about face | 01:45 |
| rww | i expect there wasn't much external discussion ubuntu-side, seems like sabdfl made an executive decision there (which is better than having another argument on this side of the fence would have been imho) | 01:45 |
| psusi | it's giving me a bit of whiplash | 01:45 |
| rww | hehe | 01:45 |
| RAOF | psusi: Well, looking into switching. Possibly by 16.04 if it looks easy, probably in 16.10. :) | 01:46 |
| RAOF | psusi: So, whiplash in ~2 years time or so, perhaps :) | 01:47 |
| psusi | well, with two whole years until 16.04, I'd hope we could get it done in that time frame ;) | 01:47 |
| psusi | especially with debian going that route | 01:47 |
| jrwren | is it really that big a deal? | 01:48 |
| psusi | it requires all system service type packages to be fixed to ship systemd config files instead of upstart, which is what we had to do when we moved to upstart from sysvinit | 01:48 |
| rww | haven't other distros done most of the hard work there for us? | 01:49 |
| jrwren | so its been done once, it will be even easier the second time :) | 01:49 |
| psusi | probably, yea | 01:49 |
| rww | i know i've been able to boot with systemd on debian testing for quite a while | 01:49 |
| Unit193 | rww: Part of that is that systemd still works with init scripts. | 01:50 |
| psusi | I've been wanting to play with it for a while now but never got around to it... and the way the devs keep trying to strongarm things like udev into it in an inseperable way, and refusing to support !linux was starting to turn me off | 01:50 |
| rww | Unit193: yep. iirc i ended up with surprisingly few of those | 01:50 |
| psusi | hell, I haven't been paying attention to our initramfs for some time.. did we ever put upstart in there? | 01:52 |
| infinity | psusi: No. | 01:55 |
| psusi | it's getting a bit confusing with some form of init now possible in the initramfs, system startup, and session startup ;) | 01:55 |
| infinity | psusi: And I still think systemd-in-initrd is the wrong thing too, but upstream disagrees. :P | 01:55 |
| psusi | I'm not so sure... we do have several serious and long standing bugs that could be solved by that | 01:56 |
| * psusi looks at degraded md/lvm/crypt/etc | 01:56 | |
| rww | infinity: how come? | 01:56 |
| infinity | rww: I'm not fond of the "shove everything in initramfs, it's the new /" mentality. | 01:57 |
| infinity | Which was the driving force behind the /usr merge. | 01:57 |
| psusi | it's a brave, new, plug and play world though, and that has not jived well with shell scripts in initramfs | 01:57 |
| infinity | It entirely discounts systems where you don't want an initrd, systems where loading the initrd is incredibly expensive, so you want to keep it small, etc. | 01:57 |
| psusi | I thought it handled !initrd systems too | 01:58 |
| === ssweeny` is now known as ssweeny | ||
| infinity | psusi: If initramfs is the new /, it only handles non-initrd systems if you use one filesystem. | 01:59 |
| infinity | (But, yes, that's the most common configuation today) | 01:59 |
| infinity | And, if you run Fedora, it's the only configuration, cause / is dead. :P | 02:00 |
| psusi | ohh... yea.. I guess you did used to be able to have enough in / and not /usr to fsck the root fs and *then* initialize the rest of the system... I can't really find a reason to care about that though ;) | 02:00 |
| Unit193 | Should also make it take longer to compress the initrd, having dropbear and cryptsetup makes it slow enough as it is. Also, the possibility of breakage... | 02:01 |
| infinity | psusi: No, and neither can Lennart, and our new overlords believe that if they don't value a use-case, no one should. | 02:01 |
| * infinity isn't bitter. | 02:01 | |
| psusi | true | 02:01 |
| TheMuso | And thats my gripe. We are a little closer to being controlled more by our overlords. | 02:02 |
| TheMuso | I can live with the decision though. | 02:02 |
| psusi | indeed, that's the one reason why I've been a bit turned off on systemd lately, even though I originally thought his ideas really sounded good | 02:02 |
| infinity | I think following suit with Debian here is absolutely the right decision. I'm less certain that Debian made the right decision. | 02:02 |
| psusi | he's a bit too dictatorial | 02:02 |
| TheMuso | Yep I feel the same. | 02:03 |
| psusi | indeed | 02:03 |
| infinity | psusi: Try having a conversation with him. | 02:03 |
| infinity | psusi: (don't, if you value your sanity) | 02:03 |
| psusi | I have the same problem with David Zuthern and udisks | 02:04 |
| infinity | But udisk isn't trying to eat all of early userspace. | 02:04 |
| psusi | and all this is making me suspicious of kdbus | 02:04 |
| StevenK | kdbus will solve every problem that ever existed. | 02:05 |
| StevenK | Apparently. | 02:05 |
| infinity | And, while this is meaningless to Ubuntu, I'm really non-plussed about tying the larger GNU/GNOME/KDE/etc userspace to Linux, which it never had been before. | 02:05 |
| rww | it starts with k, so it'll probably be good | 02:05 |
| TheMuso | I for one, welcome kdbus if it means better performance. | 02:05 |
| TheMuso | Yep agreed, just because I'll likely never use BSD, doesn't mean they should get dropped like a sack of potatoes. | 02:06 |
| psusi | it sounds great for dbus users... I just don't see why everything has to be done with dbus... the unix way is to run a small, stand alone executable, and the mass push to convert everything to dbus just feels like the way Microsoft puts everything in dlls | 02:06 |
| psusi | indeed... especially if there are some bsd users that are willing to write and maintain patches to support it, there's no reason to refuse to accept them | 02:07 |
| TheMuso | But afaik it has solved security concerns with IPC, but my understanding may be missing the mark. | 02:07 |
| infinity | psusi: We put everything in DLLs too... | 02:07 |
| sarnold | to be fair, I've heard the opensolaris 10 stuff described as "sun / oracle put all the functionality in libraries" ... | 02:07 |
| infinity | psusi: In fact, if all of the systemd functionality was in libraries, I'd have very, very few complaints. | 02:08 |
| RAOF | A lot of it is; just private libraries. | 02:08 |
| infinity | psusi: But instead, they do things like the "single cgroup writer" fiasco in the systemd binary itself, and tell us all the get stuffed. | 02:08 |
| infinity | RAOF: A library I can't reasonable leverage isn't a library worth discussing. | 02:09 |
| RAOF | Absolutely. | 02:09 |
| infinity | s/reasonable/reasonably/ | 02:09 |
| psusi | why use a library when exec works fine? gparted is still quite happy to run mkfs, fsck, etc instead of running libraries in process | 02:09 |
| RAOF | I presume once systemd settles down all those things will end up as real, honest-to-god libraries with actual ABIs and stuff. | 02:10 |
| psusi | but gnome-disk-utility has to have everything cross the dbus and be run in a server... I dunno... just seems like a lot of unneeded complexity | 02:10 |
| StevenK | RAOF: If history is anything to go by, I doubt it. | 02:10 |
| infinity | psusi: I'm not particularly fussed about if your coupling method is exec() or ld.so, but I'm a big fan of sane reuse of small components, somehow. | 02:10 |
| sarnold | RAOF: "actual ABIs", I like the optimism... | 02:11 |
| psusi | true | 02:11 |
| infinity | RAOF: That seems pretty much completely counter to what Lennart and Kai want, so I doubt it. | 02:11 |
| RAOF | infinity: init will eventually be boring, and the adults can take over :P | 02:11 |
| RAOF | </joke> | 02:11 |
| TheMuso | Yep, aka how Lennart left pulseaudio development without saying anything. | 02:12 |
| sarnold | it -was- boring, once, when it was just thirty lines long.. | 02:12 |
| RAOF | Yeah, but it was boring and seriously underpowered. There'll come a time when it'll be boring and feature-complete. | 02:13 |
| infinity | RAOF: Ahh, like Emacs, which never sees any new develop-- oh, wait. | 02:13 |
| * psusi just hopes he can finally get debian+ubuntu off of parted 2.3 | 02:13 | |
| infinity | RAOF: Anyhow, init will never be boring as long as systemd keeps finding new bits of userspace to absorb. | 02:15 |
| lifeless | point him at launchpad | 02:16 |
| infinity | RAOF: When you're linking everything against systemd-libc, using systemd-gcc, spinning up systemd-qemu to try something on another arch with systemd-gdb, maybe it'll be feature-complete. | 02:16 |
| psusi | lol | 02:17 |
| psusi | I still say udisks has no buisiness configuring things like drive standby timers, while at the same time being a demand start service | 02:17 |
| infinity | RAOF: On the plus side, I assume that systemd-wayland becoming inextricably linked will put a rest to this pesky Mir thing. | 02:19 |
| === 5EXAAR2RG is now known as mwhudson_ | ||
| rww | psusi: don't worry, systemd-udisks will fix that | 02:19 |
| psusi | lol | 02:19 |
| psusi | one of these days I'm going to fix those broken udisks standby timers, and convert it to use the new kernel runtime pm | 02:20 |
| RAOF | Yeah, please do so! | 02:20 |
| psusi | probably after I get my kernel patches accepted to avoid spinning up little used disks at all after system resume | 02:21 |
| * psusi wonders where lamont has been hiding | 02:33 | |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === FourDollars_ is now known as FourDollars | ||
| === FlannelKing is now known as Flannel | ||
| pitti | Good morning | 05:15 |
| === salem_ is now known as _salem | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === bigon_ is now known as bigon | ||
| === yofel_ is now known as yofel | ||
| === Guest1184 is now known as Noskcaj | ||
| === Wellark_ is now known as Wellark | ||
| === warp10_ is now known as warp10 | ||
| shadeslayer | hi, whom do I contact regarding updating the libaccounts-qt package? | 09:48 |
| shadeslayer | since it seems to be updated by a bot which hasn't updated it in over 4 months | 09:48 |
| ogra_ | shadeslayer, try mardy | 09:55 |
| shadeslayer | mardy: poke poke @ libaccounts-qt package | 09:56 |
| shadeslayer | mardy: next KDE SC release that we want in Trusty requires libaccounts-qt 1.11 , current package reports version 1.11 but doesn't have a header that's require to build things | 09:56 |
| shadeslayer | since this is a snapshot of the 1.11 tree, I would argue for an update to the final release | 09:57 |
| pitti | @pilot in | 09:59 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti | ||
| shadeslayer | morning pitti :D | 10:00 |
| pitti | hey shadeslayer, how is it going? | 10:01 |
| shadeslayer | good, packaging a new KDE SC :) | 10:01 |
| shadeslayer | pitti: how about you | 10:02 |
| pitti | shadeslayer: quite fine, thanks! enjoying the spring, not enjoying fighting QA infrastructure :) | 10:02 |
| * shadeslayer sighs about not being able to enjoy spring from work :( | 10:04 | |
| shadeslayer | pitti: just get loads of coffee and fix it when you get a sugar rush :P | 10:04 |
| shadeslayer | or caffeine rush, or both | 10:04 |
| pitti | shadeslayer: I'm not a coffee drinker, but a big enough hammer will do :) | 10:05 |
| shadeslayer | hah :D | 10:08 |
| pitti | slangasek: I took the liberty of applying the "isolation-machine" autopkgtest fix for systemd-shim in Debian's collab-maint | 10:33 |
| pitti | slangasek: so we are back in sync | 10:33 |
| pitti | Launchpad, where are thou? | 10:39 |
| === dkessel_ is now known as dkessel | ||
| edward | https://apps.ubuntu.com/cat/applications/precise/kipi-plugins/ <-- formatting on this page looks broken | 11:19 |
| edward | Missing newlines. | 11:20 |
| bluesabre | greetings ubuntu-sponsors | 11:47 |
| bluesabre | I'm seeking sponsorship for the following package: | 11:47 |
| bluesabre | https://bugs.launchpad.net/ubuntu/+source/light-locker-settings/+bug/1291324 | 11:47 |
| ubottu | Launchpad bug 1291324 in light-locker-settings (Ubuntu) "[needs-packaging] light-locker-settings 1.0.1" [Undecided,Confirmed] | 11:47 |
| bluesabre | Please let me know if there are any changes that need to be made | 11:47 |
| pitti | bluesabre: I'll have a look | 11:50 |
| pitti | bluesabre: the changes look quite a bit more intrusive than a microrelease update suggests.. | 11:50 |
| bluesabre | thanks pitti | 11:50 |
| pitti | bluesabre: but still okayish, I'll look at the diff | 11:50 |
| bluesabre | thanks, functionally its the same, it was a cleanup to be sure | 11:51 |
| GunnarHj | pitti: Hi Martin! | 11:56 |
| pitti | hey GunnarHj, how are you? | 11:56 |
| GunnarHj | pitti: Fine thanks, how about you? | 11:56 |
| GunnarHj | pitti: See that you are piloting. Any chance that you can take a look at bug #1284701? Laney did a first review at mentors, but he's on holiday this week. | 11:56 |
| ubottu | bug 1284701 in Ubuntu "[FFE] Please upload mythes-sv to the archive" [Medium,In progress] https://launchpad.net/bugs/1284701 | 11:56 |
| pitti | GunnarHj: great, thanks! just sponsoring your locales patch :) | 11:56 |
| === MacSlow is now known as MacSlow|lunch | ||
| GunnarHj | pitti: Aha, thanks. :) | 11:56 |
| pitti | GunnarHj: yep, it's in the sponsoring queue, I'll get to it | 11:56 |
| GunnarHj | pitti: Great! | 11:57 |
| pitti | dholbach: can you handle https://code.launchpad.net/~mitya57/ubuntu-sponsoring/bold-fix-for-new-packages/+merge/208961 ? I think you have a much better idea about this than I | 11:59 |
| pitti | dholbach: meta-sponsoring FTW! | 11:59 |
| mardy | shadeslayer: hi! What header is missing? | 12:02 |
| dholbach | pitti, done | 12:02 |
| dholbach | thanks | 12:02 |
| pitti | dholbach: *hug*, danke | 12:02 |
| * dholbach hugs pitti back | 12:02 | |
| * pitti watches his laptop emitting smoke from all the sbuilding today | 12:10 | |
| pitti | bluesabre: uploaded, thanks! | 12:11 |
| bluesabre | pitti, you're the best! :D | 12:11 |
| * bluesabre hopes that doesn't offend the other uploaders | 12:11 | |
| pitti | bluesabre: *shrug* if it does, and it leads to them sposoring more, so much the better :-) | 12:13 |
| pitti | speaking of more, I need more "n"s apparenlty | 12:13 |
| pitti | Laney: bug 1290823 should be trivial, mind having a look with your release hat on? | 12:32 |
| ubottu | bug 1290823 in Ubuntu "FFe: [needs-packaging] Sync appdata-tools 0.1.7-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1290823 | 12:32 |
| pitti | Laney: bug 1290291 as well, that looks pretty much "bug fix" to me; but rbasak seems to think it needs release team ack? | 12:33 |
| ubottu | bug 1290291 in cmigemo (Ubuntu) "[FFe] Sync cmigemo 1:1.2+gh0.20140306-1 (universe) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/1290291 | 12:33 |
| rbasak | pitti: ah. I just went with the original subject that said it needed an exception. | 12:36 |
| rbasak | pitti: looking at it now, I guess perhaps it doesn't? | 12:36 |
| pitti | rbasak: by the description in #5 I would just have synced it | 12:37 |
| === _salem is now known as salem_ | ||
| rbasak | pitti: agreed. Sorry, I should have paid more attention. | 12:46 |
| === tkamppeter_ is now known as tkamppeter | ||
| shadeslayer | mardy: moment, let me check | 13:14 |
| === MacSlow|lunch is now known as MacSlow | ||
| pitti | rbasak: no worries, it's far from clear in the bug | 13:19 |
| shadeslayer | mardy: ../../../../resources/google/../shared/getcredentialsjob.h:27:30: fatal error: SignOn/SessionData: No such file or directory | 13:25 |
| shadeslayer | #include <SignOn/SessionData> | 13:25 |
| mardy | shadeslayer: that comes from libsignon-qt5-dev, not libaccounts-qt5-dev | 13:27 |
| shadeslayer | uhhhh | 13:29 |
| shadeslayer | mardy: http://paste.ubuntu.com/7079296/ | 13:31 |
| shadeslayer | mardy: so it finds signon but can't find that header, weird, apt-file search says it can find it | 13:32 |
| mardy | shadeslayer: weird, the cflags seem to be correct, I see it's using " -I/usr/include/signon-qt5" | 13:35 |
| mardy | shadeslayer: possibly unrelated, but I see that that package is mixing qt4 and qt5 libs, which is probably very wrong | 13:35 |
| shadeslayer | mardy: how so? it's using libsignon-qt-dev | 13:36 |
| shadeslayer | oh huh | 13:36 |
| shadeslayer | /usr/include/signon-qt5 does seem very very wrong | 13:37 |
| barry | xnox: are you working on any of the still unported apps? i want to work on them, but not step on any branches of yours in progress | 13:42 |
| pitti | GunnarHj: the licensing of that package is still wrong | 13:48 |
| pitti | GunnarHj: doc/Info-en.txt only says MIT and nothing else at all anywhere | 13:48 |
| pitti | GunnarHj: so it can't be CC-BY-SA | 13:48 |
| pitti | GunnarHj: if it's meant to be, then doc/Info-en.txt needs to be adjusted accordingly | 13:48 |
| xnox | barry: i still have a few clicks to convert, i didn't look into deb based ones yet. | 13:51 |
| xnox | barry: there is a tweak/hotfix i'm pushing for gallery-app, cause it's blocking landing phablet-tools. | 13:51 |
| barry | xnox: cool. i'll likely pick them off (under FUTURE port/test in the bp) alphabetically. i already have branches in progress for many of them | 13:51 |
| barry | xnox: ack | 13:52 |
| xnox | barry: cool! thanks =) add links ;-) | 13:52 |
| barry | xnox: of course! :) | 13:52 |
| pitti | GunnarHj: replied on mentors | 13:52 |
| cjwatson | pitti: the burp sync you sponsored seemed to have incomplete autoreconfage, since it broke ppc64el | 14:10 |
| pitti | cjwatson: ah thanks, I'll have a look | 14:11 |
| pitti | single-digit sponsoring queue! http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html | 14:12 |
| pitti | cjwatson: odd, I thought --with autoreconf would also update config.* | 14:25 |
| pitti | cjwatson: reuploaded the "with autotools_dev", thanks | 14:25 |
| pitti | rsalveti: err.. the changelog of https://code.launchpad.net/~boiko/ubuntu/trusty/telepathy-qt5/conf_call_client_side/+merge/210302 is exactly the one in https://launchpad.net/ubuntu/+source/telepathy-qt5/0.9.3-0ubuntu7 | 14:27 |
| rsalveti | pitti: mind also joining #ubuntu-touch, we discussed that there | 14:28 |
| rsalveti | pitti: but basically boiko forgot to update debian/changelog | 14:28 |
| rsalveti | he's doing that now | 14:28 |
| pitti | rsalveti: ah; so that also needs to be merged with the previous upload then? | 14:28 |
| cjwatson | pitti: only if the package is using automake+libtool | 14:28 |
| rsalveti | pitti: yeah | 14:29 |
| cjwatson | pitti: but there are some cases where the package uses autoconf + AC_CANONICAL_FOO, and in that case config.* is required but isn't updated by autoreconf | 14:29 |
| cjwatson | pitti: you might want to combine autoreconf and autotools_dev here | 14:29 |
| cjwatson | this is a case when that's sensible | 14:29 |
| pitti | cjwatson: yes, that's what I did | 14:29 |
| cjwatson | ok, cool | 14:29 |
| pitti | -…………………dh $@ --with autoreconf | 14:29 |
| pitti | +…………………dh $@ --with autoreconf,autotools_dev | 14:29 |
| pitti | buidls fine here on amd64 | 14:30 |
| pitti | and https://launchpad.net/ubuntu/+source/burp/1.3.48-2ubuntu1/+build/5805268 is at "test", so looks good | 14:30 |
| infinity | pitti: Looks more like the autoreconf isn't hitting subdirectories. | 14:30 |
| cjwatson | thanks | 14:30 |
| cjwatson | yeah, that could be too | 14:30 |
| infinity | pitti: The top level configure is rebuilt, relibtoolizes, and config.* updated fine, it's a later subdir that falls over. | 14:31 |
| cjwatson | right, so the usual rune for that is something like: | 14:32 |
| cjwatson | autoreconf: | 14:32 |
| cjwatson | autoreconf -fi | 14:32 |
| cjwatson | cd subdir && autoreconf -fi | 14:32 |
| pitti | infinity: ah, thanks; I relayed that to the Debian maintainer via the sponsoring bug | 14:32 |
| cjwatson | override_dh_autoreconf: | 14:32 |
| cjwatson | dh_autoreconf debian/rules -- autoreconf | 14:32 |
| === kyleN is now known as kyleN-afk | ||
| PierreF | Hi | 14:34 |
| PierreF | I'm trying to sort out the build issue on ppc64el of OpenLAP patch i've submitted on LP #1287730 | 14:35 |
| ubottu | Launchpad bug 1287730 in openldap (Ubuntu) "openldap segfault on startup with delta-syncrepl MMR" [Undecided,Fix committed] https://launchpad.net/bugs/1287730 | 14:35 |
| PierreF | (but since I don't have access to ppc64el hardware it's a little complicated :)) | 14:36 |
| PierreF | pitti: you told in the bug that you can test build on such hardware. Have you some time to look on this issue ? | 14:36 |
| pitti | PierreF: I can do test builds, yes; but I know next to nothing about openldap itself | 14:37 |
| infinity | PierreF: The openldap/ppc64el build failure is libdb bug, it's in progress. | 14:37 |
| pitti | oh, nice | 14:37 |
| pitti | the previous version's tests ran fine, and that patch wasn't really intrusive | 14:37 |
| pitti | infinity: i. e. we'll just retry the build after a fixed libdb lands? | 14:37 |
| infinity | pitti: The previous version went fine because the buildd was running a kernel with 4k pages, this build was on a buildd with 64k pages. | 14:38 |
| infinity | pitti: So, yes, once libdb is fixed, a retry will make it happy. | 14:38 |
| pitti | infinity: sweet, thanks | 14:38 |
| pitti | PierreF: *phew* :) | 14:38 |
| PierreF | Good to know :) | 14:38 |
| PierreF | thanks | 14:38 |
| GunnarHj | pitti: Is the solution to the license issue with mythes-sv to simply state MIT in debian/copyright and disregard what's stated at the web page? | 14:54 |
| pitti | dholbach: wow, for the first time ever I actually got "done" with the sponsoring queue -- 4 items left which are non-actionable | 14:54 |
| dholbach | holy cow | 14:54 |
| * dholbach hugs pitti | 14:54 | |
| pitti | GunnarHj: that's how it appears to me | 14:54 |
| dholbach | you're unstoppable! | 14:55 |
| dholbach | great work! :-D | 14:55 |
| pitti | thanks :) | 14:55 |
| GunnarHj | pitti: Ok, will do that. | 14:55 |
| GunnarHj | pitti: And thanks a bunch for your great sponsoring work! :) | 14:55 |
| === caribou_ is now known as caribou | ||
| shadeslayer | slangasek: would have been nice to be able to comment on your blog | 15:07 |
| shadeslayer | re @ cubox i | 15:07 |
| pitti | @pilout out | 15:08 |
| udevbot | Error: "pilout" is not a valid command. | 15:08 |
| pitti | @pilot out | 15:08 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| slangasek | shadeslayer: feedback noted, but I'm not going to install a comment system any time in the foreseeable future :) | 15:09 |
| shadeslayer | :( | 15:09 |
| shadeslayer | slangasek: anyway, how does it perform? | 15:09 |
| * shadeslayer is on the edge of buying one | 15:09 | |
| slangasek | shadeslayer: I'm still working on the "enablement" aspects and haven't measured its performance at all... I don't even get hdmi out with any kernel except the 3.0 BSP kernel, I don't get USB keyboard with *any* kernel even though other people say that works, and I'm only using the SD card so any conclusions about I/O performance would be invalid | 15:11 |
| shadeslayer | slangasek: the enablement aspect is why I want to buy one :P | 15:11 |
| slangasek | shadeslayer: I know that it's *supposed* to do HD video out quite well, but right now I'm still tinkering :) | 15:11 |
| shadeslayer | :D | 15:12 |
| * shadeslayer is very tempted to order one from the March batch | 15:12 | |
| shadeslayer | s/March/April | 15:12 |
| shadeslayer | slangasek: how much did it cost you? | 15:13 |
| slangasek | shadeslayer: eh, whatever it says on the website? :) | 15:14 |
| === superm1__ is now known as superm1 | ||
| shadeslayer | slangasek: just wanted to compare if there was a change in price when compared with the december batch :P | 15:14 |
| slangasek | I don't think so | 15:15 |
| shadeslayer | hm, ok, might as well order | 15:15 |
| shadeslayer | going to use it with owncloud + 4 TB HDD \o/ | 15:15 |
| * infinity has too many random ARM things littering his desk already. | 15:17 | |
| mdeslaur | slangasek: does it have drivers for hardware video decoding? | 15:18 |
| slangasek | mdeslaur: it's meant to, but I haven't started chasing that side yet - it's possible they're only available for the 3.0 BSP kernel | 15:18 |
| slangasek | infinity: ah, but this one's small | 15:19 |
| infinity | slangasek: Most of them are. | 15:19 |
| infinity | slangasek: Though, small in different directions. | 15:19 |
| attente | hi | 15:33 |
| attente | i can't boot my machine... i keep getting "The disk drive for /dev/mapper/ubuntu--vg-swap_1 is not ready yet or not present" under plymouth :( | 15:33 |
| attente | i installed ubuntu-touch which caused the problem | 15:33 |
| attente | on my laptop | 15:34 |
| attente | rebooted, causing the problem, removed ubuntu-touch and its dependencies, but still get this error message | 15:34 |
| xnox | attente: you shouldn't install ubuntu-touch on your laptop, unity8 / unity8-session* packages are the most you may install. | 15:34 |
| xnox | attente: can you boot into recovery? e.g. press shift, get grub menu, select advanced features, select any kernel with (recovery mode). | 15:35 |
| attente | xnox: yeah... i'm realizing that now | 15:35 |
| seb128 | attente, do you have the list of the packages that got included? (e.g /var/log/dpkg.log) | 15:35 |
| attente | xnox: i can boot into recovery | 15:37 |
| xnox | attente: so you should be able to get root shell, and figure out what's wrong. | 15:37 |
| xnox | attente: you may need to mount/remount things rw. | 15:38 |
| attente | initctl: Event failed | 15:38 |
| attente | /scripts/local-top/cryptroot: line 1: can't open /dev/mapper/ubuntu--vg-root: no such file | 15:42 |
| xnox | attente: you don't pass initramfs, so do break=top kernel command line option and figure out why cryptsetup is not mounting your crypt/lvm in the right orders. | 15:47 |
| xnox | attente: or boot of a live cd & mount target for easier debug. | 15:47 |
| xnox | attente: if it's problem with initramfs, you should be able to boot older kernel/initramfs combo, if you have any around. | 15:48 |
| attente | xnox: seb128: ok, works now, i just ended up purging those packages instead of just removing them | 15:49 |
| seb128 | which ones? | 15:49 |
| xnox | attente: lvm2 and cryptsetup? | 15:50 |
| xnox | attente: oh, i wonder if you got initramfs-tools-ubuntu-touch installed, which is a borked up initramfs =) | 15:50 |
| infinity | If there are packages that break on remove-but-not-purge, that's a bug that needs fixing. | 15:50 |
| xnox | (borked up for normal desktops) | 15:50 |
| attente | seb128: just all of the ubuntu-touch dependencies | 15:52 |
| attente | i'm not sure which package caused in specifically... | 15:52 |
| seb128 | attente, ok, good that you got it back working in any case | 15:59 |
| pitti | awe__: http://git.kernel.org/cgit/network/ofono/ofono.git \o/ | 16:04 |
| ogra_ | pitti, did you fix it first ? | 16:06 |
| pitti | ogra_: I don't have any fix at the moment; but of course I'll send patches for stuff that comes up | 16:06 |
| awe__ | pitti, awesome! bonus points that we both got added to the AUTHORS list! | 16:06 |
| awe__ | ;D | 16:06 |
| awe__ | pitti, much thanks again for your help on this too | 16:07 |
| pitti | awe__: no worries | 16:07 |
| pitti | I'll look at dialer-app tomorrow morning (UDS/patch pilot today) | 16:07 |
| * pitti watches rbasakTV now | 16:07 | |
| ogra_ | haha | 16:07 |
| ogra_ | does it go "arm ARMARM arm armarmarm ... server" ? | 16:08 |
| pitti | ogra_: more like cloudvmcloudvmcloudvmcloudvm ... virt! | 16:10 |
| ogra_ | heh | 16:10 |
| xnox | .. | 16:12 |
| xnox | cjwatson: i'd expect each major qt 5.x release to have something major in it ;-) and it did harm us not moving to 5.1 first. We only started fixing 5.1 issues post 5.1 got released, thus those fixes landed in 5.2 only. | 16:14 |
| xnox | ditto our 5.2 fixes are landing in 5.3 only. | 16:14 |
| xnox | cjwatson: ideally, we'd have touch images with 5.3-trunk available under test. | 16:14 |
| ogra_ | xnox, ECHAN ? | 16:15 |
| ogra_ | :) | 16:15 |
| xnox | ogra_: yes. | 16:15 |
| smoser | slangasek, are we expecting https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1160079 fix ? | 16:45 |
| ubottu | Launchpad bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed] | 16:45 |
| slangasek | xnox: ^^ did you have a chance to smoke-test plymouth yet? | 16:46 |
| xnox | slangasek: i didn't test crypt yet. let me do that now. | 16:48 |
| === snatan is now known as sassyn | ||
| dakira | hi. is there any chance on getting updated libimobiledevice packages into trusty? the current ones (1.1.5) don't work with iOS7. I built new packages based on the debian/* files in trusty and the current git master of libimobiledevice. They work nicely. How would one go about getting a new version into Ubuntu? The current version is in main and maintained by Debian maintainers. They won't update until there's a new release of libimobiledevice (which is p | 17:14 |
| xnox | slangasek: looks good, still doesn't fix my problem that my boot.log is incomplete. | 17:14 |
| tarpman | dakira: you got cut off after "(which is p" | 17:14 |
| dakira | (which is probably never). | 17:15 |
| slangasek | xnox: oh, what's the issue with your boot.log being incomplete? | 17:15 |
| xnox | slangasek: i believe i did attach 10x of my boot.log's basicallly on my SSD laptop, 7 out of 10times it only has like 3-4 of the last jobs in boot sequence that are started and nothing else. | 17:16 |
| slangasek | xnox: attached where? bug #? | 17:17 |
| xnox | yeah, trying to find now. | 17:17 |
| seb128 | dakira, you need a ffe, read https://wiki.ubuntu.com/FreezeExceptionProcess for details | 17:17 |
| dakira | seb128: okay. But the question I ask myself is how would one go about the package. Mine is not up to standards, I just did a git clone, copied over and fixed debian/*, updated the changelog and told dpkg-gensymbols to ignore warnings. | 17:20 |
| seb128 | dakira, do you know if upstream plans to roll a new version or if there are specifics commit we can backport for iOS7 support? | 17:21 |
| dakira | seb128: a new version is not on the way, i'm not sure if they are releasing at all anymore (there is only some github activity on iOS updates to support new versions). | 17:22 |
| dakira | seb128: The iOS7 support could probably be tracked to a certain commit. | 17:23 |
| xnox | slangasek: filed a fresh bug #1291498 | 17:25 |
| ubottu | bug 1291498 in plymouth (Ubuntu) "only partial boot.log is recorded" [Undecided,New] https://launchpad.net/bugs/1291498 | 17:25 |
| slangasek | xnox: thanks | 17:25 |
| xnox | slangasek: maybe it's expected for one boot.log to be 312 bytes and anothers e.g. 1.5kB | 17:25 |
| === kyleN-afk is now known as kyleN | ||
| dakira | seb128: I found the commit: https://github.com/libimobiledevice/libimobiledevice/commit/ec720cc1c30ac3f9b7996575e835565f60ce2b3e | 17:28 |
| seb128 | dakira, that seems non trivial... | 17:28 |
| dakira | seb128: yup. but the current state of libimobiledevice is completely broken (i.e. iOS7 doesn't work at all). | 17:30 |
| xnox | seb128: but it is "hardware enablement" iOS users upgrade very aggresively, and thus trusty will not work with iDevices at all without this =/ | 17:30 |
| xnox | seb128: thus it's even acceptable as an SRU, thus it should be fine for FFe as well. | 17:31 |
| seb128 | well, I'm going to let somebody who owns an iOS device update | 17:31 |
| seb128 | xnox, ^ | 17:31 |
| tarpman | dakira: the news on the homepage figures ios7 should work in 1.1.5 but with some hiccups, which would be resolved in 1.1.6 ... what changed? | 17:31 |
| seb128 | xnox, sure, I'm not arguing against that, I just can't sanity check that commit from a look and I don't own hardware to test | 17:31 |
| seb128 | xnox, would be nice if somebody with access to a device could test... | 17:32 |
| dakira | tarpman: if your device was ever authenticated and then upgraded to ios7, 1.1.5 does work. If not, you can't get past the "trust this device?" dialog on the phone. | 17:33 |
| slangasek | xnox: so, certainly the plymouth-upstart-bridge job will race the rest of the startup | 17:35 |
| tarpman | dakira: so no luck for anyone who bought a newer device (ie. ios7 included) then | 17:35 |
| dakira | seb128: here's what I built: https://launchpad.net/~mniess/+archive/libimobiledevice/ | 17:35 |
| dakira | tarpman: exactly. There is no way to get an iOS7 device working on a fresh Ubuntu install | 17:37 |
| xnox | slangasek: but plymouth-upstart-bridge should not be "start on (started dbus or runlevel [06])" it should be on "start on startup or runlevel [06]", no?! | 17:37 |
| slangasek | xnox: presumably so - I don't know why it's 'on started dbus', maybe it's trying to use the public upstart socket currently and shouldn't? | 17:38 |
| xnox | slangasek: i think that's what cjwatson mentioned to me in passing on monday. Let me see if I can fix that up. | 17:39 |
| slangasek | xnox: so currently, plymouth-upstart-bridge talks to the system bus, which explains the listed start condition | 17:42 |
| slangasek | s/talks to the system bus/talks to upstart over the system bus/ | 17:42 |
| cjwatson | slangasek: when I wrote plymouth-upstart-bridge, it didn't look as if the private upstart socket was going to be a stable interface, and I felt I shouldn't rely on it | 17:56 |
| cjwatson | (arguably I should have put it in upstart rather than plymouth, but that's definitely not worth changing now) | 17:56 |
| cjwatson | slangasek: at this point it's probably reasonable to distro-patch to use the private socket, since we're not expecting to have a new interface | 17:56 |
| cjwatson | xnox: ^- | 17:57 |
| xnox | cjwatson: ack. | 17:58 |
| dakira | seb128: is there anything else I can do about the issue? | 17:58 |
| slangasek | cjwatson: ah, k. I wasn't aware that there was ever expected to be a difference between the public and private sockets, other than the root-only / depends-on-dbus-daemon aspects | 17:58 |
| cjwatson | it was a private API and I was being a good boy :-) | 17:59 |
| seb128 | dakira, open a bug on launchpad, add the link to your work/the upstream patch, subscribe ubuntu-sponsors | 18:00 |
| dakira | seb128: There is this. https://launchpad.net/bugs/1207812 | 18:07 |
| ubottu | Launchpad bug 1207812 in libimobiledevice (Ubuntu) "iOS 7, Trust Prompt Looping" [Medium,Triaged] | 18:07 |
| dakira | seb128: should I create a new bug? | 18:07 |
| seb128 | dakira, no, use that one | 18:08 |
| dakira | seb128: okay done, thank you. | 18:12 |
| === cody-somerville_ is now known as cody-somerville | ||
| xnox | cjwatson: slangasek: 1 file changed, 10 insertions(+), 129 deletions(-) -> and it seems to use upstart private socket now bypassing dbus system bus, but that's with plymouth-x11. | 19:01 |
| xnox | let me test this actually works =)))) | 19:01 |
| xnox | cjwatson: slangasek: please review/test https://code.launchpad.net/~xnox/ubuntu/trusty/plymouth/private-upstart-socket/+merge/210672 | 19:24 |
| xnox | cjwatson: slangasek: mostly it simply opesn private connection, and kicks off statemachine with listing jobs, without registering any filters/rules/nameowerchanges, since org.freedesktop.dbus interface is not there and none of those are needed. | 19:24 |
| xnox | i now get a 6.2kB boot.log starting with "mounting filesystems" =)))) | 19:25 |
| slangasek | heywow | 19:25 |
| slangasek | xnox: I don't have time to test it today; maybe stgraber and smoser can give it a whirl? | 19:26 |
| smoser | xnox, interesting. so it turns out that i would never have known i was missing boot.log or data in it. | 19:28 |
| smoser | well, we were missing data in it because of bug 1160079 | 19:28 |
| ubottu | bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed] https://launchpad.net/bugs/1160079 | 19:28 |
| smoser | which i REALLY want fixed. | 19:28 |
| xnox | smoser: well lp:ubuntu/upstart has a staged fix for bug 1160079 | 19:31 |
| ubottu | bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed] https://launchpad.net/bugs/1160079 | 19:31 |
| xnox | smoser: and now i will be collecting boot.log, even if dbus is not installed. | 19:31 |
| xnox | smoser: with my merge proposal. | 19:32 |
| xnox | smoser: so, can you test lp:~xnox/ubuntu/trusty/plymouth/private-upstart-socket ? it should fix bug 1160079 _and_ create a useful boot.log. | 19:32 |
| ubottu | bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed] https://launchpad.net/bugs/1160079 | 19:32 |
| smoser | :) | 19:33 |
| smoser | i see what you did there. | 19:33 |
| smoser | tricky | 19:33 |
| smoser | xnox, yeah, i'll give it a go | 19:33 |
| === FJKong is now known as FJKong_afk | ||
| xnox | dholbach: mhall119: sergiusens: running $ webbrowser-app --help; coredumps. Running $ webapp-container -h; also coredumps. | 20:04 |
| sergiusens | xnox, interesting | 20:05 |
| sergiusens | xnox, but you pinged the wrong people ;) bfiller ^^ | 20:05 |
| xnox | dbarth: ^ ?! | 20:06 |
| bfiller | xnox: I think a fix for that just was proposed | 20:06 |
| xnox | bfiller: a manpage would be good, explaining all the options. | 20:07 |
| xnox | bfiller: since e.g. http://developer.ubuntu.com/publish/webapp/packaging-web-apps/ is incomplete. | 20:07 |
| xnox | bfiller: g+ can use _any_ url hypothetically, due to redirects for 3rd party authentication. | 20:07 |
| bfiller | xnox: https://code.launchpad.net/~osomon/webbrowser-app/fix-crash-help/+merge/210655 | 20:07 |
| sergiusens | xnox, yeah, that's why I mentioned to avoid the containment | 20:08 |
| psusi | anyone know how to convince emacs to use hard tabs in sh-mode? apparently indent-tabs-mode is a C mode thing only | 20:09 |
| sergiusens | xnox, only webappUrlPatterns are explained there; not the other one which could potentially allow you to workaround it | 20:09 |
| xnox | bfiller: also http://developer.ubuntu.com/publish/webapp/packaging-web-apps/ seems wrong to suggest webbrowser-app instead of webapp-container. | 20:10 |
| bfiller | xnox: ack, please file bugs | 20:10 |
| slangasek | gah, why is the new bash so terrible? | 20:31 |
| ScottK | So it's not "new bash, same as the old bash"? | 20:32 |
| slangasek | only if you never use it interactively, I guess | 20:32 |
| * ScottK wonders if you're ignoring the pun on purpose or not. | 20:33 | |
| xnox | slangasek: did you upgrade bash-completion as well? | 20:33 |
| jtaylor | xnox: didn't fix it for me | 20:35 |
| jtaylor | if the issue is completion not working properly | 20:35 |
| slangasek | xnox: yes, but it's not the completion that's messed up | 20:36 |
| slangasek | ScottK: I must be missing the pun | 20:36 |
| xnox | slangasek: completion is supposed to be fixed with new bash-completion... | 20:36 |
| slangasek | xnox: it's not the completion I was complaining about! :) | 20:36 |
| ScottK | slangasek: I was trying for a line from the Who, Won't Get Fooled Again. "New boss, same as the old boss". | 20:36 |
| slangasek | ScottK: ah :) | 20:36 |
| jtaylor | ls ~/Downloads/<tab> just not working for me? | 20:38 |
| jtaylor | I have the latest completion update I think | 20:38 |
| xnox | slangasek: oh, i see. well, hold that thought about bash and wait for doko to come back from hollidays ;-) | 20:38 |
| slangasek | xnox: so the problems I'm seeing are that 'failed reverse-i-search' now doesn't give me sensible feedback that it's failed, but continues to display what I'm typing; and ^C on a wrapped line puts the prompt in the middle of the previous output | 20:39 |
| barry | jtaylor: i hit that a few days ago. it's a bash-completion bug | 20:39 |
| jtaylor | oh es that sucks too | 20:39 |
| barry | LP: #1288031 probably | 20:40 |
| ubottu | Launchpad bug 1288031 in bash-completion (Ubuntu) "Tab expansion only auto-completes directory names" [High,Confirmed] https://launchpad.net/bugs/1288031 | 20:40 |
| jtaylor | thx | 20:40 |
| xnox | slangasek: right, i've noticed both of those. | 20:41 |
| xnox | barry: i've fixed completion bug i thought. | 20:42 |
| barry | xnox: hey, it looks like you did! maybe a different bug got closed? | 20:43 |
| xnox | barry: hm, though maybe not. | 20:44 |
| jtaylor | the changelog bug seems something else | 20:44 |
| * barry only tried a simple example | 20:44 | |
| jtaylor | infinity: do you already have plans how to deal with the glibc miscompile on i386? | 21:01 |
| smoser | xnox, hey. | 21:01 |
| jtaylor | adding fno-regmove is probably safe and easy, if something else is needed I guess one needs to bisect gcc 4.7-4.8 to figure out where it broke | 21:01 |
| smoser | so i'm walking through the same thing i did https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1235231 | 21:01 |
| ubottu | Launchpad bug 1235231 in plymouth (Ubuntu) "plymouth loses output to /dev/console (such as ci-info: messages)" [High,Confirmed] | 21:01 |
| smoser | and i'm seeing (i *think*) duplicate data | 21:02 |
| smoser | http://paste.ubuntu.com/7081443/ | 21:02 |
| infinity | jtaylor: fno-regmove is what I have committed locally. | 21:03 |
| jtaylor | oh nice | 21:03 |
| infinity | jtaylor: A bit scared that it might be a random fluke that it only manifests on i386, and perhaps it could affect all x86 if enough code shuffles around, but meh. | 21:04 |
| infinity | jtaylor: I guess we have a solid test for it, so if it regresses, we'll know. | 21:04 |
| jtaylor | its quite possible it has to do with the x87 fpu | 21:04 |
| jtaylor | so only i386 | 21:04 |
| jtaylor | but its probably wise to check what actually broke it | 21:05 |
| jtaylor | I can maybe check this weekend which gcc commit it was | 21:05 |
| infinity | jtaylor: Well, fixing GCC would be nice. But since that whole bit has been torn out in 4.9, I'm not massively fussed either. | 21:05 |
| infinity | jtaylor: I guess the concern wouldn't be glibc at that point, but the thought that gcc is silently miscompiling other things where we've not been so lucky to catch it. :/ | 21:05 |
| infinity | (And way too late now, really) | 21:06 |
| xnox | smoser: hey. | 21:09 |
| smoser | xnox, this is what i'm running right now. | 21:10 |
| smoser | http://paste.ubuntu.com/7081481/ | 21:10 |
| smoser | you can recreate it if you want | 21:10 |
| xnox | smoser: correct, $ echo manual | sudo tee /etc/init/plymouth-upstart-bridge.override | 21:10 |
| xnox | smoser: do you want plymouth, or do you not?! =) | 21:10 |
| smoser | what ? | 21:11 |
| xnox | smoser: also do you happen to _not_ have dbus in the cloudimage? | 21:11 |
| smoser | i dont want *two* copies of all messages to the console | 21:11 |
| smoser | i dont think anyone does | 21:11 |
| smoser | ever | 21:11 |
| xnox | smoser: right, so plymouth-upstart-bridge listens to upstart messages (previously over system dbus, now over private socket) and it reprints upstart messages via plymouth. | 21:12 |
| xnox | smoser: and also to the console output. | 21:12 |
| xnox | smoser: can i see manifest of packages for cloudimages? | 21:13 |
| smoser | http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64.manifest | 21:13 |
| smoser | i have to run. sorry. | 21:13 |
| xnox | smoser: no worries, i'll work on it. | 21:13 |
| xnox | slangasek: so my "fix" has unwanted consequences on the cloudimages, since plymouth-upstart-bridge prints things to the "console output" it's thus now generating duplicates. | 21:14 |
| xnox | slangasek: i wonder if plymouth-upstart-bridge should not run, if there is cloud-init. | 21:15 |
| slangasek | hmm, really? | 21:16 |
| xnox | slangasek: well, that's my interpretation so far. See the paste from smoser here: http://paste.ubuntu.com/7081443/ | 21:16 |
| xnox | and steps to repeat: http://paste.ubuntu.com/7081481/ | 21:17 |
| slangasek | xnox: are you sure the bridge behavior isn't broken for all cases when not using a graphical splash (including Ubuntu Server)? | 21:17 |
| xnox | slangasek: good point. let me try to verify that. | 21:17 |
| slangasek | oh yuck, we bridge messages about the startpar bridge | 21:18 |
| xnox | slangasek: oh, yeah about the startpar bridge, i thought none of that should be printed anywhere _ever_ | 21:18 |
| slangasek | it really ought not | 21:18 |
| jtaylor | hm I'm getting weird segfaults from tk/tcl from python testsuites recently, anyone else seen that? | 21:20 |
| jtaylor | maybe bug 1290805 | 21:20 |
| ubottu | Error: Launchpad bug 1290805 could not be found | 21:20 |
| === salem_ is now known as _salem | ||
| xnox | slangasek: yeah, i'll add further patches to fix this up properly. | 21:33 |
| === jibel_ is now known as jibel | ||
| === pgraner` is now known as pgraner | ||
| jtaylor | xnox, infinity as you TIL tk8.6, seems we need the fix for this bug in trusty: http://core.tcl.tk/tk/info/f214b8ad5b | 21:57 |
| jtaylor | looks like this diff: http://core.tcl.tk/tk/fdiff?v1=35cfb387a8821ec3&v2=039e0a2d49a1ef3c&sbs=1 | 21:57 |
| jtaylor | else e.g. tk based python-matplotlib apps will crash when you close the plots | 21:58 |
| ScottK | jtaylor: Isn't crash on close just a fancier way to get what you wanted anyway? | 22:00 |
| ScottK | ;-) | 22:00 |
| jtaylor | closing plots != application end | 22:00 |
| jtaylor | though some changes in tk8.6 seem to break matplotlib anyway, after the close tk does not autoreinitialize itself :/ | 22:01 |
| jtaylor | but warnigns are better than acrash :) | 22:02 |
| infinity | jtaylor: http://core.tcl.tk/tk/vpatch?from=8b40f8cacfa04130&to=9fc8df19b1c093ef is slightly more readable (and has a test!) | 22:05 |
| jtaylor | let me try that patch | 22:06 |
| infinity | jtaylor: Should be the same as what you linked, except for being the full commit. | 22:06 |
| jtaylor | yes looks the same | 22:06 |
| jtaylor | hm doesn't apply to the package | 22:07 |
| infinity | Indeed, 1 hunk fails. Probably something that moved on in trunk. | 22:08 |
| * infinity looks. | 22:08 | |
| infinity | Yeah, that free got moved out of the brace. | 22:08 |
| infinity | s/free/NULL/ | 22:09 |
| * infinity mangled the patch a bit to account for that. | 22:09 | |
| infinity | jtaylor: http://paste.ubuntu.com/7081732/ <-- Try that. | 22:12 |
| jtaylor | hm still fails for me, I applied this http://paste.ubuntu.com/7081755/ | 22:18 |
| infinity | Looks a lot like what I was about to apply. How can I easily test this? | 22:19 |
| infinity | jtaylor: Wait, by "fails", do you mean it still crashes, or it still fails to reinit? | 22:19 |
| jtaylor | hm python-statsmodels tests fail, I swa it in another package but forgot which one | 22:19 |
| infinity | (Like, does this fix anything? :P) | 22:19 |
| jtaylor | fails to apply | 22:19 |
| jtaylor | the patch fixes the crash | 22:20 |
| infinity | Oh. Doesn't fail to apply here, let me just feed you packages instead. | 22:20 |
| jtaylor | your patch has different whitespace, weird it applies for you, but doesn't matter the content is the same as mine | 22:22 |
| infinity | jtaylor: Yeah, just going to get you to double-check my binaries before I upload. | 22:22 |
| infinity | jtaylor: Because paranoid. | 22:22 |
| infinity | jtaylor: amd64? | 22:22 |
| jtaylor | yes | 22:23 |
| infinity | jtaylor: dget http://lucifer.0c3.net/~adconrad/tk/tk8.6_8.6.1-3ubuntu2_amd64.changes | 22:23 |
| jtaylor | infinity: my testcase: sudo apt-get install python-statsmodels; python -c "import statsmodels.graphics; statsmodels.graphics.test()" | 22:23 |
| jtaylor | should segfault after about 60 dots | 22:24 |
| jtaylor | ~20 sec | 22:24 |
| jtaylor | with the fix just a couple warnings and no test failures | 22:24 |
| jtaylor | infinity: your packages work, thx | 22:26 |
| infinity | Ta. | 22:27 |
| infinity | Uploading, then. | 22:27 |
| A3D_Damir | kubuntu can make pannel for adds and marketing compannies so when they want to make adds it will be on desktop with option for users to choese branch , section and to remove or show up MARKETING PANNEL | 22:46 |
| A3D_Damir | or ubuntu hehehe | 22:46 |
| A3D_Damir | ubuntu should have how to section for users and most common problems like BLUR newbeeeeee will throw it when that happen to HIM | 22:50 |
| === lionel_ is now known as lionel | ||
| YokoZar | Is apt supposed to interpret "replaces" this way? I just installed wine1.6 on a system with wine1.7 installed (wine1.7 replaces wine1.6), and apt unpacked wine1.6 before removing wine1.7, resulting in a fake install of wine1.6 without any binaries. | 23:00 |
| YokoZar | Or is apt bugging out here and getting the order wrong | 23:02 |
| === plars is now known as plars-away | ||
| === cjohnston_ is now known as cjohnston | ||
| infinity | YokoZar: Replaces refers to file overlaps... | 23:15 |
| infinity | YokoZar: So, yes, it's absolutely expected that if you remove the package that Replaces another, you'll lose the files that overlapped, since it now owns them. | 23:16 |
| infinity | YokoZar: If you want them to not be coinstallable, you want a Conflicts. | 23:18 |
| YokoZar | infinity: they also conflict | 23:18 |
| YokoZar | infinity: remove wine 1.7 followed by install wine1.6 results in a different system state than just install wine1.6, but the same package set | 23:19 |
| teward | infinity: (1) sorry for pinging you then dying, my internet was being stupid. (2) NGINX MIR has a debdiff uploaded, sarnold said you're on the MIR team and know the process, care to review my debdiff? (it's based off of the latest stable that we merged in) | 23:19 |
| infinity | Hrm, if they conflict too, that's a bit odder. | 23:19 |
| teward | (no rush, though :) ) | 23:19 |
| YokoZar | https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1291668 | 23:19 |
| ubottu | Launchpad bug 1291668 in wine1.6 (Ubuntu) "Apt installs wine1.6 without its binaries when wine1.7 was on the system" [High,New] | 23:19 |
| infinity | YokoZar: Where are these wine1.7 packages? | 23:21 |
| YokoZar | infinity: From a PPA (it might matter to apt that the ppa was disabled at the time of the operation) | 23:22 |
| infinity | YokoZar: It shouldn't, and this isn't apt at all, it's dpkg. | 23:23 |
| YokoZar | oh right | 23:24 |
| infinity | YokoZar: Where is this PPA? | 23:24 |
| YokoZar | I suspect that apt might be getting its ordering wrong due to multiarch changes or similar weirdness | 23:24 |
| YokoZar | https://launchpad.net/~ubuntu-wine/+archive/ppa | 23:24 |
| YokoZar | *dpkg | 23:24 |
| YokoZar | oh | 23:25 |
| YokoZar | maybe wine1.7 doesn't conflict wine1.6 | 23:25 |
| infinity | That doesn't have the packages from the log. | 23:26 |
| infinity | And yes, not conflicting is what I suspect. | 23:26 |
| infinity | dpkg interprets Replaces/Conflicts *completely* differently from just Replaces. | 23:26 |
| infinity | One is a "tear out package B to install package A" and the other is "overwrite files from B with A". | 23:26 |
| infinity | Conflicts: wine1.0, wine1.2, wine1.3, wine1.4 | 23:27 |
| infinity | Definitely no 1.6 conflict there. | 23:27 |
| YokoZar | Yup, that'd do it | 23:27 |
| YokoZar | well, sorta | 23:27 |
| YokoZar | They depend on things that conflict | 23:27 |
| infinity | YokoZar: Right, which is why the package was eventually removed. | 23:27 |
| infinity | YokoZar: But that won't save you from the (correct) interpretation of your relationships. :P | 23:28 |
| YokoZar | I think i left out the conflict to make migration to eventual dummy package earlier | 23:28 |
| infinity | YokoZar: I'd assume your Replaces and Conflict lines should match. I don't see a 1.5 conflict either. | 23:28 |
| YokoZar | 1.5 was converted to a dummy package | 23:28 |
| YokoZar | I have to do dummy packages to do version transitions :/ | 23:28 |
| infinity | Why? | 23:29 |
| infinity | Why not just have a "wine" package that tracks the latest? | 23:29 |
| infinity | Which, indeed, you do. | 23:29 |
| infinity | So why would you need dummy packages? | 23:29 |
| YokoZar | The intended workflow is that wine1.6 and wine1.7 live together as different options, wine gives a default, and packages depend on wine1.7-i386 (or similar) if they need the newer version of wine. | 23:31 |
| YokoZar | Then when wine1.8 is out it can provide both of those things | 23:31 |
| YokoZar | But if I do conflicts, apt gets confused about the conversion of a former real package into a dummy one and gets in the way of the upgrade | 23:31 |
| infinity | wine1.7 Conflicts: wine1.6 << 1.7 ; wine1.8: Conflicts: wine1.8 << 1.9 ; etc? | 23:33 |
| infinity | Assuming the dummy package comes from the next wine version. | 23:33 |
| infinity | (base)adconrad@cthulhu:~$ apt-cache show wine1.4 | grep Version | 23:33 |
| infinity | Version: 1:1.6.1-0ubuntu4 | 23:33 |
| infinity | Would certainly work there. | 23:34 |
| YokoZar | As I understood it, versioning something that then becomes a virtual package eventually is bad too | 23:34 |
| infinity | Oh, they move from full to dummy to virtual? | 23:34 |
| infinity | Whee. | 23:34 |
| infinity | Why the virtual? | 23:34 |
| infinity | And is that even true? | 23:35 |
| infinity | I don't see anything with a "Provides: wine1.2" (or whatever). | 23:35 |
| YokoZar | I'm trying to remember the reasons I ended up setting a lot of this up | 23:35 |
| YokoZar | the dummy packages may have just started because the upgrades weren't happening automatically without them actually | 23:35 |
| infinity | wine1.6 just Provides: wine | 23:35 |
| infinity | No versioned ones. | 23:35 |
| YokoZar | wine is also a dummy package in wine1.7 package | 23:36 |
| YokoZar | This is an elaborate mess | 23:37 |
| infinity | Sure looks like one, yes. | 23:37 |
| YokoZar | Built up over several years of workaround installation issues | 23:37 |
| infinity | Anyhow, your bug isn't a dpkg bug, it's a packaging bug. Sorry. :P | 23:37 |
| YokoZar | Well, I didn't file it vs dpkg :P | 23:37 |
| YokoZar | Sorry my memory about why all this was done is a bit hazy | 23:37 |
| YokoZar | But I may get back to you if I run into a catch-22 here | 23:38 |
| infinity | teward: Remind me of the bug number? | 23:38 |
| infinity | YokoZar: I suspect you might be using the transitional packages because you're trying to force the old ones off the system, and update-manager (or apt in upgrade mode) is pretty grumpy about making sweeping changes that remove a bunch of packages. | 23:39 |
| sarnold | infinity: 1262710 | 23:39 |
| YokoZar | infinity: yes that sounds right | 23:39 |
| infinity | YokoZar: But it could take some experimentation to figure out the best path forward. Still, versioning those conflicts would work fine. | 23:39 |
| infinity | YokoZar: Not that that helps people who already have the broken 1.7 installed. | 23:39 |
| infinity | (But here's hoping you get them to upgrade before they blow up the world installing 1.6) | 23:40 |
| infinity | sarnold: I will say I'm not wildly happy about the "just tear out lua support" option with no real indication of how many people might consider that a useful feature. | 23:40 |
| sarnold | infinity: yes, i'm not real thrilled with it either. | 23:41 |
| infinity | sarnold: So, this might come back to "why (other than jcastro blogging about it) are we pushing nginx into main in a potentially crippled state?" | 23:42 |
| sarnold | infinity: but I'm not particularly keen on supporting two vastly different versions of lua in trusty, and upstream for the nginx_lua module is content to stay on lua 5.1 for eternity... | 23:42 |
| sarnold | infinity: if you were to download an nginx tarball from nginx.org, you wouldn't get this module anyhow; they think nginx is useful enough without also trying to turn it into a node.js competitor but with lua :) | 23:43 |
| teward | infinity: one moment i have to pull it from my history | 23:43 |
| teward | https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710 | 23:43 |
| ubottu | Launchpad bug 1262710 in nginx (Ubuntu) "[MIR] nginx" [Undecided,Confirmed] | 23:43 |
| teward | infinity: i'm not a fan of it either, but the lua module upstream has basically told us they won't port to 5.2 | 23:44 |
| teward | and the only other alternative would be to try and get luajit-5.1-dev's source package into main alongside nginx | 23:44 |
| teward | (that's the only other option that seems to build this, and run it) | 23:44 |
| infinity | That's still 5.1 :P | 23:44 |
| infinity | And I agree, we don't want two luas in main. | 23:44 |
| teward | true statement. | 23:44 |
| infinity | I guess the upstream lua dude has chosen his fate. | 23:44 |
| teward | infinity: the way to think about this is that the nginx team PPA will always have the Lua module | 23:45 |
| teward | until 5.1 is dropped from the archives completely | 23:45 |
| infinity | It didn't look *too* hard to port, but I only got about 10% of the way through before realizing I have better ways to waste my time. | 23:45 |
| teward | infinity: https://github.com/chaoslawful/lua-nginx-module/issues/343 is the summary of my attempts to get them to try and port it | 23:45 |
| infinity | teward: Pointing people at a PPA to get missing options isn't the right answer. | 23:45 |
| teward | infinity: nor is stripping modules from the package that we know people use. | 23:46 |
| teward | but as i see it we don't *really* have many options. | 23:46 |
| sarnold | infinity: cripes, you actually started making that conversion even after reading the changelog between lua 5.1 and 5.2? :) | 23:46 |
| infinity | sarnold: The API changes aren't as dire as the nginx-lua people are claiming. | 23:48 |
| infinity | sarnold: It's not hard to follow if you've done compiler/VM work before. | 23:48 |
| infinity | (Which, to me, should almost be a prereq for writing a mod_lang style embedded language plugin) | 23:49 |
| sarnold | infinity: that does seem like a fair enough pre-req :) | 23:49 |
| infinity | teward: If we *know* people use the lua modules, the best option is to reject the MIR. | 23:49 |
| infinity | teward: The best option is NOT to say "hey, we totally suport a subset of the package that you will NO LONGER USE, but here's a PPA." | 23:50 |
| teward | infinity: well, the problem I see is that everyone's expecting the MIR to go through (blame jcastro) | 23:50 |
| infinity | That's... Pointless. | 23:50 |
| teward | this is a catch-22 here now | 23:50 |
| infinity | jcastro: Hey you. Come have an opinion. | 23:50 |
| sarnold | I wish the debian nginx package had never included a bunch of extra crazy crap glued onto the side... sigh. | 23:51 |
| infinity | jcastro: Or, come have mine. | 23:51 |
| xnox | infinity: i thought nginx lua is about as reliable as Randall's opinion on haskell https://xkcd.com/1312/ | 23:51 |
| infinity | sarnold: To be fair, the lua module is extra crazy crap that upstream includes. | 23:51 |
| teward | infinity: jcastro was the one who jumped-the-gun and said it was probably going to get into main. | 23:51 |
| teward | and later updated saying it might not, but it's still likely to | 23:51 |
| infinity | sarnold: I'm fine with dropping the third party modules, but it's not really a stretch to say that people probably expect the upstream stuff to be there. | 23:51 |
| infinity | sarnold: Imagine if I gave you a "LAMP" server but, well, left out mod_perl, mod_python, and mod_php, and said "well, it's LAM... You don't need the P". | 23:52 |
| teward | infinity: TBH the nginx people direct people to the PPAs anyways | 23:52 |
| xnox | i think it's totally fine to disable lua, and redirect people nags to upstream "look they don't support lua" and cherry-pick lua module support whenever it gets written. | 23:52 |
| teward | heck, even I do that in #Ubuntu-server because people are demanding spdy3 | 23:52 |
| sarnold | infinity: I asked for the extra binary packages because I didn't want two source packages, but we -could- go that route: one source package for nginx-core and nginx, one source package for all the other crazy crap that stays in universe. it's not an awesome idea but .. sigh. | 23:52 |
| teward | and that won't be in here anyways. | 23:52 |
| teward | (that's only nginx mainline) | 23:53 |
| teward | (and that's not even in Debian yet) | 23:53 |
| sarnold | xnox: it's harder because nginx won't dlopen() load modules; they have to built in at compile time. | 23:53 |
| infinity | xnox: How is that better than the status quo, which is "it all works just fine, but we don't officially support it"? | 23:54 |
| infinity | Seriously, I just see zero point in "supporting" things if we admit we're just going to point people to upstream packages and PPAs. | 23:54 |
| xnox | smoser: i can't reproduce your bug. in the script you pasted you prepare "disk.img", boot "disk1.img", pull boot.log from "disk.img". | 23:54 |
| sarnold | we'd be pointing three people at it, not everyone :) | 23:54 |
| infinity | It's a press release bullet point, but it's otherwise a waste of everyone's time and makes us look pretty crap. | 23:54 |
| xnox | smoser: after fixing that up, it's consistent output, without dupes. | 23:54 |
| infinity | sarnold: Sounds like more than three people get pointed there. | 23:55 |
| teward | (general note: if the MIR *is* rejected I'm going to go to jcastro and basically do the internet equivalent of yelling "I told you this might happen" at him for jumping the gun) | 23:55 |
| infinity | sarnold: (see teward's comment about upstream pointing people to PPAs too) | 23:55 |
| teward | infinity: um... | 23:55 |
| teward | you missed my point | 23:55 |
| xnox | infinity: we support lua?! =) | 23:55 |
| teward | the reason we point people to the ppas is because of the spdy demand | 23:55 |
| sarnold | infinity: oh you know how upstream authors are, they always want people to just run their tarballs. :) | 23:55 |
| teward | not the lua | 23:55 |
| infinity | teward: Sure, I think you missed my point. | 23:55 |
| teward | infinity: i saw it and dismissed it. at this point i'm on the fence about the MIR | 23:56 |
| infinity | teward: This isn't *just* about lua. This is about "why is it going to be officially supported if people aren't running it?" | 23:56 |
| infinity | xnox: Yes, we support lua. | 23:56 |
| teward | infinity: true. honestly, I could care less which way this goes, it's a catch-22 regardless of what we do | 23:56 |
| infinity | xnox: Just not 5.1 | 23:56 |
| teward | people're going to complain regardless. | 23:56 |
| teward | infinity: and there-in lies the catch. waht's the reason for not supporting 5.1, again? | 23:57 |
| * teward doesn't follow the entire -devel list, so missed some things | 23:57 | |
| infinity | teward: Because supporting multiple versions of things becomes exponentially pain-in-the-assicult. | 23:57 |
| teward | that doesn't explicitly answer my question | 23:57 |
| infinity | teward: We don't tend to have multiple versions of much of anything in main. Except GCC, cause it's a uniquely annoying snowflake. | 23:58 |
| infinity | teward: Sure it does. We support 5.2. We don't support multiple versions. 5.1 is another version. | 23:58 |
| infinity | teward: The upstream hilarity of "we want people running cutting edge software, so we don't care what crusty LTS distros do" is wonderfully ironic, when they insist on using a many-year-old version of lua. | 23:58 |
| * teward sighs | 23:59 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!