| saiarcot895 | For the openscenegraph-3.4 package in Bionic for i386, it appears the symbols that are provided by libosg.so.3.4 are different than what the symbols would be if they were recompiled now with current Bionic build environment. In other words, I believe there is a reproduciblity issue | 01:06 |
|---|---|---|
| saiarcot895 | I have an application that is trying to use OSG 3.4, and building for i386 fails because the symbols in the library and the symbols expected by the header files are different | 01:07 |
| saiarcot895 | Symbol differences are here: https://paste.ubuntu.com/p/X93JnhHJmQ/ Most of the changes are due to ptrdiff_t being a long currently instead of int back when this package was compiled | 01:15 |
| === vicamo_ is now known as vicamo | ||
| infinity | saiarcot895: int and long are the same on i386. Are you sure you didn't recompile for amd64 by accident? | 05:31 |
| saiarcot895 | infinity: Nope, this is going through i386 chroot in sbuild | 06:27 |
| saiarcot895 | The size should be the same, but I guess the symbol names that get generated are different for some reason? | 06:28 |
| LocutusOfBorg | Adri2000, you should bump libfilezilla soname, or add some break/replaces against filezilla, before uploading filezilla | 07:19 |
| LocutusOfBorg | also, fix the two build failures (maybe adding latomic helps) | 07:19 |
| LocutusOfBorg | meh, you need break not replaces | 07:20 |
| didrocks | cyphermox: hey, mind pushing grub2 2.04-1ubuntu6 to the VCS? | 07:31 |
| caribou | Hello, I see that partman-md is a sync from Debian so I would hate to introduce an Ubuntu delta, so is there any other way to get Debian Bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838503 SRUed into Bionic so Installs on RAID5 stop being slow as a pig ? | 07:49 |
| ubottu | Debian bug 838503 in partman-md "debian-installer: mdadm should not start syncing RAID1 arrays at full speed during installation" [Normal,Fixed] | 07:49 |
| caribou | I have a workaround in the meantime but it would be nice to fix that one | 07:50 |
| Laney | juliank: any chance you want to review https://code.launchpad.net/~jibel/ubiquity/+git/ubiquity/+merge/373302 (small, apt_pkg) please? | 08:10 |
| LocutusOfBorg | caribou, let me see if I got it right: the bug is *fixed* in eoan, right? | 08:16 |
| LocutusOfBorg | since version 89 | 08:16 |
| LocutusOfBorg | so fixed in eoan and disco already | 08:17 |
| LocutusOfBorg | you want it fixed in bionic? | 08:17 |
| juliank | Laney: done | 08:17 |
| LocutusOfBorg | caribou, open a bug like this one https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template | 08:17 |
| LocutusOfBorg | and ping back in this case | 08:18 |
| LocutusOfBorg | just o be sure, existing isos will probably have the old version of the tool, until the iso is regenerated (18.04.4 is scheduled for 06 feb 2020 or so) | 08:19 |
| infinity | Real Sysadmins(tm) don't install from ISOs. | 08:20 |
| LocutusOfBorg | :) | 08:20 |
| Laney | juliank: thanks! | 08:21 |
| infinity | Laney: Is it a bug or a feature that my screen blanking no longer fades out for several seconds before actually blanking/locking (giving me a chance to hammer a key in a panic and make it stop)? | 08:21 |
| LocutusOfBorg | in any case, SRUing the fix should be possible the fix seems to be safe enough for bionic | 08:21 |
| LocutusOfBorg | infinity just to be sure, real admins probably inside the installation manually fix that bug by calling local md_min_sync_speed=$(cat /proc/sys/dev/raid/speed_limit_min) | 08:23 |
| LocutusOfBorg | echo "$md_min_sync_speed" > /proc/sys/dev/raid/speed_limit_max | 08:23 |
| infinity | Probably not. :P | 08:23 |
| LocutusOfBorg | :) | 08:27 |
| LocutusOfBorg | did the beta testing go successfully? | 08:27 |
| LocutusOfBorg | xnox, you patched python-cryptography to run tests only against the current python3 version, back in cosmic days, because python3.7 rc2 was failing to test, and was not the default... I don't see such issues anymore with the new version, so I did sync it again | 08:28 |
| LocutusOfBorg | I'll followup with a merge fix in case the test on arm64 is bad, but I think the new 2.6 version is good since the begin, or maybe python fixed the bug when 3.7 went stable | 08:29 |
| cpaelzer | rbasak: for the now frequent "please rebuild openssl 1.1.1" bugs and the SRU decision to say yes to those the newest development on bug 1841936 might be interesting to you (and the SRU team) | 08:40 |
| ubottu | bug 1841936 in haproxy (Ubuntu Bionic) "Rebuild haproxy with openssl 1.1.1 will change features (bionic)" [Medium,Fix committed] https://launchpad.net/bugs/1841936 | 08:40 |
| cpaelzer | I'm waiting on seucrity there to chime in, but definetly interesting from an SRU POV | 08:40 |
| Laney | infinity: not sure, I haven't heard of it being removed, maybe file a bug | 08:40 |
| === vicamo_ is now known as vicamo | ||
| caribou | @LocutusOfBorg sorry did not see your answer | 09:10 |
| udevbot | Error: "LocutusOfBorg" is not a valid command. | 09:10 |
| caribou | LocutusOfBorg sorry did not see your answer | 09:10 |
| caribou | doing SRU is not the issue. So far partman-md do not have an Ubuntu delta so doing an SRU for it on Bionic will introduce one, I just want to know if there is a specific way to handle this one.If not, I'll fix it and do the SRU | 09:11 |
| cjwatson | That's not a problem | 09:14 |
| cjwatson | The primary reason to be careful about Ubuntu deltas when there isn't already a delta is that it inhibits autosync, and that's not relevant for stable releases | 09:14 |
| LocutusOfBorg | exactly, delta is fine for stable, since autosync can't run there :) | 09:15 |
| cjwatson | In this case something like 86ubuntu0.1 is entirely sensible | 09:17 |
| LocutusOfBorg | interesting, I was thinking more about 86ubuntu1.18.04.1 | 09:20 |
| caribou | that's what I thought too, but since I did not see _any_ delta on this one I preferred to ask | 09:21 |
| caribou | LocutusOfBorg: and the preseed workaround is what I do btw :) | 09:26 |
| cjwatson | 86ubuntu1.18.04.1 makes no sense because there was never an 86ubuntu1 | 09:33 |
| cjwatson | you could do 86ubuntu0.18.04.1 if you really wanted, but TBH it's a bit over-pedantic because no newer series has version 86 | 09:34 |
| LocutusOfBorg | nice to know, I usually do it anyway, I never thought about do it only if ubuntu1 never existed, it looks like more "coherent with the rest of the archive" :D | 09:37 |
| cjwatson | https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging recommends your practice only when pushing the same thing to multiple releases | 09:39 |
| rbalint | rafaeldtinoco, 243 had too many regressions, so please plan with 242 being in eoan | 11:07 |
| rbalint | rafaeldtinoco, i'm preparing one more upload if it gets FFe, if you seek FFe for your changes then they can go in together | 11:16 |
| rbasak | mysql-router (from src:mysql-8.0) ships /usr/bin/mysql-router which needs some shared objects. They don't need to be shared objects because nothing except /usr/bin/mysql-router loads them. I'm not sure I'd call them plugins either. libmysqlrouter.so.1 is one of them. But it's strictly internal. I stuffed them inside /usr/lib/mysql-router/ to try to keep them away from public use. Do you think that's | 11:41 |
| rbasak | acceptable, or should packaging go further? | 11:41 |
| === ricab is now known as ricab|lunch | ||
| === ricab|lunch is now known as ricab | ||
| ahasenack | rbasak: picking your git knowledge, | 14:28 |
| ahasenack | rbasak: I have two remotes, two different repositories | 14:28 |
| ahasenack | rbasak: I'm working on one, which has a file I want to change | 14:28 |
| ahasenack | rbasak: I want to cherry pick that change from the other remote | 14:28 |
| ahasenack | but these are different repositories, and that file is in different places in each | 14:28 |
| ahasenack | I was hoping for something like a cherry-pick with a -p parameter, like patch's, to just ignore the directory the file is in | 14:29 |
| ahasenack | specifically, I want to cherry pick a change that is in the file "scripts/test-postfix.py", but in my local branch that file is in "debian/tests/test-postfix.py" | 14:29 |
| rbasak | git checkout <local-branch>; git log -p -1 <source-commit>|patch | 14:30 |
| rbasak | Maybe? | 14:30 |
| ahasenack | any git tricks for that? Or should I just convert it into a patch | 14:30 |
| rbasak | It is a patch :) | 14:30 |
| ahasenack | I mean, save it to a file, then apply with patch -p 1 | 14:30 |
| ahasenack | then commit | 14:31 |
| rbasak | Yes, essentially | 14:31 |
| ahasenack | k | 14:31 |
| rbasak | I suppose that won't preserve the commit metadata if you want that | 14:31 |
| rbasak | You could format-patch, hack the path in the patch, and then git am | 14:31 |
| rbasak | I assume that the two commits don't have any shared history | 14:32 |
| rbasak | Because if they do, git can often do the right thing automatically | 14:32 |
| bdmurray | rbasak: I don't think regression-release was appropriate for bug 1845599. Maybe that was an inappropriate stock response? | 14:50 |
| ubottu | bug 1845599 in duplicity (Ubuntu) "eoan regression: ImportError: librsync.so.1: cannot open shared object file: No such file or directory" [Undecided,Invalid] https://launchpad.net/bugs/1845599 | 14:50 |
| rbasak | bdmurray: I thought the claim (not my conclusion) met the definition at https://wiki.ubuntu.com/Bugs/Tags#Regression_specific. Do you disagree? | 14:51 |
| bdmurray | rbasak: I read "locally installed version of duplicity". | 14:52 |
| bdmurray | which means not our issue as you said. | 14:53 |
| rbasak | bdmurray: right, but if I'm wrong, say I made a mistake or the reporter says something like "oh, sorry, I did that to debug the issue, here are full steps to reproduce" then the bug would reopen with the correct tag | 14:54 |
| rbasak | So I try to tag according to the claim, and leave it to the bug status field to represent validity | 14:54 |
| bdmurray | Oh that's a forward thinking and reasonable idea. Got it! | 14:55 |
| rbasak | I'm just defending against my own potential mistakes. I triage heavy on the Invalid and Incomplete statuses, but try to do it with humility and make it clear that with further information or clarification the reporter can always request a second look. | 14:57 |
| rbasak | :) | 14:57 |
| ahasenack | hi sru team, could someone take a look at base-files in xenial? | 18:12 |
| ahasenack | I think https://launchpad.net/ubuntu/+source/base-files/9.4ubuntu4.9 had a regression, and https://launchpad.net/ubuntu/+source/base-files/9.4ubuntu4.10 is there to fix it, but xenial still only has 4ubuntu4.8 | 18:13 |
| ahasenack | rbasak: if still around ^ | 18:14 |
| bdmurray | ahasenack: 9.4ubuntu4.9 didn't do what it was supposed to see my comment regarding it failing verification. | 18:24 |
| ahasenack | hm, and 4.10 just fixed the syntax error | 18:26 |
| ahasenack | bdmurray: ok, thanks, I guess I get to fix it now :) | 18:27 |
| bdmurray | ahasenack: you might check with vorlon about what went wrong | 18:31 |
| kyrofa | I need an expert to confirm this for me: I have version 1.0 of package A installed. Version 1.1 of package A is released, but it comes with a new dependency. I will NOT update to version 1.1 of package A by running `apt upgrade`. I must run `apt dist-upgrade`. Correct? | 19:53 |
| kyrofa | i.e. `apt upgrade` only updates existing software, does not install new or remove existing. `apt dist-upgrade` will update existing software AND install new/remove existing as necessary | 19:53 |
| kyrofa | Did I get that right? | 19:54 |
| Skuggen | Not 100% sure, but I think no | 19:57 |
| Skuggen | upgrade won't _remove_ any packages, I think | 19:57 |
| kyrofa | Yeah that's the only clarifier I've found... but I THINK it also applies to NEW dependencies | 19:57 |
| kyrofa | Not sure how to confirm | 19:57 |
| Skuggen | Actually, it might be different for apt vs apt-get, as well | 19:57 |
| kyrofa | Hahaha, nooo | 19:58 |
| kyrofa | That's another relationship I have yet to wrap my head around | 19:58 |
| kyrofa | I assumed apt just dispatched | 19:59 |
| Skuggen | manpage for apt says it will install new deps on upgrade, while the one for apt-get says it won't. | 20:00 |
| cjwatson | Right. | 20:00 |
| Skuggen | Maybe just make some trivial empty packages to test out? | 20:00 |
| cjwatson | No need - what you've got from the man pages is correct | 20:01 |
| cjwatson | It was a deliberate change from apt-get to apt because in fact the "install new but don't remove existing" option turns out to be a better conservative choice most of the time for people who want a conservative choice | 20:01 |
| Skuggen | Aha, thanks :) | 20:02 |
| cjwatson | But not really changeable in apt-get without breaking compatibility | 20:02 |
| kyrofa | cjwatson, ah ha! So the behavior is indeed different | 20:03 |
| kyrofa | Thank you both, that's what I needed | 20:04 |
| vorlon | ahasenack: base-files> It's on my backlog to sort out; your analysis in the bug comment is spot on; are you taking this from me? | 20:14 |
| vorlon | ahasenack: (I do not object if you are) | 20:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!