[00:57] jbicha: It'd be rather nice if you didn't sync packages that are seeded in other flavors. xfce4-power-manager has a regression in .6, we were specifically avoiding sync'ing it since it's in our (Xubuntu) and Ubuntu Studio's packagsets.. [00:57] Specifically when past feature freeze* [00:59] ^ Ditto. While I do welcome the MyPaint sync, the xfce4-power-manager sync is not good if it's going to mess us up. [01:00] Eickmeyer: There should be a new release soon, we'll fix it. In the meantime I think it was suspend that's a bit off. [01:02] Unit193: I haven't looked at it, but that's good to know. [01:03] With regards to interaction with xfce4-screensaver, suspend/lock interaction. [01:03] Oh, yeah. Not good if it's regressing that. [01:04] Like I said, there should be a new release soon™ [01:05] Hehe [01:51] Eickmeyer only had to wait two years for a new release! [01:52] valorie: Seriously! :D === cpaelzer__ is now known as cpaelzer [10:17] Unit193: sorry about the headache :/ [10:44] jbicha: With the screensaver and -session just uploaded (or uploaded soon), it wasn't broken for too long at least. :) [11:20] hum, sbuild is very slow here.. the actual compile part is quick but everything else is very slow.. what could cause that? [11:25] apache build takes 10min instead of 3 [11:25] as an example [11:30] To speed up unpack/configure of packages, I have pbuilder use eatmydata. [11:31] I mean everything is slow, like setting the chroot up, listing contents of the built packages etc.. [11:32] it's not I/O bound, there's no process eating time or anything.. [11:33] installing build-deps is quick [12:31] doko, Somohow I am not understanding what is happening with Ghostscript on ppl64el. Is there some new bug, not the -O3 of gcc? [12:32] doko, is there any evidence that 9.52 would build? [12:33] tkamppeter: I told you that the GCC issues had to be reverted, and ghostscript needs to be built with -O2 for now [12:35] doko, sorry, this I had perhaps overlooked. So I will re-introduce it as quick as possible. [12:36] doko, what happened, did the upstream fix cause a regression and upstream has pulled it back? [12:48] tkamppeter: yes [12:50] doko, so we should re-open bug 1862053 as there is no solution in sight yet. [12:50] bug 1862053 in gcc "Compiler gets stuck (or extremely slow) on ppc64el" [Medium,Confirmed] https://launchpad.net/bugs/1862053 [12:59] doko, I will put the exception back in and to avoid flip-flopping all the time around with it I will keep it until shortly before 20.10. === platonical_ is now known as platonical === tai271828__ is now known as tai271828_ === Zic is now known as Guest29138 [13:59] tjaalton: hi, have you checked if we need this in ubuntu? https://salsa.debian.org/apache-team/apache2/-/merge_requests/11/diffs [13:59] ahasenack: hehe :) [13:59] ahasenack: that'd allow freeipa to support tls1.3, it's currently forced to use 1.2 [14:01] presumably other clients could benefit? [14:01] maybe [14:03] poked yadd about it [14:16] juliank hi, just checking if you had a chance to review https://salsa.debian.org/apt-team/python-apt/-/merge_requests/43 [14:18] ahasenack: note that I'll sync freeipa back in a bit.. so that MR would be nice though not essential [14:26] ddstreet: not yet [14:27] juliank ack, maybe after focal release? [14:27] probably [14:27] thanks [14:29] doko, ghostscript uploaded, please remove the ppc64el exception only if upstream fixes the problem in a way which actually stays. === mitya57_ is now known as mitya57 [15:22] ahasenack: [15:22] execd_commands.c: In function ‘stonith_recurring_op_helper’: [15:22] execd_commands.c:257:5: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] [15:22] I'll fix this in the merge I'm preparing to address public bugs [15:22] (pacemaker FTBFS) [15:23] rafaeldtinoco: that s the ftbfs? [15:23] looks like we have new compiler warnings =) [15:23] ahasenack: yep [15:23] I'll add the Wno-error for it [15:23] let me open a bug [15:23] that's not a "fix" :) [15:23] but if there is no alternative, nothing from upstream... [15:24] ahasenack: oh well, for this release its a "fix" as ftime will continue being deprecated but not yet removed [15:24] further releases will have to make sure to remove ftime, but likely upstream will take care of it [15:25] NOTE: This function is deprecated, and will be removed in a future version of the GNU C library. Use clock_gettime(2) instead. [15:25] man page already mentions that =o) [15:26] i guess I can suggest upstream a fix as well [15:26] ghostscript (9.50~dfsg-5ubuntu4) focal; urgency=medium [15:26] ... [15:26] -- Till Kamppeter Mon, 30 Feb 2020 15:50:58 +0200 [15:27] git-ubuntu is unable to parse that date :-/ [15:27] feb had no 30th [15:27] Indeed :) [15:27] was that added manually? [15:27] tkamppeter: ^ :) [15:28] I don't know, but I guess if Launchpad accepts it, git-ubuntu will have to accept it [15:28] I need to specify what that should map to, I suppose. [15:28] ROFL [15:28] 30 Feb [15:29] thats the sextile year [15:29] in flat earth [15:29] ok ok i'll shut up [15:29] even the changes file has it [15:29] http://launchpadlibrarian.net/471742374/ghostscript_9.50~dfsg-5ubuntu4_source.changes [15:30] I mean, ingested it [15:30] that's also a bug in the tooling that builds the package [15:31] unless the thought is that the tooling can be behind legislation, tz data, etc, and failing hard on what looks like an invalid date could be too harsh [15:32] Nothing much (if anything?) in the build machinery needs to parse that date really. [15:32] git-ubuntu is trying to convert it into a git commit authorship timestamp - that's why it's parsing it. [15:32] Perhaps I should just define it to use the epoch if it doesn't parse. [15:32] rbasak: try {} except { pass } ? [15:33] :o) [15:33] I have to set it to _something_ :) [15:37] There is some debate here as to whether 30 Feb was a Saturday or a Sunday. We agree though that it certainly wasn't a Monday! === M_hc is now known as _hc [15:44] ahasenack: git-ubuntu is trying to import linux-kvm and linux-gcp. Had you already investigated those? [15:44] Ah yes, you did, sorry. [15:44] My manual meddling bypassed the whitelist. [16:10] hi - if I were to download the daily image of 20.04 now [16:11] when 20.04 stable came out would I stick to the 20.04 branch or as i would be running the development branch would I then startr using 20.10 branch ? [16:12] I believe when the beta for 20.04 that would stick to the 20.04 branch - just not sure if the same thing happens using the daily image ?> [16:40] rbasak: oops :) [16:40] yossarianuk: you would be running 20.04 final [16:41] yossarianuk: the sources.list entries are already pointing at the focal pockets [16:41] yossarianuk: I believe there is one difference though, please check if focal-proposed is enabled in those images. You might want to disable that [16:54] ahasenack: thanks ! [17:09] rbasak: I suspect LP simply doesn't parse that field at all [17:11] Yeah, it looks like it extracts it but only as unparsed text [17:16] Thanks [19:22] Hello everyone, is PPA upload working for you ? [19:32] arunpyasi: seems fine [19:32] RikMills, thats weird. Let me try to upload another package then. [19:33] Though, it said Successfully uploaded packages. I didn't receive any email and there is no package upload stuff going on the Launchpad [19:48] arunpyasi: you did sign them properly? otherwise, ask in #launchpad [19:49] Lack of notification is usually some problem with the signature [19:49] RikMills, yes, else an email should have come I think. [19:49] No that is absolutely not true [19:49] cjwatson, oh ok. [19:49] e.g. lack of signature is one of the main reasons that a notification is specifically and deliberately *not* sent [19:50] (in order that people don't get non-consensually spammed with confusing error messages about things they didn't do) [19:50] cjwatson, Oh ok. Thanks for the information. Let me check. [19:50] Come to #launchpad and give us details of the attempted upload [20:01] 'sudo hwclock -s' is broken in focal :/ [20:02] glibc 2.31 perhaps