[01:06] pitti: bug 1533839 trivial debdiff seems to work; assume you're out for the weekend but if you get a moment to review that would be great [01:06] bug 1533839 in libvirt (Ubuntu) "vms shutting down on libvirt upgrade" [Critical,Triaged] https://launchpad.net/bugs/1533839 [01:56] hallyn: nice find [01:59] sarnold: really pitti found it :) [02:00] hallyn: aha :) [02:00] pitti: nice find :) [03:56] Pharaoh_Atem: nothing else sticking out to me yet, but I'll think about it over the weekend [03:57] nacc: okay cool === jincreator is now known as jincreator_ [08:10] https://bugs.launchpad.net/ubuntu/+source/calendar-exchange-provider/+bug/1203433 [08:10] Launchpad bug 1203433 in calendar-exchange-provider (Ubuntu) "Please remove and blacklist calendar-exchange-provider" [Wishlist,Fix released] [08:13] what can I also do, to push on? [10:53] good morning people, can anybody please sync when possible tcl and tk 8.6 in main? [10:53] https://bugs.launchpad.net/ubuntu/+source/tcl8.6/+bug/1417563/comments/10 has the rationale [10:53] Launchpad bug 1417563 in tk8.6 (Ubuntu) "please merge t{cl,tk} 8.{5,6} from debian" [Undecided,Fix released] [10:54] https://bugs.launchpad.net/ubuntu/+source/calendar-exchange-provider/+bug/1203433 [10:54] Launchpad bug 1203433 in calendar-exchange-provider (Ubuntu) "Please remove and blacklist calendar-exchange-provider" [Wishlist,Fix released] [10:54] what can I also do, to push on? [11:01] Mechtilde: it's not about whether it's active upstream or not - there's an archive-wide policy to not include Mozilla extensions because of the lack of time to ensure that extensions still work properly when doing aggressive updates to new versions of Mozilla [11:02] one of my own packages suffers from this too *shrug* [11:05] also it is maintained in Debian? [11:06] can you give me a link to this policy? [11:06] Debian> same answer [11:07] can you give me a link to this policy? [11:07] s/this/that [11:07] just digging it out [11:09] https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel [11:09] (yeah, I know calendar != firefox, I think that's more a badly-named page) [11:10] you can of course talk to the mozilla packaging people if there's a specific problem with this, e.g. Chris Coulson [11:12] but in PPA it is allowed? [11:12] sure [11:27] cjwatson, I sync'd cmtk :) [11:27] mapreri, cherry-picked in debian all the stuff [11:30] LocutusOfBorg: now if you want you can take care of the dcmtk transition in ubuntu (in debian just migrated :P) [11:30] mapreri, guarda che cjwatson ha già fatto cmtk aveva già una ubuntu2 no change rebuild [11:30] erm [11:30] oops, sorry! [11:31] ELANGUAGE [11:31] I mean, cmtk had already an ubuntu2 no change rebuild from cjwatson, so I presume he already took care of the transition [11:31] * LocutusOfBorg is sorry for the confusion [11:33] LocutusOfBorg: yeah, I read the changelog :P btw, no the transition is stalled in ubuntu atm, dcmtk is stuck in proposed due to old binaries [11:33] also, ubuntu doesn't seem to have something like the auto-transitioner, so there is no transition tracker, uh === vrruiz_ is now known as rvr [11:55] cjwatson, https://launchpadlibrarian.net/232931972/buildlog_ubuntu-xenial-arm64.grub2_2.02~beta2-33_BUILDING.txt.gz [11:55] isn't this a problem because of virtualizated builders? [11:56] also dcmtk, is missing build on arm64, (I retried the build) [12:00] mapreri, there are, but they need to be manually setup (or copied from debian) [12:02] mapreri, i.e if you want one, just ask (not me though, I don't have access) [12:05] https://code.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/ben [12:07] maybe that branch is old though [12:32] darkxst: yeah, I know that branch, but I was talking about a thing that generetes ben packages automatically, as it's done in debian. anyway, I'm already busy enough without taking care of ubuntu's transitions atm... [12:51] dcmtk is built on arm64 === jincreator is now known as jincreator_ [16:18] Hello, where can I find the linux_4.3.0.orig.tar.gz file ? I can find linux_4.2.0.orig.tar.gz but not 4.3.0 . Thanks. [16:32] NikTh: looking at https://launchpad.net/ubuntu/+source/linux/4.3.0-5.16, I'm not sure why there isn't an orig there, but that is the source I believe. I don't know if linux is somehow special in a way that I'm not aware, or if it's just a native package (which would be odd). [16:43] rbasak: I'm not sure either. If I download linux_4.3.0-5.16.tar.gz and rename it, will it work ? I want to avoid uploading the whole source every time I build a new package (in Launchpad). It worked before, but I need the orig.tar.gz file. [18:12] NikTh: Tim tends to operate without an orig until just before a stable release, but if you want one for a PPA, just use Linus's. [18:13] https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.3.tar.gz [18:15] infinity: I think this will be rejected from Launchpad. Because it's not exist (in Launchpad). Also "debuild" wants a specific form (orig.tar.gz ...etc) in order to work. Am I correct ? Will rename it work ? [18:16] NikTh: LP doesn't enforce consistency between PPAs and the archive. [18:16] NikTh: And yes, the name needs to be correct. linux_4.3.0.orig.tar.gz [18:17] infinity: OK, thanks for the info. I will try. :-) [18:17] NikTh: Basically, unpack Tim's native source, plunk new orig in parent dir, run debuild -S, voila, you should have an orig/diff/dsc setup now. [18:18] There will be a lot of noise if you debdiff old and new (files in the orig that can't be deleted by that source format), but that's expected. It'll still build fine. [18:18] infinity: Yes I have done this before but it only worked with orig.tar.gz in parent dir and orig.tar.gz downloaded from Launchpad. [18:19] NikTh: The orig.tar.gz used by the kernel team (when they use one) *is* Linus's tar.gz renamed, it should work fine. ;) [18:20] infinity: I didn't know this info. Thanks again. :-) [18:20] NikTh: Oh, and on your first upload to the PPA with the new orig, you'll need "debuild -S -sa" to include the orig in .changes [18:20] NikTh: Since you need to upload the orig once. :P [18:21] infinity: Yes, actually the command I'm running is " debuild -S -sa -I.git -I.gitignore...blah..blah :) [18:22] Then, and after I upload the orig.tar.gz, the same command but with -sd at the end. [18:38] infinity: Yes ! It seems it's working correctly. Just a simple rename :-) From dput: "Uploading linux_4.4.0.orig.tar.gz" [18:38] infinity: Thank you :) [18:40] Why's everyone so eager for 4.3? [18:41] infinity: After I upload this orig.tar.gz I will try without it and see if I reach my goal. I cannot think why could fail, but until uploading only the diff.gz .changes...etc , I cannot be 100% sure. [18:43] Unit193: I'm not. Actually skipped this version completely. I'm testing 4.4 right now and using 4.1.15 LTS for production :) [18:48] does someone have any docs about fixing FTBFS like "undefined reference to" ? [19:11] ari-tczew: Wha [19:11] What's there to document? Some library must be missing [19:11] Figure out which and add it to LDFLAGS [19:12] (Assuming C/C++ and friends) [19:13] juliank: see buildlog: http://paste.ubuntu.com/14531712/ [19:14] I just added -lacl to the +libgnu_a_LIBADD = $(gl_LIBOBJS) -lacl [19:14] but seems to be not working [19:14] I think that only works for static libraries [19:15] That is, you need to add an LDADD target to the rrep target or something [19:15] No wait, it's there [19:15] juliank: could you take a look on https://sources.debian.net/src/rrep/1.3.6-1/ ? [19:15] I did not know a static library was involved in it. [19:16] juliank: your feedback/help would be really appreciated [19:17] With autotools and static libraries involved, that's harder than I thought [19:18] But if you're using libtool, I think "libgnu_a_LIBADD" should be "libgnu_la_LIBADD" [19:19] with the extra l between _ and a [19:20] juliank: I don't know, I just based on the source [19:20] Ah OK, no libtool [19:20] maybe that line I choose might be wrong? [19:21] Nah [19:21] LocutusOfBorg: no, the grub2/arm64 problem has nothing whatsoever to do with virtualised builders. Please don't blame virt builders for everything! [19:21] ari-tczew: Did you also add it to libgnu_a_DEPENDENCIES? [19:21] LocutusOfBorg: I've already passed it upstream [19:21] thanks :) [19:22] it is trivial to blame the virtualization :D [19:22] juliank: no, I didn't. should do I? If so, should -lacl be the first or the last? [19:22] LocutusOfBorg: No wonder you thought virt builders were to blame for lots of problems if you're blaming everything on virt. :-P [19:22] ari-tczew: All the other libraries are there too [19:22] Example being "libgnu_a_LIBADD += @ALLOCA@" "libgnu_a_DEPENDENCIES += @ALLOCA@" [19:23] Not sure if that changes anything, but it seems to be the more correct thing to do [19:24] ari-tczew: But AFAICT it should already be in LDADD: [19:24] "LDADD = $(LIB_ACL) $(LIBICONV) $(LIBINTL) ../lib/libgnu.a" [19:24] I'd just move the libgnu.a to the front of it [19:24] LocutusOfBorg: synced tcl8.6 and tk8.6 for you [19:24] That's in src/Makefile.am [19:25] juliank: OK, I'll try it without my first own change [19:37] juliank: pbuilder seems to be happy with change suggested by you. thanks!!!! [19:37] I'll build it now on PPA. [19:53] ari-tczew: Yeah, it's a matter of specifying the -l options *after* the objects needing them (here: the libgnu.a) [19:59] juliank: It's odd, that the same package in Debian builds fine there, though. [19:59] Different linker settings. [19:59] Maybe bsymbolic-functions, I don't know [20:02] --as-needed, I expect [20:04] (which isn't on by default in Debian, but is in Ubuntu since natty) [20:05] https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition [20:05] juliank: Also, there is no _missing_ library. The another just should be moved. (conclusion) [20:08] cjwatson: Yeah, makes sense [20:11] * cjwatson pokes Leif about grub2/arm64 to see if he got anywhere with relocation improvements [23:25] cjwatson, vlc daily builds fail: https://launchpad.net/~videolan/+archive/ubuntu/stable-daily/+build/8859183 [23:25] cjwatson, configure: error: "You cannot build VLC with Qt-5.5.0. You need to backport I78ef29975181ee22429c9bd4b11d96d9e68b7a9c" [23:25] cjwatson, can you backport that fix to xenial's qt version?