| nacc | doko: ah nm, that's not he failure, it's the lack of debian/tmp/usr/lib/python2.7/dist-packages/cts | 00:07 |
|---|---|---|
| nacc | why dioesn't that also fail on amd64? | 00:07 |
| tumbleweed | difference between a -b and -B build? | 00:08 |
| nacc | tumbleweed: hrm, could be | 00:09 |
| tsimonq2 | does Ubuntu offer machines I could use to debug an s390x build? or is there a guide somewhere for emulating that? | 00:22 |
| Unit193 | nacc: I wouldn't know on that. | 00:23 |
| tumbleweed | tsimonq2: Ubuntu doesn't have any porterboxes for non-canonical employees | 00:24 |
| tsimonq2 | tumbleweed: :(( | 00:24 |
| tsimonq2 | that sucks | 00:24 |
| tumbleweed | tsimonq2: qemu works apparently | 00:25 |
| tsimonq2 | it would be great if there were porterboxes for at the very minimum flavors | 00:25 |
| tumbleweed | https://en.wikipedia.org/wiki/Linux_on_z_Systems#Developer_resources ? | 00:27 |
| nacc | Unit193: ok, np | 00:30 |
| Unit193 | nacc: Sorry, don't really know the context on that. Just always nice when Debian takes the delta and something is sync'able. | 00:31 |
| nacc | Unit193: ack, not a problem, just trying to fixup server packages ftbfs from the archive rebuild e-mail doko recently sent | 00:32 |
| jbicha | nacc: you can use 'syncpackage'; since the package is seeded it probably will stay in the unapproved queue until this week's Ubuntu beta is released | 00:34 |
| nacc | jbicha: ok, that's what i wasn't sure about | 00:39 |
| nacc | jbicha: thanks for clarifying! | 00:39 |
| nacc | jbicha: given this is my first attempt to use so as core-dev, and there is a current delta, should i do `requestsync` instead? or is it appropriate to use --force if I've verified the delta has been picked up by debian? | 00:42 |
| jbicha | I don't think it's necessary to use requestsync since this isn't a Feature Freeze Exception | 00:44 |
| xnox | tumbleweed, moreover canonical doesn't even have a s390x porter box | 00:45 |
| xnox | tsimonq2, can i be of any help at all? i do have access to s390x. | 00:45 |
| nacc | jbicha: ack, so i would use --force to drop the delta then? i'm used to filling out the requestsync template to explain that the delta has been examined and verified | 00:45 |
| jbicha | nacc: yes | 00:46 |
| nacc | jbicha: thanks! | 00:46 |
| Unit193 | nacc: Heh, I'm not even a MOTU. :) | 00:47 |
| tsimonq2 | xnox: I'm assuming you don't want me to just tell you to fix it, right? I don't know what's wrong with it... | 00:51 |
| tsimonq2 | xnox: hardinfo | 00:51 |
| tsimonq2 | xnox: in the lubuntu packageset | 00:51 |
| xnox | tsimonq2, check which object "strend" is, and wether it's correctly included / linked when linking shell.o and others. in that line. | 00:53 |
| xnox | as in it's missing from the long line where hardinfo is linked. | 00:53 |
| sarnold | amd64 fail log looks nearly identical to the s390x failure log https://launchpadlibrarian.net/285995082/buildlog_ubuntu-yakkety-amd64.hardinfo_0.5.1-1.4ubuntu1_BUILDING.txt.gz | 00:54 |
| xnox | tsimonq2, earlier it appears to be defined as inline.... yet expected later on. Does shell.c missing #include "hardinfo.h" or some such? | 00:54 |
| xnox | it all looks odd. | 00:55 |
| tsimonq2 | we're talking about 0.5.1-1.4ubuntu1 here | 00:55 |
| tsimonq2 | xnox: been failing ever since vivid, I've had my eye on it but I haven't worked on the package source (yet) | 00:57 |
| xnox | tsimonq2, indeed $ pull-lp-source -d hardinfo && sbuild -A -d yakkety hardinfo*.dsc fails. | 00:59 |
| xnox | this is not architecture specific at all, and can be worked on / fixed on amd64 | 00:59 |
| tsimonq2 | xnox: but it's not FTBFS on amd64, is it? | 00:59 |
| xnox | tsimonq2, it is | 00:59 |
| sarnold | it is, see the link I pasted a few lines back | 00:59 |
| xnox | that's what sarnold said. | 00:59 |
| xnox | and that's what i've just reproduced locally | 01:00 |
| tsimonq2 | oh, weird | 01:00 |
| tsimonq2 | ok | 01:00 |
| xnox | tsimonq2, strend is claimed to be referenced and undefined. find which unit it is implemented in, and make sure it is linked correctly. | 01:00 |
| sarnold | tsimonq2: 'inline' can be a funny thing, skim this when nothing else makes sense: https://gcc.gnu.org/onlinedocs/gcc/Inline.html | 01:01 |
| tsimonq2 | thank you both | 01:01 |
| xnox | tsimonq2, it seems to me that util.o linking is missing, /after/ shell.o | 01:01 |
| xnox | however it is there... | 01:01 |
| xnox | not sure, but yeah, not architecture specific at all =) | 01:02 |
| sarnold | oh, hrm, did vivid introduce the as-needed linking? https://wiki.debian.org/ToolChain/DSOLinking | 01:02 |
| tsimonq2 | good to know xnox :) | 01:03 |
| sarnold | it -is- good to know xnox :) | 01:03 |
| * xnox blushes | 01:03 | |
| tsimonq2 | could you guys slightly simplify this a little bit or point me in the right direction in finding out how? I'm no expert at this ;) | 01:04 |
| sarnold | tsimonq2: it looks a bit like the hardinfo.h file declares several functions with an 'inline' keyword; they're defined in (well, at least some are in) util.c : http://sources.debian.net/src/hardinfo/0.5.1-1.5/util.c/?hl=149#L149 | 01:07 |
| xnox | which to me is odd. | 01:07 |
| sarnold | tsimonq2: that usually means that either there's going to be an #include "util.c" -- which looks -strange- | 01:07 |
| xnox | usually inline functions are implemented in the header. | 01:07 |
| xnox | alternative to that, is to make that function just a normal, non-inline one. and link things normally. | 01:08 |
| sarnold | tsimonq2: or it means that util.o needs to be mentioned on every gcc line in the log for every file that uses those functions.. | 01:08 |
| sarnold | removing the 'inline' seems like the easiest thing to try | 01:08 |
| sarnold | actually, -would- mentioning util.o on every line actually help? I'm unsure now. | 01:09 |
| tsimonq2 | I'll play with it a bit | 01:12 |
| tsimonq2 | I don't consider myself good at C++ but I think I'm good enough to figure this out with a lot of trial and error :) | 01:12 |
| sarnold | woo :) | 01:14 |
| tsimonq2 | emphasis on /lot/ | 01:14 |
| tsimonq2 | :P | 01:14 |
| tsimonq2 | ok, I think I fixed it | 02:28 |
| sarnold | \o/ | 02:28 |
| tsimonq2 | experienced C++ people will probably scream :P | 02:28 |
| tsimonq2 | but hey, it builds | 02:29 |
| tsimonq2 | and I also need to convert everything into debian patches | 02:29 |
| tsimonq2 | but I'm getting a diff ready so you can tell me how insane I am :P | 02:29 |
| === gaughen_ is now known as gaughen | ||
| tsimonq2 | sarnold: is this correct? http://paste.ubuntu.com/23218477/ | 02:44 |
| tsimonq2 | sarnold: I added a header and all of a sudden it builds | 02:45 |
| tsimonq2 | I have a feeling it might not be the header that's doing that | 02:45 |
| tsimonq2 | it may just be me removing the inline | 02:45 |
| * tsimonq2 tests more | 02:45 | |
| sarnold | tsimonq2: I think it's just removing the inline -- files would have to #include "util.h" in order for the header file to have an influence | 02:47 |
| tsimonq2 | that's correct | 02:47 |
| tsimonq2 | sarnold: so I'm not fully seeing why removing inline does the trick, could you give me a tl;dr so I can convince gilir to upload this for me? :) | 02:48 |
| sarnold | well, "fixes FTBFS" ought to be pretty compelling on its own :) | 02:48 |
| tsimonq2 | (gilir is the development head for Lubuntu, MOTU, if you didn't know ;) ) | 02:48 |
| tsimonq2 | sarnold: well how about if *I* want to know why :P | 02:48 |
| sarnold | tsimonq2: the "inline static" means that the compiler absolutely should not generate a function that is callable by other object files -- it should _only_ be available to the same "compilation unit", and not have a name. | 02:49 |
| sarnold | hm, I thought util.c was "inline static", not just "inline" | 02:49 |
| tsimonq2 | what's the difference? | 02:50 |
| sarnold | I think "inline" alone means "try to inline this but also generate a callable function for it if it is needed" | 02:51 |
| tsimonq2 | then why don't you think it was accessible? | 02:52 |
| sarnold | this has the full details: https://gcc.gnu.org/onlinedocs/gcc/Inline.html -- I forget them about ten minutes after re-reading that, every single time.. | 02:52 |
| tsimonq2 | heh | 02:52 |
| tsimonq2 | sarnold: are you a DD? | 02:52 |
| sarnold | tsimonq2: no | 02:53 |
| * tsimonq2 checks if this failure is also in Debian | 02:53 | |
| tsimonq2 | upstreaming is good, right? ;) | 02:53 |
| sarnold | yes :) | 02:53 |
| tsimonq2 | seems to be ubuntu-specific | 02:55 |
| tsimonq2 | sarnold: thank you for your help, I really appreciate it :) | 02:55 |
| Unit193 | Debian, by default, doesn't use --as-needed. | 02:55 |
| tsimonq2 | sarnold: have a good evening | 02:56 |
| tsimonq2 | Unit193: oh, good to know, thanks | 02:56 |
| sarnold | Unit193: oh? that'd do it.. | 02:56 |
| sarnold | you're welcome tsimonq2, have fun :) | 02:56 |
| Unit193 | sarnold: How aren't you a DD anyway, if you don't mind? | 02:56 |
| sarnold | Unit193: when I wanted to apply back in 2000 or so, the new maintainer process was closed | 02:57 |
| sarnold | Unit193: since then I got lazy | 02:58 |
| Unit193 | sarnold: Even I applied to become a DM. :3 | 02:58 |
| sarnold | :) | 02:58 |
| mwhudson | hey, it's easy now, there's a web form and everything | 02:58 |
| Unit193 | mwhudson: Unless, you have no name and don't exactly live real close to DDs to get sigs. ;) | 02:59 |
| mwhudson | well yes, that's true | 02:59 |
| mwhudson | but you don't have to try to figure out what a jetring changeset is | 02:59 |
| sarnold | i used to see a debian developer at the local coffee shop all the time.. until he had a kid. I don't see him so often any more, hehe :) | 02:59 |
| Unit193 | Haha, nice sarnold. :) | 03:00 |
| mwhudson | i go drinking with a bunch of DDs every six months or so... | 03:00 |
| Unit193 | sarnold: Anyway, thanks for telling me. | 03:00 |
| Unit193 | I've...Only ever met one. | 03:01 |
| tumbleweed | Unit193: come to a debconf then :) | 03:01 |
| sarnold | mwhudson: it's odd to run into coworkers -- who live a few minutes away from me -- only in foreign countries. | 03:01 |
| mwhudson | heh | 03:01 |
| Unit193 | tumbleweed: Yeah, heard you had fun. superfly was telling me a bit. My plan is OLF here. | 03:02 |
| tumbleweed | Unit193: OLF? | 03:03 |
| Unit193 | tumbleweed: Ohio Linux Fest, not Debian or Ubuntu centered. :P | 03:03 |
| tumbleweed | right, I thought you might mean that | 03:03 |
| tumbleweed | the next debconf is in montreal, which isn't *that* far from ohio | 03:03 |
| Unit193 | Considering the last was in SA? Yeah, not too far. | 03:04 |
| tumbleweed | :) | 03:04 |
| * tumbleweed was at pyohio this year, maybe again next year... | 03:04 | |
| Unit193 | ...You live in SA, right? | 03:05 |
| tumbleweed | SF, I'm ex-ZA, though | 03:06 |
| Unit193 | Ah! I met Asheesh, know him? | 03:06 |
| tumbleweed | everybody knows asheesh | 03:06 |
| Unit193 | Still, consider Ohio a bit of a flyover state, so interesting you've gone to a conf here. | 03:08 |
| tumbleweed | CarlFK wanted help with video recording | 03:09 |
| tumbleweed | but generally, small conferences are fun | 03:09 |
| Unit193 | If I make it this year, it'll actually be my first one (with Nathan Handler, pleia2, jose, and maybe a few others.) Anywho, this isn't exactly development related.. | 03:14 |
| tsimonq2 | xnox, sarnold: https://lists.ubuntu.com/archives/lubuntu-devel/2016-September/000824.html | 03:19 |
| tsimonq2 | hmm, what's up with Firefox?!?!???? | 03:37 |
| tsimonq2 | !Info firefox xenial | 03:37 |
| tsimonq2 | !info firefox xenial-updates | 03:37 |
| ubottu | 'xenial-updates' is not a valid distribution: kubuntu-backports, kubuntu-experimental, kubuntu-updates, partner, precise, precise-backports, precise-proposed, stable, testing, trusty, trusty-backports, trusty-proposed, unstable, utopic, utopic-backports, utopic-proposed, vivid, vivid-backports, vivid-proposed, wily, wily-backports, wily-proposed, xenial, xenial-backports, xenial-proposed, yakkety, yakkety-backports, yakkety-proposed | 03:37 |
| tsimonq2 | !info firefox xenial | 03:38 |
| ubottu | firefox (source: firefox): Safe and easy web browser from Mozilla. In component main, is optional. Version 49.0+build4-0ubuntu0.16.04.1 (xenial), package size 45662 kB, installed size 110656 kB | 03:38 |
| tsimonq2 | !info firefox yakkety | 03:38 |
| ubottu | firefox (source: firefox): Safe and easy web browser from Mozilla. In component main, is optional. Version 48.0+build2-0ubuntu1 (yakkety), package size 46753 kB, installed size 110732 kB | 03:38 |
| tsimonq2 | anyone see the problem? | 03:38 |
| tsimonq2 | AND firefox in Yakkety is FTBFS | 03:38 |
| tsimonq2 | who is the person that's usually in charge for firefox? | 03:38 |
| Unit193 | !info firefox yakkety-proposed | 03:39 |
| ubottu | Package firefox does not exist in yakkety-proposed | 03:39 |
| Unit193 | Fancy. | 03:39 |
| tsimonq2 | O__o | 03:40 |
| tsimonq2 | ...so it mograted to release while failing on two arches? | 03:41 |
| tsimonq2 | *migrated | 03:41 |
| tsimonq2 | weird | 03:41 |
| tsimonq2 | also...why upload to xenial but not yakkety?!? | 03:42 |
| Unit193 | Just PPC and system-z where nobody cares. Those are the reasons it gets stuck in devel-proposed though. | 03:42 |
| Unit193 | tsimonq2: In case you didn't remember, beta freeze and ISO rebuilds might have a little to do with it, or just plain time. | 03:43 |
| tsimonq2 | Unit193: but I guess the point I'm trying to make is it's not the fact that it's FTBFS that's the issue, it's the fact that the Xenial version is greater than the Yakkety version | 03:43 |
| tsimonq2 | Unit193: -- Chris Coulson <chris.coulson@canonical.com> Mon, 12 Sep 2016 13:03:01 +0100 | 03:43 |
| tsimonq2 | Unit193: done a week ago | 03:43 |
| tsimonq2 | (more than that) | 03:44 |
| tsimonq2 | Feature Freeze could be a thing | 03:44 |
| * tsimonq2 shrugs | 03:44 | |
| pitti | Good morning | 05:04 |
| === hikiko is now known as hikiko|off | ||
| mardy | seb128: hi! Is everything fine here, or does this hint to some error: https://bileto.ubuntu.com/#/ticket/1497 ? | 07:21 |
| pitti | mardy: I think it's just pointing out https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1&queue_text= | 07:23 |
| pitti | mardy: (we are in beta freeze) | 07:23 |
| mardy | pitti: ok, so no error there, right? | 07:24 |
| pitti | yes | 07:24 |
| === jamespag` is now known as jamespage | ||
| doko | seb128: I uploaded libabw with changed library name. could you rebuild writerperfect and libreoffice? will be offline until Monday | 09:04 |
| seb128 | doko, let me check with Bjoern if he has a libreoffice upload planned | 09:05 |
| seb128 | but yeah, can do | 09:05 |
| seb128 | doko, enjoy your w.e! | 09:05 |
| === vigo is now known as vigo-afk | ||
| seb128 | mardy, sorry forgot to reply earlier but yeah, no error indeed, just beta freeze holding the package in the review queue | 09:29 |
| mardy | seb128: nw, thanks | 09:30 |
| caribou | juliank: I just replied to LP: #1625667; sorry for the serie's mixup I fixed that | 09:43 |
| ubottu | Launchpad bug 1625667 in apt (Ubuntu Trusty) "Trusty: apt does not try next mirror if index file download fails with mirror:// source" [Medium,In progress] https://launchpad.net/bugs/1625667 | 09:43 |
| caribou | juliank: TL;DR : I have a fix for this, just awaiting for MVO to review so I can SRU to trusty | 09:44 |
| caribou | juliank: I was supposed to update the case with the info I sent to mvo but forgot about it | 09:44 |
| juliank | caribou: I would not call mvo the main apt developer anymore, he rarely did anything the past months (since April, mvo!) :D | 09:54 |
| caribou | juliank: well, I had doubts & didn't want to hurt any feelings ;-) | 09:54 |
| caribou | juliank: I only met David once @UDS-R & Michael was the other one I knew f2f | 09:55 |
| caribou | juliank: so you do work on apt these days ? | 09:55 |
| * juliank manages apt releases (series) and maintains the new cmake build system | 09:56 | |
| juliank | And yes, I also fix tiny bugs. | 09:56 |
| juliank | David does most of the large work | 09:56 |
| caribou | juliank: yes, just glanced at the git history | 09:56 |
| caribou | juliank: ok, so this Trusty issue is just a one line fix (details in the bug _now_). Sorry for dropping the ball on the details | 09:57 |
| juliank | Oh, I also handle pull requests of github, and maintain the xenial series | 09:57 |
| juliank | and soon I'll add yakkety (1.3) to my list of stable APT series to maintain... | 09:58 |
| juliank | caribou: That's great, BTW. Did you bisect the fix? I wonder what release fixed that. | 09:59 |
| caribou | juliank: Wily had the fix | 10:00 |
| juliank | Right. | 10:00 |
| caribou | juliank: & I spent a few days reading the code & running gdb sessions to figure out how the Queues, Fetchers & other niceties worked | 10:00 |
| juliank | I'm interested to know if 1.0.9.8 (Debian stable series) was broken too, which happened between vivid and wily :/ | 10:00 |
| juliank | caribou: Whoa. I'd just tried the new one, noticed it works, track back to the oldest Ubuntu release, and run git bisect :D | 10:01 |
| caribou | juliank: well, it all started with discussion with mvo who thought at the beginning that there were no retries on index files | 10:02 |
| juliank | I thought that too, but noticed I was wrong a few weeks ago :D | 10:02 |
| caribou | juliank: so the explanation I sent to mvo are in the bug, so if the fix looks ok to you, I'll handle the SRU | 10:13 |
| juliank | caribou: I think it looks OK. | 10:19 |
| caribou | juliank: ok, I'll SRU this, thanks! | 10:22 |
| tsimonq2 | pitti: hey, ping, you're patch pilot today? | 11:15 |
| pitti | tsimonq2: by the calendar, yes; but not a good day today (beta preparations, archive is frozen, and I'm currently bandwidth deprived) -- will do Monday instead | 11:16 |
| tsimonq2 | pitti: can you at the very minimum tell me if something is *sane*, then upload on Monday? I sent this to gilir (MOTU, Lubuntu dev head) and he responded on FB Messenger that he hasn't really had the time for this sort of thing lately, so he told me to ask a patch pilot. https://lists.ubuntu.com/archives/lubuntu-devel/2016-September/000824.html | 11:18 |
| pitti | tsimonq2: that looks a bit weird at first sight -- if it's a public function it must be in the .h, not the .c; and if it's a private function within util.c, it shuld be declared "static" | 11:26 |
| tsimonq2 | pitti: but there's no .h | 11:27 |
| tsimonq2 | pitti: *I* thought *that* was weird | 11:27 |
| tsimonq2 | pitti: bunch of other files have headers but not this one... | 11:27 |
| pitti | tsimonq2: so how are functions in util.c being used by other files then? | 11:29 |
| tsimonq2 | pitti: that's what I have absolutely no clue about | 11:29 |
| pitti | tsimonq2: anyway, if sarnold and xnox already reviewed it, it's fine (I don't need to second/third-guess them) | 11:29 |
| pitti | but it shoudl at least be forwarded upstream -- this sort of hacky patch isn't something we want to carry downstream forever | 11:30 |
| pitti | (and it's also not a real solution) | 11:30 |
| tsimonq2 | well upstream has a lot of commits and no tags... | 11:30 |
| tsimonq2 | pitti: as I said in the email, doesn't apply to Debian, and eventually, when they tag and Debian packages it (I might just do it myself and then talk to a DD about getting it uploaded) we should be able to drop this when we merge from Debian | 11:32 |
| tsimonq2 | pitti: if not, then I'd say file upstream | 11:32 |
| pitti | tsimonq2: ah, so that's already fixed upstream, just not in our currnet ubuntu version? | 11:32 |
| tsimonq2 | pitti: it should be, I'm making assumptions there, everything got moved around upstream | 11:33 |
| tsimonq2 | pitti: I'll do a little testing later | 11:33 |
| tsimonq2 | pitti: but regardless, this fixes the issue for the time being | 11:34 |
| pitti | tsimonq2: ack; still a really curious patch which I don't really understand :/ | 11:35 |
| tsimonq2 | pitti: < sarnold> this has the full details: https://gcc.gnu.org/onlinedocs/gcc/Inline.html -- I forget them about ten minutes after re-reading that, every single time.. | 11:36 |
| tsimonq2 | :P | 11:36 |
| pitti | heh, indeed -- I just don't see how a public inline function would ever work in a .c file | 11:37 |
| pitti | "static inline" → .c files; public "inline" → .h file | 11:37 |
| xnox | yeah .h should drop inline as well, or difinition be moved into the header file. | 11:38 |
| xnox | i didn't review anything, i just speculated that dropping inline and making the undefined symbol a normal function should do the trick =) | 11:39 |
| pitti | yes, that's what I mean -- the whole definition belongs into the .h, not just the declaration | 11:39 |
| tsimonq2 | pitti: as I told them yesterday, I don't consider myself good at C++, seems logical enough :P | 11:39 |
| pitti | but if there is no .h file which declares that strend() function, how is it ever being used? | 11:39 |
| pitti | implicitly? (eww) | 11:39 |
| xnox | tsimonq2, also this is not C++ =) | 11:39 |
| xnox | pitti, i thought hardinfo.h did | 11:39 |
| tsimonq2 | oh shoot it isn't?!? | 11:40 |
| pitti | ah, then move it to hardinfo.h | 11:40 |
| tsimonq2 | huh | 11:40 |
| pitti | tsimonq2: (plain C) | 11:40 |
| tsimonq2 | hahahahahaha /o\ | 11:40 |
| pitti | or drop the "inline" from both declaratoin and definition, yes | 11:40 |
| pitti | but either way, if it's fixed upstream I'm fine with it | 11:40 |
| tsimonq2 | ok cool | 11:41 |
| tsimonq2 | pitti: thanks for your time :) | 11:42 |
| * tsimonq2 is off to school o/ | 11:42 | |
| ogra_ | bah, why cant file-roller open udebs | 11:50 |
| === _salem is now known as salem_ | ||
| === vigo-afk is now known as vigo | ||
| seb128 | mardy, did you see my comment yesterday about u-c-c/uoa google account view going away when focussing the textentry? | 14:06 |
| pitti | doko: FYI, I fixed the libreadline recommends in postgresql-common more generically and reuploaded | 14:09 |
| pitti | (just in case you wonder why I clobber your upload) | 14:09 |
| rbasak | doko: would you mind taking a look at bug 1609043 please? I'm not sure it's MySQL-specific. Could it be an unintentional ABI break in libstdc++? | 14:13 |
| ubottu | bug 1609043 in mysql-5.7 (Ubuntu) "mysqld: relocation error: mysqld: symbol _ZTVNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference" [High,Confirmed] https://launchpad.net/bugs/1609043 | 14:13 |
| doko | rbasak: will try | 14:14 |
| tyhicks | wgrant: hey - it looks like LP is no longer importing packages from wheezy LTS security updates but I want to sync unadf 0.7.11a-3+deb7u1 from wheezy to yakkety to fix two CVEs | 14:15 |
| tyhicks | wgrant: should I use syncpackage --no-lp in this instance? | 14:16 |
| tyhicks | (the reason I think that LP is no longer importing packages from wheezy LTS is because it still doesn't know about cacti 0.8.8a+dfsg-5+deb7u10 | 14:17 |
| tyhicks | ) | 14:17 |
| xnox | pitti, would you expect this to work? sudo busctl --address=unix:path=/run/systemd/private get-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager SystemState | 14:17 |
| * xnox is trying to find a way to probe /run/systemd/private to see if systemd is listening and replying on it. | 14:18 | |
| pitti | xnox: not really, the internal socket is a bit special; for example, it also doesn't handle property notifications, you need the real dbus for that | 14:19 |
| pitti | the internal one is only being used if dbus is not installed | 14:19 |
| wgrant | tyhicks: Hrm, we import anything from the wheezy suite itself. If Debian's LTS process uses a separate wheezy-lts suite then we've probably never supported that. | 14:20 |
| doko | rbasak: the cxx11 symbols were only introduced with GCC 5, so maybe checked if the new libstdc++ is alreeady unpacked? | 14:21 |
| doko | but afk now | 14:21 |
| pitti | xnox: you can check if "systemctl list-units" works as root (then it will use /run/systemd/private) | 14:22 |
| pitti | xnox: but, why would it not listen to that? | 14:22 |
| tyhicks | wgrant: they're not using a separate wheezy-lts suite so I'm surprised that it isn't working (https://wiki.debian.org/LTS/Using#Using_Debian_Long_Term_Support_.28LTS.29) | 14:22 |
| pitti | xnox: or is-system-running | 14:22 |
| rbasak | doko: could it be a partial upgrade problem? On upgrade from T to X, a build-against-X mysql binary is running without a versioned depdendency on libstdc++? | 14:23 |
| tyhicks | wgrant: 'For Debian 7 "Wheezy" LTS there will be no requirement to add a separate wheezy-lts suite to your sources.list any more.' | 14:23 |
| wgrant | tyhicks: Mysterious. How long has that been published in wheezy? | 14:23 |
| pitti | xnox: run it with DBUS_SYSTEM_BUS_ADDRESS=/nonexisting to make sure it doesn't use the "official" dbus | 14:23 |
| xnox | ack | 14:23 |
| tyhicks | wgrant: unadf has been published for 2 days but cacti was published Sep 1 | 14:23 |
| xnox | pitti, well, it doesn't =) when zhcp devices are present on kernel machines on s390x..... | 14:24 |
| rbasak | doko: BTW, I'm off next week too. | 14:24 |
| wgrant | tyhicks: The Debian importer is having some disk space issues, but I thought we had them mostly under control. Give me a few to investigate. | 14:25 |
| mardy | seb128: yes, it's strange, it should be fixed; I'll try reproducing it on Monday | 14:25 |
| seb128 | mardy, thanks | 14:25 |
| mardy | seb128: maybe not all needed patches have been backported | 14:25 |
| seb128 | Mirv, ^ | 14:25 |
| seb128 | yeah, dunno | 14:26 |
| seb128 | scrolling is fixed | 14:26 |
| seb128 | but now the view gets white on focussing the textentry | 14:26 |
| seb128 | so in practice it's not much better | 14:26 |
| seb128 | still can't enter your login info | 14:26 |
| tyhicks | wgrant: It may not be disk space related beacuse I'm not seeing any wheezy-lts package imports since the LTS team took over security support in late April | 14:30 |
| tyhicks | wgrant: I'm happy to run syncpackage --no-lp, rather than have you sort out the importer issues, but I have never used that option and wanted to get an "ack" from you before doing so after reading the warning in the syncpackage man page | 14:31 |
| cjwatson | tyhicks,wgrant: That's only in wheezy/updates (aka wheezy-security), which I don't think we've ever imported. | 14:32 |
| wgrant | tyhicks: It looks to me like that unadf updateis only in wheezy-security | 14:32 |
| wgrant | Which I don't think we've... that | 14:32 |
| tyhicks | oh | 14:32 |
| wgrant | I've imported post-release suites locally, but we've never had that capability on prod. | 14:33 |
| cjwatson | I think --no-lp would be fine here. | 14:33 |
| tyhicks | wgrant, cjwatson: thanks for getting to the bottom of it - this is good info to know :) | 14:34 |
| * tyhicks will use --no-lp | 14:34 | |
| seb128 | Mirv, mardy, L_aney confirmed it does the same on his install so it's not only virtualbox iso testing | 14:41 |
| === JanC is now known as Guest73904 | ||
| === JanC_ is now known as JanC | ||
| nacc | doko: if you're around, what do i need to do to reproduce the build failures locally? e.g., pacemaker's failure is weird and I'm not seeing how it would only affect non-amd64 archs | 15:27 |
| Laney | nacc: Builds-only-on-amd64 makes me think of an arch-only build problem | 15:34 |
| Laney | try to sbuild with --no-arch-all | 15:34 |
| nacc | Laney: thanks, i'll test that now | 15:37 |
| nacc | Laney: perfect, thank you! | 15:48 |
| Laney | nacc: now the fun part :-) | 15:54 |
| nacc | Laney: yeah :) | 15:56 |
| === bschaefer_ is now known as bschaefer | ||
| nacc | Laney: doko: ah interesting with --no-arch-all on amd64, it also fails, not sure why that's not the case in the archive version, but makes the fix clearer to me | 16:02 |
| Laney | nacc: The problem is the type of build (arch + indep or arch only), not the architecture it's building on | 16:03 |
| nacc | Laney: right, but why would the amd64 not also have been run as a arch only build? | 16:03 |
| Laney | because we have to build the arch:all packages somewhere, and for us it's amd64 | 16:03 |
| nacc | ah! | 16:03 |
| nacc | that's what i was missing :) | 16:04 |
| nacc | i wonder if it would be clearer to do both for the rebuild purposes? that way it's a bit more obvious when there's a generic bug? | 16:04 |
| Laney | if you look at the build log, you can see that different debian/rules targets are called | 16:04 |
| nacc | oh well, i know what to do for now :) | 16:04 |
| nacc | ok, i have a fix, but i'm not sure it's 100% correct, in that two things are changing, 2.7 -> 3.5 and dist -> site. The first seems expected, but not sure if the second is? Maybe because it's a 'local' installation of the python files? | 16:38 |
| nacc | pacemaker_1.1.15-1ubuntu2.dsc | 16:38 |
| nacc | http://paste.ubuntu.com/23220944/ | 16:38 |
| nacc | gah | 16:38 |
| === nacc_ is now known as nacc | ||
| smoser | what would make thsi happen | 17:06 |
| smoser | http://paste.ubuntu.com/23221052/ | 17:06 |
| smoser | 'groups' says the ubuntu user is in the libvirtd group twice | 17:06 |
| smoser | ah. isee 2 lines for libvirtd group in e/tc/group. wonder what did that | 17:06 |
| nacc | libvirtd and libvirt? | 17:06 |
| nacc | weird | 17:07 |
| smoser | ah. by same name | 17:07 |
| smoser | er... gid | 17:07 |
| nacc | yeah, that's ... fun | 17:07 |
| nacc | so a pseudo-bug in groups? :) | 17:07 |
| smoser | i bet it is fallout of either a human or machine dealing with the fact that libvirt group changed from libvirt-bin to libvirtd | 17:08 |
| smoser | er... libvirt to libvirtd | 17:09 |
| smoser | whatever it was | 17:09 |
| nacc | yeah | 17:09 |
| slangasek | seb128: hey, so investigating python slowness on arm/snappy turned up that we were stripping .pyc files out in livecd-rootfs | 18:44 |
| slangasek | seb128: this was originally added for the desktop CD, where it's still being used - does that still make sense there? Are people happy with the performance of python on the live CD? | 18:45 |
| ahoneybun | what is the package name for the Ubuntu Software on Launchpad? | 18:48 |
| sarnold | slangasek: seb128's gone on holidays for a few weeks apparently | 18:48 |
| ahoneybun | I know it's GNOME software but did we fork it or is it upstream? | 18:48 |
| jbicha | ahoneybun: gnome-software is the new xenial era source package | 18:48 |
| ahoneybun | jbicha: https://launchpad.net/gnome-software ? | 18:49 |
| ahoneybun | need to file a bug about Steam not showing in the search | 18:49 |
| jbicha | ubuntu-bug gnome-software | 18:49 |
| ahoneybun | is there a reason the LP bugs are turned off? | 18:50 |
| jbicha | https://bugs.launchpad.net/gnome-software "Bugs are tracked in GNOME bug tracker" | 18:51 |
| ahoneybun | right | 18:51 |
| jbicha | but I think you're thinking of https://bugs.launchpad.net/ubuntu/+source/gnome-software | 18:51 |
| ahoneybun | well I'll just use ubuntu-bug then | 18:51 |
| jbicha | upstream bugs are filed with GNOME directly; Ubuntu ones use the Ubuntu url | 18:52 |
| ahoneybun | mm not sure if it's upstream | 18:53 |
| slangasek | sarnold: if the question sits in his scrollback for a while, that's ok :) | 18:53 |
| ahoneybun | you can install Steam with apt and find it with apt search | 18:53 |
| sarnold | slangasek: ah, good :) | 18:54 |
| ahoneybun | just can't see it in Ubuntu Software | 18:54 |
| jbicha | ahoneybun: thanks; when you use ubuntu-bug it automatically picks up your distro version number and the package version number | 19:10 |
| seb128 | slangasek, we don't have complains about the performances of e.g update-manager or language-selector on desktop afaik so I would keep the hack at least for yakkety, we can look at how much space difference it makes and performances next cycle | 19:56 |
| slangasek | seb128: ok. how should we keep this on the desktop team's radar? it went unnoticed for years, none of the people working on livecd-rootfs probably remembered it was there | 19:58 |
| seb128 | slangasek, open a bug against livecd-rootfs and assign to us | 19:59 |
| === nobuto_ is now known as nobuto | ||
| === salem_ is now known as _salem | ||
| tsimonq2 | so I want to know, is there a good guide for updating symbols? | 23:34 |
| tsimonq2 | when it's ok to remove symbols etc. | 23:34 |
| tsimonq2 | search engines aren't helping :/ | 23:35 |
| tsimonq2 | (for debian/*.symbols files) | 23:35 |
| tumbleweed | removing symbols will cause dynamic linker errors for anything that was using them | 23:35 |
| tumbleweed | so generally if you remove a symbol, you bump the soname | 23:35 |
| tumbleweed | unless you can be sure that it wasn't being used, and you don't have any other ABI incompatibility | 23:36 |
| tsimonq2 | tumbleweed: how do I tell if it's being used? | 23:37 |
| tumbleweed | you look at all the reverse dependencies with readelf / nm | 23:37 |
| tumbleweed | so much fun | 23:37 |
| sarnold | .. and hope there's not significant use of out-of-archive tools | 23:38 |
| tumbleweed | and that there's no dlopen usage | 23:38 |
| tsimonq2 | tumbleweed: you got a manpage and/or an example for using those tools? | 23:38 |
| tumbleweed | they have manpages | 23:38 |
| sarnold | they're not the friendliest, heh | 23:38 |
| tumbleweed | readelf -sw is what I'd use there | 23:38 |
| tumbleweed | err W | 23:39 |
| tumbleweed | not w | 23:39 |
| tsimonq2 | sarnold: you have any better suggestions? ;) | 23:39 |
| tumbleweed | and I wouldn't even think about keeping the soname, unless there were just a couple of reverse-deps | 23:39 |
| tsimonq2 | tumbleweed: does the package have to be native or the source at least unpacked? what preparation do I need for this? | 23:39 |
| tumbleweed | tsimonq2: this is looking at built binaries | 23:40 |
| tsimonq2 | tumbleweed: ah, so *.deb files? | 23:40 |
| tumbleweed | no /usr/bin/foo | 23:40 |
| sarnold | it's odd to recommend _drepper_ for something more friendly... but here we are :) https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf | 23:40 |
| slangasek | or 'objdump -T' | 23:40 |
| slangasek | but also, in general since you can't control what symbols someone outside the archive might be using from that library, best practice is to always change the soname upstream if that symbol was ever exported in a public header | 23:41 |
| slangasek | and if upstream doesn't change the soname, best practice is for the binary package name to change but keep the soname as-is | 23:41 |
| tumbleweed | and if it's C++, accept the fact that every time you touch it the soname will change | 23:42 |
| slangasek | well, not entirely :) | 23:42 |
| tsimonq2 | (I'm working with akonadi in the Kubuntu set, I just thought I'd ask here) | 23:42 |
| tsimonq2 | this is what I'd like to fix: https://launchpad.net/~kubuntu-ci/+archive/ubuntu/unstable/+build/10941905/+files/buildlog_ubuntu-yakkety-amd64.akonadi_4%3A16.04.3+p16.10+git20160922.0751-0_BUILDING.txt.gz | 23:43 |
| tumbleweed | so, removed symbols aren't the only kind of ABI breakage, you also care about backwards-incompatible changes to structs, and C++ classes | 23:43 |
| tsimonq2 | so I basically need to inspect the upstream diff? | 23:44 |
| tsimonq2 | is there any case where a symbol will go MISSING and it's *not* good to remove it? | 23:45 |
| slangasek | what do you mean by "good to remove it"? | 23:45 |
| tsimonq2 | sarnold: well look at that log I pasted | 23:45 |
| tsimonq2 | whoops, I mean slangasek ^ | 23:45 |
| tsimonq2 | slangasek: there's a bunch of symbols there that got the "#MISSING" prefix added to them | 23:46 |
| tsimonq2 | slangasek: when are symbols like that safe to remove and not safe to remove, is what I'm essentially asking | 23:46 |
| slangasek | yes, and we've just explained that you *shouldn't* just remove those from the .symbols file without the soname / package name getting changed | 23:46 |
| tsimonq2 | what if I do bump that? | 23:47 |
| slangasek | for C++, an exception is template symbols | 23:47 |
| slangasek | which are exported but not part of the ABI | 23:47 |
| slangasek | I'm afraid the answer for this is not straigtforward, especially for C++ | 23:47 |
| tsimonq2 | I see | 23:48 |
| tsimonq2 | ok | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!