| === FJKong_afk is now known as FJKong | ||
| dobey | infinity: oh. hope you're feeling better. are you still around? | 01:16 |
|---|---|---|
| infinity | dobey: Ish. | 01:25 |
| dobey | infinity: just uploaded a new ubuntuone-client for saucy-proposed, and about to do the same for precise-proposed, if you could accept them? | 01:28 |
| infinity | dobey: I will have a look, yeahp. | 01:36 |
| dobey | infinity: and precise-proposed uploaded too. thanks much. i'll test as soon as they're built in -proposed | 01:37 |
| infinity | dobey: Done and done. | 01:41 |
| dobey | thanks! | 01:43 |
| * dobey wonders how long it will take for them to show up in the archive | 01:58 | |
| === beisner- is now known as beisner | ||
| === sz0 is now known as sz0` | ||
| dobey | sigh, i wonder if it's virtualbox that makes setting the time so difficult, or what | 02:18 |
| infinity | dobey: "date -s ..."? | 02:22 |
| infinity | dobey: Preferably in the VM, not in the host, if you value your sanity. | 02:23 |
| dobey | sanity? what's that? | 02:23 |
| dobey | in saucy i can set the date ok from the system settings | 02:24 |
| dobey | but in the precise vm it keeps automatically changing back to the current date | 02:24 |
| dobey | no idea why | 02:24 |
| infinity | dobey: Some "use network time" tickbox being overexhuberant, perhaps? | 02:25 |
| infinity | dobey: But setting it from a terminal should do fine, I'd think. | 02:25 |
| dobey | maybe, but i unchecked it (you can't actually change the date with the radio button set to "automatic") | 02:25 |
| dobey | nope, date -s doesn't help | 02:26 |
| infinity | Your VM hates you... | 02:27 |
| dobey | it set it for a few seconds, but by the time i typed the command to start u1 and connect, it had already changed back :( | 02:27 |
| infinity | I'd suggest ntpd is running, but ntpd usually gives up if you're too far out of sync with reality. | 02:27 |
| dobey | ps doesn't show any ntpd | 02:28 |
| dobey | whee | 02:28 |
| dobey | and i unplugged the network and it still gets reset | 02:30 |
| dobey | so yeah, precise vm is hating me | 02:30 |
| infinity | I can't imagine what would be resetting it. | 02:30 |
| dobey | yeah, me either :( | 02:31 |
| infinity | If in doubt, blame g-s-d? | 02:31 |
| dobey | wfm | 02:31 |
| infinity | Though killing g-s-d wouldn't be so helpful if what you're testing needs it. :P | 02:31 |
| dobey | ok, so the notifications are still weird on precise (but i think tthat's a bigger bug in the code that we don't really have time to fix at this point) | 02:32 |
| infinity | I wouldn't be aboe blaming indicator-datetime, or similar, either. But I'm just grasping at straws, without staring at the VM in question. | 02:32 |
| dobey | but the connecting post-june-1 fix is working right on precise | 02:32 |
| infinity | s/aboe/above/ | 02:32 |
| infinity | dobey: If you're happy enough with the state of those packages, then, we'll just let 'em in. | 02:33 |
| infinity | dobey: I don't want to delay any longer unless you think you can fix the weird notification thing in short order. | 02:33 |
| dobey | infinity: i don't think we can fix it. i just now changed the bug to verification-done and added a comment to that effect. i think we should push the update out now | 02:35 |
| infinity | dobey: Alrighty. Doing. | 02:36 |
| infinity | mdeslaur: Around? | 02:37 |
| dobey | infinity: thanks a lot for your help with this. | 02:37 |
| infinity | jdstrand: Or you? | 02:37 |
| infinity | Oh, wait, I think the security team might be on European time... | 02:37 |
| mdeslaur | infinity: what's up? | 02:39 |
| infinity | mdeslaur: Any qualms about me pushing the above ubuntuone-client update to precise-security as well, overwriting what you have in the pocket? | 02:39 |
| infinity | mdeslaur: I think it'd be monumentally confusing to the 2 people who run security-only without updates when the package explodes and stops working correctly on Jun 1. :) | 02:40 |
| mdeslaur | infinity: no qualms at all, go right ahead | 02:40 |
| infinity | mdeslaur: Ta. | 02:40 |
| mdeslaur | does it need to be rebuilt with only -security though? | 02:40 |
| infinity | Seems pretty unlikely, but maybe I should have double-checked before hitting enter. | 02:41 |
| * infinity quickly goes to look at deps. | 02:41 | |
| infinity | mdeslaur: binary deps all looks safe. | 02:42 |
| mdeslaur | infinity: cool | 02:44 |
| === FJKong is now known as FJKong_afk | ||
| dobey | hooray | 02:45 |
| infinity | mdeslaur: Speaking of things that aren't technically security updates but screw with people who run security-only, I wonder if we should chat about tzdata sometime. | 02:51 |
| mdeslaur | hrm, interesting | 02:52 |
| mdeslaur | yeah, I guess that could go into -security too | 02:52 |
| infinity | mdeslaur: I mean, the part where we've never had complaints either means no one actually runs security-only, or the people who do are all in regions with stable timezones. :) | 02:52 |
| infinity | mdeslaur: Cause you tend to notice pretty quickly when tzdata is wrong for you. | 02:53 |
| mdeslaur | I've always been really curious as to how many people actually do run -security only | 02:53 |
| infinity | Me too. I'm not even sure how we'd go about mocking pseudo-metrics for that, let alone good ones. | 02:53 |
| infinity | Could start with maybe looking for desktop apps that are out of sync between security and updates and reporting crashes to errors. | 02:54 |
| mdeslaur | when someone enables unattended updates during the server image install, that's security only, right? | 02:54 |
| infinity | Not sure. | 02:54 |
| Logan_ | is the implicit conversion to pointer failure really necessary on amd64? it only inevitably causes a problem on ia64, and Debian only checked on ia64 buildds (but we fail builds on amd64 as well) | 02:54 |
| infinity | Unattended-Upgrade::Allowed-Origins { | 02:55 |
| infinity | "${distro_id}:${distro_codename}-security"; | 02:55 |
| infinity | }; | 02:55 |
| mdeslaur | hrm, interesting | 02:55 |
| infinity | mdeslaur: The default conffile comments out other pockets, so yeah, I guess. | 02:55 |
| infinity | /etc/apt/apt.conf.d/50unattended-upgrades | 02:55 |
| dobey | weird | 02:55 |
| mdeslaur | I always thought it would be used more by server users than desktop users | 02:56 |
| infinity | Logan_: Yes. | 02:56 |
| dobey | my server has backports and updates in the list when i do "apt-get update" | 02:56 |
| infinity | Logan_: It's actually worse on amd64 than ia64, in that it's a guaranteed runtime explosion on ia64, and it's nondeterministic "wheeee!" on amd64. | 02:56 |
| mdeslaur | dobey: when done manually, yes | 02:56 |
| Logan_ | infinity: I see - but then why doesn't Debian do it? | 02:56 |
| mdeslaur | dobey: when done automatically by unattended-updates, no | 02:56 |
| infinity | Logan_: Plus, it's always a bug. And a bad one. Even on 32-bit arches, it usually points to a bad bug elsewhere (like an implicit declaration). | 02:57 |
| dobey | mdeslaur: oh, that's kind of weird | 02:57 |
| infinity | Logan_: Debian failed for it on ia64 because LaMont ran those buildds. Guess who wrote the code that fails it on our buildds? :) | 02:57 |
| Logan_ | I see :P | 02:57 |
| infinity | Logan_: Anyhow, I'm the one at "fault" for extending the check to all 64-bit arches, but with good reason. | 02:58 |
| infinity | Logan_: I'm tempted to extend the check to all implicit declarations as well, as they cause more interestingly subtle bugs. | 02:58 |
| Logan_ | what's weird is that I just synced over your delta for jmagick because I didn't get any references to "implicitly" in my pbuilder log, but it happened on the build | 02:58 |
| Logan_ | any idea why that's the case? | 02:58 |
| Logan_ | *buildd | 02:58 |
| Logan_ | I'll obviously reinstate your changes, but I don't get why I didn't get those warnings in my local build | 03:00 |
| infinity | Logan_: What arch was your local build on? | 03:00 |
| Logan_ | amd64 | 03:00 |
| infinity | Also, wow, this code is a mess. I must have been very tempted to rewrite half of it last time I was in there. | 03:00 |
| Logan_ | should I use sbuild instead or something? or would that not make a difference? | 03:02 |
| infinity | Logan_: I don't see why it would make a difference. I'm doing a test build here. | 03:03 |
| Logan_ | infinity: oh wait - is the line "Function `getByteArrayFieldValue' implicitly converted to pointer at magick_MagickImage.c:3454" injected into the log? | 03:05 |
| Logan_ | because it occurs right beneath a warning in the buildd log | 03:05 |
| Logan_ | and that's what I grepped for in my local build log | 03:05 |
| infinity | Ahh, yes, that's inserted. :) | 03:05 |
| Logan_ | grrr :P | 03:05 |
| Logan_ | rewriting history | 03:05 |
| * Logan_ begrudgingly reintroduces the delta | 03:06 | |
| infinity | Logan_: http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/view/head:/lpbuildd/check_implicit_pointer_functions.py | 03:07 |
| infinity | Logan_: That's responsible for the insertion. | 03:07 |
| Logan_ | ah, I see | 03:07 |
| Logan_ | I think I'll also forward your patch to Debian once I upload this, unless you want to | 03:08 |
| infinity | It's already there. | 03:08 |
| Logan_ | tbh, it should be upstream | 03:08 |
| Logan_ | oh | 03:08 |
| infinity | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727776 | 03:08 |
| ubottu | Debian bug 727776 in jmagick "jmagick implictly declares getByteArrayFieldValue due to missing prototype" [Important,Open] | 03:08 |
| Logan_ | alright, reupped with the patch | 03:09 |
| Logan_ | thanks as always :P | 03:10 |
| infinity | Reading that build log just makes me cry. | 03:10 |
| infinity | How do people never actually check the output of their compilers? | 03:10 |
| Logan_ | I like all of the deprecated functions | 03:12 |
| infinity | That's to be expected, as the thing they're building against moves on... | 03:12 |
| infinity | But all the type mismatches have probably been there since day 1. | 03:12 |
| infinity | I don't think that's an underlying API moving. | 03:12 |
| infinity | That's just lazy programming. | 03:12 |
| Logan_ | erm | 03:13 |
| Logan_ | one of the functions they use, DestroyImages, has been deprecated in ImageMagick since 2002 | 03:13 |
| infinity | Hahahaha. | 03:13 |
| infinity | Okay, some lazy there too then. :) | 03:13 |
| infinity | If we turned on -Wall -Wextra -Werror, we could probably reduce the archive size by 90%. | 03:17 |
| infinity | So tempting. | 03:17 |
| Logan_ | we're not supposed to babysit upstream :P | 03:18 |
| Logan_ | as nice as it would be to remove warnings from all packages in the archive, it ain't gonna happen with our limited devs | 03:20 |
| infinity | I know. It's a pipe dream I'll never realize. | 03:20 |
| infinity | So, I'll go back to nursing my flu instead. | 03:21 |
| === sz0` is now known as sz0 | ||
| === sz0 is now known as sz0` | ||
| === Ursinha is now known as Ursinha-afk | ||
| === elky_ is now known as elky | ||
| === Ursinha-afk is now known as Ursinha | ||
| pitti | Good morning | 05:22 |
| michagogo | dobey, infinity: Yeah, Virtualbox does mess with the clock | 05:49 |
| michagogo | I think it keeps the VM's hardware clock synced with the host or something | 05:49 |
| michagogo | Which is annoying if you need to mess with the clock inside the VM | 05:50 |
| michagogo | But I think there's a way to turn it off -- if not in the GUI, then with vboxmanage | 05:50 |
| infinity | michagogo: That's completely broken behaviour... | 05:50 |
| infinity | Of course, the best way to avoid it is to use kvm or Xen. :P | 05:50 |
| michagogo | Heh, starting to google for "virtualbox disable..." first suggestion is "time sync" | 05:50 |
| RAOF | infinity: You'll be in Malta next week, right? | 05:55 |
| === Ursinha is now known as Ursinha-afk | ||
| infinity | RAOF: Aye. | 05:59 |
| infinity | siretart: I'm rejecting the libav binaries from the queue, so we don't half-start the transition on 4/6 arches. | 05:59 |
| infinity | siretart: If you need help figure out the arm64/ppc64el build failures (in both cases, it looks like perhaps bad assumptions about the compatibility of vector assembly), ask. | 05:59 |
| RAOF | infinity: Rad. It might be time to get to that AA training. | 06:01 |
| infinity | RAOF: Yeah. I'm trying to get arges to be a limited-scope AA just to be able to back me up for kernel SRU stuff (which requires AA because reasons), so maybe the three of us should spend some quality time together. | 06:03 |
| slangasek | cjwatson, xnox: I got a ucf prompt on upgrade from trusty->utopic for /etc/kernel-img.conf. Does d-i or ubiquity set this up for us on install, or was this my own doing? | 06:05 |
| infinity | slangasek: d-i creates it, I believe, but what on earth thinks it owns it all of a sudden? | 06:06 |
| === Ursinha-afk is now known as Ursinha | ||
| slangasek | infinity: "kernel-common", because Manoj woke up | 06:06 |
| RAOF | And by “requires AA because reasons” what you mean is “needs to be a member of ~ubuntu-archive because LP permissions”, as *I'm* a member of ~ubuntu-archive for the same reasons. | 06:06 |
| infinity | slangasek: Ah-ha. So, yeah, it was completely unowned in Ubuntu until then. | 06:06 |
| infinity | RAOF: Yeah, that. ;) | 06:07 |
| infinity | RAOF: But if we have people we "shouldn't" have in ~ubuntu-archive, I also want to make sure they're prepared to flex those permissions sanely when needed. | 06:07 |
| infinity | (Or to remove them) | 06:07 |
| infinity | (Or to get notes from their mothers promising they won't touch anything) | 06:08 |
| RAOF | That's what I've done :) | 06:08 |
| RAOF | People ask for things not-SRU-related, and I say “sorry, no can do” ☺ | 06:08 |
| infinity | slangasek: Did kernel-common always "own" it, and we only just recently pulled it in as a dep of something else? | 06:08 |
| infinity | slangasek: I don't have it installed here... | 06:08 |
| slangasek | infinity: no, from the changelog kernel-common is a new package; I had kernel-package installed for $reasons, and on upgrade it pulled in the new kernel-common | 06:09 |
| infinity | slangasek: Indeed, new in sid and utopic. | 06:09 |
| infinity | slangasek: So, that's entirely Manoj's fail. He can't just take over a config file like that. Go forth and smack him. | 06:10 |
| slangasek | infinity: so I think we want to fix kernel-common to /actually/ install a file that matches what the installer does, or else launch the new package out of an airlock if we don't want it in utopic | 06:10 |
| slangasek | infinity: is this a bug also in Debian? | 06:10 |
| infinity | slangasek: Yeahp. | 06:10 |
| slangasek | infinity: you want to do the smacking? :) | 06:10 |
| infinity | slangasek: kernel-img.conf has the same semantics there, both its use in kernel postsints, and its unowned (until now) status. | 06:10 |
| infinity | slangasek: You discovered it, smack on. | 06:10 |
| slangasek | infinity: you seem to have a better handle on the details, surely the smack would be more effective from you :) | 06:11 |
| infinity | slangasek: I tried. Can't tab complete his name in #debian-devel. I give up. | 06:11 |
| slangasek | infinity: relatedly, why do we still create /vmlinuz and /initrd.img links by default? That's silly | 06:18 |
| infinity | slangasek: You mean why do we not default to link_in_boot=yes, or why have the links at all? | 06:19 |
| slangasek | infinity: if we're going to have them at all, they should be in /boot, not somewhere that may be a separate filesystem; and the bootloader no longer uses them on x86 so we should probably not have them at all | 06:20 |
| infinity | slangasek: Except for the 7 people who still use lilo, yeah, no one else uses them, I imagine. | 06:20 |
| infinity | slangasek: But absolutely agreed that if we have them, they should be in boot (and I always alter my config to do so). | 06:21 |
| slangasek | me too | 06:21 |
| infinity | Anyhow, looks like the kernel-common thing was an overzealous reply to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626216 | 06:22 |
| ubottu | Debian bug 626216 in kernel-package "Manpage should live in a different package" [Minor,Fixed] | 06:22 |
| infinity | I'm thinking just putting the manpage in linux-base and keeping the rest alone would have been saner. :P | 06:22 |
| StevenK | I have do_symlinks = no, and yet /vmlinuz is a symlink to latest kernel | 06:22 |
| infinity | StevenK: That's because it's do_symlink | 06:23 |
| StevenK | Hah | 06:23 |
| StevenK | I also don't have a kernel-img.conf manual page, which is helpful | 06:23 |
| infinity | Oh, hrm. No. It's do_symlink in the code, but do_symlinks in the config file. Whee. | 06:24 |
| StevenK | Hahaha | 06:24 |
| StevenK | infinity: Is this where I say "You're welcome." and back away slowly? :-P | 06:24 |
| === Adri2000_ is now known as Adri2000 | ||
| LocutusOfBorg1 | Hi, can I ask somebody of the buildd team to retry a build failed? | 06:56 |
| LocutusOfBorg1 | https://launchpad.net/ubuntu/+source/wxwidgets3.0 | 06:56 |
| LocutusOfBorg1 | https://launchpad.net/ubuntu/+source/wxwidgets3.0/3.0.0-3/+build/6030586 | 06:56 |
| LocutusOfBorg1 | don't know, "compiler segmentation fault" doko_ do you have any idea? | 06:57 |
| LocutusOfBorg1 | maybe just a retry is enough | 06:57 |
| === fginther` is now known as fginther | ||
| infinity | LocutusOfBorg1: Retried, but I bet it fails again. | 07:09 |
| LocutusOfBorg1 | thanks infinity I hope not :p | 07:10 |
| LocutusOfBorg1 | I would like to upload some packages that use wx3.0 on debian | 07:11 |
| LocutusOfBorg1 | I don't want to see them in proposed until somebody retries/processes them, and I need at least the wx -3 release | 07:12 |
| LocutusOfBorg1 | because of the new package | 07:12 |
| infinity | pitti: Your patches to do rebuilds with dpkg-buildpackage for linux/glibc fail because there's no fakeroot. That needs to be in the deps. | 07:19 |
| * infinity wonders if this is worth killing his sid build to fix... | 07:19 | |
| === _salem is now known as salem_ | ||
| apw | infinity, pitti, yeah the rebuild fixes for linux fail for lack of fakeroot as well | 07:23 |
| infinity | apw: Yeah, that's where I noticed the bug, and am now fixing it in glibc. ;) | 07:23 |
| apw | infinity, so ... why isn't that build-essential | 07:24 |
| apw | ie ... already installed | 07:24 |
| infinity | apw: Because it's not. gain-root is buildd-specific. | 07:24 |
| infinity | apw: http://paste.ubuntu.com/7504510/ | 07:24 |
| infinity | apw: That's what I'm applying to glibc, something similar should do for the kernel. | 07:24 |
| LocutusOfBorg1 | :( g++: internal compiler error: Segmentation fault (program cc1plus) | 07:25 |
| LocutusOfBorg1 | Please submit a full bug report, | 07:25 |
| apw | infinity, oh, i see ... unexpected but ok ... will get that applied to the kernel, not sure i want to upload for it though, uggg | 07:25 |
| infinity | LocutusOfBorg1: File a bug on gcc-4.8 and poke doko about it. | 07:25 |
| infinity | apw: Don't bother uploading for it, just queue it up. | 07:25 |
| apw | infinity, also is there anything i can _test_ these changes on do you know | 07:26 |
| infinity | apw: I'll just be naughty and ignore the -2.6 tests, if the other tests pass. | 07:26 |
| apw | infinity, thanks :) | 07:26 |
| infinity | apw: There's a magic wiki page somewhere about how to do adt at home. I always lose it... | 07:26 |
| infinity | apw: http://packaging.ubuntu.com/html/auto-pkg-test.html | 07:27 |
| apw | infinity, also does the error line in p-m make sense to you, the version it reports for linux | 07:27 |
| infinity | apw: The version there is completely bogus, yes. | 07:27 |
| infinity | jibel: What's up with that? | 07:27 |
| apw | jibel, http://paste.ubuntu.com/7504521/ is what it was saying | 07:28 |
| apw | jibel, everything is right there in the sense there is a regression, but it is not in that version of linux | 07:29 |
| LocutusOfBorg1 | ok wilco | 07:30 |
| LocutusOfBorg1 | does anybody knows why cppcheck is still in proposed queue? https://launchpad.net/ubuntu/+source/cppcheck | 07:31 |
| infinity | LocutusOfBorg1: Causes two packages to become uninstallable. | 07:32 |
| infinity | Or, rather, the tinyxml2 transition does. | 07:33 |
| infinity | Why is there a library in those metapackages? :/ | 07:33 |
| * infinity fixes... | 07:34 | |
| LocutusOfBorg1 | thanks :) | 07:37 |
| LocutusOfBorg1 | doko_, ----> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1322485 | 07:37 |
| ubottu | Launchpad bug 1322485 in gcc-4.8 (Ubuntu) "wxwidgets3.0 arm64 fails to build with gcc 4.8" [Undecided,New] | 07:37 |
| jibel | apw, infinity looking | 07:42 |
| infinity | jibel: It's not actually causing a problem currently, but the reporting having the wrong version is definitely confusing. :P | 07:45 |
| jibel | infinity, right, and in the logs of britney it's the correct version "Collected autopkgtest status for linux_3.15.0-2.6/linux_3.15.0-2.6: FAIL" I'll investigate further after the sprint today | 07:48 |
| === klubko is now known as naivka | ||
| === FJKong_afk is now known as FJKong | ||
| zyga | hey | 08:21 |
| zyga | mvo: running update-manager on utopic today I've noticed that checkboxes next to package names are cropped (about 30% on the left) | 08:22 |
| mvo | zyga: I can reproduce this, thanks! this smells like iz gtk bug because I don't think we changed update-manager in utopc much. just a internal change fo the meta-index stuff, nothing in the UI | 08:26 |
| zyga | mvo: yeah, I suspect that as well | 08:27 |
| zyga | mvo: want a bug report for that? | 08:27 |
| * zyga wonders how to file that bug ;) | 08:27 | |
| zyga | if I use ubuntu-bug it will say packages are outdated | 08:27 |
| mvo | zyga: lets discuss in malta, then I can nudge seb128 diretly to fix it :P | 08:28 |
| zyga | if I update I cannot show the bug ;0 | 08:28 |
| mvo | zyga: hihi | 08:28 |
| zyga | heh, sure :) | 08:28 |
| zyga | mvo: I'm not in malta btw | 08:28 |
| zyga | mvo: are you guys still there? | 08:28 |
| mvo | zyga: aha, ok. I will fly there sunday | 08:28 |
| zyga | oh, I heard some folks are there for a week or so | 08:28 |
| zyga | nice place to sprint! | 08:28 |
| mvo | zyga: I never went there, I'm curious about it | 08:29 |
| infinity | mvo: 'iz gtk bug'... Haven't seen that in a while. :) | 08:29 |
| Laney | I don't see that problem btw and gtk hasn't really changed in utopic yet | 08:29 |
| mvo | infinity: soon it will be "iz qt bug" :P | 08:30 |
| mvo | Laney: oh? hm, hm | 08:30 |
| Laney | well, unless I don't know what I'm looking for :) | 08:31 |
| Laney | it looks like http://ubuntuone.com/0ZlmWracPK89WzWSAUMAdf | 08:32 |
| mvo | Laney: the gtk treeview paints the "triangles" wrong and cuts parts of the text. once a expander is clicked (or theme is changed) it is ok again. simple resize is not sufficient | 08:33 |
| mvo | Laney: http://ctrlv.in/335583 | 08:38 |
| infinity | Laney: Getting the most out of that service before June 1? :P | 08:40 |
| === sz0` is now known as sz0 | ||
| jtaylor | if a package does not work at all as it does not support the software version in trusty, but a new upstream version does, can one SRU the new upstream? | 08:41 |
| jtaylor | (subversion 1.8 and eclipse subversion plugin are the packages in question) | 08:42 |
| infinity | jtaylor: If that's literally the only way to fix it, perhaps. | 08:42 |
| Laney | infinity: Old habits die hard :P | 08:42 |
| infinity | jtaylor: I assume it's the plugin you're talking about, not updating SVN itself? | 08:42 |
| xnox | infinity: tinyxml library is used by gallery-app click. | 08:43 |
| jtaylor | yes | 08:43 |
| jtaylor | technically its a java library the plugin uses | 08:43 |
| infinity | jtaylor: How scary is the delta, and can the necessary bits be backported? | 08:43 |
| jtaylor | didn't look | 08:43 |
| jtaylor | I'm wondering if can safe looking as there is zero regression potential | 08:43 |
| jtaylor | it can't get worse than does not work at all | 08:43 |
| infinity | xnox: Yeah, I saw the note in the seeds when I fixed it. Gross that we're seeding libraries due to underrepresented (or unrepresentable) deps. | 08:44 |
| xnox | infinity: hence it's in the touch seed, i've filed bug to either get tinyxml into the click itself, during click build. or move from tinyxml to qt. | 08:44 |
| xnox | infinity: cause camera-app click to longer depends on tinyxml. | 08:44 |
| infinity | jtaylor: Yeah, that's a pretty valid argument, I'd still like to see the proposed diff. :) | 08:44 |
| jtaylor | svnclientadapter is the source | 08:45 |
| infinity | You'd think 1.8 would work with 1.8... | 08:46 |
| infinity | Silly people. | 08:46 |
| jtaylor | I don't think the versions are coupled | 08:47 |
| jtaylor | utopic has 1.10 | 08:47 |
| jtaylor | I'll check if a rebuild works first | 08:47 |
| infinity | jtaylor: Is it svnclientadapter or libsvn-java that's the problem? | 08:47 |
| jtaylor | (installing utopic in trusty works fine) | 08:48 |
| jtaylor | the adapter | 08:48 |
| jtaylor | its got a version == 1.7 check in it | 08:48 |
| infinity | Are you getting this string? "Incompatible JavaHL library loaded. Subversion 1.7.x required." | 08:51 |
| jtaylor | yes | 08:51 |
| jtaylor | the diff to utopic is not large | 08:51 |
| jtaylor | but I don't see time well spent in backporting | 08:51 |
| infinity | Theoretically, the package had a patch for that... | 08:51 |
| infinity | Oh, no it didn't, I can't read. | 08:52 |
| jtaylor | I'll file a bug that the package should have a stricter svn dependency | 08:53 |
| infinity | But that one delta to src/javahl/org/tigris/subversion/svnclientadapter/javahl/JhlClientAdapterFactory.java might fix it. | 08:53 |
| jtaylor | yes, but is it really worthwhile testing if that is enough? | 08:53 |
| pitti | infinity, apw: argh, sorry about that; thanks | 08:53 |
| jtaylor | upstream tested utopic with 1.8 | 08:54 |
| jtaylor | so we should use that for trusty | 08:54 |
| pitti | apw: right, I don't think you need to upload just for that -- new kernels come often enough anyway? :-) | 08:54 |
| jtaylor | instead of trying to do a partial backport | 08:54 |
| infinity | pitti: Should this be the right fix? http://anonscm.debian.org/viewvc/pkg-glibc?view=revision&revision=6105 | 08:54 |
| infinity | pitti: Identical commit was made to the kernel. | 08:55 |
| infinity | jtaylor: Sure, bumping the version might be the saner thing to do, just want to explore options. | 08:55 |
| infinity | jtaylor: It's certainly not an enormously scary diff. | 08:55 |
| pitti | apw: BTW, http://people.canonical.com/~pitti/tmp/linux-autopkgtest/ are the updated tests for linux-exynos5 (now including fakeroot) | 08:56 |
| pitti | apw: that also restricts the test to armhf, to avoid a failure on x86 | 08:56 |
| pitti | infinity: looks good; -rfakeroot should be the default these days though? | 08:56 |
| infinity | pitti: It is, but if we're explicitly depending on a specific gainroot, I feel we should also explicitly call it. | 08:57 |
| pitti | *nod* | 08:57 |
| infinity | pitti: Why the need to restrict tests to armhf when the source only produces armhf binaries? That seems like a test infra issue, not something that should be literring tests. | 08:58 |
| infinity | pitti: It makes exactly zero sense to run tests on an arch the package doesn't build for. | 08:58 |
| pitti | ah, I guess we could apply some debian/control parsing magic to find that out, yes | 08:59 |
| infinity | pitti: Or just read the .dsc | 08:59 |
| infinity | pitti: Oh, but you only work with unpacked trees? | 08:59 |
| infinity | Anyhow, that package is also buggy and claims to build arch:all packages that it can't possibly. | 09:00 |
| pitti | infinity: tree, .dsc, or (as in production) apt-get source | 09:00 |
| infinity | I fixed that in linux-ppc long ago, I guess the stupid carried over. :P | 09:00 |
| pitti | so debian/control it is | 09:00 |
| infinity | pitti: Kay, apt-get source gets you a .dsc, which is much easier to parse than control in this case. | 09:00 |
| infinity | But meh. | 09:00 |
| infinity | First, control needs to be fixed to stop pretending it builds things it doesn't. | 09:01 |
| infinity | apw: Where is the exynos5 git? | 09:01 |
| cjwatson | xnox: does the click package in question actually link against tinyxml directly, or is it perhaps via libmediainfo? | 09:01 |
| pitti | well, needs to work for anything, so debian/control it is; but the parsing isn't the problem really, it's figuring out from the Architecture: fields whether or not this applies | 09:01 |
| cjwatson | xnox: (compare gallery-app.deb) | 09:01 |
| apw | infinity, now why did i need to know that already this week | 09:01 |
| infinity | pitti: Sure. In this case, you'd (rightly) guess wrong, I think, since there are arch:all debs, but there shouldn't be. | 09:02 |
| infinity | Oh, wait, the git is right there in the control. I wonder if it's right. | 09:02 |
| xnox | cjwatson: actually, i think you are right. I'll test that out. | 09:03 |
| apw | infinity, i'd assume it is git://kernel.ubuntu.com/hwe/ubuntu-trusty-meta-exynos5.git | 09:03 |
| apw | infinity, i'd assume it is git://kernel.ubuntu.com/hwe/ubuntu-trusty-exynos5.git | 09:03 |
| infinity | apw: Yeah, that's what I'm cloning right now. | 09:03 |
| infinity | apw: Do you have write access to that, or do I need to bug ike with a patch? | 09:03 |
| apw | i should have, but will check | 09:04 |
| apw | infinity, that repo is _ahead_ of the archive | 09:04 |
| infinity | apw: That seems reasonable... | 09:04 |
| infinity | zinc needs a go-faster button. | 09:05 |
| apw | i do have write access to it indeed, though this out of sync fun makes life trixy | 09:06 |
| cjwatson | xnox: objdump -p <ELF object> | grep NEEDED should show it | 09:08 |
| xnox | cjwatson: right. it has NEEDED libmediainfo.so.0, and no mentions of tinyxml. | 09:09 |
| xnox | cjwatson: so infinity's seed change can go it & unblock that transition. | 09:10 |
| infinity | xnox: It's already in... | 09:10 |
| infinity | final: cppcheck,libmediainfo,tinyxml2,ubuntu-touch-meta | 09:11 |
| infinity | SUCCESS (26/0) | 09:11 |
| xnox | i wonder if i should be subscribed to -changes mailing list =) | 09:11 |
| infinity | I had to do that update by hand, though. Turns out ./update doesn't work so well when the thing you're seeding only exists in proposed... | 09:11 |
| infinity | Quite annoying. | 09:11 |
| cjwatson | it sounds like the correct seed change (given the intent) would actually have been to seed libmediainfo0 directly. | 09:22 |
| infinity | Perhaps, yes. I was just following the ABI change, this was before anyone did analysis into the why. | 09:25 |
| infinity | libmediainfo0 appears to already be there anyway. | 09:25 |
| infinity | So libtinyxml and libzen could both go away from the seed, I'd think. | 09:26 |
| infinity | But I'll leave that to someone who knows more about this stack. | 09:27 |
| infinity | pitti: So, the bug where exynos5 claims to build packages it doesn't will be fixed in the next upload, at which point a parsing of debian/control or .dsc will return nothing but armhf. | 09:28 |
| infinity | pitti: Which, to me, seems much saner than arch-restricting the test in the source, but YMMV. | 09:28 |
| infinity | pitti: OTOH, I'm not sure there's value in that test in that source anyway. The point of the glibc/linux/binutils/gcc rebuilt test circle is just to make sure no part of the toolchain breaks another part. I'm not sure there's much extra value in making sure every out-of-tree kernel builds. | 09:33 |
| cjwatson | hallyn: So I belatedly looked through your log from last night. Your problem is that your preseed file isn't being read at all. You either need to add file-preseed to your image (build/pkg-lists/netboot/common, probably), or (perhaps easier) given that you're embedding the preseed file in the initrd anyway, just embed it specifically as "/preseed.cfg", at which point it will be read automatically and you can drop the file= boot ... | 09:35 |
| cjwatson | ... parameter. | 09:35 |
| cjwatson | (We should perhaps add file-preseed to netboot images at some point, since it's in Debian's) | 09:36 |
| === vrruiz_ is now known as rvr | ||
| === salem_ is now known as _salem | ||
| siretart | infinity: yes, I could really use some help on those two ftbfs. for arm64, I guess it would be a matter of identifying the upstream commits in master that need to be backported. Please tell me and I see to include them for 10.2 | 11:15 |
| siretart | infinity: for ppc64, I have no idea what this is supposed to mean, nor what could be causing it: /usr/bin/ld: libavcodec/libavcodec.a(fft_altivec_s.o): ABI version 1 is not compatible with ABI version 2 output | 11:15 |
| infinity | siretart: It means it's trying to link a big-endian and little-endian object together. | 11:16 |
| infinity | siretart: Which probably means the Altivec bits are endian-specific. | 11:16 |
| siretart | I guess we could disable altivec on ppc64 and neon on arm64 | 11:16 |
| infinity | siretart: Which should be fixed, but the easiest solution would be to disable altivec on ppc64el. | 11:16 |
| siretart | do we have PPA where I could do the testbuilds, or can you take care of that? | 11:17 |
| infinity | siretart: And I haven't looked at the neon code in question, but it's probably similarly buggy in assuming neon == armv7t2 or some such. | 11:17 |
| infinity | siretart: I can do some test builds for you, though possibly not right this instant. | 11:17 |
| siretart | no problem, take your time | 11:18 |
| siretart | if we can push this transition before the beta, that'd be great | 11:18 |
| infinity | siretart: That seems like a pretty doable goal. | 11:18 |
| siretart | while the transition is not fully over, libav reached testing yesterday, and going with libav9 is imo a no-go for utopic | 11:19 |
| infinity | siretart: So, with libav9, was it using altivec on ppc64el and neon on armv8? | 11:19 |
| infinity | siretart: If so, we should perhaps figure out what broke in each case. | 11:19 |
| infinity | siretart: But I'd suspect it never was before, and now it's detecting "correctly", which happens to be incorrectly for the code in question. | 11:19 |
| siretart | that's entirely possible | 11:20 |
| siretart | if you need help, you might want to talk to jannau on #libav-devel@freenode, he was doing most of the aarch64 work lately | 11:21 |
| infinity | siretart: Well, I'd happily just turn off both SIMD options and sort it out later, my only concern is that fixing it later might change the ABI. | 11:21 |
| siretart | --disable-neon in debian/confflags should do the trick then | 11:22 |
| siretart | in that case they will use the plain C version | 11:23 |
| siretart | I don't have ABI concerns here | 11:23 |
| === MacSlow is now known as MacSlow|lunch | ||
| infinity | siretart: You don't have ABI concerns because you don't care if it breaks, or because you're positive the alternate SIMD implementations are opaquely hidden behind a stable ABI? :) | 11:23 |
| xnox | infinity: cjwatson: should cross-pkg-config, allow cross-compiling against non-multiarched libraries? | 11:25 |
| cjwatson | Err. I'd be inclined to say probably, since the worst it can do is make errors more confusing | 11:26 |
| xnox | cjwatson: ack, and it would unblock a lot of cross-compilation queries i'm getting in #ubuntu-unity, for leaf -dev packages that are not multiarched yet. | 11:27 |
| cjwatson | I don't think it's vital, since there are other fixes possible, but it probably smooths the path | 11:27 |
| infinity | How is it currently preventing it? | 11:27 |
| xnox | infinity: commented out /usr/lib/pkgconfig from PKG_CONFIG_LIBDIR in /usr/share/pkg-config-crosswrapper | 11:28 |
| Laney | It says " # If you want to allow use of un-multiarched -dev packages for crossing | 11:28 |
| Laney | # (at the risk of finding build-arch stuff you didn't want, if not in a clean chroot) | 11:28 |
| Laney | # Uncomment the next line: | 11:29 |
| Laney | " | 11:29 |
| cjwatson | My opinion on the spur of the moment on IRC doesn't necessarily override reasoned argument that you might find in the history, of course | 11:29 |
| infinity | xnox: Hrm. Perhaps changing that to be keyed off an environment variable instead of encouraging people to edit the script? :P | 11:30 |
| xnox | infinity: by default, it is keyed off environment. | 11:31 |
| xnox | cjwatson: Laney: infinity: i'm thinking this might be a simple regression, cause package was forced synced. | 11:31 |
| infinity | xnox: I can absolutely understand the reasoning. The errors would be confusing to the "average" person if they had wrong-arch libs found because of that. | 11:31 |
| infinity | xnox: Err, no, I mean that particular bit keyed off environment, not asking people to set the entire PKG_CONFIG_LIBDIR themselves. | 11:32 |
| xnox | Well, previous edition of pkg-config-wrapper was a two-liner: | 11:32 |
| xnox | triplet=`basename $0 | sed -e 's:-pkg-config::'` | 11:32 |
| xnox | PKG_CONFIG_PATH=/usr/lib/${triplet}/pkgconfig:/usr/${triplet}/lib/pkgconfig pkg-config $@ | 11:32 |
| infinity | xnox: So, that was buggy in that it missed /usr/share, and it also missed the directory you're talking about. | 11:33 |
| * xnox ponders what are the differences between PKG_CONFIG_LIBDIR & PKG_CONFIG_PATH | 11:33 | |
| xnox | infinity: we used to prepend multiarch paths, now we replace all paths with multiarch-only without original. | 11:34 |
| xnox | which is regressing cross-buildability of a lot of touch stuff in ubuntu. | 11:34 |
| infinity | xnox: That's not what your paste implied. | 11:35 |
| Laney | I've already eaten this change for a few libraries, but letting people opt back in might be a good idea | 11:35 |
| infinity | xnox: Anyhow, if we were including /usr/lib/pkgconfig before, and no one was complaining about it being confusing, go ahead and uncomment that line. If you're positive that's how it used to work. Your paste certainly doesn't imply what you said, though. | 11:35 |
| infinity | Oh, I see. | 11:36 |
| infinity | PKG_CONFIG_PATH behaves differently. | 11:37 |
| infinity | Kay. | 11:37 |
| infinity | xnox: Yeah, possibly just the path of least reistance to uncomment that line in Ubuntu, since that was the previous status quo, if no one was complaining about the occasional breakage. | 11:38 |
| infinity | Curiously, the old way we did it would have never worked when crossing to i386. Obviously not something many people do. | 11:38 |
| siretart | infinity: we use linker scripts to hide internal symbols. applications have (or at least should not) no way to access those internals directly | 11:44 |
| infinity | siretart: Some quick symbol dumps certainly look to agree with you. So, yeah, if you want to just disable neon on arm64 and altivec on ppc64el, that would get you over the hump for now, though it would be really good to make sure we revisit both. | 11:46 |
| siretart | absolutely, we should do that. In terms of priority, transitioning the archive seems more important and time-critical to me at this point, though | 11:51 |
| siretart | infinity: if you have a look at http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=blob;f=debian/confflags, disabling neon for arm64 and altivec on powerpc should be straight forward, if you know what to look for (I would need a porter machine to look up what environment variables to test for) | 11:55 |
| infinity | siretart: Kay. I'll try to have a look at that after I've slept a bit. | 12:00 |
| siretart | infinity: Thanks! | 12:00 |
| ahasenack | hi, anyone know why the systemd-logind crash isn't fixed yet in trusty? It happens on every login since the release, seems very high priority | 12:01 |
| mdeslaur | ahasenack: what crash is that? do you have a bug number? | 12:12 |
| ahasenack | mdeslaur: just a crash report, that I upload everytime, but apport doesn't tell me what it did with it | 12:12 |
| ahasenack | -rw-r----- 1 root whoopsie 145K Mai 23 09:00 _lib_systemd_systemd-logind.0.crash | 12:12 |
| ahasenack | -rw-r--r-- 1 root whoopsie 0 Mai 23 09:00 _lib_systemd_systemd-logind.0.upload | 12:12 |
| ahasenack | well, I don't upload it everytime anymore, got tired of that :) | 12:13 |
| ahasenack | but did upload it today | 12:13 |
| mdeslaur | ahasenack: I don't see it being reported on errors.ubuntu.com by anyone, sorry | 12:16 |
| mdeslaur | ahasenack: perhaps file an actual bug about it? does it happen in your guest account too6 | 12:17 |
| ahasenack | it was a fresh install | 12:17 |
| ahasenack | but haven't tried the guest account | 12:17 |
| ahasenack | I suspect most people suspend/resume | 12:18 |
| ahasenack | it happens after a cold start, first login | 12:18 |
| mdeslaur | ahasenack: I definitely haven't seen that, and there aren't any errors being reported about that | 12:19 |
| mdeslaur | ahasenack: so please file a bug | 12:19 |
| ahasenack | ok | 12:19 |
| ahasenack | mdeslaur: do you know where my crash report went? | 12:19 |
| ahasenack | I've got colleages who also tell me they clicked the report button in the crash dialog box dozens of times | 12:20 |
| mdeslaur | ahasenack: is this it? bug 1309025 | 12:22 |
| ubottu | bug 1309025 in systemd (Ubuntu) "systemd-logind assert failure: cgmanager-client.c:6322: Assertion failed in cgmanager_list_children_sync: proxy != NULL" [Medium,Confirmed] https://launchpad.net/bugs/1309025 | 12:22 |
| ahasenack | mdeslaur: could be, let me look at my stacktrace from the crash file | 12:23 |
| xnox | ahasenack: do you have cgroups-lite installed? | 12:23 |
| ahasenack | xnox: yes | 12:24 |
| xnox | ahasenack: uninstall it & reboot. check if that fixes it for you. | 12:24 |
| xnox | ahasenack: you want cgmanager installed at the same time (if not otherwise installed) | 12:25 |
| ahasenack | xnox: isn't that needed by lxc? cgroups-lite? | 12:25 |
| ahasenack | Title: systemd-logind assert failure: cgmanager-client.c:4546: Assertion failed in cgmanager_get_value_sync: proxy != NULL | 12:25 |
| xnox | ahasenack: no. | 12:25 |
| ahasenack | that's the title from my crash report | 12:25 |
| ahasenack | so yeah, looks like it's the same bug | 12:26 |
| xnox | ahasenack: although i have cgroup-lite installed and everything works fine.... | 12:26 |
| xnox | hm... | 12:26 |
| ahasenack | xnox: cgmanager is installed too already | 12:26 |
| mdeslaur | xnox: I also have cgroup-lite installed | 12:27 |
| ahasenack | xnox: can't remove cgroup-lite: | 12:27 |
| ahasenack | The following packages will be REMOVED: | 12:27 |
| ahasenack | cgroup-lite* libvirt-bin* | 12:27 |
| xnox | mdeslaur: hm, why does libvirt-bin & utah still use cgroup-lite? | 12:27 |
| xnox | hallyn: jibel: can libvirt-bin & utah switch to use cgmanager instead of cgroup-lite | 12:27 |
| xnox | ? | 12:27 |
| lamont` | infinity: actually, dannf wrote the code to fail implicit-conversions... I just brought it over to ubuntu, and yes, it's a far worse (though less frequent ant therefore a total surprise in debugging) on amd64 | 12:37 |
| marga | infinity, ping? We've added more info to the weird libx32 bug (https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1302605) | 12:39 |
| ubottu | Launchpad bug 1302605 in eglibc (Ubuntu) "Calls to /libx32/ld-linux-x32.so.2 hang" [Undecided,Confirmed] | 12:39 |
| === ara is now known as Guest58311 | ||
| marga | infinity, we believe it's an issue related to auditd being enabled, and that it's the kernel who's at fault. | 12:40 |
| marga | Uhm, seems infinity is sick and away... Is there anybody around here knowledgeable on both kernel issues and auditd that could give a hand? | 13:09 |
| yoh | Hi guys, I wondered if there any recipe somewhere to replicate existing PPA environment locally? in particular to the given version of kernel. PPA build (on 12.04) fails in a unique fashion and we need to troubleshoot it. | 13:15 |
| geser | marga: even infinity sleeps now and then | 13:20 |
| marga | geser, sure, I thought he was in more or less my timezone, but I might be wrong. | 13:21 |
| ScottK | He did say he was sick yesterday. | 13:22 |
| marga | His away message says so. | 13:24 |
| === _salem is now known as salem_ | ||
| geser | hmm, ok, he was active up till around 90 min ago and his last words were "after I've slept a bit." | 13:25 |
| marga | Oh, ok. | 13:25 |
| marga | geser, thanks for the info. | 13:25 |
| === Ursinha is now known as Ursinha-afk | ||
| leex | hi, my do-release-upgrade segfaults with this error message: http://paste.ubuntu.com/7505633/ while trying to upgrade 13.04 to 13.10 does anyone have an idea on how to fix it? | 13:34 |
| === lucas_ is now known as lucas | ||
| === Ursinha-afk is now known as Ursinha | ||
| ara | stgraber, salut! qt-base has been in the trusty unapproved queue for quite a bit of time now (https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=) | 13:40 |
| ara | stgraber, and it will help solve an important bug (https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1307701) | 13:40 |
| ubottu | Launchpad bug 1307701 in qtbase-opensource-src (Ubuntu Trusty) "xserver mouse pointer emulation from touch breaks with QML app." [High,In progress] | 13:40 |
| === zyga_ is now known as zyga-remote | ||
| ara | stgraber, as SRU team member, could you please have a look, please? | 13:40 |
| TJ- | leex: It suggests there is an illegal UTF8 character in one of the existing /etc/apt/sources.list.d/* files | 13:42 |
| leex | TJ-: damn I had an .un~ file in there :/ maybe they should be ignored by the script, thanks! | 13:44 |
| leex | TJ-: nevertheless, thanks a lot, upgrading works now :) | 13:45 |
| ScottK | ara: The tools the SRU team use for SRU processing don't really work for CI train syncs so they tend to not get looked at as often. | 13:49 |
| === sz0 is now known as sz0` | ||
| ara | ScottK, so, do I have to do anything differently to make sure it is looked at? | 13:51 |
| ScottK | No. I'm sure it will get looked at. | 13:52 |
| === sz0` is now known as sz0 | ||
| === salem_ is now known as _salem | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === sz0 is now known as sz0` | ||
| hallyn | cjwatson: d'oh, but som eof the questions i thought weren't being asked. i think i've been copying it lately as the wrong filename now that you mention it, but in the past it has never taken the username preseeds while it didn't ask me for partitioning... hm. well i'll fix the filename and test next week. hoefully i'll just feel silly and it'll work :) | 14:11 |
| hallyn | xnox: do you mind opening a bug against libvirt? i'm out until next tue. i had originally wanted to do it during 14.04 cycle | 14:12 |
| hallyn | i need to do that as well as test out the upstart patch. but, dropping irc now - ttyl | 14:12 |
| infinity | marga: I'm not quite asleep yet, but also in no shape to wrap my head around that bug either. | 14:22 |
| marga | infinity, well, pkern just found a fix | 14:22 |
| marga | infinity, it's 3 lines in one .S file :-/ | 14:22 |
| infinity | marga: Oh, handy. | 14:22 |
| marga | infinity, he's updating the bug now, with the diff. | 14:23 |
| infinity | marga: Lovely. Who's to blame? | 14:23 |
| marga | infinity, uhm... the interaction between x32 syscall masking and auditd | 14:24 |
| marga | when running on x32, syscalls have an extra high bit, that needs to be removed before calling auditd, and this wasn't happening. | 14:25 |
| infinity | apw: Can you have a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1302605 | 14:26 |
| ubottu | Launchpad bug 1302605 in linux (Ubuntu) "Calls to /libx32/ld-linux-x32.so.2 hang when using auditd" [Undecided,Confirmed] | 14:26 |
| infinity | marga: Thanks to you (and pkern) for the debugging and patch. | 14:26 |
| marga | infinity, :) | 14:26 |
| infinity | marga: Does he intend to push that upstream himself? | 14:26 |
| marga | infinity, upstream being kernel.org? | 14:27 |
| infinity | marga: Yeah. | 14:27 |
| apw | infinity, x32 ? | 14:27 |
| infinity | apw: Yeah, check the last couple of comments. | 14:27 |
| infinity | pkern: Oh, I guess you're here, I could ask you directly. :P | 14:28 |
| marga | infinity, ok, he says he will try to do it | 14:28 |
| apw | infinity, yeah that looks about right, do i need to do something, or are they interacting upstream about it | 14:31 |
| infinity | apw: The last two lines of IRC backcroll seem to imply that pkern will attempt to upstream it, but if it passes muster for you guys, SAUCEing it and then replacing with an upstream commit might not be terrible. Seems like the sort of thing that shouldn't blow up. | 14:32 |
| apw | infinity, ok, will ahve a poke | 14:32 |
| marga | apw, personally, given my experience with previous kernel.org patches coming from non kernel hackers, it would be nice if this could get applied early. | 14:32 |
| infinity | apw: Which is why I also gave it a trusty task for you (probably broken in saucy too, but carefactor of zero there) | 14:32 |
| pkern | infinity: I'll try. As you might now... Is there a primary x32 maintainer? | 14:34 |
| infinity | pkern: Not sure on the kernel side. x32 in general is HJ Lu's baby, but I have no idea if he's also doing kernel or just toolchain. | 14:35 |
| pkern | I saw his name on the ABI documents at least. | 14:35 |
| pkern | Ok. | 14:35 |
| infinity | pkern: It might fall in hpa's lap. Dunno. | 14:36 |
| infinity | pkern: The patch looks pretty mind-numbingly obvious, so I don't imagine much push-back if you can actually get noticed and get it in the right person's patch queue. | 14:37 |
| infinity | pkern: Anyhow, I think apw will be a gentleman and get it into the Ubuntu kernel for you guys soonish, but you should be the one submitting upstream for attribution and bragging rights. We can swap the local patch for the upstream commit when it happens. | 14:39 |
| apw | infinity, pkern, that indeed | 14:39 |
| pkern | infinity: ACK, thanks! | 14:41 |
| === jono is now known as Guest70896 | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| cjwatson | xnox: is lp:~xnox/ubuntu-test-cases/touch-emulator still maintained? | 15:22 |
| cjwatson | xnox: just want to check if I'm working on the right basis for building autopkgtest stuff around it - if so, I have a patch to fix it up for python3 on the target | 15:23 |
| === sz0` is now known as sz0 | ||
| xnox | cjwatson: i don't believe that's latest. There was work done by #ci folks around touch-emulator. | 15:30 |
| xnox | cjwatson: i'd take patches / fixes for it. | 15:30 |
| xnox | cjwatson: plars tells me latest is in https://code.launchpad.net/~doanac/ubuntu-test-cases/emulator-scripts | 15:33 |
| cjwatson | Aha, right | 15:33 |
| xnox | cjwatson: about to land (it's emulator/x86 focused) | 15:33 |
| cjwatson | you have mail anyway | 15:33 |
| xnox | cjwatson: ack. will review. | 15:33 |
| cjwatson | looks like it's obsolete with that new branch | 15:34 |
| xnox | IMAGE_OPT="--channel ubuntu-touch/utopic-proposed --arch=i386" USE_EMULATOR=1 xvfb-run -a -s "-screen 0 640x480x24" ./scripts/run-smoke -a friends-app | 15:34 |
| xnox | is the new way of doing things. | 15:34 |
| xnox | plars telling in #ci =) | 15:34 |
| plars | hi | 15:34 |
| plars | Having some issues on the emulator side though | 15:35 |
| * cjwatson notes | 15:35 | |
| plars | I ran it yesterday a few times and saw the emulator crash | 15:35 |
| cjwatson | I did manage to get xnox's scripts working today, but only one in three or so emulator runs actually starts up properly | 15:35 |
| plars | trying it with larger tests (webbrowser for example), the device just disappeared at one point on me | 15:35 |
| cjwatson | I had adb push hang at one point too | 15:37 |
| zyga | hey, is there any reason why python3-dbg doesn't load any native modules? I cannot import lxml and other things like that | 15:39 |
| zyga | barry: ^ any idea? | 15:41 |
| zyga | I need to poke around a problematic python app with gdb | 15:41 |
| zyga | and I want to have access to all the fancy py- macros in gdb | 15:41 |
| stgraber | c | 15:43 |
| stgraber | oops :) | 15:43 |
| zyga | too much gdb | 15:43 |
| zyga | ;) | 15:43 |
| zyga | s/python/python3/ | 15:43 |
| xnox | stgraber: is your login name "c" and pasword "oops :)" ?! =) | 15:43 |
| stgraber | xnox: sure is :) | 15:43 |
| * ogra_ throws envious looks at stgraber ... | 15:45 | |
| ogra_ | i just read that you can get symmetrical 1GBit fiber in switzerland now | 15:45 |
| ogra_ | evil ! | 15:45 |
| zyga | ogra_: you make me sick, | 15:45 |
| zyga | ogra_: that should be illegal ;) | 15:45 |
| ogra_ | ++ | 15:45 |
| ogra_ | and they say thats the low end offer ! they plan even bigger setups | 15:46 |
| zyga | ogra_: they must make up for the fact they have no sea ;) | 15:46 |
| ogra_ | lol | 15:46 |
| xnox | zyga: they have lakes to make up for that ;-) | 15:49 |
| barry | zyga: you need to install the -dbg packages for any extension modules | 15:49 |
| zyga | barry: thanks | 15:50 |
| zyga | barry: I reverted to using plain python3 and py-bt finally works :) | 15:50 |
| zyga | it's godsend when a multi-threaded dbus service deadlocks | 15:50 |
| barry | nice | 15:51 |
| xnox | everything is nice about dbus, apart from writing bindings to dbus services or debugging it server side..... | 15:52 |
| stgraber | ogra_: sort of, it's been possible to get gigabit or even 10gbit fiber for a few years now but not through mainstream ISPs and obviously retricted to tiny areas, now swisscom launched their fiber service which is covering quite a few more cities but it's still a long way from being the usual kind of speed | 15:52 |
| ogra_ | ah | 15:53 |
| stgraber | ogra_: nowadays your standard internet over there is around 150/15 over cable, with the fast one being 250/25, both pretty reasonably priced | 15:53 |
| stgraber | however, as I don't live there anymore (I just happen to be there this week before Malta) I don't get to enjoy it too often, my home connection in Montreal is just 30/10 vdsl (but very very stable, native ipv6, static IPs, ... so perfect for work) | 15:54 |
| stgraber | well, I can get 250/25 over cable in Montreal, it's just that it'd come with a stupid 500GB quota and won't allow using it for home servers, so not really an option... | 15:55 |
| ogra_ | i could get 50/25 VDSL here ... if i only could get rid of my 2M SDSL line | 15:57 |
| xnox | i have 120/10 in London. And I am disappoint. Fairly static IPs (~ it renews only about 2 times a year, or well never if you keep your router on), no IPv6 =( | 15:57 |
| Laney | at least no CGNAT on virgin... yet... | 15:58 |
| cjwatson | xnox: Is that ADSL? You could probably get native IPv6 from A&A then | 15:59 |
| xnox | cjwatson: that's cable. I have not had ADSL since 2010. (since there is no options but ADSL in Hull) | 16:00 |
| xnox | cjwatson: A&A is pricey =) | 16:01 |
| cjwatson | They actually improved their pricing a fair bit recently from my point of view, so I was going to look at them again after I got back from Malta | 16:02 |
| stgraber | my current DSL provider also comes at a premium vs the usual ones, but that's what you have to pay to get good service and competent support when things go wrong. Otherwise you'll end up with the usual "did you update Windows?" kind of tech support and will be stuck without internet for a week... | 16:04 |
| stgraber | (though with DSL, it's usually the phone provider that screws up and unfortunately you can't quite change that, unless you go cable and then it's even worse, at least in Canada) | 16:05 |
| cjwatson | A&A take special pride in browbeating the phone provider into fixing things faster than anyone else, which is one reason I'm interested :) | 16:06 |
| cjwatson | Anyway, EOW | 16:06 |
| stgraber | :) | 16:07 |
| stgraber | ok, have fun, see you on Sunday/Monday! | 16:07 |
| === roadmr is now known as roadmr_afk | ||
| === sz0 is now known as sz0` | ||
| === sz0` is now known as sz0 | ||
| rbasak | xnox: I'm with A&A. For the quality I get, I don't think 100GB/mo for £25 (+£10 line rental) is pricy. | 16:21 |
| rbasak | It's sometimes a bit annoying to have to watch the bandwidth when doing some repeated test that uses cloud images though. | 16:23 |
| rbasak | I tend to try and do that sort of thing somewhere online instead, rather than local. | 16:23 |
| elmo | I agree, I don't think A&A is pricey either; I'll happily pay their prices for a competent ISP and the native v6 is a nice added bonus | 16:38 |
| === sz0 is now known as sz0` | ||
| === gusnan_ is now known as gusnan | ||
| xnox | rbasak: i should find out how much bandwidth i waste, cause we stream television over the internet (via russian channels subscription) | 17:00 |
| === roadmr_afk is now known as roadmr | ||
| ryanneufeld | Can someone point me to a guide for building my own deb packages for trusty that doesn't include all the bazzar and launchpad stuff? | 17:31 |
| apw | pkern, ok test kernels are posted in the bug, if you could let me know how they pan out. | 17:38 |
| === sz0` is now known as sz0 | ||
| Henne91 | Hey guys! I'm trying to create a patch to fix/workaround the following bug: https://bugs.launchpad.net/ubuntu/+source/indicator-keyboard/+bug/1240198 | 18:41 |
| ubottu | Launchpad bug 1240198 in indicator-keyboard (Ubuntu) "wrong keyboard layout active after booting into desktop, after upgrade to saucy" [High,Confirmed] | 18:41 |
| Henne91 | I've never done this before so I thought maybe somebody here can help me with this. | 18:41 |
| Henne91 | Basically it seems like it is necessary to create an additional config file for ibus to change its default behaviour. | 18:43 |
| Henne91 | I used Quilt to create the file as a patch. | 18:44 |
| Henne91 | Ok, just found the required infos in the docs. Nevermind! ;-) Thanks anyway. | 18:46 |
| === Ursinha is now known as Ursinha-afk | ||
| smoser | hey, is there any way of getting ddebs through a ppa ? | 18:59 |
| === Ursinha-afk is now known as Ursinha | ||
| dobey | smoser: you can request it be enabled for your ppa i think | 19:01 |
| smoser | dobey, just as in a request to launchpad ? | 19:02 |
| smoser | specifically i'm after this for cloud archive, which is built via a ppa and then copied elsewhere. | 19:02 |
| dobey | smoser: as in asking an lp admin, yeah. | 19:04 |
| dobey | smoser: ask, as in the asme way one would ask for arm support in a ppa | 19:05 |
| smoser | dobey, thanks. | 19:05 |
| * xnox stops doing random uploads and goes to pack | 19:47 | |
| Shock | hi | 21:15 |
| Shock | I've made a patch for #1247584 and tested locally on my system. would anyone be willing to help me prepare the patch for inclusion in ubuntu? | 21:16 |
| sarnold | Shock: oof, looks complicated. If you attach your patch to the bug, it'll kick off another bot that'll add some messages and perhaps prod other people into looking at the bug to sponser the patch. | 21:43 |
| Shock | sarnold: thanks. would've liked to learn how to do it myself, though. | 21:44 |
| sarnold | Shock: makes sense :) do you have sbuild set up on your machine yet? That'd be a handy next step, if not; that'll make it easier to test patches in the packaging | 21:54 |
| Shock | sarnold: nope, I've been building the packages with dpkg-buildpackage | 21:54 |
| sarnold | Shock: ah, fair enough. for occasional use that's just fine :) | 21:55 |
| sarnold | Shock: what does 'what-patch' return for that package? | 21:55 |
| Shock | quilt | 21:56 |
| sarnold | Shock: nice. if you quilt push -a all the patches onto the queue, then you could use quilt import /path/to/patch to add your patch to the end of the file | 21:57 |
| Shock | sarnold: I've been reading http://packaging.ubuntu.com/html/fixing-a-bug.html but I don't understand the relationship between all the parts | 21:57 |
| Shock | sarnold: I've already built a package with the patch locally | 21:58 |
| sarnold | Shock: nice! now you need a debdiff. this is the part that gets hard for me, because I use a different toolchain that automates this away from me :) hehe | 21:58 |
| Shock | sarnold: I've installed devscripts | 21:59 |
| sarnold | Shock: did you update the debian/changelog? | 21:59 |
| sarnold | (add new version etc) | 21:59 |
| Shock | sarnold: no | 21:59 |
| sarnold | Shock: okay, dch -r will help you there :) | 21:59 |
| Shock | sarnold: I dont know all the rules pertaining to the changelog/versioning so I've left it alone. the package I've built has the same version as the one in the archive | 22:00 |
| sarnold | Shock: there's some version update examples here: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging | 22:00 |
| Shock | sarnold: ok, I'm in the editor | 22:01 |
| Shock | this is insane :) is it not possible to automate it somehow? | 22:01 |
| sarnold | Shock: that's the handy tool I mentioned earlier :) I'm not sure if it would repay the setup costs for just dealing with a package once in a while, but it's really handy for dealing with five versions of four packages each week :) | 22:02 |
| Shock | sarnold: I'm talking about stuff like "Please be careful. Security updates must have a version number higher than any version that was in the archive for that release. This means you must check the release pocket, the proposed pocket and the updates pocket (see SecurityTeam/FAQ#Repositories for details)." | 22:03 |
| Shock | sarnold: it seems very error prone | 22:03 |
| Shock | sarnold: in time, I plan to understand the relationships between pbuilder, dpkg-buildpackage, sbuild, schroot, debootstrap, etc | 22:04 |
| Shock | sarnold: seems a lot to take in | 22:04 |
| sarnold | Shock: the launchpad 'source package' page will have version numbers all handily collected in one place; check https://launchpad.net/ubuntu/+source/systemd for the numbers | 22:04 |
| sarnold | Shock: (again, this is another step that is abstracted away a bit by the 'umt' tool I use, it'd be 'umt search system' -> http://paste.ubuntu.com/7507428/ | 22:05 |
| Shock | sarnold: if I understand correctly, my version should be 204-5ubuntu20.3 | 22:06 |
| sarnold | Shock: looks right to me | 22:07 |
| Shock | sarnold: ok, I'm in the editor spawned by dch -r | 22:08 |
| Shock | sarnold: at the top is the last official changelog entry | 22:08 |
| sarnold | Shock: oh man. I'm sorry. I mis-remembered. :( quit out of that without saving.. | 22:08 |
| sarnold | Shock: dch -a should do what you want | 22:09 |
| Shock | sarnold: with my name under it :-/ | 22:09 |
| Shock | sarnold: I must've done something wrong because dch -a is somehow replacing the last changelog entry | 22:10 |
| sarnold | Shock: it didn't make a new one for you? | 22:10 |
| cjwatson | dch -i would be more usual for that. | 22:11 |
| Shock | sarnold: no, I think this is because I've issued a debcommit at one point in order to comply with what dpkg-buildsource was asking | 22:11 |
| cjwatson | dch -a explicitly asks to append to the current entry. | 22:11 |
| sarnold | cjwatson: sigh. thanks. :) | 22:12 |
| sarnold | neat though, that'll be handy to have. | 22:12 |
| sarnold | Shock: twice wrong in one go. sorry. sigh. | 22:12 |
| Shock | ok, dch -i left the last entry intact and created a new one for me. it doesn't have the version at the top like the last official entry | 22:12 |
| Shock | sarnold: don't worry, this way I've learned the difference between dch -r, -a, and -i :) | 22:13 |
| sarnold | Shock: haha :) me too, when before all I ever used was -r .. | 22:13 |
| sarnold | (which worked in my workflow, 'umt changelog' does the dch -i with a calculated version number...) | 22:14 |
| Shock | sarnold: I prefer to stay with the low level stuff until I understand how the plumbing works, then move to higher level stuff | 22:16 |
| sarnold | Shock: *nod* | 22:17 |
| Shock | sarnold: this is the top of the changelog in the editor: http://paste.ubuntu.com/7507454/ | 22:19 |
| === Ursinha is now known as Ursinha-afk | ||
| sarnold | Shock: nice; could you also add (LP: #1247584) to the comment, so the bug will be closed when the package is uploaded? | 22:21 |
| ubottu | Launchpad bug 1247584 in systemd (Ubuntu) "[keymap] Since upgrade to Ubuntu 13.10, udev doesn't map middle mouse button." [Undecided,Confirmed] https://launchpad.net/bugs/1247584 | 22:21 |
| Shock | sarnold: added! do I need to add a version line? | 22:22 |
| sarnold | Shock: yes, I believe 'trusty-updates' for the release name | 22:22 |
| Shock | sarnold: added "systemd (204-5ubuntu20.3) trusty-updates; urgency=medium", what now? | 22:25 |
| Shock | parsechangelog/debian: warning: debian/changelog(l3): found start of entry where expected start of change data | 22:26 |
| Shock | LINE: systemd (204-5ubuntu20.3) trusty-updates; urgency=medium | 22:26 |
| Shock | parsechangelog/debian: warning: debian/changelog(l3): found eof where expected start of change data | 22:26 |
| Shock | got that after saving | 22:26 |
| sarnold | Shock: rebuild the package; find a pristine copy of 204-5ubuntu20.2 source package -- and use debdiff between the two .dsc files to generate a debdiff that you can attach to the bug and ask for a sponser | 22:26 |
| Shock | sarnold: should I ignore the warning from dch? | 22:27 |
| sarnold | Shock: I -think- your asterisk was one column too soon | 22:28 |
| sarnold | the one on line 8 is under the second 's' in 'systemd', make sure yours lines up on the same column | 22:29 |
| Shock | sarnold: it seems alligned with the other asterisks. dch added a line above my version line "systemd (204-5ubuntu20.3) UNRELEASED; urgency=medium" | 22:30 |
| sarnold | Shock: ah, yeah, you only need one of those lines | 22:31 |
| Shock | sarnold: I'll delete the one added by dch | 22:31 |
| Shock | sarnold: I've run debdiff: http://paste.ubuntu.com/7507521/ | 22:36 |
| sarnold | Shock: you ought to be using the 20.3.dsc from your 'work' directory instead | 22:38 |
| sarnold | (it'll be built once you rebuild the package with your new changelog entry in place) | 22:38 |
| Shock | sarnold: I dont have a 20.3.dsc :-/ | 22:38 |
| Shock | oh | 22:38 |
| Shock | is a source build sufficient? | 22:39 |
| sarnold | it should be for a changelog-only change | 22:39 |
| Shock | sarnold: it's telling me it detected local changes (to files I've not modified) and aborting. do you need pastebin with the errors? | 22:43 |
| sarnold | Shock: try quilt pop -a and then rebuild? | 22:43 |
| Shock | sarnold: debdiff worked but maybe using what it output would be giving the maintainer more work than attaching a simple diff :( | 22:48 |
| sarnold | Shock: maybe, can you pastebin it? | 22:49 |
| Shock | sure | 22:49 |
| Shock | sarnold: http://paste.ubuntu.com/7507563/ | 22:50 |
| ScottK | sarnold: Actually trusty or trusty-proposed. | 22:50 |
| sarnold | ScottK: oh! thanks | 22:50 |
| sarnold | Shock: man that looks very nearly awesome. the patch headers for the 99-keyboard-test.patch are funny :) -- those should be replaced with something more useful | 22:51 |
| infinity | Just trusty, please. | 22:51 |
| Shock | sarnold: it told me "The information above should follow the Patch Tagging Guidelines" and I was like "eject! eject!" :) information overflow | 22:52 |
| sarnold | Shock: hehe yeah I've had this tab open for nearly two years now :) http://dep.debian.net/deps/dep3/ | 22:53 |
| infinity | The boilerplate it gives you should be enough to go by, usually. Just fill in the blanks. | 22:54 |
| Shock | sarnold: I'm gonna modify the debdiff directly. how do I check if it applies cleanly to the pristine package source? | 22:55 |
| sarnold | Shock: unpack the sources in a clean tree, then run patch --dry-run -p1 < /path/to/debdiff -- ifit applies, then take off the --dry-run, re-apply, then re-run the build | 22:55 |
| Shock | sarnold: there's a patch in the patches directory that creates a whole file (on which my patch depends on). how do I ensure my patch is run after the other one? does quilt take care of the ordering? | 23:00 |
| infinity | Shock: ordering is based on the order in the series file. | 23:00 |
| Shock | infinity: thanks, then I'll drop the numeric prefix from the patch file name | 23:00 |
| Shock | sarnold: ok, I edited the debdiff, applied it and built the package | 23:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!