[14:03] <flixr> hi, would be great if someone could sync dpkg in yakkety and zesty to >= 1.10.11
[14:04] <flixr> meant >= 1.18.11
[14:04] <flixr> dpkg 1.18.10 has some bugs that are already fixed in Debian upstream that e.g. prevent building some packages on launchpad
[16:03] <rbasak> flixr: dpkg has a delta. Just blindly syncing it would be wrong.
[16:51] <tsimonq2> flixr: You might want to file a bug against dpkg, that's a good way to report it.
[16:51] <tsimonq2> !info dpkg zesty
[16:51] <tsimonq2> !info dpkg yakkety
[16:51] <tsimonq2> Ahh ok...
[16:51] <tsimonq2> !info dpkg unstable
[17:57] <flixr> tsimonq2, file a bug https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1652945
[18:09] <tsimonq2> flixr: Ok, thanks.
[18:26] <tsimonq2> Hey everyone, I'm a little stuck on this and since Steve is on holiday, I thought I might ask to see if anyone here knows how to deal with this
[18:26] <tsimonq2> bug 1648295
[18:27] <tsimonq2> So this merge is because of a change made when G++5 was landing(?)
[18:28] <mapreri> tsimonq2: what you did in that last patch is exactly what I was suggesting to you in private, just that that change could be done in Debian too (is a nop), with the single problem that you'd need to make sure nobody removes it before 18.04 (but I'd like to think a comment explaining that could be enough).
[18:28] <mapreri> now, dinner for me, cu later!
[18:29] <tsimonq2> I guess I saw examples of Steve doing this (he pointed me to zesty-changes) and I'm wondering if I did this right.
[18:29] <tsimonq2> And why does it need to be done this way?
[18:29] <tsimonq2> o/ mapreri
[18:30] <tsimonq2> (Steve being Steve Langasek)
[18:34] <mitya57> tsimonq2, s/Conflicts/Breaks/, I see no reason for Conflicts here
[18:35] <mitya57> Also maybe Provides is not necessary, but it won't hurt either.
[18:36] <mitya57> Do you want me to sponsor it?
[18:37] <tsimonq2> mitya57: Ok, so why Breaks, not Conflicts?
[18:37] <tsimonq2> What's your reasoning for that?
[18:37] <tsimonq2> (seeing as Conflicts is already there)
[18:37] <tsimonq2> mitya57: Like I said, I was using something Steve did as a model... :)
[18:38] <rbasak> Usually it's Breaks that is normal, and Conflicts that needs some special reasoning.
[18:38] <tsimonq2> Ok, fair enough. Then why might Steve do this? http://launchpadlibrarian.net/290421985/hmat-oss_1.2.0-1ubuntu1_1.2.0-2ubuntu1.diff.gz
[18:38] <mitya57> It's more difficult for APT to handle Conflicts
[18:39] <tsimonq2> (just hoping to understand why he did it that way versus using Breaks)
[18:39] <tsimonq2> And when do I use Conflicts instead?
[18:39] <rbasak> Conflict/Replace/Provide is special. It's for swapping virtual packages.
[18:39] <rbasak> I suggest not cargo culting, not even if it's from Steve :-)
[18:40] <tsimonq2> Heh. :P
[18:40] <rbasak> You might find https://wiki.debian.org/PackageTransition helpful
[18:40] <tsimonq2> rbasak: Oh cool thanks
[18:40] <rbasak> Also https://www.debian.org/doc/debian-policy/ch-relationships.html
[18:40] <mitya57> I don't really know why Steve used conflicts, but that's unnecessary here. Also thanks rbasak for pasting these links :)
[18:41] <tsimonq2> But when dealing with merges with G++5 ABI stuff, I should use Breaks, Replaces, and Provides won't hurt?
[18:42] <rbasak> why Steve used conflicts> because " Conflicts should be used
[18:42] <rbasak> ...
[18:42] <rbasak> in conjunction with Provides when only one package providing a given virtual facility may be unpacked at a time "
[18:42] <rbasak> from https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
[18:42] <rbasak> (I assume, as I see that he's also doing Provides)
[18:42] <slangasek> because Conflicts/Provides/Replaces has a special meaning
[18:42] <tsimonq2> OHAI slangasek :)
[18:42]  * slangasek waves
[18:43] <slangasek> unfortunately the meanings of these fields are not independent
[18:43] <mitya57> Doesn't Breaks/Provides/Replaces have the same meaning then?
[18:45] <tsimonq2> Isn't Breaks/Provides/Replaces used when package X-dev0v5 (for example) is replacing X-dev0 and it shouldn't be installed at the same time?
[18:46] <tsimonq2> When is that used?
[18:46]  * tsimonq2 searches list archives for why this particular transition was done this way
[18:50] <tsimonq2> Oh so this I think? https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[18:52] <mitya57> That page suggests using Breaks/Replaces, that's what I would use too
[18:53] <mitya57> As far as I understand, Conflicts is used when there are two packages that provide the same file, and they both will continue to exist. In our case one of the packages will no longer exist, in which case Breaks is better.
[18:54] <mitya57> But maybe slangasek can explain where I am wrong :)
[18:55] <tsimonq2> mitya57: Alright, if I respond to the bug with an updated diff, would you sponsor? :)
[18:56] <mitya57> No need for updated diff, I want to see if slangasek has any explanation for Conflicts, and then I'll sponsor it.
[18:56] <tsimonq2> Ok cool
[19:38] <mitya57> tsimonq2, ok, uploading your change as is. There are no rdependencies, right?
[19:39] <tsimonq2> mitya57: Haven't checked, please do!
[19:39] <mitya57> Looks like no
[19:40] <tsimonq2> mitya57: So why would that matter then? Would they need a no-change rebuild?
[19:40] <mitya57> Yes, the might need it
[19:41] <mitya57> E: freehdl source: version-substvar-for-external-package libfreehdl0-dev -> libfreehdl0v5
[19:41] <tsimonq2> O_o
[19:42] <mitya57> .shlibs and .lintian-overrides need to be renamed, and some other file need s/v5//
[19:42] <tsimonq2> mitya57: But you didn't upload yet right?
[19:42] <mitya57> Right
[19:42] <mitya57> I'll fix that myself
[19:42] <tsimonq2> Ok, Good.
[19:42] <tsimonq2> Awesome, thanks. :)
[19:43] <mitya57> (oh wait, why is there a .shlibs file in the source? it should be generated by dh_makeshlibs)
[19:43] <mitya57> (but the package uses the ancient debhelper level v5 so this might not work)
[19:44] <tsimonq2> ...?
[19:56] <mitya57> tsimonq2, this is what I got as a diff: http://launchpadlibrarian.net/300468451/freehdl_0.0.8-2.2ubuntu1_0.0.8-2.2ubuntu2.diff.gz
[19:56] <mitya57> Now the package is mostly identical to Debian
[20:00] <tsimonq2> Yay
[20:01] <tsimonq2> Ok, I see you uploaded, got the email \o/
[20:04] <tzero> does dpkg-buildpackage require a GPG key to be saved with a passphrase? I have used `gpg --edit-key` and `passwd` with blank passphrase to remove it (or so I believe), but still get prompted
[21:38] <ytrezq> Hello, how to build a .deb source package with the Intel compiler (icc instead of gcc)??
[23:24] <slangasek> mitya57: you have that backwards; when one of the packages is being obsoleted completely, Conflicts is preferred