Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
> @Norbert: nevertheless I'd follow Karl's advice to build dvisvgm Fully agreed. The integration of dvisvgm into the TL sources is always a bit hacky. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
On 16.08.19 20:11, Hector Oron wrote: Hi Hector, > JFYI, a give back (package rebuild from failed state) has been triggered > per IRC request: > > Day changed to 16 Aug 2019 > 12:08 < gnu_srs1> (11:51:02 PM) srs: Can somebody gb texlive-bin > 2019.20190605.51237-2 on > hurd-i386. It built fine locally. > Built successfully! Do you have a clue why exactly the same libtool command line now succeeds? @Norbert: nevertheless I'd follow Karl's advice to build dvisvgm separately. As tl-bin is now available on all arches there is no time pressure any more. Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Hello, JFYI, a give back (package rebuild from failed state) has been triggered per IRC request: Day changed to 16 Aug 2019 12:08 < gnu_srs1> (11:51:02 PM) srs: Can somebody gb texlive-bin 2019.20190605.51237-2 on hurd-i386. It built fine locally. signature.asc Description: PGP signature
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Control: block 926701 by 932968 Control: tags 926701 + pending Am 30.07.2019 um 08:20 teilte Norbert Preining mit: > On Tue, 30 Jul 2019, Hilmar Preuße wrote: >> rejected) you have to tag commit > > Thanks for the warning, but I have already tagged, but not pushed ;-) > Bug manipulation. H. -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
On Tue, 30 Jul 2019, Hilmar Preuße wrote: > rejected) you have to tag commit Thanks for the warning, but I have already tagged, but not pushed ;-) Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Am 26.07.2019 um 15:07 teilte Norbert Preining mit: Hi Norbert, > Uploaded. > > I wait with tagging until it is accepted. > I just noticed that the debian/watch file I created was broken. I've corrected it and pushed it to github. So (unless our package get's rejected) you have to tag commit a011374d72a14ee7637c3c87e81278e78d9f6d58, instead of the last state of the tree. Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Am 26.07.2019 um 07:24 teilte Norbert Preining mit: On Thu, 25 Jul 2019, Hilmar Preuße wrote: Hi, dvisvgm build (and links) fine on Hurd. We have a failure in the test suite. I'll care about that later on. Ok, please check that I opened a bug @upstream [1] and got a patch for it. I'll commit it to our repo as soon as -1 has entered the archive. Hilmar [1] https://github.com/mgieseki/dvisvgm/issues/116 -- #206401 http://counter.li.org
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
On Fri, 26 Jul 2019, Hilmar Preuße wrote: > For the issue on Hurd I got a patch; I'll test it ASAP. The chroot on That could be the non-source upload in case of acceptance. Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Am 26.07.2019 um 15:07 teilte Norbert Preining mit: Hi, Uploaded. I wait with tagging until it is accepted. Great thanks! For the issue on Hurd I got a patch; I'll test it ASAP. The chroot on exodar was fixed, so I can use an official Debian porters box. Hope this is more fun, than my local Hurd VM. ;-) H. -- #206401 http://counter.li.org
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Uploaded. I wait with tagging until it is accepted. On Fri, 26 Jul 2019, Hilmar Preuße wrote: > > Am 26.07.2019 um 14:41 teilte Norbert Preining mit: > > > How do you interpret this? > > > See below. > > > On Fri, 26 Jul 2019, Hilmar Preuße wrote: > > > From now on, we will no longer allow binaries uploaded by maintainers to > > > migrate to testing. This means that you will need to do source-only > > > uploads if you want them to reach bullseye. > > ... > > >Q: I needed to do a binary upload because my upload went to the NEW > > > queue, > > > do I need to do a new (source-only) upload for it to reach bullseye? > > >A: Yes. We also suggest going through NEW in experimental instead of > > > unstable > > > where possible, to avoid disruption in unstable. > > > > ??? > > > > So for NEW we need to do a binary upload, right? > > > Correct. And once the package reached the archive, we do another upload > source only to make sure it enters testing. On [1] I see at least all > uploads as binary uploads. > > H. > > [1] https://ftp-master.debian.org/new.html > -- > #206401 http://counter.li.org > Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Am 26.07.2019 um 14:41 teilte Norbert Preining mit: How do you interpret this? See below. On Fri, 26 Jul 2019, Hilmar Preuße wrote: From now on, we will no longer allow binaries uploaded by maintainers to migrate to testing. This means that you will need to do source-only uploads if you want them to reach bullseye. ... Q: I needed to do a binary upload because my upload went to the NEW queue, do I need to do a new (source-only) upload for it to reach bullseye? A: Yes. We also suggest going through NEW in experimental instead of unstable where possible, to avoid disruption in unstable. ??? So for NEW we need to do a binary upload, right? Correct. And once the package reached the archive, we do another upload source only to make sure it enters testing. On [1] I see at least all uploads as binary uploads. H. [1] https://ftp-master.debian.org/new.html -- #206401 http://counter.li.org
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
On Fri, 26 Jul 2019, Hilmar Preuße wrote: > Yes. It has to got through the new queue. Once this is done we can care Just to check, going to NEW do we need to do source only or source/binary uploads? Do you remember? Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Am 26.07.2019 um 14:28 teilte Norbert Preining mit: On Fri, 26 Jul 2019, Hilmar Preuße wrote: Hi, Yes. It has to got through the new queue. Once this is done we can care Just to check, going to NEW do we need to do source only or source/binary uploads? Do you remember? No binary maintainer uploads for bullseye = The release of buster also means the bullseye release cycle is about to begin. From now on, we will no longer allow binaries uploaded by maintainers to migrate to testing. This means that you will need to do source-only uploads if you want them to reach bullseye. Q: I already did a binary upload, do I need to do a new (source-only) upload? A: Yes (preferably with other changes, not just a version bump). Q: I needed to do a binary upload because my upload went to the NEW queue, do I need to do a new (source-only) upload for it to reach bullseye? A: Yes. We also suggest going through NEW in experimental instead of unstable where possible, to avoid disruption in unstable. Q: Does this also apply to contrib and non-free? A: No. Not all packages in contrib and non-free can be built on the buildds, so maintainer uploads will still be allowed to migrate for packages outside main. Hilmar -- #206401 http://counter.li.org
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Am 26.07.2019 um 14:29 teilte Norbert Preining mit: Hi, Yes. It has to got through the new queue. Once this is done we can care about tl-binaries. Actually since you put in only a suggest, we could do that immediately. I am not sure whether we shouldn't do a Depends on dvisvgm instead... I would do Depends only, where there are 100% necessary. Maybe we could do Recommends. But this can be changed before tl-binaries upload. H. -- #206401 http://counter.li.org
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Hi How do you interpret this? On Fri, 26 Jul 2019, Hilmar Preuße wrote: > From now on, we will no longer allow binaries uploaded by maintainers to > migrate to testing. This means that you will need to do source-only > uploads if you want them to reach bullseye. ... > Q: I needed to do a binary upload because my upload went to the NEW queue, > do I need to do a new (source-only) upload for it to reach bullseye? > A: Yes. We also suggest going through NEW in experimental instead of > unstable > where possible, to avoid disruption in unstable. ??? So for NEW we need to do a binary upload, right? Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
> Yes. It has to got through the new queue. Once this is done we can care > about tl-binaries. Actually since you put in only a suggest, we could do that immediately. I am not sure whether we shouldn't do a Depends on dvisvgm instead... Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Am 26.07.2019 um 13:48 teilte Norbert Preining mit: Hi, Done for dvisvgm. texlive-binaries has been adapted too, dvisvgm is not built any more, manual page is not installed. Ok, so should I upload dvisvgm? Yes. It has to got through the new queue. Once this is done we can care about tl-binaries. Hilmar -- #206401 http://counter.li.org
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Hallo Hilmar, > Done for dvisvgm. texlive-binaries has been adapted too, dvisvgm is not > built any more, manual page is not installed. Ok, so should I upload dvisvgm? > ??? What kind of support files? The manual page is not installed by > tl-bin any more. The dvisvgm package just contains docs, manual page and > the binary. Ok, all fine. Thanks Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
On 26.07.19 07:55, Norbert Preining wrote: Hi Norbert, > We still need to do the replace stuff ... I might be able to look into > it tomorrow, but today my time is running out. > > We need for sure replaces: texlive-binaries <= the current version in > sid. Then we disable it for the next upload in tl-binaries. > Done for dvisvgm. texlive-binaries has been adapted too, dvisvgm is not built any more, manual page is not installed. > I am not sure about support files, though. > ??? What kind of support files? The manual page is not installed by tl-bin any more. The dvisvgm package just contains docs, manual page and the binary. Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Hi Hilmar, On Fri, 26 Jul 2019, Hilmar Preuße wrote: > > Should we rewrite the history? Or leave it like it is? > > > Leave it. Ok. > I can't promise that I'll have a result soon. As Hurd is not a release > arch I don't see that as a show stopper. We could fix that in -1+x (with > x >= 1). Ok. We still need to do the replace stuff ... I might be able to look into it tomorrow, but today my time is running out. We need for sure replaces: texlive-binaries <= the current version in sid. Then we disable it for the next upload in tl-binaries. I am not sure about support files, though. Probably the only thing necessary Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
On 26.07.19 07:24, Norbert Preining wrote: Hi Norbert, > On Thu, 25 Jul 2019, Hilmar Preuße wrote: >>> hille@debian-amd64-sid >>> >> Solved...hopefully. Sorry, missed that. > > Should we rewrite the history? Or leave it like it is? > Leave it. >> We're lintian clean. Do you have to chance to test the package in a >> pbuilder chroot (didn't do so yet)? If that works OK, we're ready for >> "new" I guess. > > Python and ghostscript were missing for the tests. I added them, now it > builds fine in a clean chroot > Great, thanks! >> dvisvgm build (and links) fine on Hurd. We have a failure in the test >> suite. I'll care about that later on. > > Ok, please check that > I can't promise that I'll have a result soon. As Hurd is not a release arch I don't see that as a show stopper. We could fix that in -1+x (with x >= 1). Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Hi Hilmar, On Thu, 25 Jul 2019, Hilmar Preuße wrote: > > hille@debian-amd64-sid > > > Solved...hopefully. Sorry, missed that. Should we rewrite the history? Or leave it like it is? > Statical "linking" the md5 calculation code solved the problem. Thanks > Have to re-learn that... ;-( Do I have to create the pristine-tar branch > manually? That is a bit a pain since you started the way you did. What I did for your info: git checkout cdeec9bc651861b682bcd68e871f0a99fc919150 git checkout -b upstream git checkout master pristine-tar commit ./dvisvgm_2.7.3.orig.tar.gz That should do it, since dvisvgm original upstream sources were commited first into the repo at cdeec9. > re-create the build tree every time I do a re-build. Patch created and > committed. Thanks > We're lintian clean. Do you have to chance to test the package in a > pbuilder chroot (didn't do so yet)? If that works OK, we're ready for > "new" I guess. Python and ghostscript were missing for the tests. I added them, now it builds fine in a clean chroot > dvisvgm build (and links) fine on Hurd. We have a failure in the test > suite. I'll care about that later on. Ok, please check that Thanks for all your work! Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Am 25.07.2019 um 23:53 teilte Hilmar Preuße mit: Am 25.07.2019 um 20:53 teilte Norbert Preining mit: Hi, - I did not push the orig.tar.gz to pristine-tar branch yet, it is on [1], please push the code. Ok, please do so at some point. Have to re-learn that... ;-( Do I have to create the pristine-tar branch manually? hille@debian-amd64-sid:~/devel/build/dvisvgm$ pristine-tar commit ../dvisvgm_2.7.3.orig.tar.gz pristine-tar: failed to find ref using: git show-ref upstream I noticed that we don't have neither an pristine-tar nor an upstream branch. I've committed everything into master. Is it possible to fix the situation or do we have to re-create the repo from scratch? Please be so kind to fix it, I'll commit the orig.tar.gz then. dvisvgm build (and links) fine on Hurd. We have a failure in the test suite. I'll care about that later on. ColorTest.cpp:207: Failure Expected equality of these values: uint32_t(color) Which is: 1717068 0x1a334du Which is: 1717069 [ FAILED ] ColorTest.set (0 ms) [--] 11 tests from ColorTest (0 ms total) [--] Global test environment tear-down [==] 11 tests from 1 test case ran. (10 ms total) [ PASSED ] 10 tests. [ FAILED ] 1 test, listed below: [ FAILED ] ColorTest.set 1 FAILED TEST FAIL ColorTest (exit status: 1) Hilmar -- #206401 http://counter.li.org
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Am 25.07.2019 um 20:53 teilte Norbert Preining mit: Hi, a few things: - your email is not configured for git, git lists hille@debian-amd64-sid as email. Solved...hopefully. Sorry, missed that. E: dvisvgm: possible-gpl-code-linked-with-openssl That is still open. Statical "linking" the md5 calculation code solved the problem. - I did not push the orig.tar.gz to pristine-tar branch yet, it is on [1], please push the code. Ok, please do so at some point. Have to re-learn that... ;-( Do I have to create the pristine-tar branch manually? hille@debian-amd64-sid:~/devel/build/dvisvgm$ pristine-tar commit ../dvisvgm_2.7.3.orig.tar.gz pristine-tar: failed to find ref using: git show-ref upstream - you can't build the package twice using debuild. The reason is that make distclean deletes the manual page, which is not re-created during build. I've opened [2] for now. So what, that is not a requirement. I have several packages with similar problems. I'm aware of this. However I find it very convenient if I don't have to re-create the build tree every time I do a re-build. Patch created and committed. We're lintian clean. Do you have to chance to test the package in a pbuilder chroot (didn't do so yet)? If that works OK, we're ready for "new" I guess. Date: Fri, 26 Jul 2019 03:53:10 +0900 -> Is that your normal working time? Hilmar -- #206401 http://counter.li.org
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Hi Hilmar, a few things: - your email is not configured for git, git lists hille@debian-amd64-sid as email. > W: dvisvgm source: useless-autoreconf-build-depends autotools-dev fixed > W: dvisvgm source: dep5-copyright-license-name-not-unique gpl-3+ > (paragraph at line 11) > W: dvisvgm source: dep5-copyright-license-name-not-unique gpl-3+ > (paragraph at line 63) > W: dvisvgm source: dep5-copyright-license-name-not-unique mit (paragraph > at line 128) > W: dvisvgm source: dep5-copyright-license-name-not-unique gpl-2+ > (paragraph at line 179) fixed > W: dvisvgm: description-synopsis-starts-with-article fixed > E: dvisvgm: possible-gpl-code-linked-with-openssl That is still open. > - the possible-gpl-code-linked-with-openssl could eventually be resolved > by statical linking w/ the delivered libs/md5 instead of dyn link > against libssl. I'll try again later. That would be great. > - I did not push the orig.tar.gz to pristine-tar branch yet, it is on > [1], please push the code. Ok, please do so at some point. > - you can't build the package twice using debuild. The reason is that > make distclean deletes the manual page, which is not re-created during > build. I've opened [2] for now. So what, that is not a requirement. I have several packages with similar problems. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Am 25.07.2019 um 14:24 teilte Norbert Preining mit: Hi Norbert, No need to be lintian clean. It should be lintian clean when we tag a release, not before. Please don't hesitate to commit half-backed not ready stuff, that is normal!! Looking forward to your work. OK, I pushed everything to github. Here is the remaining lintian stuff Now running lintian dvisvgm_2.7.3-1_amd64.changes ... W: dvisvgm source: useless-autoreconf-build-depends autotools-dev W: dvisvgm source: dep5-copyright-license-name-not-unique gpl-3+ (paragraph at line 11) W: dvisvgm source: dep5-copyright-license-name-not-unique gpl-3+ (paragraph at line 63) W: dvisvgm source: dep5-copyright-license-name-not-unique mit (paragraph at line 128) W: dvisvgm source: dep5-copyright-license-name-not-unique gpl-2+ (paragraph at line 179) E: dvisvgm: possible-gpl-code-linked-with-openssl W: dvisvgm: description-synopsis-starts-with-article Finished running lintian. Remarks: - the copyright file needs overhaul - the possible-gpl-code-linked-with-openssl could eventually be resolved by statical linking w/ the delivered libs/md5 instead of dyn link against libssl. I'll try again later. - I did not push the orig.tar.gz to pristine-tar branch yet, it is on [1], please push the code. - you can't build the package twice using debuild. The reason is that make distclean deletes the manual page, which is not re-created during build. I've opened [2] for now. Have fun! Hilmar [1] https://freeshell.de/~hille42/dvisvgm_2.7.3.orig.tar.gz [2] https://github.com/mgieseki/dvisvgm/issues/115 -- #206401 http://counter.li.org
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Hi Hilmar, On Thu, 25 Jul 2019, Hilmar Preuße wrote: > I've created a repo on github now. The package should be at least > lintian clean before first commit. No need to be lintian clean. It should be lintian clean when we tag a release, not before. Please don't hesitate to commit half-backed not ready stuff, that is normal!! Looking forward to your work. All the best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
On 25.07.19 11:00, Norbert Preining wrote: > On Thu, 25 Jul 2019, Hilmar Preuße wrote: Hi, >> I did some basic steps in packaging dvisvgm separately. Of course I'll > > Great, did you push your work to github so that I can take a look at it? > I will also take a look into the replace/depends calls necessary for the > upgrade. > I've created a repo on github now. The package should be at least lintian clean before first commit. Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd
Hi Hilmar, On Thu, 25 Jul 2019, Hilmar Preuße wrote: > I did some basic steps in packaging dvisvgm separately. Of course I'll Great, did you push your work to github so that I can take a look at it? I will also take a look into the replace/depends calls necessary for the upgrade. Thanks a lot Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
