<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(0,0,0)">Hi all,</div><br><br>2016-08-25 3:47 GMT-03:00 Raphael Hertzog <span dir="ltr"><<a href="mailto:hertzog@debian.org" target="_blank">hertzog@debian.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Wed, 24 Aug 2016, Marcos Fouces wrote:<br>
> I left the credits for every kali packager because i use kali package as<br>
> starting point. It is surely unfair not to give them credits.<br>
<br>
</span>There's certainly nothing wrong to keep the full history including the<br>
Kali one. If you look into the Debian archive, you will find ubuntu<br>
changelog entries as well.<br>
<br>
It's also not the end of the world if you start with an empty changelog.<br>
<br>
My personal preference is to keep the original changelog in general as<br>
it might contain indications about some of the old packaging choices that<br>
might still be relevant.<br>
<span class=""><br>
> > pristine-tar: The first tarball uploaded to this branch was the kali<br>
> > one, from 5.4.1 (first debian shipped version is 5.6.4), is that a a<br>
> > problem? Can we reset the pristine-tar branch with 5.6.4?<br>
<br>
</span>The pristine-tar branch contains data for all the historical tarballs and<br>
it's fine that way. There's nothing problematic here.<br>
<span class=""><br>
> > Please also note that no upstream tags were made yet, so i believe it<br>
> > would be less intrusive to reset pristine-tar.<br>
<br>
</span>What do you mean? I see a 5.4.1 tag in<br>
<a href="https://github.com/fredericopissarra/t50/releases" rel="noreferrer" target="_blank">https://github.com/<wbr>fredericopissarra/t50/releases</a><br>
<span class=""><br>
> > If somebody clones t50 packaging repo from our team and tries gbp<br>
> > buildpackage, the build will fail because gbp will try to build the kali<br>
> > version: "dpkg-deb: building package 't50' in<br>
> > '../t50_5.4.1-rc1-1kali1_<wbr>amd64.deb'."<br>
> Perhaps you need to configure gbp to use "debian/master" as the Debian<br>
> branch. By default it uses the "master" branch that actually points to kali<br>
> version.<br>
<br>
</span>Right... I dropped the master branch on <a href="http://git.debian.org" rel="noreferrer" target="_blank">git.debian.org</a> to avoid this<br>
mistake on a fresh clone.<br></blockquote><div><br><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(0,0,0)">When i said upstream tags, i was referring to the upstream branch, it didn't have the "upstream/5.6.4" tag, i already fixed that.<br><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(0,0,0)">Regarding keeping kali leftovers, i have no problem in that, i was afraid that was unintentional, personally i prefer to give credits to kali maintainers by mentioning them on the first debian's changelog entry, but i have no problem with your approaches. </div><br><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(0,0,0)"><br><div class="gmail_quote">2016-08-24 5:19 GMT-03:00 Marcos Fouces <span dir="ltr"><<a href="mailto:mfouces@yahoo.es" target="_blank">mfouces@yahoo.es</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">Yes, it needs to be fixed. march=native is not ok. You can try to
compile (or crosscompile) on other architectures and check of it is
ok without this option. If so, it is trivial to patch upstream
makefile.<br>
<br>
Keep in mind that upstreams states clearly that t50 is only tested
on amd64 and linux.</div></blockquote></div><br><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(0,0,0)">Hi Marco, as you already seen, we've already fixed the problem with
march. I'm not aware of anything intel specific on T50, but we'll have
to keep an eye on that.<br><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(0,0,0)">The
main problem with march=native is not that it broke some architectures
buildings, is that it has broken T50 on successful builds, the amd64 and
i386 actual ones won't run on various amd64 and i386 processors because
its build was made specifically for the processor used on the building
machine, specially the amd64 one, which only runs on processors
identical or very look-a-like with yours.<br><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(0,0,0)">If we'll have to drop some architecture, we can deal with that on d/control.<br><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(0,0,0)">Thanks for accepting me as a co-maintainer!<br></div><br>
By the way, your email address is still very problematic, gmail states that the
owner of mfouces handle is Sonia Fernandez and all your emails are sent
straight up to spam folder, are you using some kind of email spoofing?</div><br> </div><div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(0,0,0);display:inline"><div dir="ltr"><span style="font-family:verdana,sans-serif"><span style="color:rgb(102,102,102)">Samuel Henrique O. P. [samueloph]</span></span></div>
</div> </div></div><br></div></div>