[Pkg-security-team] Some problems with T50 packaging
?Hi all,
2016-08-25 3:47 GMT-03:00 Raphael Hertzog <hertzog at debian.org>:
> On Wed, 24 Aug 2016, Marcos Fouces wrote:
> > I left the credits for every kali packager because i use kali package as
> > starting point. It is surely unfair not to give them credits.
>
> There's certainly nothing wrong to keep the full history including the
> Kali one. If you look into the Debian archive, you will find ubuntu
> changelog entries as well.
>
> It's also not the end of the world if you start with an empty changelog.
>
> My personal preference is to keep the original changelog in general as
> it might contain indications about some of the old packaging choices that
> might still be relevant.
>
> > > pristine-tar: The first tarball uploaded to this branch was the kali
> > > one, from 5.4.1 (first debian shipped version is 5.6.4), is that a a
> > > problem? Can we reset the pristine-tar branch with 5.6.4?
>
> The pristine-tar branch contains data for all the historical tarballs and
> it's fine that way. There's nothing problematic here.
>
> > > Please also note that no upstream tags were made yet, so i believe it
> > > would be less intrusive to reset pristine-tar.
>
> What do you mean? I see a 5.4.1 tag in
> https://github.com/fredericopissarra/t50/releases
>
> > > If somebody clones t50 packaging repo from our team and tries gbp
> > > buildpackage, the build will fail because gbp will try to build the
> kali
> > > version: "dpkg-deb: building package 't50' in
> > > '../t50_5.4.1-rc1-1kali1_amd64.deb'."
> > Perhaps you need to configure gbp to use "debian/master" as the Debian
> > branch. By default it uses the "master" branch that actually points to
> kali
> > version.
>
> Right... I dropped the master branch on git.debian.org to avoid this
> mistake on a fresh clone.
>
?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.
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. ?
??
2016-08-24 5:19 GMT-03:00 Marcos Fouces <mfouces at yahoo.es>:
> 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.
>
> Keep in mind that upstreams states clearly that t50 is only tested on
> amd64 and linux.
>
?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.
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.
If we'll have to drop some architecture, we can deal with that on d/control.
Thanks for accepting me as a co-maintainer!
? 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??
Samuel Henrique O. P. [samueloph]
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-security-team/attachments/20160826/4c07a97d/attachment.html>
Reply to: