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