Bug#882730: RFS: wolfssl/3.12.2+dfsg-1 [requires NEW] -- wolfSSL encryption library
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "wolfssl": * Package name: wolfssl Version : 3.12.2+dfsg-1 Upstream Author : wolfSSL Inc. * URL : www.wolfssl.com * License : various Section : libs It builds these binary packages: libwolfssl14 - wolfSSL encryption library libwolfssl-dev - Development files for the wolfSSL encryption library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wolfssl Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wolfssl/ wolfssl_3.12.2+dfsg-1.dsc More information about wolfSSL can be obtained from https://www.wolfssl.com. Changes since the last upload: * New upstream release * New major number 14 * Updated symbols file * Updated watch file * Replaced upstream signing key with 0xEBC80E415CA29677 * Updated Standard-Versions: to 4.1.1 Best regards, Felix Lechner
Re: How to determine the filename for dlopen()
Hi! On Mon, 2017-11-13 at 13:23:01 +0100, Ferenc Wágner wrote: > I'm packaging a program which wants to dlopen() some library. It finds > this library via pkg-config (PKG_CHECK_MODULES). How to best determine > the filename to use in the dlopen() call? It should work cross-distro, > for cross-compilation and whatnot. Is it always safe to use the SONAME > as the filename? I'm currently considering something like > > ld -shared -o dummy.so $(my_LIBS) > objdump -p dummy.so | fgrep NEEDED > > coded up properly for Automake. I'd be grateful for any insight. IMO dlopen()ing an external library that is not part of the same project is a practice that should be very strongly discouraged, if not completely abolished. Please see this very nice mail from Simon McVittie [S], my reply [G], and Florian Weimer's [F], for several of the reasons why. [S] https://lists.debian.org/debian-devel/2017/03/msg00164.html [G] https://lists.debian.org/debian-devel/2017/03/msg00343.html [F] https://lists.debian.org/debian-devel/2017/03/msg00346.html Thanks, Guillem
Bug#882565: marked as done (RFS: lr/1.2-1 -- list files, recursively)
Your message dated Sat, 25 Nov 2017 23:50:56 +0100 with message-id <20171125225056.3pqihjopz25tq...@angband.pl> and subject line Re: Bug#882565: RFS: lr/1.2-1 -- list files, recursively has caused the Debian Bug report #882565, regarding RFS: lr/1.2-1 -- list files, recursively to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 882565: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882565 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear mentors, I am looking for a sponsor for my package "lr" * Package name: lr Version : 1.2-1 Upstream Author : Leah Neukirchen * URL : https://github.com/chneukirchen/lr * License : MIT Section : utils It builds those binary packages: lr- list files, recursively To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lr Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lr/lr_1.2-1.dsc Changes since the last upload: * New upstream version (2017-11-17) * Performance improvements * `-U` now supports default width * New features * -B option for breadth-first search * New ternary `?:` operator * New `skip` action Regards, nicoo - -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloXdnwZHG5pY29sYXNA YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z4+y2D/0ROpPrT/R2PX9P0vG7WKPy xhqF9PIniwUJdFBRLe7TwW/5UM3pHuj0cyPgNgmxVXWZDpqNdEUOYsOP+XDE3uh0 kC3D+qpkx9cof8ZtX9LmUvOb509AS1oqxi8+vXlSmb+M6KkyX+OUZVr1tFF7Wzb1 x5vUXiIiDQF6rsf7q5YyaEGDcSDFkIszZxqwQNC/iFSTPTd2WHEWqtw03hdKP1UH WFOfyhha6LZV8nFRiLuE1nw2KpQQg2Um0JoLWBu9/xi3pCnvyAUS5MU8bq77qNoA u48q0psmUaYqH75Sv5k/q632+Q+445er9TEHKyjHHOZrHcNgK6mYJzkT4mpFuSKu TnfXqrNd4ZnwmpGOhVP7QOaKOlkWcMO8alZ3zq+J7oIyYQzFAgzk9c9sT5jQiISq pyJYcblI90sv3iM8PDLlyCG/sXaEqyNn3ZHYbRejYp1p4Rq1GzX/ob7RyHYBQpdN npsiU6MLHNOYCHbi44Y6+inPP4G3O2NxIh9m10xAO+RAlqTg5Jhg84NEVIBN1nPE zoMzHJa5q9LoJyNpRQrGRN6otVCsNFHogLMKCV+l2YNa7qD0+fGMl28KTrfGmE57 5BPTRt0M2PoVITJJZ9BeZvjzj8sDnqDheQ5t4z+yOk7gCL8LlEv7+u/v+g0wBCv+ TDVqaWm++zB/ZEXvJgEysQ== =ycIt -END PGP SIGNATURE- --- End Message --- --- Begin Message --- On Fri, Nov 24, 2017 at 02:31:43AM +0100, Nicolas Braud-Santoni wrote: > * Package name: lr > Version : 1.2-1 > Changes since the last upload: > > * New upstream version (2017-11-17) > * Performance improvements > * `-U` now supports default width > * New features > * -B option for breadth-first search > * New ternary `?:` operator > * New `skip` action ✓ -- ⢀⣴⠾⠻⢶⣦⠀ Mozilla's Hippocritical Oath: "Keep trackers off your trail" ⣾⠁⢰⠒⠀⣿⡁ blah blah evading "tracking technology" blah blah ⢿⡄⠘⠷⠚⠋⠀ "https://click.e.mozilla.org/?qs=e7bb0dcf14b1013fca3820..."; ⠈⠳⣄ (same for all links)--- End Message ---
Re: C++ help needed for centrifuge
Andreas Tille wrote: > Hi, > > I started packaging centrifuge[1] and hit a build error which > is most probably caused by gcc-7 incompatibility: > > ... > In file included from centrifuge_build.cpp:27:0: > bt2_idx.h: In static member function 'static std::pair*, > Ebwt*> Ebwt::fromStrings(const > EList >&, bool, int, int, bool, int32_t, > int32_t, int32_t, const string&, bool, index_t, index_t, index_t, int, > uint32_t, bool, bool, bool)': > bt2_idx.h:1053:3: warning: 'template class std::auto_ptr' is > deprecated [-Wdeprecated-declarations] This is only a warning, so you can ignore it. If you are feeling ambitious, the recommended fix is to replace all auto_ptr's with unique_ptr's and copies with moves(). Apparently, clang-modernize can do this automatically. Walter Landry
Re: C++ help needed for centrifuge
Le 25/11/2017 à 21:56, Andreas Tille a écrit : > Hi, > > I started packaging centrifuge[1] and hit a build error which > is most probably caused by gcc-7 incompatibility: > > ... > In file included from centrifuge_build.cpp:27:0: > bt2_idx.h: In static member function 'static std::pair*, > Ebwt*> Ebwt::fromStrings(const > EList >&, bool, int, int, bool, int32_t, > int32_t, int32_t, const string&, bool, index_t, index_t, index_t, int, > uint32_t, bool, bool, bool)': > bt2_idx.h:1053:3: warning: 'template class std::auto_ptr' is > deprecated [-Wdeprecated-declarations] >auto_ptr ss(new stringstream()); >^~~~ > In file included from /usr/include/c++/7/memory:80:0, > from bt2_idx.h:28, > from centrifuge_build.cpp:27: > /usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here >template class auto_ptr; > ^~~~ > In file included from centrifuge_build.cpp:27:0: > bt2_idx.h:1057:3: warning: 'template class std::auto_ptr' is > deprecated [-Wdeprecated-declarations] >auto_ptr fb(new FileBuf(ss.get())); >^~~~ > In file included from /usr/include/c++/7/memory:80:0, > from bt2_idx.h:28, > from centrifuge_build.cpp:27: > /usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here >template class auto_ptr; > ... > Hi, You can replace auto_ptr with unique_ptr which was introduced with C++11. std::unique_ptr is declared in the same header as auto_ptr (). One major difference is that std::unique_ptr cannot be copied but moved instead. For example: std::unique_ptr fb(new FileBuf); std::unique_ptr fb2 = std::move(p); After that second line, p will be empty/null and p2 will contains the FileBuf pointer. But in bt2_idx.h, the auto_ptr variables are not copied around so you probably just need to replace "auto_ptr" with "unique_ptr" and that's all. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
C++ help needed for centrifuge
Hi, I started packaging centrifuge[1] and hit a build error which is most probably caused by gcc-7 incompatibility: ... In file included from centrifuge_build.cpp:27:0: bt2_idx.h: In static member function 'static std::pair*, Ebwt*> Ebwt::fromStrings(const EList >&, bool, int, int, bool, int32_t, int32_t, int32_t, const string&, bool, index_t, index_t, index_t, int, uint32_t, bool, bool, bool)': bt2_idx.h:1053:3: warning: 'template class std::auto_ptr' is deprecated [-Wdeprecated-declarations] auto_ptr ss(new stringstream()); ^~~~ In file included from /usr/include/c++/7/memory:80:0, from bt2_idx.h:28, from centrifuge_build.cpp:27: /usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here template class auto_ptr; ^~~~ In file included from centrifuge_build.cpp:27:0: bt2_idx.h:1057:3: warning: 'template class std::auto_ptr' is deprecated [-Wdeprecated-declarations] auto_ptr fb(new FileBuf(ss.get())); ^~~~ In file included from /usr/include/c++/7/memory:80:0, from bt2_idx.h:28, from centrifuge_build.cpp:27: /usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here template class auto_ptr; ... Unfortunately I have no idea about C++. Any idea how to fix this? Kind regards Andreas. [1] https://anonscm.debian.org/git/debian-med/centrifuge.git -- http://fam-tille.de
Re: package pynmea2
On Tue, 2017-11-14 at 12:13:55 -0200, Herbert Fortes wrote: > There was a ITP-RFS for pynmea2. But python-nmea2 already > exists. > > https://packages.qa.debian.org/p/python-nmea2.html > > I asked the contributor (2017-11-12) to close the bugs with > an n-d...@bugs.debian.org but he sent -cl...@bugs.debian.org > to ITP only. RFS still open. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871468 > > Today I received an email saying that pynmea2 was accepted. It > already has a page: > > https://packages.qa.debian.org/p/pynmea2.html :( > What to do ? Ask FTP-Master to remove the package ? This is IMO, fundamentally a problem with the current python policy which does not require that source package names MUST be normalized and namespaced with python-, and get py prefixes removed and similar. Following the exemple set by other lang-specific policies. This causes the problem of different name manglings depending on who is packaging, and search misses like happened here. It also unjustifyingly stomps on the global source package namespace with many times extremely generic names. :( I filed #791635 some time ago, but didn't find the energy to it discuss forward given the initial reply. But probably I should! Thanks, Guillem
Re: How to find Multi-Arch path(s)
On Sat, 2017-11-25 at 11:36:27 +0100, Ole Streicher wrote: > Guillem Jover writes: > > The point is that the Multi-Arch concept in Debian is all about the > > interfaces. How packages and files interface with each other, and > > what is possible and allowed. Some examples: > > > > * A script might be arch-independent in the contents sense; i.e., it > > is the same on all architectures. But its interface might be > > arch-dependent, because itself uses processor or kernel specific > > interfaces, and its output changes depending on the architecture. > > These cannot be marked as Mutli-Arch foreign. > > * A compiled binary might be arch-dependent in the contents sense; > > i.e., it is different on each architecture. But its interface might > > be arch-independent, because it does not change independently on > > where it is executed, or for what arch it was built for. These can > > be marked as Multi-Arch foreign. > > Ahh. This is the point. So, there is (in my case) no reason to put *any* > binary to /usr/lib//iraf; they all should go to /usr/lib/iraf, > indepentent of the architecture. That means, that the main package > (f.e.) cannot be co-installed for different archs, but this is also not > required. Correct. > > * A shared library that is being linked by some other package with > > executables, needs to match their architecture and needs to be > > coinstallable with itself, otherwise you could not install > > packages of different architectures linking againts that library. > > Say prog-a:i386 → libso:i386, and prog-b:amd64 → libso:amd64. > > These are usually as Multi-Arch same. > > The package does not support shared libs yet -- as I said they made some > funny solutions: f.e. IRAF has its own incarnation of the libc, which is > implemented on the base of FORTRAN libs, and this lib is also called > "libc.a". To avoid using the wrong lib, this one is not linked by "-lc", > but by specifying the full path. Changing this to some shared lib > approach *and* being still compatible to third-party plugins is not > trivial and part of the longer-term evolution (depending on the success > of the package). Ugh. :) > So, I have a development package with "libc.a" and other stuff, but also > some executables (compiler) which are arch dependent. Handling multiarch > here is probably not worth the effort -- I see no use case to have the > development environment for more than one arch co-installed, and > therefore I would put the contents (binaries and static libs) to > /usr/lib/iraf/ and mark it with "Multi-arch: no". > > Would this be OK? Depends on who are the intended users of those libraries and for that compiler (!?). If those are needed to build only the iraf plugins, then Multi-Archifying them, might make it possible to cross-build them easily. But that depends on what all of this entails. Personally I'd only mark a package as Multi-Arch: no in case there's been determined that marking it with anything else would be wrong, and that there's no other option, like package splitting and file reorganization, etc, to make it Multi-Arch ready. > > So, say, your native arch (the one dpkg was built for) is amd64, > > and you have enabled i386 as a foreign arch. You then install the > > main iraf package for amd64 (the default), and then want to use some > > extension/plugin that is available only for 32-bit arches. apt for > > example will just pull the i386 version, because it'd be marked as > > Multi-Arch foreign and the dependencies would be fullfilled. > > Looks like as I want it. Let me repeat with my own words (just to be > sure I understand it): I have > > iraf - Multi-arch: foreign, x86_64, i386, ... > iraf-sptables - Multi-arch: foreign, i386; Depends: iraf > > On a x86_64 with i386 enabled, when I do an "apt install iraf-sptables", > I get iraf as x86_64 and iraf-sptables as i386. Correct? That depends on apt's behavior, other package manager frontends could behave differently. In this case apt might prefer to make the dependencies "self-contained" and pull iraf:i386, or it might prefer to give the native version more weight. I'm not certain. In any case you'd always be able to do: # apt install iraf-sptables iraf:amd64 or if you've got iraf:i386, just: # apt install iraf:amd64 and the package would get cross-graded. > Thank you very much for your patience and your good explanations! I feel > now that I understand the multiarch idea a bit better (well, hopefully). No problem! Thanks, Guillem
Re: How to find Multi-Arch path(s)
Guillem Jover writes: > The point is that the Multi-Arch concept in Debian is all about the > interfaces. How packages and files interface with each other, and > what is possible and allowed. Some examples: > > * A script might be arch-independent in the contents sense; i.e., it > is the same on all architectures. But its interface might be > arch-dependent, because itself uses processor or kernel specific > interfaces, and its output changes depending on the architecture. > These cannot be marked as Mutli-Arch foreign. > * A compiled binary might be arch-dependent in the contents sense; > i.e., it is different on each architecture. But its interface might > be arch-independent, because it does not change independently on > where it is executed, or for what arch it was built for. These can > be marked as Multi-Arch foreign. Ahh. This is the point. So, there is (in my case) no reason to put *any* binary to /usr/lib//iraf; they all should go to /usr/lib/iraf, indepentent of the architecture. That means, that the main package (f.e.) cannot be co-installed for different archs, but this is also not required. > * A shared library that is being linked by some other package with > executables, needs to match their architecture and needs to be > coinstallable with itself, otherwise you could not install > packages of different architectures linking againts that library. > Say prog-a:i386 → libso:i386, and prog-b:amd64 → libso:amd64. > These are usually as Multi-Arch same. The package does not support shared libs yet -- as I said they made some funny solutions: f.e. IRAF has its own incarnation of the libc, which is implemented on the base of FORTRAN libs, and this lib is also called "libc.a". To avoid using the wrong lib, this one is not linked by "-lc", but by specifying the full path. Changing this to some shared lib approach *and* being still compatible to third-party plugins is not trivial and part of the longer-term evolution (depending on the success of the package). So, I have a development package with "libc.a" and other stuff, but also some executables (compiler) which are arch dependent. Handling multiarch here is probably not worth the effort -- I see no use case to have the development environment for more than one arch co-installed, and therefore I would put the contents (binaries and static libs) to /usr/lib/iraf/ and mark it with "Multi-arch: no". Would this be OK? > So, say, your native arch (the one dpkg was built for) is amd64, > and you have enabled i386 as a foreign arch. You then install the > main iraf package for amd64 (the default), and then want to use some > extension/plugin that is available only for 32-bit arches. apt for > example will just pull the i386 version, because it'd be marked as > Multi-Arch foreign and the dependencies would be fullfilled. Looks like as I want it. Let me repeat with my own words (just to be sure I understand it): I have iraf - Multi-arch: foreign, x86_64, i386, ... iraf-sptables - Multi-arch: foreign, i386; Depends: iraf On a x86_64 with i386 enabled, when I do an "apt install iraf-sptables", I get iraf as x86_64 and iraf-sptables as i386. Correct? > Hope my clarifications above, clarified things. And regarding upstrea, > I'd just remove the multilib support stuff. Although other distributions > and upstreams seem to still have a strange love affair with that, so, > dunno. :) I am in contact with the Fedora astro guy, so in any case I will discuss with him. But my fork is meant to have a chance to be included upstream, so I will not do things that where I know they don't get accepted. Thank you very much for your patience and your good explanations! I feel now that I understand the multiarch idea a bit better (well, hopefully). Best regards Ole
