Re: python-pyepics
I already did the change and uploaded it :). thanks
Re: python-pyepics
> The best way to get dependencies on shared libraries is of course
> dpkg-shlibdeps, but I assume there is a reason it's not used here so you
> should explain why.
Yes but this a python binding which use ctypes, so the code is never linked to
the libraries...
I wrote this
d/rules:
override_dh_gencontrol:
libca=$(shell dpkg-query -W -f '$${Depends}' libca-dev | awk '{print
$$1}'); \
libcom=$(shell dpkg-query -W -f '$${Depends}' libcom-dev | awk '{print
$$1}'); \
echo "lib:Depends=$$libca, $$libcom" >> debian/python3-pyepics.substvars
dh_gencontrol
d/control:
Package: python3-pyepics
Architecture: amd64
Depends:
python3-pkg-resources,
${lib:Depends},
${misc:Depends},
${python3:Depends},
but I do not know if this is the best solution.
Fred
python-pyepics
Hello,
the python-pyepics depends on the libca-dev and libcom-deb provided by
epics-base.
The upstream hardcode the version of the API in the library name and so in the
binary package name
ii libca4.14.4:amd647.0.8.1+dfsg1-2
amd64EPICS channel access client library
ii libcom3.23.1:amd64 7.0.8.1+dfsg1-2
amd64EPICS common library
I would like to make python-pyepics binNMUable
So I need to generate this dependency during the build of pyepics.
for now the binary dependency is hardcoded like this and obviously wrong.
Package: python3-pyepics
Architecture: amd64
Depends:
${python3:Depends},
${misc:Depends},
python3-pkg-resources,
libca4.14.2,
libcom3.22.0
Suggests: python-pyepics-doc
what is the best way to solve this issue.
thanks for your help
Frederic
Re: watch file for Fiji
thanks a lot I found the solution for this one. the other which consiste in a simple download of a file via an url https://drive.switch.ch/index.php/s/WOVSIPMky2JsXsp/download the downloaded file endup with this name on the disk xlib_.jar Is uscan capable to do the job for his this wget command which does the job is wget -O xlib_.jar https://drive.switch.ch/index.php/s/WOVSIPMky2JsXsp/download
Re: watch file for Fiji
to myself :)) it works like this # Fiji https://downloads.imagej.net/fiji/archive/@ANY_VERSION@/ .*/@ANY_VERSION@/fiji-linux64.zip group now the next one :)) i just need to download https://drive.switch.ch/index.php/s/WOVSIPMky2JsXsp/download $ uscan --report Use of uninitialized value in string eq at /usr/share/perl5/Devscripts/Uscan/WatchFile.pm line 340. Newest version of fiji on remote site is 20240614-2117, local version is 0.0.1 => Newer package available from: => https://downloads.imagej.net/fiji/archive/20240614-2117/fiji-linux64.zip Use of uninitialized value in string eq at /usr/share/perl5/Devscripts/Uscan/WatchFile.pm line 353. Use of uninitialized value in string eq at /usr/share/perl5/Devscripts/Uscan/WatchFile.pm line 353. Use of uninitialized value in string eq at /usr/share/perl5/Devscripts/Uscan/WatchFile.pm line 372. Use of uninitialized value in string eq at /usr/share/perl5/Devscripts/Uscan/WatchFile.pm line 378. Use of uninitialized value in string eq at /usr/share/perl5/Devscripts/Uscan/WatchFile.pm line 400. Use of uninitialized value in string eq at /usr/share/perl5/Devscripts/Uscan/WatchFile.pm line 400. uscan warn: Tag pattern missing version delimiters () in debian/watch, skipping: https://drive.switch.ch/index.php/s/WOVSIPMky2JsXsp/download checksum Is it possible to ask for uncoditionnal download ?
watch file for Fiji
Hello, I am trying to write a watch file for Fiji All the version are available in this https://downloads.imagej.net/fiji/archive/@ANY_VERSION@/fiji-linux64.zip I tryed with the simple version=4 https://downloads.imagej.net/fiji/archive/@ANY_VERSION@/fiji-linux64.zip but I end up with this error $ uscan --verbose uscan info: uscan (version 2.23.4+deb12u1) See uscan(1) for help uscan info: Scan watch files in . uscan info: Check debian/watch and debian/changelog in . uscan info: package="fiji" version="0.0.1-1" (as seen in debian/changelog) uscan info: package="fiji" version="0.0.1" (no epoch/revision) uscan info: ./debian/changelog sets package="fiji" version="0.0.1" uscan info: Process watch file at: debian/watch package = fiji version = 0.0.1 pkg_dir = . uscan warn: Tag pattern missing version delimiters () in debian/watch, skipping: https://downloads.imagej.net/fiji/archive/(?:[-_]?v?(\d[\-+\.:\~\da-zA-Z]*))/fiji-linux64.zip group uscan info: Scan finished What is wrong ? thanks for your help Frederic
how to obtain all files named blabla
Hello, I would like to extract from the Debian archive all the files with a given name in my case (meta.yaml) This is in order to test a sort of autodep8 based on the conda test framwork. Do we have a script which allows to do this sort of things ? If not, do we have a DD accessible mach8ine with all sources packages extracted ? thanks Frederic
Re: Submitters (well, for everyone) tip of the day courtesy of Sven Hartge - Debian CI and licenserecon (lrc)
> Not everyone has a DEP5 compatible debian/copyright file and > force-activating that check for those packages would immediately break > their CI without providing any benefit. the CI could detect the DEP5 copyright and run the test only when relevant :)
Re: Submitters (well, for everyone) tip of the day courtesy of Sven Hartge - Debian CI and licenserecon (lrc)
and why not activated by default ? - Le 31 Juil 24, à 14:52, Phil Wyett philip.wy...@kathenas.org a écrit : > Hi all, > > Tip of the day today comes from Sven Hartge below. > > WRT the license checks, I found out that there is an integration with > Salsa CI available to get on the spot lrc reports, just by doing > > include: > - > https://salsa.debian.org/debian/licenserecon/raw/main/debian/licenserecon.yml > > Maybe you can advertise this to more people already using Salsa CI and > DEP5 copyright files to reduce unnecessary round trips through mentors. > > Grüße, > Sven. > > Great one Sven. > > Regards > > Phil > > -- > > "I play the game for the game’s own sake" > > Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans > > -- > > Internet Relay Chat (IRC): kathenas > > Website: https://kathenas.org > > Instagram: https://instagram.com/kathenasorg/ > > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg > > --
Re: cli interface to tracker ?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077844 But I saw you later reply... later. Cheers - Le 3 Aoû 24, à 10:28, Étienne Mollier emoll...@debian.org a écrit : > PICCA Frederic-Emmanuel, on 2024-08-03: >> I tested it on one of my package >> >> --- >> >> rmadison >> >> orange-canvas-core | 0.1.31-3 | testing | source >> orange-canvas-core | 0.2.1-3 | buildd-unstable | source >> orange-canvas-core | 0.2.1-3 | unstable| source >> >> grep-excuses >> >> Excuse for orange-canvas-core >> >> • Migration status for orange-canvas-core (0.1.31-3 to 0.2.1-2): Waiting >> for >> test results or another package, or too young (no action required now - >> check >> later) >> • Issues preventing migration: >> □ Too young, only 1 of 2 days old >> □ Build-Depends(-Arch): orange-canvas-core python-requests-cache (not >> considered) >> □ Depends: orange-canvas-core python-requests-cache (not considered) >> • Additional info: >> □ Piuparts tested OK - >> https://piuparts.debian.org/sid/source/o/orange-canvas-core.html >> □ autopkgtest for orange-canvas-core/0.2.1-2: amd64: Pass, arm64: >> Pass, armel: >> Pass, armhf: Pass, i386: Pass, ppc64el: Pass, riscv64: Pass, s390x: >> Pass >> □ Waiting for reproducibility test results on amd64 - info ♻ >> □ Waiting for reproducibility test results on arm64 - info ♻ >> □ Waiting for reproducibility test results on armhf - info ♻ >> □ Reproducible on i386 - info ♻ >> □ Required age reduced by 3 days because of autopkgtest >> • Depends: orange-canvas-core python-requests-cache >> >> Excuses generated on: Sat Aug 3 07:05:35 2024 UTC >> >> Last upload >> === >> Uploads for orange-canvas-core: >> 0.1.31-3 to unstable: Roland Mas on Tue, 15 Aug 2023 >> 13:20:27 + >> >> --- >> >> >> It seem sto me thaht the Last upload is wrong. >> >> Is it a know issue ? > > Hmn, unclear, it seems it captured the last upload that made its > way to testing. I don't see anything related in the BTS yet, so > it might be worth documenting the issue in an bug entry. > > Have a nice day, :) > -- > .''`. Étienne Mollier > : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da > `. `' sent from /dev/pts/0, please excuse my verbosity >`-
Re: cli interface to tracker ?
I tested it on one of my package --- rmadison orange-canvas-core | 0.1.31-3 | testing | source orange-canvas-core | 0.2.1-3 | buildd-unstable | source orange-canvas-core | 0.2.1-3 | unstable| source grep-excuses Excuse for orange-canvas-core • Migration status for orange-canvas-core (0.1.31-3 to 0.2.1-2): Waiting for test results or another package, or too young (no action required now - check later) • Issues preventing migration: □ Too young, only 1 of 2 days old □ Build-Depends(-Arch): orange-canvas-core python-requests-cache (not considered) □ Depends: orange-canvas-core python-requests-cache (not considered) • Additional info: □ Piuparts tested OK - https://piuparts.debian.org/sid/source/o/orange-canvas-core.html □ autopkgtest for orange-canvas-core/0.2.1-2: amd64: Pass, arm64: Pass, armel: Pass, armhf: Pass, i386: Pass, ppc64el: Pass, riscv64: Pass, s390x: Pass □ Waiting for reproducibility test results on amd64 - info ♻ □ Waiting for reproducibility test results on arm64 - info ♻ □ Waiting for reproducibility test results on armhf - info ♻ □ Reproducible on i386 - info ♻ □ Required age reduced by 3 days because of autopkgtest • Depends: orange-canvas-core python-requests-cache Excuses generated on: Sat Aug 3 07:05:35 2024 UTC Last upload === Uploads for orange-canvas-core: 0.1.31-3 to unstable: Roland Mas on Tue, 15 Aug 2023 13:20:27 + --- It seem sto me thaht the Last upload is wrong. Is it a know issue ? Cheers Fred
Re: cli interface to tracker ?
exactly what I wanted. thanks a lot the Perl team :)
cli interface to tracker ?
Hello, I would like to know if we have a command line tool which could return an equivalent of the tracker status of a package from an unpackaqued source. sort of rmadison but with most/all of the tracker informations, build status per architectue, debci status / Salsa-ci status, lintian, bugs summarize etc... thanks Frederic
Re: Open "NMU diff for 64-bit time_t transition" bugs
for libccp4, just do it :). I personnaly do not have time now to do the upload. thanks a lot Fred - Le 10 Mai 24, à 7:29, Andrius Merkys mer...@debian.org a écrit : > Hello, > > I care for tree packages which still have open "NMU diff for 64-bit > time_t transition" bugs: libccp4, macromoleculebuilder and rdkit. All of > them have NMU diffs applied in experimental, but not in unstable yet. > What should I do about them - apply NMU diffs to unstable as well, or > wait for someone performing the time_t64 transition to do that? > > Best, > Andrius
Re: poblem with dh-autoreconf ?
> [...] > > The first time `debian/rules clean` runs, dh_autoreconf has not run, so > dh_autoreconf_clean has nothing to do and is silent. The second time, > after dh_autoreconf has run, you can see it doing stuff. ok, in that case it would be nice to display a message saying I do nothing :), in order to manifest its presence :) cheers Fred
Re: poblem with dh-autoreconf ?
- Le 19 Avr 24, à 15:11, Gianfranco Costamagna locutusofb...@debian.org a
écrit :
> Hello,
>
> Instead, I see it on the very same file :)
where ???, I am looking for dh_autoreconf_clean
cheers
>
> dpkg-buildpackage: info: host architecture amd64
> debian/rules clean
> dh clean --with=gir
> debian/rules override_dh_clean
> make[1]: Entering directory '/<>'
> rm -f Documentation/api/hkl-docs.sgml
> dh_clean
>rm -f debian/debhelper-build-stamp
>rm -rf debian/.debhelper/
>rm -f -- debian/ghkl.substvars debian/libhkl5.substvars
>debian/libhkl-dev.substvars debian/libhkl-doc.substvars
>debian/gir1.2-hkl-5.0.substvars debian/files
>rm -fr -- debian/ghkl/ debian/tmp/ debian/libhkl5/ debian/libhkl-dev/
>debian/libhkl-doc/ debian/gir1.2-hkl-5.0/
>find . \( \( \
>\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path .\*/.hg
>-o -path
>.\*/CVS -o -path .\*/.pc -o -path .\*/_darcs \) -prune -o -type f -a \
>\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
> -o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
> -o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
> -o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
>\) -exec rm -f {} + \) -o \
>\( -type d -a \( -name autom4te.cache -o -name __pycache__ \) -prune
>-exec rm
>-rf {} + \) \)
> make[1]: Leaving directory '/<>'
>
> G.
>
>
>
>
>
> Il venerdì 19 aprile 2024 alle ore 14:45:15 CEST, PICCA Frederic-Emmanuel
> ha scritto:
>
>
>
>
>
> Hello,
>
> In this build, I do not see a call to dh_autoreconf_clean
>
> https://buildd.debian.org/status/fetch.php?pkg=hkl&arch=amd64&ver=5.0.0.3434-1&stamp=1713518550&raw=0
>
> this package override_dh_clean like this
>
> override_dh_clean:
> rm -f Documentation/api/hkl-docs.sgml
> dh_clean
>
> so my question is: is it normal or a bug in dh-autoreconf ?
>
> thanks for your help
>
> Frederic
poblem with dh-autoreconf ?
Hello, In this build, I do not see a call to dh_autoreconf_clean https://buildd.debian.org/status/fetch.php?pkg=hkl&arch=amd64&ver=5.0.0.3434-1&stamp=1713518550&raw=0 this package override_dh_clean like this override_dh_clean: rm -f Documentation/api/hkl-docs.sgml dh_clean so my question is: is it normal or a bug in dh-autoreconf ? thanks for your help Frederic
autopkgtest and runner configuration
Hello, I have some failures depending on the architecture. If I remember correctly I was affected by an ipv6 / ipv4 vs ipv6 only configuration. so my question is simple: What should be the right snipset in order to display network information in the autopkgtest before running the test. Maybe there is somewhere this information already available about the runner configuration. thanks Frederic
Re: MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
Do yu know If we have a Debian bug, so I can refer to this bug in mine ? I prefer to not hide the problem and wait u til mesa is fixed (if this is not too long). Do you have a idea of when this issue should be integrated into Debian mesa ?
MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
Hello, I am affected by this error in the autopkgtest of silx[1] 487s autopkgtest [22:01:24]: test gui: [--- 489s MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER) 489s glx: failed to create drisw screen 489s failed to load driver: zink 493s autopkgtest [22:01:30]: test gui: ---] Someone know how to avoid this issue the test command is here[2]. thanks for your help [1] https://ci.debian.net/packages/s/silx/testing/amd64/43836118/#S12 [2] https://salsa.debian.org/science-team/silx/-/blob/master/debian/tests/gui?ref_type=heads
Re: dh_missing and arch/indep
I found this solution. execute_before_dh_missing-arch: # rm remaining files (workaround FTBFS...) rm -rf debian/tmp/usr/share execute_before_dh_missing-indep: # rm remaining files (workaround FTBFS...) rm -f debian/tmp/usr/bin/bornagain rm -rf debian/tmp/usr/lib rm -rf debian/tmp/usr/share/BornAgain/ rm -f debian/tmp/usr/share/man/man1/bornagain.1 thanks for your help Fred
Re: dh_missing and arch/indep
> I see you are currently using a bunch of "dh_install -p" > calls in your execute_before_dh_install target. When I update a package I prefer a lot to edit one file (rules) instead of opening multiples files... > > Maybe the next logical step would be to use debian/*.install > files. maybe... Fred
Re: dh_missing and arch/indep
> Hi. Have you tried splitting override_dh_auto_install into > override_dh_auto_install-arch > and override_dh_auto_install-indep? no effect at all..., it is especially difficult to deal with the nopython, nodoc, nocheck profiles if dh_missing does not take into account all the dh_install targets > (and maybe also with dh_installdocs) No, I need to rename the targets, so I can not use dh_installdocs Fred
dh_missing and arch/indep
Hello, I am working on the bornagain package
the arch all build failed with this error mesage
dh_missing: warning: usr/bin/bornagain exists in debian/tmp but is not
installed to anywhere
dh_missing: warning: usr/lib/python3/dist-packages/bornagain/__init__.py exists
in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3/dist-packages/bornagain/ba_fitmonitor.py
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3/dist-packages/bornagain/ba_plot.py exists
in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3/dist-packages/bornagain/sample_tools.py
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3/dist-packages/bornagain/std_samples.py
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3/dist-packages/bornagain/std_simulations.py
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3/dist-packages/libBornAgainBase.py exists
in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3/dist-packages/libBornAgainDevice.py exists
in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3/dist-packages/libBornAgainFit.py exists in
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3/dist-packages/libBornAgainParam.py exists
in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3/dist-packages/libBornAgainResample.py
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3/dist-packages/libBornAgainSample.py exists
in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3/dist-packages/libBornAgainSim.py exists in
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/bornagain/_libBornAgainBase.so
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/bornagain/_libBornAgainDevice.so
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/bornagain/_libBornAgainFit.so
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/bornagain/_libBornAgainGUI.so
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/bornagain/_libBornAgainParam.so
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/bornagain/_libBornAgainPyCore.so
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/x86_64-linux-gnu/bornagain/_libBornAgainResample.so exists in
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/bornagain/_libBornAgainSample.so
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/bornagain/_libBornAgainSim.so
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/BornAgain/Images/BornAgain.icns exists in
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/BornAgain/Images/BornAgain.ico exists in
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/BornAgain/Images/BornAgain_48x48.png exists in
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/BornAgain/Images/BornAgain_64x64.png exists in
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/share/man/man1/bornagain.1 exists in debian/tmp but is
not installed to anywhere
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed (with
files per package)
* dh_install: bornagain (0), bornagain-doc (39), python3-bornagain (0)
* dh_installdocs: bornagain (0), bornagain-doc (0), python3-bornagain
(0)
If the missing files are installed by another tool, please file a bug
against it.
When filing the report, if the tool is not part of debhelper itself,
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide
for debhelper (10.6.3+).
(in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.md.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary
when only a subset is built
If the omission is intentional or no other helper can take care of this
consider adding the
paths to debian/not-installed.
Remember to be careful with paths containing "x86_64-linux-gnu", where
you might need to
use a wildcard or (assuming compat 13+) e.g. ${DEB_HOST_MULTIARCH} in
debian/not-installed
to ensure it works on all architectures (see #961104).
make: *** [debian/rules:37: binary-indep] Error 25
dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit
status
Re: parsing of the .changes files
thanks a lot ! - Le 27 Nov 23, à 15:55, Daniel Gröber d...@darkboxed.org a écrit : > Hi Frederic, > > On Mon, Nov 27, 2023 at 02:30:28PM +0100, PICCA Frederic-Emmanuel wrote: >> Hello, I would like to know if there is command line tool usable from >> bash , which allows to list all the artefacts of a given .changes file. > > You can use the dcmd wrapper from devscripts: > >$ dcmd echo foo.changes > > it also supports getting various subsets, only debs (--debs), only tarballs > (--tar) and even just the package names (--package, -p). > > In fact just today I figured out how to download all the debs for a source > package (given a changes file): > >$ dcmd -p apt download foo.changes > > --Daniel
parsing of the .changes files
Hello, I would like to know if there is command line tool usable from bash , which allows to list all the artefacts of a given .changes file. thanks Frederic
RE:Package not migrating although status says 'Will attempt migration'
It seems to me that this is due to the python-defaults removal of python3.7 there is no more python3.7 python extensions but the test are still running. I think that this should be solved once python3-defaults will had migrated to testing and the autopkgtest was re-run for these packages.
RE:gbp import-orig --uscan: tar -t -a -f returns exit status 2
maybe this : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831870
RE:gbp import-orig --uscan: tar -t -a -f returns exit status 2
Maybe a hint. tar.gz generated via github, seems to cause troubles during the import process. just try to extract the tar.gz via tar and regenerate it from the extracted files. Maybe it should solve your problem.
piuparts error for vitables
Hello, I am preparing the new vitables, but I get this error message from piuparts. Preparing to unpack /tmp/vitables_3.0.0-1_all.deb ... Unpacking vitables (3.0.0-1) over (2.1-1) ... dpkg: warning: unable to delete old directory '/usr/share/vitables/vitables/htmldocs/_static': Directory not empty dpkg: warning: unable to delete old directory '/usr/share/vitables/vitables/htmldocs/_images': Directory not empty dpkg: warning: unable to delete old directory '/usr/share/vitables/vitables/htmldocs': Directory not empty Setting up vitables (3.0.0-1) ... But when I install and remove the current unsatble version, nothing is left on the computer. So I do not understand this message, when it tryes to upgrade vitables. Someone could have a hint ? Cheers Frederic
RE:uscan of the tango package, mk-origtargz
> Can you reproduce the problem with: > $ cat tango-9.3.3-rc2.tar | tar --delete > \ > tango-9.3.3-rc2-excluded.tar > ? here :~/Debian/tango$ cat tango-9.3.3-rc2.tar | tar --delete tango-9.3.3/lib/java/RestServer-1.14.jar > tango-9.3.3-rc2-excluded.tar tar: tango-9.3.3/lib/java/RestServer-1.14.jar : non trouvé dans l'archive tar: Arrêt avec code d'échec à cause des erreurs précédentes So it does not work this way
RE:uscan of the tango package, mk-origtargz
> Please confirm that > > LANG=C tar --delete $(tar tf tango-9.3.3-rc2.tar | grep "lib/java/R.*jar") > > < tango-9.3.3-rc2.tar > tango.tar > is inspired by `mk-origtargz`. not at all, I found this in #869087, which is a tar bug with --delete. It is not clear to me what is the cmd executed by mk-origtargz. It would be nice to have a debug mode for this. Cheers Fred > Karma bonus points for providing context. I just try to make gbp import-orig --uscan works with my package. cheers
RE:uscan of the tango package
I tryed to reproduce the issue like this LANG=C tar --delete $(tar tf tango-9.3.3-rc2.tar | grep "lib/java/R.*jar") < tango-9.3.3-rc2.tar > tango.tar tar: tango-9.3.3/lib/java/RestServer-1.14.jar: Not found in archive tar: Exiting with failure status due to previous errors Is it the right way to use --delete ?
RE:uscan of the tango package
> mk-origtargz just calls tar --delete < file > newfile and as you can > easily check this indeed gives the same error message. the listed files are the right files as extracted by tar from the upstream tar.gz, so this is an issue with tar ? Is it possible to display the exact tar command line generated by mk-origtargz ?
RE:uscan of the tango package
looking at the directroy, I find this drwxr-xr-x 11 picca picca 4096 août 20 17:23 tango-9.3.3 -rw-r--r-- 1 picca picca 282982400 août 25 08:37 tango_9.3.3~rc2+dfsg1.orig.tar -rw-r--r-- 1 picca picca 232776497 août 25 08:36 tango-9.3.3-rc2.tar.gz what is strange it that the extracted directory is tango-9.3.3 and not tango-9.3.3-rc2 like the upstream version. In fact, I just changed the uscan file in order to get an artefact from github version=4 opts="dversionmangle=s/\+dfsg\d*$//,\ repacksuffix=+dfsg1,\ uversionmangle=s/-(rc|a|b|c)/~$1/" \ https://github.com/tango-controls/TangoSourceDistribution/releases \ .*/@PACKAGE@@ANY_VERSION@\.tar\.gz debian uupdate Is there something wrong here ?
RE:uscan of the tango package
Hello > Found jar deletion instruction > at https://salsa.debian.org/science-team/tango/blob/master/debian/copyright#L5 yes I use Files-Excluded: lib/java/*.jar from DEP-5 (it was find until now) > I assume that upstream has stopped shipping jars in there .tar.gz > If so, then it is a good thing. not at all, the files are right there and the version number of each jars are the one of the upstream tar. so I do not understand the error. did you tryed to do gbp import-orig --uscan and look at the upstream tar.gz ?
uscan of the tango package
Hello, When I try to import the new tango[1] sources with gbp import-orig -uscan I get this error :~/Debian/tango/tango$ LANG=C gbp import-orig --uscan gbp:info: Launching uscan... tar: tango-9.3.3/lib/java/RestServer-1.14.jar: Not found in archive tar: tango-9.3.3/lib/java/Pogo-9.6.23.jar: Not found in archive tar: tango-9.3.3/lib/java/LogViewer-2.0.5.jar: Not found in archive tar: tango-9.3.3/lib/java/Jive-7.22.jar: Not found in archive tar: tango-9.3.3/lib/java/JTango-9.5.15.jar: Not found in archive tar: tango-9.3.3/lib/java/JSSHTerminal-1.16.jar: Not found in archive tar: tango-9.3.3/lib/java/DBBench-1.3.jar: Not found in archive tar: tango-9.3.3/lib/java/Astor-7.2.7.jar: Not found in archive tar: tango-9.3.3/lib/java/ATKWidget-9.3.6.jar: Not found in archive tar: tango-9.3.3/lib/java/ATKTuning-4.7.jar: Not found in archive tar: tango-9.3.3/lib/java/ATKPanel-5.8.jar: Not found in archive tar: tango-9.3.3/lib/java/ATKCore-9.3.6.jar: Not found in archive tar: Exiting with failure status due to previous errors uscan: error: tar --delete tango-9.3.3/lib/java/RestServer-1.14.jar tango-9.3.3/lib/java/Pogo-9.6.23.jar tango-9.3.3/lib/java/LogViewer-2.0.5.jar tango-9.3.3/lib/java/Jive-7.22.jar tango-9.3.3/lib/java/JTango-9.5.15.jar tango-9.3.3/lib/java/JSSHTerminal-1.16.jar tango-9.3.3/lib/java/DBBench-1.3.jar tango-9.3.3/lib/java/Astor-7.2.7.jar tango-9.3.3/lib/java/ATKWidget-9.3.6.jar tango-9.3.3/lib/java/ATKTuning-4.7.jar tango-9.3.3/lib/java/ATKPanel-5.8.jar tango-9.3.3/lib/java/ATKCore-9.3.6.jar subprocess returned exit status 2 gbp:error: Uscan failed - debug by running 'uscan --verbose' The copyright file exclude all the .jar files from the sources. So I do not undrrstand why tar complain about these missing files. Cheers Frederic [1] https://salsa.debian.org/science-team/tango.git
RE:private library whci is not that private
> Must? by must , I just express that the upsteam says in the documentation, that we can import bornagain from python. so it is a public module. > In that case I find it strange that the librray API is published as a > Python binding but not as underlying C lib. Yes the python module and the shared library are the same. this is strange but it is like this :(.
RE:private library whci is not that private
(First of all, is there a typo in "_libBorAgainFit.so"?) yes I forgot the n of born :) [...] > I expect that in the case of bornagain, libBornAgainFit.py looks for > _libBornAgainFit.so in the same directory, > /usr/lib/python3/dist-packages/bornagain/. yes and /usr/bin/bornagain also look for these library. this why I am asking, where to put a library wchih is sort of private... Cheers Frederic
private library whci is not that private
Hello,
I am preparing a package knows as bornagain.
this software provide a GUI application and a python modules generated via swig.
part of the code is shared between the binary and the modules.
the upstream put the library
_libBornAgainCore.so
_libBorAgainFit.so
_libbornagainGUI.so
under
/usr/lib/bornagain/...
Indeed when I just do an import in python3, I have an error
>>> import bornagain
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/bornagain/libBornAgainFit.py", line 14,
in swig_import_helper
return importlib.import_module(mname)
File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1006, in _gcd_import
File "", line 983, in _find_and_load
File "", line 965, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'bornagain._libBornAgainFit'
so my question is should just put theses libraries under
/usr/lib/{multiarch} in the bornagain binary, and make the python3-bornagain
module depends on bornagain.
or
Should I provide a dedicated binary package for these private libraries ? and
depends on it fot he binary and the modules.
Indeed they are meant to stay in the same source package.
thanks for your help
Frederic
RE:dh_dwz failure
with buster, I will check if this is the same on unstable. thanks Fred
dh_dwz failure
Hello, I am woriking on a new package called bornagain. I switched to compat level 12 and now I have this error message. I do not know how to fix this ? thanks for your help. Frederic dh_dwz install -d debian/bornagain/usr/lib/debug/.dwz/x86_64-linux-gnu dwz -q -mdebian/bornagain/usr/lib/debug/.dwz/x86_64-linux-gnu/bornagain.debug -M/usr/lib/debug/.dwz/x86_64-linux-gnu/bornagain.debug -- debian/bornagain/usr/bin/bornagain debian/bornagain/usr/lib/bornagain/_libBornAgainCore.so debian/bornagain/usr/lib/bornagain/_libBornAgainFit.so debian/bornagain/usr/lib/bornagain/_libBornAgainGUI.so dwz: debian/bornagain/usr/lib/bornagain/_libBornAgainGUI.so: Couldn't find DIE referenced by DW_OP_GNU_parameter_ref dh_dwz: dwz -q -mdebian/bornagain/usr/lib/debug/.dwz/x86_64-linux-gnu/bornagain.debug -M/usr/lib/debug/.dwz/x86_64-linux-gnu/bornagain.debug -- debian/bornagain/usr/bin/bornagain debian/bornagain/usr/lib/bornagain/_libBornAgainCore.so debian/bornagain/usr/lib/bornagain/_libBornAgainFit.so debian/bornagain/usr/lib/bornagain/_libBornAgainGUI.so returned exit code 1
Bug#921548: taurus-pyqtgraph is building fine in salsa
> I tried but I couldn't (probably because of not having enough permissions in > science-team group) > So I just invited you to be a maintainer of the project so that you can do the > transfer I do not know how to do this transfer. I am wondering if it is not necessary to open a tick to the salsa support[1] in order to move a repository. Can you open this ticket, then we will have the official answer of the salsa guyes :) > Are you sure? taurus is **not needed at all** for building taurus-pyqtgraph, > and this would add a lot of other dependencies for nothing to my opinion, all the dependencies should be added during the build, and setuptools, should generate automaticaly the dependencies. but this is just my point of view :). so it is up to you to decide :)) Cheers Fred [1] https://salsa.debian.org/salsa/support
Bug#921548: taurus-pyqtgraph is building fine in salsa
Hello carlos, > All tests are passed except for piuparts which fails due to unavailability of > the python3-taurus dependency (provided by taurus_4.5.0+dfsg-2 which is > already in salsa, but not yet uploaded) > What should I do now? I can not access the lintian artefacts [1] looking at the control file, it seems to me that you should have a bunch of lintian warning, like same short descriptions etc... > Should taurus-pyqtgraph be transferred from my personal area in salsa to > debian-science ? I thing that it would be great :). > Should we wait until taurus_4.5.0+dfsg-2 is uploaded? not necessarely, but maybe you should add a build dependency to python-taurus >= 4.5.0+dfsg-2, which is the first version with python3 modules. See you Fred [1] https://salsa.debian.org/cpascual-guest/taurus-pyqtgraph/-/jobs/138400
Bug#921548: taurus-pyqtgraph/0.1-1 -- extension for taurus
Hello carlos, If your package provide this pyhton module taurus.pyqtgraph, then the binary package should be named python-taurus.pyqtgraph. Cheers Frederic
help for a watch file
Hello, I would like to create a watch file for this package http://xds.mpimf-heidelberg.mpg.de/ as explained in page a new version is when the laast line of the page change. then we can download the binaries from here http://xds.mpimf-heidelberg.mpg.de/html_doc/downloading.html so do you think that it is possible to write a watch file for this ? thanks for your help Frederic
Bug#903904: RFS: wannier90/2.1.0 -- maximally localized Wannier functions
Hello Andrius, You can use sbuild or pbuilder, cowbuilder in order to build in a clean room. Cheers Frédéric
PermissionError: [Errno 13] Permission denied: '/sbuild-nonexistent'
Hello, I am preparing the new silx package and I get this error message during the build WARNING: autodoc: failed to import module 'silx.opencl.codec.byte_offset'; the following exception was raised: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/sphinx/ext/autodoc/importer.py", line 152, in import_module __import__(modname) File "/<>/silx-0.8.0+dfsg/.pybuild/cpython3_3.6_silx/build/silx/opencl/codec/byte_offset.py", line 58, in from pyopencl.algorithm import GenericScanKernel File "/usr/lib/python3/dist-packages/pyopencl/algorithm.py", line 37, in from pyopencl.scan import ScanTemplate File "/usr/lib/python3/dist-packages/pyopencl/scan.py", line 1137, in key_builder=_NumpyTypesKeyBuilder()) File "/usr/lib/python3/dist-packages/pytools/persistent_dict.py", line 566, in __init__ _PersistentDictBase.__init__(self, identifier, key_builder, container_dir) File "/usr/lib/python3/dist-packages/pytools/persistent_dict.py", line 463, in __init__ self._make_container_dir() File "/usr/lib/python3/dist-packages/pytools/persistent_dict.py", line 97, in wrapper return f(obj, *args, **kwargs) File "/usr/lib/python3/dist-packages/pytools/persistent_dict.py", line 505, in _make_container_dir _make_dir_recursively(self.container_dir) File "/usr/lib/python3/dist-packages/pytools/persistent_dict.py", line 72, in _make_dir_recursively os.makedirs(dir) File "/usr/lib/python3.6/os.py", line 210, in makedirs makedirs(head, mode, exist_ok) File "/usr/lib/python3.6/os.py", line 210, in makedirs makedirs(head, mode, exist_ok) File "/usr/lib/python3.6/os.py", line 210, in makedirs makedirs(head, mode, exist_ok) File "/usr/lib/python3.6/os.py", line 220, in makedirs mkdir(name, mode) PermissionError: [Errno 13] Permission denied: '/sbuild-nonexistent' so my question is. what is the right solutin in order to solve this ? export HOME=$CURDIR in the rules files (and voila) or this is a bug in pytools ? What I understant is that there is a persitent mechanism which is legitimate in nomal use. So what is the purpose of HOME pointing no-where during the build process. thanks for your help. Frédéric
Bug#872652: Problems building package
Hello guyes, look at here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873921 :((
Bug#852626: RFS: h5py/2.7.0~rc3-1 [RC]
to late ;) De : PICCA Frederic-Emmanuel Envoyé : mercredi 25 janvier 2017 19:10 À : Ghislain Vaillant; 852...@bugs.debian.org; sub...@bugs.debian.org Objet : Bug#852626: RFS: h5py/2.7.0~rc3-1 [RC] I am on it :) Cheers De : Ghislain Vaillant [ghisv...@gmail.com] Envoyé : mercredi 25 janvier 2017 19:00 À : sub...@bugs.debian.org Objet : Bug#852626: RFS: h5py/2.7.0~rc3-1 [RC] Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "h5py" * Package name: h5py Version : 2.7.0~rc3-1 Upstream Author : Andrew Colette * URL : http://www.h5py.org/ * License : BSD Section : python It builds those binary packages: python-h5py - general-purpose Python interface to hdf5 (Python 2) python-h5py-dbg - debug extension for h5py (Python 2) python-h5py-doc - h5py documentation python3-h5py - general-purpose Python interface to hdf5 (Python 3) python3-h5py-dbg - debug extension for h5py (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/h5py Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/h5py/h5py_2.7.0~rc3-1.dsc Or checkout the packaging repository at: https://anonscm.debian.org/git/debian-science/packages/h5py.git Changes since the last upload: * New upstream release (Closes: #851162) * Rebase patch queue - Drop 0002-Explicity-specify-endianess-of-expected-output-type.patch, applied upstream * Cherry pick upstream fix for builds on ppc64el - New patch 0002-Fix-arch-name-for-ppc64le.patch * Cherry-pick proposed fix for version numbers - New patch 0003-Fix-version_tuple-to-make-it-PEP440-compliant.patch Regards, Ghislain Vaillant
Bug#852626: RFS: h5py/2.7.0~rc3-1 [RC]
I am on it :) Cheers De : Ghislain Vaillant [ghisv...@gmail.com] Envoyé : mercredi 25 janvier 2017 19:00 À : sub...@bugs.debian.org Objet : Bug#852626: RFS: h5py/2.7.0~rc3-1 [RC] Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "h5py" * Package name: h5py Version : 2.7.0~rc3-1 Upstream Author : Andrew Colette * URL : http://www.h5py.org/ * License : BSD Section : python It builds those binary packages: python-h5py - general-purpose Python interface to hdf5 (Python 2) python-h5py-dbg - debug extension for h5py (Python 2) python-h5py-doc - h5py documentation python3-h5py - general-purpose Python interface to hdf5 (Python 3) python3-h5py-dbg - debug extension for h5py (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/h5py Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/h5py/h5py_2.7.0~rc3-1.dsc Or checkout the packaging repository at: https://anonscm.debian.org/git/debian-science/packages/h5py.git Changes since the last upload: * New upstream release (Closes: #851162) * Rebase patch queue - Drop 0002-Explicity-specify-endianess-of-expected-output-type.patch, applied upstream * Cherry pick upstream fix for builds on ppc64el - New patch 0002-Fix-arch-name-for-ppc64le.patch * Cherry-pick proposed fix for version numbers - New patch 0003-Fix-version_tuple-to-make-it-PEP440-compliant.patch Regards, Ghislain Vaillant
Bug#851696: RFS: python-qtpy/1.2.0-1
Hello Ghislain. do you know if this version is compatible with the reverse dependencies already in Debian ? python-qtpy Reverse Depends: python-spyder python-ginga python-qtawesome python-glue We are close from the freeze and I do not want to end up with a bunch of autorm packages due to this kind of upload. BUT if you can show that there is no problem I am ok to sponsorize this package. Cheers Fred
RE:watch file with multiple download url
> This has nothing to do with that you have multiple download URLs. > You are simply missing to replace - with ~ to sort RCs before final versions. > uversionmangle=s/-rc/~rc/ I will do this change and see if with two URL, uscan upload only one .tar.gz. I do not want to download two times the same pacakge from the two URL. thansk Fred
RE:watch file with multiple download url
> uscan works out of the box with both URLs as far as I can tell. you I uncomment everythongs and uscan check at bothe URL compares the version and at the end download the most recent package from the right URL ? ok, I uncomment both URL and now I get this version=4 opts=dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1 \ http://sf.net/tango-cs/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) debian uupdate opts=dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1 \ ftp://ftp.esrf.eu/pub/cs/tango/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) debian uupdate picca@mordor:~/Debian/tango/tango$ uscan --verbose uscan info: uscan (version 2.17.0) See uscan(1) for help uscan info: Scan watch files in . uscan info: Check debian/watch and debian/changelog in . uscan info: package="tango" version="9.2.5a+dfsg1-2" (as seen in debian/changelog) uscan info: package="tango" version="9.2.5a+dfsg1" (no epoch/revision) uscan info: Check debian/watch and debian/changelog in ./.git/refs/tags uscan info: ./debian/changelog sets package="tango" version="9.2.5a+dfsg1" uscan info: Process ./debian/watch (package=tango version=9.2.5a+dfsg1) uscan info: opts: dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1 uscan info: line: http://sf.net/tango-cs/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) debian uupdate uscan info: Parsing dversionmangle=s/\+dfsg\d*$// uscan info: Parsing repacksuffix=+dfsg1 uscan info: line: http://sf.net/tango-cs/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) debian uupdate uscan info: sf.net redirection to qa.debian.org/watch/sf.php uscan info: Last orig.tar.* tarball version (from debian/changelog): 9.2.5a+dfsg1 uscan info: Last orig.tar.* tarball version (dversionmangled): 9.2.5a uscan info: Requesting URL: https://qa.debian.org/watch/sf.php/tango-cs/ uscan info: Matching pattern: (?:(?:https://qa.debian.org)?\/watch\/sf\.php\/tango\-cs\/)?tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))(?:\?.*)? uscan info: Found the following matching hrefs on the web page (newest first): /watch/sf.php/tango-cs/tango-9.2.5a.tar.gz (9.2.5a) index=9.2.5a-1 /watch/sf.php/tango-cs/tango-9.2.5a.tar.gz (9.2.5a) index=9.2.5a-1 /watch/sf.php/tango-cs/tango-9.2.2.tar.gz (9.2.2) index=9.2.2-1 /watch/sf.php/tango-cs/tango-9.2.2.tar.gz (9.2.2) index=9.2.2-1 /watch/sf.php/tango-cs/tango-9.2.1.tar.gz (9.2.1) index=9.2.1-1 /watch/sf.php/tango-cs/tango-9.2.1.tar.gz (9.2.1) index=9.2.1-1 /watch/sf.php/tango-cs/tango-8.1.2c-patched.tar.gz (8.1.2c-patched) index=8.1.2c-patched-1 /watch/sf.php/tango-cs/tango-8.1.2c.tar.gz (8.1.2c) index=8.1.2c-1 /watch/sf.php/tango-cs/tango-8.0.5.tar.gz (8.0.5) index=8.0.5-1 uscan info: Matching target for downloadurlmangle: https://qa.debian.org/watch/sf.php/tango-cs/tango-9.2.5a.tar.gz uscan info: Upstream URL (downloadurlmangled): https://qa.debian.org/watch/sf.php/tango-cs/tango-9.2.5a.tar.gz uscan info: Newest upstream tarball version selected for download (uversionmangled): 9.2.5a uscan info: Download filename (filenamemangled): tango-9.2.5a.tar.gz uscan info: Newest version of tango on remote site is 9.2.5a, local version is 9.2.5a+dfsg1 (mangled local version is 9.2.5a) uscan info:=> Package is up to date for from https://qa.debian.org/watch/sf.php/tango-cs/tango-9.2.5a.tar.gz uscan info: opts: dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1 uscan info: line: ftp://ftp.esrf.eu/pub/cs/tango/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) debian uupdate uscan info: Parsing dversionmangle=s/\+dfsg\d*$// uscan info: Parsing repacksuffix=+dfsg1 uscan info: line: ftp://ftp.esrf.eu/pub/cs/tango/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) debian uupdate uscan warn: more than one main upstream tarballs listed. uscan info: Last orig.tar.* tarball version (from debian/changelog): 9.2.5a+dfsg1 uscan info: Last orig.tar.* tarball version (dversionmangled): 9.2.5a uscan info: Requesting URL: ftp://ftp.esrf.eu/pub/cs/tango/ uscan info: matching pattern (?:(?:ftp://ftp.esrf.eu)?\/pub\/cs\/tango\/)?tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) uscan info: Standard FTP listing. uscan info: Found the following matching files on the web page (newest first): tango-9.2.5-rc2.tar.gz (9.2.5-rc2) index=9.2.5-rc2-1 tango-9.2.5-rc1.tar.gz (9.2.5-rc1) index=9.2.5-rc1-1 tango-9.2.5a.tar.gz (9.2.5a) index=9.2.5a-1 tango-9.2.2.tar.gz (9.2.2) index=9.2.2-1 tango-9.1.0.tar.gz (9.1.0) index=9.1.0-1 tango-8.1.2c.tar.gz (8.1.2c) index=8.1.2c-1 tango-8.1.2b.tar.gz (8.1.2b) index=8.1.2b-1 tango-8.1.2a.tar.gz (8.1.2a) index=8.1.2a-1 tango-8.1.2.tar.gz (8.1.2) index=8.1.2-1 tango-8.0.5.tar.gz (8.0.5) index=8.0.5-1 tango-7.2.6-svn-17100-win-x64-msvc-2010.zip (7.2.6-svn-17100-win-x64-msvc-2010) index=7.2.6-svn-17100-win-x64-msvc-2010-0 tango-7.2.6a.tar.gz (7.2.6a) index=7.2.6a-1 tango-7.2.6.tar.gz (7.2.6) index=7.2.6-1 ta
RE:watch file with multiple download url
> Just uncommenting both seems to work for me, what issue do you get? No issues, I just wanted to know if I could have something with uscan which work out of the box with both URL's. So I would like something without the comment / uncomment trick. Cheers
watch file with multiple download url
Hello, for one of my package, I need to check at two location for new upstream release. the official release are usually located on sourceforge. but rc's are usually provided via their internal ftp. This is important for me to be able to prepare experimental upload of the rc's. so I would like to let uscan check the two location and download the newest from the right URL. Is it possible with uscan ? Here my current watch content where I comment and uncomment the URL. version=4 #opts=dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1 \ # http://sf.net/tango-cs/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) debian uupdate opts=dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1 \ ftp://ftp.esrf.eu/pub/cs/tango/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) debian uupdate Cheers Frederic
Bug#836350: RFS: flycheck/29-1 -- modern on-the-fly syntax checking for Emacs
Hello Sean,
in flycheck-doc, you put this
+Depends: www-browser, elpa-flycheck (= ${source:Version})
+Suggests: elpa-flycheck
why this dependency to elpa-flycheck ?
Bug#827273: RFS: python-vispy/0.4.0-1 [ITP]
done thanks a lot for this package ;) Fred De : Ghislain Vaillant [ghisv...@gmail.com] Envoyé : mardi 14 juin 2016 16:13 À : Debian Bug Tracking System Objet : Bug#827273: RFS: python-vispy/0.4.0-1 [ITP] Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-vispy" * Package name: python-vispy Version : 0.4.0-1 Upstream Author : VisPy Development Team * URL : http://vispy.org/ * License : BSD Section : python It builds those binary packages: python-vispy - interactive visualization in Python 2 python3-vispy - interactive visualization in Python 3 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-vispy Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-vispy/python-vispy_0.4.0-1.dsc Successful build logs on debomatic: [amd64] http://debomatic-amd64.debian.net/distribution#unstable/python-vispy/0.4.0-1/buildlog [i386] http://debomatic-i386.debian.net/distribution#unstable/python-vispy/0.4.0-1/buildlog Changes since the last upload: * Initial release. (Closes: #759820) Regards, Ghislain Vaillant
Bug#819514: RFS: emacs-buttercup/1.5-1 -- behaviour-driven testing for Emacs Lisp packages
uploaded Cheers Fred
Bug#816266: python-qtawesome/0.3.2-1 [ITP]
Hello Ghislain. I see only one problem you did not repackage the source with a +dfsg in order to remove the font files. If you let the files inside the source package you need to add the copyright information of these files. the best is to repackge using the Files-Excludes in the copyright files. Cheers once done, I will upload the package :) thanks Fred
Bug#816266: RE:Bug#816266: RFS: python-qtawesome/0.3.0-1 [ITP]
> I don't know enough about the python-qtawesome package to tell whether > python-xstatic-font-awesome is equivalent functionality-wise. Me too :) > I don't expect it to be an easy pitch to ask the Spyder team to > rethink their dependency chain just for the sake of re-usability. > Unless you had a different reason in mind? No thi si sjuste that I do not want duplication in the Debina archive. so maybe this qtaesome code is almost equivalent to the python-xstatic-font-aweosme. I need to investigate :) > Besides, what about the elusive fonts? I am on it And I think that it will be an easy task :) I already asked to become part of the pkg-fonts team today :) Cheers Fred > FYI, I have upgraded the packaging with the latest upstream version > (0.3.1). Shall I upload it to mentors? If you want :) Cheers Fred
Bug#816266: RE:Bug#816266: RFS: python-qtawesome/0.3.0-1 [ITP]
Hello Ghislain, I am wondering it this python-qtawesome package should not be replace by the already available one [1] python-xstatic-font-awesome. It would be great if we could convince the spyder upstream to use the python-xstatic system instead of embeding third party solutions. Cheers Fred https://pypi.python.org/pypi/XStatic-Font-Awesome
Bug#816266: RFS: python-qtawesome/0.3.0-1 [ITP]
> The Spyder Development Team is not upstream of this font actually. So I > don't think creating a font package from this source package is the > right solution, is it? No you are right I looked at the elusive content /tmp$ unzip elusive-icons-2.0.0.zip Archive: elusive-icons-2.0.0.zip creating: elusive-icons-2.0.0/ creating: elusive-icons-2.0.0/css/ inflating: elusive-icons-2.0.0/css/elusive-icons.css inflating: elusive-icons-2.0.0/css/elusive-icons.min.css creating: elusive-icons-2.0.0/fonts/ inflating: elusive-icons-2.0.0/fonts/elusiveicons-webfont.eot inflating: elusive-icons-2.0.0/fonts/elusiveicons-webfont.svg inflating: elusive-icons-2.0.0/fonts/elusiveicons-webfont.ttf inflating: elusive-icons-2.0.0/fonts/elusiveicons-webfont.woff creating: elusive-icons-2.0.0/less/ inflating: elusive-icons-2.0.0/less/animated.less inflating: elusive-icons-2.0.0/less/bordered-pulled.less inflating: elusive-icons-2.0.0/less/core.less inflating: elusive-icons-2.0.0/less/elusive-icons.less inflating: elusive-icons-2.0.0/less/fixed-width.less inflating: elusive-icons-2.0.0/less/icons.less inflating: elusive-icons-2.0.0/less/larger.less inflating: elusive-icons-2.0.0/less/list.less inflating: elusive-icons-2.0.0/less/mixins.less inflating: elusive-icons-2.0.0/less/path.less inflating: elusive-icons-2.0.0/less/rotated-flipped.less inflating: elusive-icons-2.0.0/less/stacked.less inflating: elusive-icons-2.0.0/less/variables.less creating: elusive-icons-2.0.0/scss/ inflating: elusive-icons-2.0.0/scss/_animated.scss inflating: elusive-icons-2.0.0/scss/_bordered-pulled.scss inflating: elusive-icons-2.0.0/scss/_core.scss inflating: elusive-icons-2.0.0/scss/_fixed-width.scss inflating: elusive-icons-2.0.0/scss/_icons.scss inflating: elusive-icons-2.0.0/scss/_larger.scss inflating: elusive-icons-2.0.0/scss/_list.scss inflating: elusive-icons-2.0.0/scss/_mixins.scss inflating: elusive-icons-2.0.0/scss/_path.scss inflating: elusive-icons-2.0.0/scss/_rotated-flipped.scss inflating: elusive-icons-2.0.0/scss/_stacked.scss inflating: elusive-icons-2.0.0/scss/_variables.scss inflating: elusive-icons-2.0.0/scss/elusive-icons.scss There is plenty of files I do not know what to do with, but I amnot part of the font team. > What I thought of doing was to keep the embedded copy of the font for > now and file a RFP for elusive-iconfont. I don't think I'll have time to > work on yet another source package at this time. I understand (welcome onboard ;). In that case just fill the RFP. The license is DFSG free :) . And just ping the font team in order to make them aware of our problem :). Cheers Fred
Bug#816266: RFS: python-qtawesome/0.3.0-1 [ITP]
Hello Ghislain >* The -common package contains 2 fonts, one of which is not available > for Debian (elusive-iconfont, SIL OFL 1.1). The other one (fontawesome) > is symlinked from its corresponding package. in that case can you create a real fonts package in order to be consistant with all other font packages Here the font policy[1] thanks Fred Ps; I will be on vacation starting now :) [1] https://wiki.debian.org/Fonts/PackagingPolicy
Bug#816099: RFS: python-qtpy/1.0~b1-1 [ITP]
uploaded. thanks a lot Fred
Bug#814660: RFS: propellor/2.15.4-1 -- property-based host configuration management in haskell
Done :) thanks for your work. Fred
Bug#813523: RFS: h5py/2.6.0-1
Uploaded thanks for your work Frederic
Bug#812491: RFS: h5py/2.5.0-2
I am on it :) De : Ghislain Vaillant [ghisv...@gmail.com] Envoyé : dimanche 24 janvier 2016 13:12 À : sub...@bugs.debian.org Objet : Bug#812491: RFS: h5py/2.5.0-2 Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "h5py" * Package name: h5py Version : 2.5.0-2 Upstream Author : Andrew Colette * URL : http://www.h5py.org/ * License : BSD Section : python It builds those binary packages: python-h5py - general-purpose Python interface to hdf5 (Python 2) python-h5py-dbg - debug extension for h5py (Python 2) python-h5py-doc - h5py documentation python3-h5py - general-purpose Python interface to hdf5 (Python 3) python3-h5py-dbg - debug extension for h5py (Python 3) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/h5py Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/h/h5py/h5py_2.5.0-2.dsc Changes since the last upload: * Add debug extension packages. Thanks to Picca Frederic-Emmanuel (Closes: #793789) * d/control: cme fix, wrap and sort, update descriptions. * Add examples to doc package. * Move documentation generation to arch-indep targets. * Add autopkgtest testsuite. * Simplify clean target. Best regards, Ghislain Vaillant
Bug#810870: RFS: propellor/2.15.3-1 -- property-based host configuration management in haskell
accepted :)
Bug#810870: RFS: propellor/2.15.3-1 -- property-based host configuration management in haskell
uploaded. thanks for your work :) De : Sean Whitton [spwhit...@spwhitton.name] Envoyé : mercredi 13 janvier 2016 04:19 À : sub...@bugs.debian.org Objet : Bug#810870: RFS: propellor/2.15.3-1 -- property-based host configuration management in haskell Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a new version of propellor. * Package name: propellor Version : 2.15.3-1 Upstream Author : Joey Hess * URL : https://propellor.branchable.com/ * License : BSD-2-clause Section : admin Changes since the last upload: * New upstream version. * Fix override of Lintian tag debian-watch-may-check-gpg-signature. Download with dget: dget -x http://mentors.debian.net/debian/pool/main/p/propellor/propellor_2.15.3-1.dsc Or build it with gbp: git clone https://git.spwhitton.name/propellor -b debian git checkout debian/2.15.3-1 git verify-tag debian/2.15.3-1 # if you have my key gbp buildpackage -sa Note to potential sponsor: due to an unorthadox changelog, you must explicitly pass -sa to either gbp or dpkg-buildpackage in order to include the *.orig.tar.xz file in your *.changes file. Thanks. Sean Whitton
Bug#809826: RFS: propellor/2.15.2-1 -- property-based host configuration management in haskell
done :) Thanks Fred De : Sean Whitton [spwhit...@spwhitton.name] Envoyé : lundi 4 janvier 2016 13:58 À : sub...@bugs.debian.org Objet : Bug#809826: RFS: propellor/2.15.2-1 -- property-based host configuration management in haskell Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a new version of propellor. Sorry for two RFSs in 24 hours: due to the holiday period I was slow packaging the previous version, and upstream made a new release right after 2.15.1-1 was uploaded to Debian. * Package name: propellor Version : 2.15.2-1 Upstream Author : Joey Hess * URL : https://propellor.branchable.com/ * License : BSD-2-clause Section : admin Changes since the last upload: * New upstream version. * Fix duplicate Section: in debian/control file. Download with dget: dget -x http://mentors.debian.net/debian/pool/main/p/propellor/propellor_2.15.2-1.dsc Or build it with gbp: git clone https://git.spwhitton.name/propellor -b debian git checkout debian/2.15.2-1 git verify-tag debian/2.15.2-1 # if you have my key gbp buildpackage -sa Note to potential sponsor: due to an unorthadox changelog, you must explicitly pass -sa to either gbp or dpkg-buildpackage in order to include the *.orig.tar.xz file in your *.changes file. Thanks. Sean Whitton
Bug#809747: RFS: propellor/2.15.1-1 -- property-based host configuration management in haskell
done. thanks for your contribution :)) De : Sean Whitton [spwhit...@spwhitton.name] Envoyé : dimanche 3 janvier 2016 18:28 À : sub...@bugs.debian.org Objet : Bug#809747: RFS: propellor/2.15.1-1 -- property-based host configuration management in haskell Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a new version of propellor. * Package name: propellor Version : 2.15.1-1 Upstream Author : Joey Hess * URL : https://propellor.branchable.com/ * License : BSD-2-clause Section : admin Changes since the last upload: * New upstream version. * Add watch file. * Fix specification of packaging branch in Vcs-Git: variable. * Silence xargs during package build when hothasktags is not installed. Patch accepted upstream for next upstream release. Download with dget: dget -x http://mentors.debian.net/debian/pool/main/p/propellor/propellor_2.15.1-1.dsc Or build it with gbp: git clone https://git.spwhitton.name/propellor -b debian git checkout debian/2.15.1-1 git verify-tag debian/2.15.1-1 # if you have my key gbp buildpackage -sa Note to potential sponsor: due to an unorthadox changelog, you must explicitly pass -sa to either gbp or dpkg-buildpackage in order to include the *.orig.tar.xz file in your *.changes file. Thanks. Sean Whitton
RE:python-fabio circular dependency
> https://wiki.debian.org/PackageTransition I know about this wiki page (very valuable), but my case is not described in here. Cheers Fred
python-fabio circular dependency
Hello, I would like to solve a circular dependency with the python-fabio package before (N) binaries python-fabio after (N+1) binaries fabio_viewer python-fabio python-fabio-dbg python3-fabio python3-fabio-dbg for this new version, I move the /usr/bin files from python-fabio (N) into fabio_viewer (N+1). So I did a split (script + python-module) of python-fabio (N) in two separate binary packages (fabio_viewer + python-fabio N+1) Here is my problem I want during the upgrade (python-fabio N) -> python-fabio N+1 to install also the fabio_viewer. this way the user has the same amount of services on it system. (python-fabio n contains also the scripts) so I added a DEpends on fabio_viewer to pyton-fabio (n+1) and now I have fabio_viewer -> python-fabio -> fabio_viewer and I got a bug report :) So what is the best way to solve my problem. upgrade with same functionnality but without this circulardependency. Indeed fabio_viewer MUST depends on python-fabio. Thanks for your help Frederic
Bug#799886: Leaving it for Frederic as well? (RFS: arrayfire/3.1.1+dfsg1-2)
Hello, I am on it. Cheers
Bug#799655: RFS: arrayfire/3.1.1+dfsg1-1
It is in the pipe :) Cheers
Bug#799655: RFS: arrayfire/3.1.1+dfsg1-1
I will take care of this. Cheers
Bug#799595: RFS: clblas/2.6-3
done :) Thanks Fred
RE:debian queue demon keeps spawning emails for clblas/2.6-2 upload
Ok, I used dcut dcut -k 4696e015 rm clblas_2.6-2_amd64.changes in order to remove the offending file Cheers Fred
Bug#796079: RFS: clfft/2.6.1-2
I'll take care of this one then I need to leave so if you come with clblas after do not hesitate to ask Andreas. Cheers Fred De : Ghislain Vaillant [ghisv...@gmail.com] Envoyé : mercredi 19 août 2015 11:15 À : sub...@bugs.debian.org Objet : Bug#796079: RFS: clfft/2.6.1-2 Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "clfft" * Package name: clfft Version : 2.6.1-2 Upstream Author : Advanced Micro Devices, Inc. * URL : https://github.com/clMathLibraries/clFFT * License : Apache version 2 Section : science It builds those binary packages: libclfft-bin - OpenCL FFT library (executables) libclfft-dev - OpenCL FFT library (development files) libclfft-doc - OpenCL FFT library (documentation) libclfft2 - OpenCL FFT library (shared library) libclfft2-dbg - OpenCL FFT library (debugging symbols) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/clfft Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/clfft/clfft_2.6.1-2.dsc Changes since the last upload: * d/*-dev.install: use more generic expressions * d/rules: use stricter hardening * d/p: add patch to use Boost dynamic libraries * d/p: add patch fixing missing inclusion of stdlib Best regards, Ghislain Vaillant
Bug#796043: RFS: clblas/2.6-2
done.
De : Ghislain Vaillant [ghisv...@gmail.com]
Envoyé : mardi 18 août 2015 21:44
À : sub...@bugs.debian.org
Objet : Bug#796043: RFS: clblas/2.6-2
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "clblas"
* Package name: clblas
Version : 2.6-2
Upstream Author : Advanced Micro Devices, Inc.
* URL : https://github.com/clMathLibraries/clBLAS
* License : Apache version 2
Section : science
It builds those binary packages:
libclblas-bin - OpenCL BLAS library (executables)
libclblas-dev - OpenCL BLAS library (development files)
libclblas-doc - OpenCL BLAS library (documentation)
libclblas2 - OpenCL BLAS library (shared library)
libclblas2-dbg - OpenCL BLAS library (debugging symbols)
To access further information about this package, please visit the
following URL:
http://mentors.debian.net/package/clblas
Alternatively, one can download the package with dget using this command:
dget -x http://mentors.debian.net/debian/pool/main/c/clblas/clblas_2.6-2.dsc
Changes since the last upload:
* d/control: remove ${shlibs:Depends} substitution from debug package
* d/*-dev.install: use more generic expressions
* d/rules: use stricter hardening
* d/p: add patch to use Boost dynamic libraries
* d/p: add patch fixing missing inclusion of stdlib
Best regards,
Ghislain Vaillant
Bug#796041: RFS: clfft/2.6.1-1
Hello Ghislain,
I get this error when building with sbuild (unstable)
[ 62%] Building CXX object library/CMakeFiles/clFFT.dir/fft_binary_lookup.cpp.o
cd /«PKGBUILDDIR»/obj-i586-linux-gnu/library && /usr/bin/c++ -DCLFFT_EXPORTS
-DclFFT_EXPORTS -pthread -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2 -O2 -g -DNDEBUG -fPIC
-I/«PKGBUILDDIR»/obj-i586-linux-gnu/include
-I/«PKGBUILDDIR»/src/library/../include-o
CMakeFiles/clFFT.dir/fft_binary_lookup.cpp.o -c
/«PKGBUILDDIR»/src/library/fft_binary_lookup.cpp
/«PKGBUILDDIR»/src/library/fft_binary_lookup.cpp: In function 'void
clfftInitBinaryCache()':
/«PKGBUILDDIR»/src/library/fft_binary_lookup.cpp:66:50: error: 'getenv' was not
declared in this scope
const char * path = getenv("CLFFT_CACHE_PATH");
^
make[4]: *** [library/CMakeFiles/clFFT.dir/fft_binary_lookup.cpp.o] Error 1
library/CMakeFiles/clFFT.dir/build.make:264: recipe for target
'library/CMakeFiles/clFFT.dir/fft_binary_lookup.cpp.o' failed
make[4]: Leaving directory '/«PKGBUILDDIR»/obj-i586-linux-gnu'
make[3]: *** [library/CMakeFiles/clFFT.dir/all] Error 2
Cheers
Bug#794086: RFS: clblas/2.4-3
idem 2.6 is out and can you fix most of the lintian warnings :) Cheers. Fred -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2f42...@sun-dag3.synchrotron-soleil.fr
Bug#794089: RFS: clfft/2.4-4
Hello, sorry but I am in VAC until mid August. can you find another sponsor or wait until I come back from holidays ? the 2.6 version is also available :p Cheers Fred -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2f41...@sun-dag3.synchrotron-soleil.fr
split A -> A + B
Hello,
I am working on a python package fabio, for the new verison I will add the
python3 pacakge and a pacakge which will contain only the scripts.
so
beffor
python-fabio (with the scripts moved into fabio-viewer)
python-fabio-dbg
python-fabio-doc
after
fabio-viewer
python-fabio
python-fabio-dbg
python3-fabio
python3-fabio-dbg
python-fabio-doc
Now I would like to know how to write the Breaks and Replaces.
I tryed with this but I got an error with piuparts.
For the upgrade I am also wondering if the python-fabio should not depends on
fabio-viewer to propose the same functionnality thant the previous python-fabio
pacakge.
Package: fabio-viewer
Architecture: all
Section: python
Depends: ${misc:Depends},
${python:Depends},
python-fabio (>= ${source:Version})
Breaks: python-fabio (<< 0.2.2+dfsg-2)
Replaces: python-fabio (<< 0.2.2+dfsg-2)
Package: python-fabio
Architecture: any
Section: python
Depends: ${misc:Depends},
${python:Depends},
${shlibs:Depends},
pymca,
python-six
Recommends: python-imaging,
python-lxml,
python-matplotlib
Suggests: pyfai,
python-fabio-doc
Selecting previously unselected package fabio-viewer.
dpkg: regarding .../fabio-viewer_0.2.2+dfsg-2_all.deb containing fabio-viewer:
fabio-viewer breaks python-fabio (<< 0.2.2+dfsg-2)
python-fabio (version 0.2.2+dfsg-1) is present and installed.
dpkg: error processing archive tmp/fabio-viewer_0.2.2+dfsg-2_all.deb
(--install):
installing fabio-viewer would break python-fabio, and
deconfiguration is not permitted (--auto-deconfigure might help)
thanks for your help
Frederic
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b217a...@sun-dag3.synchrotron-soleil.fr
Bug#793078: RFS: arrayfire/3.0.2-1
done De : Ghislain Vaillant [ghisv...@gmail.com] Envoyé : mardi 21 juillet 2015 08:54 À : sub...@bugs.debian.org Objet : Bug#793078: RFS: arrayfire/3.0.2-1 Package: sponsorship-requests Severity: normal Dear Mentors, I am looking for a sponsor for the following source package: * Package name: arrayfire Version : 3.0.2-1 Upstream Author : ArrayFire Development Group * URL : http://arrayfire.com/ * License : BSD-3-Clause Programming Lang: C++ Description : High performance library for parallel computing It builds the following binary packages: libarrayfire-cpu3 -- Shared library (CPU backend) libarrayfire-cpu3-dbg -- Debug symbols for CPU backend shlib libarrayfire-cpu-dev -- Development files for CPU backend shlib libarrayfire-doc -- Doxygen documentation To access further information about this package, please visit the following URL: http://mentors.debian.net/package/arrayfire Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/arrayfire/arrayfire_3.0.2-1.dsc Changes since the last upload: * New upstream release. * Drop fix-unneeded-opengl-dep.patch, applied upstream. * d/rules: install upstream changelog. Best regards, Ghislain -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55adecb9.9060...@gmail.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2179...@sun-dag3.synchrotron-soleil.fr
RE:rules file and build directory
> Let me give you an example here. Let us assume we have a special target > 'my_super_test' in the upstream Makefile which should be called by > dh_auto_test and let us further assume we do not want or cannot change > the upstream Makefile. > In this case I would do something like this > override_du_auto_test: >cd && make my_super_test It seems to me that this is a problem of integrating a thirdparty makefile into cmake. Is it possible to call third-party makefile target from cmake ? Cheers Fred -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2177...@sun-dag3.synchrotron-soleil.fr
RE:rules file and build directory
>> In order to run the tests in my package I first have to build them (they >> are not built by the 'all' target). This requires a non-standard target >> (build-tests) of the upstream Makefile to be invoked. >> I have two solutions how I can deal with this: >> 1.) I change to the build directory (the directory where the rules >> file invokes the upstream build system) and run 'make build-tests' >> from within rules. >> 2.) Find a simple way how to call a custom target of the upstream >> build system from within 'rules'. In fact I just checked in the debhelper. the dh_auto_test target call the first running test , check target so if you add a make chech target, it will be executer by dh Now if you want to customize the target just override_du_auto_test: Cheers Fred -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2177...@sun-dag3.synchrotron-soleil.fr
RE:rules file and build directory
Hello Eugen > In order to run the tests in my package I first have to build them (they > are not built by the 'all' target). This requires a non-standard target > (build-tests) of the upstream Makefile to be invoked. > I have two solutions how I can deal with this: > 1.) I change to the build directory (the directory where the rules > file invokes the upstream build system) and run 'make build-tests' > from within rules. > 2.) Find a simple way how to call a custom target of the upstream > build system from within 'rules'. Why not emulating the make check target[1] [1] http://www.cmake.org/Wiki/CMakeEmulateMakeCheck Then it should be easy to call make check during the build Cheers Fred -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2177...@sun-dag3.synchrotron-soleil.fr
Bug#792028: RFS: clfft/2.4-3
Hello Gislain, I will upload the package ;) During the build I saw this -- Could NOT find FFTW (missing: FFTW_LIBRARIES FFTW_INCLUDE_DIRS) -- FindFFTW looked for single precision libraries named: fftw3f or libfftw3f-3 -- FindFFTW looked for double precision libraries named: fftw3 or libfftw3-3 -- Could NOT find GTest (missing: GTEST_LIBRARY GTEST_INCLUDE_DIR GTEST_MAIN_LIBRARY) GoogleTest unit testing will NOT be built Is it possible to add this fftw part to the build ? Cheers Fred -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2175...@sun-dag3.synchrotron-soleil.fr
Bug#792028: RFS: clfft/2.4-3
Done -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2175...@sun-dag3.synchrotron-soleil.fr
Bug#792028: RFS: clfft/2.4-3
> FFTW is required for the test suite to run. However, their GTest >detection is flawed which makes the test suite not runnable. To fix this >would require heavy patching. > I'>d rather talk with upstream first and ask them to provide more freedom > with regards to GTest handling. > Does it sound ok to you ? Yes it would be great to activate the test suite during the build ANd for autopkgtest Cheers Fred -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2175...@sun-dag3.synchrotron-soleil.fr
RE:Sbuild doesn't pick experimental over unstable
> --build-dep-resolver=aptitude Is it possible to configure this per chroot in order to avoir passing this command line each time ? Thanks Frédéric -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2175...@sun-dag3.synchrotron-soleil.fr
Bug#790895: RFS: h5py/2.5.0-1
uploaded Fred -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2172...@sun-dag3.synchrotron-soleil.fr
Bug#790771: why closed ?
look at the title ;) RFS for the 2.4-1 version :) no worry upload to mentors en I will take care of the sponsoring. Cheers Fred > #790771: RFS: clblas/2.4-1 -- OpenCL BLAS library -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2172...@sun-dag3.synchrotron-soleil.fr
Bug#790771: RFS: clblas/2.4-2 -- OpenCL BLAS library
Hello Ghislain, please upload to mentors then I will upload :) wrong url in the next message ;) De : Ghislain Vaillant [ghisv...@gmail.com] Envoyé : mercredi 1 juillet 2015 18:09 À : sub...@bugs.debian.org Objet : Bug#790771: RFS: clblas/2.4-2 -- OpenCL BLAS library Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "clblas" * Package name: clblas Version : 2.4-2 Upstream Author : Advanced Micro Devices, Inc. * URL : https://github.com/clMathLibraries/clBLAS * License : Apache version 2 Section : science It builds those binary packages: libclblas-bin - OpenCL BLAS library (executables) libclblas-dev - OpenCL BLAS library (development files) libclblas-doc - OpenCL BLAS library (documentation) libclblas2 - OpenCL BLAS library (shared library) libclblas2-dbg - OpenCL BLAS library (debugging symbols) This package can be checked out at: https://anonscm.debian.org/cgit/debian-science/packages/h5py.git This package can be built with: gbp buildpackage --git-debian-branch=debian/sid \ --git-upstream-tag=v2.4 \ --git-no-pristine-tar Changes since the last upload: * Make package build reproducible. (Closes: #790122) - Thanks to Maria Valentina Marin who provided the fix. Best regards, Ghislain -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/559410ac.2000...@gmail.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2172...@sun-dag3.synchrotron-soleil.fr
Bug#788217: RFS: clfft/2.4-1 [ITP Bug#783084] -- OpenCL FFT library
Hello, upload but I have a few remarks. here the rules file > # see EXAMPLES in dpkg-buildflags(1) and read /usr/share/dpkg/* > DPKG_EXPORT_BUILDFLAGS = 1 > include /usr/share/dpkg/default.mk why is it necessary to export the symbols since you are using compat level 9 ? > %: >dh $@ --sourcedirectory=src \ >--buildsystem=cmake \ >--parallel \ >--dbg-package=libclblas2-dbg >override_dh_auto_configure: >dh_auto_configure -- \ >-DBUILD_RUNTIME=ON \ >-DBUILD_TEST=OFF \ >-DBUILD_PERFORMANCE=OFF \ >-DBUILD_SAMPLE=OFF \ >-DBUILD_CLIENT=ON \ >-DBUILD_KTEST=OFF \ >-DBUILD_SHARED_LIBS=ON >echo "I: Generating Doxygen documentation" >cd doc/ && doxygen clBLAS.doxy && rm html/jquery.js why do you build the documentation during the configuration why not puting the documentation generation under an: override_dh_auto_build ? > override_dh_auto_clean: >dh_auto_clean >[ ! -f doc/doxygen_sqlite3.db ] || $(RM) doc/doxygen_sqlite3.db >[ ! -d doc/html ] || $(RM) -rf doc/html why no -$(RM) -f doc/doxygen_sqlite3.db -$(RM) -rf doc/html Cheers Fred -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b216d...@sun-dag3.synchrotron-soleil.fr
Bug#788217: RFS: clfft/2.4-1 [ITP Bug#783084] -- OpenCL FFT library
> I have updated both clBLAS and clFFT with a patch that suppresses the > offending flags. > You can build the most recent version of the package from the d-science > repositories with: > gbp buildpackage --git-upstream-tag=v2.4 --git-upstream-branch=master \ >--git-debian-branch=debian/sid --git-no-pristine-tar Hello Ghislain, I personnaly prefer to work from mentors when doing sponsoring :) Is it possible for you to upload into mentors both packages. Thanks Fred -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b216d...@sun-dag3.synchrotron-soleil.fr
Bug#788217: RFS: clfft/2.4-1 [ITP Bug#783084] -- OpenCL FFT library
> I checked it out and both clBLAS and clFFT actually suffer from the same > problem. It seems upstream is rolling its own > "multiarch" detection / selection mechanism. The detection is based on the > result of CMAKE_SIZEOF_VOID_P, and the > selection can be overriden via a cmake option. obviously it does not work properly because it end up with a -m64 on my 32 bit system. Maybe this is the real problem. > One option would be to just patch the build system and comment out the part > where the offending build flag is set. I > doubt however that upstream would be happy with this solution, since they > must have setup their CI infrastructure > around this option I presume. > I am wondering what would be a good solution to suggest upstream about. I > guess it is just more convenient for them to > let the build system handle mutliarch builds, including setting the > appropriate build flags and arch-dependent install paths > instead of setting a proper build environment up like dh does. I do not know what is the recommended way in cmake for this kind of "multi-arch" things. maybe someone with more cmake experience can tell how to deal with this kind of problem. Cheers Fred -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b216c...@sun-dag3.synchrotron-soleil.fr
Bug#788217: RFS: clfft/2.4-1 [ITP Bug#783084] -- OpenCL FFT library
2015-06-17 10:25 GMT+01:00 PICCA Frederic-Emmanuel mailto:frederic-emmanuel.pi...@synchrotron-soleil.fr>>: Hello Ghislain, It seems to me thaht I already saw this problem with Jerome... I built my package on a 32bit system. > cd /«PKGBUILDDIR»/obj-i586-linux-gnu/library && /usr/bin/c++ > -DCLFFT_EXPORTS -DclFFT_EXPORTS -m64 -pthread -g -O2 -fstack-protector-strong > -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC > -I/«PKGBUILDDIR»/obj-i586-linux-gnu/include -I/«PKGBUILDDIR»> > /src/library/../include-o CMakeFiles/clFFT.dir/transform.cpp.o -c > /«PKGBUILDDIR»/src/library/transform.cpp the problem is this -m64 option. > Is there more to do about it on my end ? I think that the upstream build system should be fixed and not add the -m64 flag at all. Maybe you should discuss with the upstream and ask why they add this flag ? > A 10 year-old computer running wheezy, that can still last a while ;-) yes as much as possible to save the earth ;), > Thanks again for checking out all these clMath packages. with great pleasure :) Fred -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b216c...@sun-dag3.synchrotron-soleil.fr
