| === zyga_ is now known as zyga | ||
| === maclin1 is now known as maclin | ||
| ginggs | tsimonq2, mapreri: i guess i can sync healpy now (since the healpix-cxx upload) ? | 08:36 |
|---|---|---|
| mapreri | why isn't that detected by dpkg-shlibs? | 08:37 |
| mapreri | anyhow yes, you can | 08:37 |
| ginggs | mapreri: ack | 08:37 |
| === CRogers_________ is now known as CRogers | ||
| arune | rbasak, regarding bug #1641203 I have now patched the sources for Xenial-packages and got it working fine, however, it seems I'm not skilled enough to create debdiffs | 09:36 |
| ubottu | bug 1641203 in sssd (Ubuntu Xenial) "SSSD can't process GPO from Active Directory when it contains lines with no equal sign" [Medium,Triaged] https://launchpad.net/bugs/1641203 | 09:36 |
| Unit193 | ginggs: Hi! So looked into telegram before I noticed the bug. Telegram sets a Qt env var in one of the patches, I'd try taking that out and rebuilding to see if you still get the issue in question. | 09:37 |
| === maclin1 is now known as maclin | ||
| ginggs | Unit193: looking now, thanks | 10:15 |
| ginggs | Unit193: removing the Qt env var has no effect on my system, but that patch would be a good place to set QT_QPA_PLATFORMTHEME | 10:21 |
| Unit193 | ginggs: Removing it from the patch and recompiling didn't? Huh, OK..Well then. | 10:23 |
| Unit193 | (Setting env vars inside the application isn't ideal, but forcing the default of not setting them is maybe worse...) | 10:25 |
| rbasak | arune: you can use the debdiff command against the old and new dsc files | 10:45 |
| tjaalton | arune, rbasak: there will be a 1.13.5 after 1.15.3 | 10:50 |
| tjaalton | with that fix | 10:50 |
| === morphis_ is now known as morphis | ||
| arune | rbasak, where does the new dsc come from? I did dch -n and added a changelog entry according to https://wiki.debian.org/BuildingTutorial but now I'm lost again | 11:59 |
| rbasak | arune: build the new source package from the new source tree. "dpkg-buildpackage -us -uc -nc -d -S" is what I use, but that only works if the source tree is clean. | 12:00 |
| rbasak | You'll get a .dsc in the parent directory. | 12:00 |
| mapreri | Laney: is there a reason to not sync src:phonon ? | 12:09 |
| mapreri | (you're the last person who touched it) | 12:09 |
| LocutusOfBorg | I guess it wasn't updated at that time | 12:10 |
| LocutusOfBorg | (in Debian I mean) | 12:11 |
| mapreri | possibly, but I can't understand why we kept a -0ubuntuX version even after Debian long updated it | 12:11 |
| LocutusOfBorg | a diff between the ubuntu3 and the corresponding -2 debian version shows something worrysome (e.g includes have changed) | 12:16 |
| mapreri | yeah, I was noticing that | 12:16 |
| mapreri | although there is a -DPHONON_INSTALL_QT_COMPAT_HEADERS=ON thing in d/rules.. what's that | 12:17 |
| LocutusOfBorg | I would say sync, and in case some rdep breaks, test them in advance maybe :) | 12:17 |
| LocutusOfBorg | maybe put them into a ppa | 12:17 |
| mapreri | https://packages.debian.org/sid/amd64/libphonon-dev/filelist shows both versions | 12:17 |
| mapreri | s/versions/paths/ | 12:18 |
| LocutusOfBorg | true | 12:18 |
| mapreri | lrwxrwxrwx root/root 0 2016-07-31 14:34 ./usr/include/qt4/phonon -> ../phonon | 12:18 |
| LocutusOfBorg | would be nice to sync and break the whole kde stuff, better ask and leave it to him :p | 12:18 |
| mapreri | (+ that, which means a total of 3 different working paths) | 12:18 |
| mapreri | .oO who uses KDE anyway! | 12:19 |
| Laney | mapreri: Dunno. Feel free to use your judgement. | 12:20 |
| mapreri | ack | 12:20 |
| * LocutusOfBorg would sync it | 12:20 | |
| mapreri | I've got a week without any real commitment apart from studying for an exam, guess I am available enough to fix up stuff | 12:20 |
| Laney | My changelog implies that I didn't want to figure out the delta. :) | 12:21 |
| Laney | so if you do, go wild | 12:21 |
| LocutusOfBorg | a good reason for not touching at that time was probably xenial freeze schedule | 12:21 |
| mapreri | Sync this package [y|N]? y | 12:22 |
| Laney | aren't new releases fun? | 12:24 |
| mapreri | ^^ | 12:25 |
| xnox | ogra_, is src:ubuntu-core-meta .... Ubuntu Core aka snappy, or something touch related? | 12:43 |
| xnox | ogra_, or is that like snappy v1? | 12:44 |
| ogra_ | xnox, thats snappy but there needs to be a merge ... | 12:47 |
| ogra_ | xnox, we have an additional src package in the PPA (since you cant do seed changes to released versions) | 12:47 |
| ogra_ | xnox, https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial | 12:48 |
| ogra_ | xnox, though thats not super relevant since these bits are used for the core snap ... we wont need/use them from the archive before 18.04 (core is only built from 16.04) | 12:49 |
| ogra_ | so there is no hurry | 12:49 |
| xnox | ogra_, what do you mean a merge? do you mean you uploaded things into PPA without comitting things to lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu-core.$devel ?! | 12:49 |
| xnox | ogra_, well, i am making an upload off ubuntu-core.artful now into artful. | 12:49 |
| ogra_ | xnox, yes, we have to | 12:49 |
| xnox | ogra_, "have to" or did, when uploading into the PPA? =) i mean not the update to the .xenial branch, but update to .yakkety/.zesty/.artful? | 12:50 |
| ogra_ | i dont care about anything newer than xenial ... (and there mostly about that PPA) | 12:50 |
| xnox | cause in the .artful branch I have no changes since yakkety. | 12:50 |
| xnox | ogra_, you must commit seed changes to the branch, even if you don't care about it, because we will branch that for 18.04. | 12:50 |
| ogra_ | nobody cared for xenial+n ... | 12:50 |
| ogra_ | simply because thats moot | 12:50 |
| xnox | ogra_, but everyone will care about 18.04..... | 12:51 |
| xnox | it's not moot. | 12:51 |
| xnox | you could have been generating packages for your ppa, using the bzr branch of .yakkety/.zesty/.artful such that your 18.04 will be correct. | 12:51 |
| ogra_ | we dont even build core from the opfficial livecd-rootfs anymore so it is moot until we start 18.04 | 12:51 |
| xnox | i know. | 12:51 |
| xnox | but i care about one less delta, rather than "oh not that we have 1 delta, let's have gazzilion deltas and not care about any of them." =) | 12:52 |
| ogra_ | thats nice for book-keeping but nothing more, the binary debs of that serve no purtpose in these releases | 12:52 |
| xnox | ogra_, i care about keeping the branches up to date, not the binaries in the archives. | 12:52 |
| xnox | ogra_, where is your ubuntu-seeds/germinate branch fro what's in the ppa? | 12:52 |
| xnox | you did build things into the ppa with ./update script based on a seed right? | 12:52 |
| xnox | i'll merge it into .artful branch | 12:53 |
| ogra_ | right, but the branches need changing plus we need merges of ubuntu-core-meta from the PPA and from the archive | 12:53 |
| ogra_ | the authoritative seed is in the PPA package | 12:53 |
| xnox | ogra_, you have been uploading meta packages with by-hand tweaks?! what do you mean merge from PPA/archive? | 12:53 |
| ogra_ | thats the only way to upload them to a released series | 12:53 |
| xnox | dude, you should not do that. start a bzr branch for the ppa, of the seed, and update the ./update.cfg in the PPA package to point to that, and use ./update scripts to maintain the package..... | 12:54 |
| xnox | ogra_, no, it isn't. | 12:54 |
| ogra_ | you cant re-create them from seeds, seed changes to xenial are ignored | 12:54 |
| cjwatson | that's only true for tasks, not for metapackages | 12:54 |
| xnox | when one runs things locally, the seeds are read from the bzr branch, rather than the exported website. | 12:54 |
| cjwatson | the distinction between the bzr branch and the exported website is mostly not relevant here. the exported website is updated every five minutes (including for xenial etc.). | 12:55 |
| cjwatson | I think ogra_ must be thinking of tasks. | 12:55 |
| ogra_ | yes, indeed | 12:56 |
| xnox | ogra_, core build stuff uses metapackages right, not the tasks? (given that ppas don't publish tasks, as far as I understand / do not have override support). | 12:56 |
| xnox | hence we should be able to migrate ppa build to be based on the bzr branch. | 12:56 |
| ogra_ | we use deboostrap --minbase and then install the ubuntu-core task on top | 12:56 |
| xnox | s/the/a/ | 12:57 |
| ogra_ | (and then run a gazillion hooks to mangle the result) | 12:57 |
| xnox | right, but that installs the metapackage, and your ppa updates get installed, because the new metapackage is up to date? there is no updates to tasks in the ppa | 12:57 |
| ogra_ | we'll most likely completely switch away from this soon ... to a set of stacked tarballs based on to of ubuntu-base | 12:57 |
| ogra_ | (which means no more tasks or metapackages at all ... ) | 12:58 |
| xnox | and it seems like doko has been uploading into the archive without updating ubuntu-seeds branch either. | 12:59 |
| LocutusOfBorg | tjaalton, https://launchpad.net/ubuntu/+source/libepoxy/1.3.1-2ubuntu1 | 14:12 |
| LocutusOfBorg | I also opened a pull request with that patch: https://github.com/anholt/libepoxy/pull/118/files | 14:12 |
| LocutusOfBorg | seems upstream forgot some checks when fixing that issue | 14:13 |
| LocutusOfBorg | (they don't hurt, so I prefer the "better safe than sorry" approach) | 14:13 |
| tjaalton | LocutusOfBorg: cool, thx | 14:17 |
| LocutusOfBorg | tjaalton, just to be clear, I don't know how to test that particular corner case | 14:18 |
| LocutusOfBorg | so I hope everything is fine | 14:18 |
| LocutusOfBorg | double testing is appreciated | 14:18 |
| tjaalton | autopkgtests will show ;) | 14:19 |
| LocutusOfBorg | lovely autopkgtests! | 14:20 |
| === JanC is now known as Guest16266 | ||
| === JanC_ is now known as JanC | ||
| juliank | mvo: various people and slangasek voiced concern about our apt timer in bug 1615482, it happening at random times. I plan to limit that to around 6am again: https://github.com/julian-klode/apt/commit/93a513c4953bab9b0569c9e2bc2c74075a50dc00 - any objections? | 16:08 |
| ubottu | bug 1615482 in apt (Ubuntu) "apt-daily timer runs at random hours of the day" [High,Triaged] https://launchpad.net/bugs/1615482 | 16:08 |
| juliank | This chooses 6:00 + up to 30 mins, an alternative is 5:30 + up to 1 hour (aka 6 +/- 30) | 16:08 |
| juliank | You picked the original 2 times I think, not sure what your reason was for that | 16:09 |
| mvo | juliank: please check with slangasek if there is no concern about hitting the mirror all at once in a too tiny time-window, I don't mind that | 16:09 |
| juliank | mvo: OK, just thought you had a special reason for going twice a day with huge randomization | 16:10 |
| mvo | juliank: unfortunately I need to run right now, we can talk either late today or tomorow morning. but its fine with me as long as the load is reasonable spread | 16:10 |
| mvo | juliank: the reason was to ease the load on mirrors | 16:11 |
| juliank | That was sarnold's concern too | 16:11 |
| mvo | juliank: but if the randomness is a bigger concern than the load on mirrors, then it needs to change :) | 16:11 |
| juliank | Yep | 16:11 |
| mvo | juliank: I don't mind either way, back when I did it the priority was ease on mirrors | 16:12 |
| * mvo really needs to run | 16:12 | |
| juliank | run, mvo, run! | 16:12 |
| slangasek | xnox: ah, fresh apt discussion :) ^^ | 16:31 |
| xnox | juliank, i'm pretty sure we want it between 6..7am in the machine's timezone whatever it may be. | 16:35 |
| xnox | we will have a 6..7 UTC time spike, because people don't set timezones, but so be it. | 16:35 |
| xnox | juliank, and i'm pretty sure we want it at 6:30 +/- :30 | 16:35 |
| juliank | xnox: 6 to 7 is fine with me (that's 6:00 with 1 hour randomized delay) | 16:35 |
| xnox | which in systemd.timer speak is 6:00 Randomized delay 1h | 16:35 |
| xnox | juliank, that. | 16:35 |
| xnox | juliank, and we will be picking that up as an SRU. | 16:35 |
| juliank | xnox: I already queued that in my head with the other change for the next SRU(s) | 16:36 |
| xnox | juliank, hm. that might not be quick enough for our customer.... | 16:37 |
| juliank | Yep, SRUs | 16:37 |
| xnox | i think we (I) will need to crank this out, just by itself. | 16:37 |
| xnox | and then we can go back to the regularly scheduled programming =) | 16:37 |
| juliank | xnox: There are already SRUs in -proposed, mostly waiting on those. | 16:38 |
| juliank | They are all verified now, and a month old, so good to go | 16:38 |
| juliank | xnox: I can prepare releases within the next ~ 12 hours or so, that's not a problem. And the other issue for yakkety is also important (and xenial only really has https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=5094697fe4b2459ff6f706a22006d3028369f3fa, a one line change, in addition) | 16:40 |
| xnox | juliank, i can ping about that. | 16:40 |
| xnox | juliank, hehe, yes =) nice one. | 16:40 |
| juliank | If we agree on 6 + 1, I'll upload 1.4.1 to Debian today, sync that, and upload 1.4.1~17.04 to zesty (1.4 being the zesty/stretch series, basically), and 1.3.6 to yakkety and 1.2.21 to xenial tomorrow. No big deal. | 16:42 |
| juliank | tomorrow if the current SRUs go through today, obviously | 16:42 |
| xnox | juliank, yes, 6am + 1h in the systems' / machine timezone. | 16:42 |
| juliank | Well, that's what systemd does, right? | 16:43 |
| xnox | juliank, by default yes. But one can also specify timezones e.g. UTC, but we do _not_ want that. we want no timezone specified aka machine timezone | 16:51 |
| juliank | Complete diff for 1.4.1: https://github.com/julian-klode/apt/compare/1.4...master | 16:52 |
| * sarnold groans at xnox for "regularly scheduled programming" | 16:59 | |
| xnox | juliank, +1 | 17:02 |
| juliank | xnox: Now go and bug people about the SRUs stuck in -proposed, and we can roll out new SRUs tomorrow :D | 17:03 |
| xnox | juliank, yeah. as soon as we upgrade critical piece of infra which runs britney et.al. because we started upgrading it, unexpectedly. (scheduled to upgrade it for wednesday, started to upgrade it by accident) | 17:04 |
| xnox | and that went south, obviously. | 17:04 |
| juliank | Ooops... | 17:04 |
| juliank | xnox: You made it sound so extremely urgent :D | 17:05 |
| xnox | juliank, well =) it is, and it is nice that you agree on the expected timing for things. Cause having upstream backing is nice. | 17:06 |
| xnox | juliank, i'm pretty sure, someone will be angry tomorrow asking when this will land, expecting me to reply it was all fixed last week. | 17:07 |
| xnox | asking me that is =) | 17:07 |
| juliank | xnox: No problem. I would have fixed it last week already, but there was no time consensus back then, and mvo was already gone | 17:08 |
| xnox | juliank, yeah, and mvo is having slightly different consensus then the foundations team =) | 17:09 |
| juliank | xnox: Well, my only question was that there was a special reason why he picked both 6 and 18:00. | 17:09 |
| juliank | s/that/if there/ | 17:09 |
| xnox | slangasek, juliank, but given that this used to be triggered via anachron too. (in case machine is off during 6am..7am window) should we not specify that this is Persistent=yes too. | 17:10 |
| xnox | Persistent= | 17:10 |
| xnox | Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer is activated, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive. This is useful to catch up on missed runs of the service when the machine was off. Note that this setting only has an effect on timers configured with OnCalendar=. Defaults to false. | 17:10 |
| juliank | xnox: It is | 17:10 |
| xnox | cool! | 17:10 |
| xnox | perfect =) | 17:10 |
| xnox | nothing else i can think off. | 17:10 |
| juliank | xnox: It did not used to work at boot because it mostly ran before network, but as you can see in the diff, I added the network-online dep | 17:11 |
| xnox | yeap. | 17:11 |
| juliank | I still think it does not work with resume, as network-online just stays active when suspending, but it's some progress | 17:11 |
| xnox | yeah, i would expect network-online.target to for-example restart on resume, such that things can bindto network-online.target and get retriggered on resume. | 17:12 |
| juliank | That would be optimal, yes | 17:12 |
| xnox | i think i need to talk to upstream about that. | 17:12 |
| xnox | juliank, but i thought my recommendation there was that .service unit should fail; and have a retry argument with a delay | 17:13 |
| juliank | Ah yeah, retry with backoff for failing timer services would be great | 17:14 |
| xnox | RestartSec=1min | 17:14 |
| xnox | Restart=on-failure | 17:15 |
| xnox | and i think we need to limit that too | 17:15 |
| juliank | So, 1.4.1 is on the Debian infra now, should hit the dinstall there in 2 hours 40 mins | 17:15 |
| juliank | xnox: Let's think about that carefully for May :D | 17:15 |
| xnox | yes | 17:15 |
| xnox | ah "Note that service restart is subject to unit start rate limiting configured with StartLimitIntervalSec= and StartLimitBurst=, see systemd.unit(5) for details. | 17:16 |
| xnox | " | 17:16 |
| juliank | xnox: RestartSec is suboptimal, it really should be doing exponential backoff | 17:16 |
| juliank | And of course, if you run upgrades and they fail, do you even want to retry? | 17:17 |
| xnox | "Note that units which are configured for Restart= and which reach the start limit are not attempted to be restarted anymore;" | 17:17 |
| xnox | well, i only want to re-run apt update step =/ maybe we need to inject special exit codes for apt update failed, and only restart on those exit codes. | 17:18 |
| infinity | xnox: | 17:54 |
| infinity | * journal: fix up syslog facility when forwarding native messages. | 17:54 |
| infinity | Native journal messages (_TRANSPORT=journal) typically don't have a | 17:54 |
| infinity | syslog facility attached to it. As a result when forwarding the | 17:54 |
| infinity | messages to syslog they ended up with facility 0 (LOG_KERN). | 17:54 |
| infinity | Apply syslog_fixup_facility() so we use LOG_USER instead. (Closes: #837893) | 17:54 |
| infinity | (LP: #1682484) | 17:54 |
| ubottu | Launchpad bug 1682484 in systemd (Ubuntu Zesty) "systemd: Logging from gnome session is passed on to all syslog facilities" [High,Fix released] https://launchpad.net/bugs/1682484 | 17:54 |
| infinity | xnox: ^-- That sounds like something we might like to SRU. | 17:54 |
| infinity | xnox: (noticed that dmesg on the upgraded snakefruit is full of timer adjust messages, which is just vile) | 17:55 |
| xnox | infinity, yes. | 17:55 |
| xnox | infinity, i didn't yet trace how far the bug goes, i presume forever. | 17:55 |
| infinity | xnox: Err, assuming that also applies to timer messages? | 17:56 |
| infinity | [ 265.446293] systemd[1]: snapd.refresh.timer: Adding 4h 38min 10.024228s random time. | 17:56 |
| xnox | infinity, depends if it is a user timer, or a system one. | 17:56 |
| infinity | That stuff really doesn't belong in the ringbuffer. | 17:56 |
| xnox | infinity, no, this bug report is about user session apps, doing syslog() and that ending up in the kern.log | 17:56 |
| xnox | as in stuff running under uid 1000 | 17:56 |
| infinity | Oh. So we need another bug and fix for this sort of thing? :P | 17:57 |
| xnox | that lovely timer message is from systemd =) | 17:57 |
| xnox | it that timer stuff in kern.log though? i guess i can check my own system. | 17:57 |
| xnox | i do not have any .timer messages in dmesg | 17:58 |
| xnox | are you booted with debug? | 17:58 |
| xnox | you should only have stuff in dmesg, upto until journal service is started and flushed | 17:59 |
| xnox | after that things go into journal. | 17:59 |
| infinity | xnox: Oh, that may indeed be early boot. But wow, gross that I get so many of them. | 18:00 |
| infinity | xnox: http://paste.ubuntu.com/24449338/ | 18:00 |
| infinity | xnox: That's a whole lot of noise for such a short period. | 18:00 |
| xnox | well, you can disable that, but then if things stuck before systemd manages to write things somewhere nicer one wouldn't even know what has stuck. | 18:00 |
| xnox | that's not normal. | 18:01 |
| xnox | e.g. by 265 it's not early boot anymore. | 18:01 |
| xnox | infinity, can i have a grep of just systemd? e.g. $ dmesg | grep systemd ? | 18:01 |
| xnox | systemctl list-units --failed ? | 18:01 |
| infinity | xnox: http://paste.ubuntu.com/24449341/ | 18:02 |
| xnox | also EOD an hour ago =/ | 18:02 |
| xnox | infinity, yeah timer stuff is not normal. will follow up on that. | 18:02 |
| xnox | also lldpd denied notify is not nice. | 18:02 |
| infinity | xnox: Only failed is psql (which migh warrant investigation too, but shouldn't relate to this?) | 18:02 |
| xnox | one is not booted, if one is degraded. | 18:03 |
| xnox | systemct is-system-running | 18:03 |
| infinity | xnox: degraded indeed. | 18:03 |
| xnox | https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1685874 | 18:05 |
| ubottu | Launchpad bug 1685874 in systemd (Ubuntu) "on xenial timer messaeges are in dmesg, wtf?!" [Undecided,New] | 18:05 |
| juliank | xnox: Seeign that: Does snapd also use similar timer values as apt? Might make sense to change that too, then, if the argument is that shit breaks if you upgrade software at random times | 18:07 |
| infinity | xnox: I haven't had any more timers since those, which is also curious. So maybe that really was all "early boot". Regardless, that's super noisy. | 18:08 |
| juliank | infinity: That will be less severe once the random delay is shorter, for apt at les | 18:09 |
| juliank | s/les/least/ | 18:09 |
| * zyga focuses on reviews and making tests pass | 18:44 | |
| * zyga wonders if anyone would merge his update-ns branches | 18:48 | |
| infinity | zyga: Was that meant to be aimed at this channel? | 18:50 |
| zyga | oh | 18:51 |
| zyga | no, irssi moved me over somehow | 18:51 |
| infinity | Sure, blame the client. ;) | 18:51 |
| infinity | (Alt-Left and Alt-Right bounce between irssi windows, if maybe you fat-fingered that when you meant to Ctrl-Alt-Right to hit another virtual desktop?) | 18:52 |
| sil2100 | !dmb-ping | 19:01 |
| ubottu | bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping. | 19:01 |
| cyphermox | oi. | 19:03 |
| cyphermox | I think everything's done and we didn't update the wiki last time; no new applicants? | 19:03 |
| nacc | dpb1: rbasak: fyi, automated imports are running again, from the snap! | 20:18 |
| dpb1 | awwww, snap | 20:19 |
| dpb1 | in a good way | 20:19 |
| rbasak | \o/ | 20:20 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| infinity | xnox: Ahh, and I got more timer spam in the ringbuffer later. So, yeah. Not cool. | 23:44 |
| infinity | xnox: FWIW, I have the same on my desktop machine. | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!