OSCON - PGP key signing request
Greetings, Any debian developers attending the OSCON conference in Portland, Oregon next week that would be willing to meet me to sign my PGP key? Kind regards, Debora Velarde Babb IBM Linux Technology Center deb...@linux.ibm.com and dvela...@us.ibm.com
Bug#903515: ITP: samblaster -- marks duplicates, extracts discordant/split reads
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: samblaster * URL : https://github.com/GregoryFaust/samblaster * License : MIT Programming Lang: C Description : marks duplicates, extracts discordant/split reads Team-maintained at https://salsa.debian.org/med-team/samblaster
Bug#903510: ITP: exa -- A modern replacement for ls.
Package: wnpp Severity: wishlist Owner: Emmanouil Kampitakis X-Debbugs-Cc: debian-devel@lists.debian.org,pkg-rust-maintain...@alioth-lists.debian.net * Package name: exa Version : 0.8.0 Upstream Author : Benjamin Sago (ogham at github) * URL : http://the.exa.website/ * License : MIT Programming Lang: Rust Description : A modern replacement for ls exa is an improved file lister with more features and better defaults. It uses colours to distinguish file types and metadata. It knows about symlinks, extended attributes, and Git. pgpp2qeXs7222.pgp Description: OpenPGP digital signature
Bug#903507: ITP: delly -- structural variant discovery by read analysis
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: delly Version : 0.7.8 Upstream Author : Tobias Rausch * URL : https://github.com/dellytools/delly * License : GPL Programming Lang: C++ Description : structural variant discovery by read analysis Team-maintained at https://salsa.debian.org/med-team/delly.
Re: workarounds for Planet bugs?
On 10/07/18 12:09, Jonathan Dowland wrote: > On Mon, Jul 09, 2018 at 08:36:35PM +0200, Daniel Pocock wrote: >> Yes, I don't think they are all the same problem. >> >> For Anisa, Jona and Kristi they are all using Wordpress and it is polled >> successfully by the version of planet-venus[1] in stretch and by other >> Planet sites so I didn't want to bother them to try changing their whole >> blog unless there is a known workaround for the issue that they can >> enable without too much effort. > > Perhaps you can get access to Planet Debian's run logs to see what > error reporting those blogs trigger, if any. > Yes, I did that, the planet admins have a wiki about[1] it and I looked there before posting. The wiki suggests filing a bug against the package planet-venus but the service is not running the package and the bug doesn't exist in the latest package anyway, Planet is running an old version from 2011. I was hoping somebody else using Wordpress may remember what options they selected in their Wordpress settings to make it work This is what appears in the log for the last poll: $ cat /srv/planet.debian.org/log/planet.log.0 | egrep 'kuci|progri|azizaj' INFO:planet.runner:Fetching https://anisakuci.com/feed/ via 6 INFO:planet.runner:Fetching https://blog.azizaj.com/tag/debian/feed/ via 9 INFO:planet.runner:Fetching https://kristiprogri.com/feed/ via 14 ERROR:planet.runner:Error 500 while updating feed https://anisakuci.com/feed/ (HTTPS not supported) INFO:planet.runner:Feed https://blog.azizaj.com/tag/debian/feed/ unchanged INFO:planet.runner:Feed https://kristiprogri.com/feed/ unchanged DEBUG:planet.runner:missing self link for https://blog.azizaj.com/tag/debian/feed/ DEBUG:planet.runner:missing html link for https://blog.azizaj.com/tag/debian/feed/ DEBUG:planet.runner:missing self link for https://kristiprogri.com/feed/ DEBUG:planet.runner:missing html link for https://kristiprogri.com/feed/ Regards, Daniel 1. https://wiki.debian.org/PlanetDebian#Maintenance_notes
Re: A message from CMake upstream: announcing dh-cmake
On Tue, 2018-07-10 at 12:52 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Well, there are cases when upstream is doing things the right way > with respect to Debian but... what about derivatives (distributions > which base themselves in Debian)? Sometimes they need something > different, and even if the package fits perfectly well in Debian it > might not be true for them. So they need to either patch CMake files > or re do the whole packaging using traditional tools. I understand what you're saying. As a concrete example, we all know that Debian requires *.so library symlinks to live in the -dev package. But let's say there's a hypothetical Debian derivative that requires them to live in the library binary package instead. If upstream has both the headers and the symlink in the "Development" component, then this would certainly be a problem. Perhaps the solution is for upstream to make this more flexible, through one of several options: 1. Further divide the "Development" component into "Headers" and "Symlinks", allowing downstream to put the symlink in whichever package is required to meet the distribution's policy. Remember: dh-cmake allows you to specify *more than one* component per package. In this case, erring on the side of smaller components would give downstream the maximum flexibility for grouping them as needed. 2. Make the component names configurable and intelligent through a new, standardized CMake module, similar to GNUInstallDirs. For example, there could be new cache variables such as CMAKE_INSTALL_LIBRARY_COMPONENT, CMAKE_INSTALL_NAMELINK_COMPONENT, CMAKE_INSTALL_HEADER_COMPONENT, etc. They could be set to defaults that make sense for the detected distribution, but also configurable to allow downstream to override them as needed. I would also add that while this component system might not be as valuable for smaller, single-library packages, it makes a lot of sense for VTK. VTK has a module system, with its own internal dependency graph, that builds and installs dozens of modules, each with their own headers and CMake files that have to be installed with their respective shared libraries. Without the component-based approach taken by dh-cmake, trying to break up this installation into multiple packages is very difficult. The VTK7 package divides it up into Qt and non-Qt modules (along with docs, executables, bindings, etc.) To separate Qt and non-Qt modules, it has to install everything into the non-Qt package, and then manually remove the Qt modules from it. But if VTK's module system was updated to install each module into its own set of components (vtkCommonCore-Libaries, vtkCommonCore-Headers, etc.), then the debian/*.cpack-components files used by dh-cmake could simply list these module components, making it very easy to group the modules together as needed. (Perhaps we could even add a globbing mechanism so you can just say "vtkCommon*-Libraries" as a shorthand.) Then, we could further break the VTK package into smaller packages so you can install some modules without having to install everything. Now let's say a problem is encountered with the package later on, and one of the modules needs to be moved into a different package. No problem - just move the problem module into the correct *.cpack- components file, and you're done. If there's another approach we could take to solve this particular packaging issue, I would love to hear about it, but this is the best we've come up with so far. > To sum it up: I *do* think there is a *huge* potential for this > helper, just not for Debian proper. Of course I would *love* to see > it packaged in Debian because it will help projects trying to create > their own Debian packages, but I would expect a very clear > explanation that this is not a suitable way to maintain packages in > Debian proper. In fact, CPack already provides its own method for maintaining 3rd party Debian packages - it has its own .deb generator. But dh-cmake is our attempt to make something that fits better into the Debian workflow, so that it *can* be used to maintain packages in Debian proper. We want CMake packaging to be as easy as Python packaging, where you just activate dh-python. The end goal of dh-cmake is to make CMake packaging as easy as writing a few configuration files, and then declaring "dh $@ --buildsystem=cmake --with cmake --with ctest --with cpack". In our case, our goal is to maintain an official VTK package in both Debian proper and Ubuntu proper. VTK is a huge project which has proven to be difficult to package, and dh-cmake is being created to solve this problem. We've also made changes to both VTK and CMake itself to support the VTK packaging effort, and we can and will make more. > Except we can find smart work arounds for this cases, of course. I think making the component names configurable and/or standardized, as I described above, would help tremendously with this. Kyle
Re: Reproducible builds error: libQt5Core.so.5: cannot open shared object file: No such file or directory
El lunes, 9 de julio de 2018 14:05:36 -03 Mattia Rizzolo escribió: > On Mon, Jul 09, 2018 at 07:02:00PM +0200, Innocent De Marchi wrote: > > Recently, ALL the packages that I maintain based on Qt, have problems > > of reproducibility on build on i386. > > This is: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895718 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902383 > > Which turned out to be needed due to: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875990 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876035 > > > The message is always the same: > > /usr/lib/qt5/bin/uic: error while loading shared libraries: > > libQt5Core.so.5: cannot open shared object file: No such file or > > directory [0] > > The (IMHO) misleading message is instead a linker bug, that I don't > think anybody filed anywhere. Although that stupid message did cause > and is still causing a ton of wasted time for people to figure what is > going on. Apart from the possible linker bug, the Qt5Core part could be solved by adding runtime detection. It should not be too complicated to achieve, but: It should be easy to fix, but we Qt maintainers could not make time for this yet, nor we can assure we will. But: * In case we get a patch created we want it submitted to upstream, that means agreeing with the [CLA]. So if anyone is thinking about creating a patch **pretty please** check that you will agree to it. We will not be able to forward [any patch], they should be submitted to their gerrit instance by the person who coded it. Of course we will be happy to help with the process if needed. [CLA] It's worth to note that this CLA does not makes one give copyright to others, but the permission to use the code in proprietary versions. [any patch] Except the patch is so small that it can't be considered copyrighteable. * Before applying it we want the patch "blessed" by upstream, meaning that even if they don't want to accept it (let's say, just as an example, because it's slows loading) they see the patch fit. Cheers, Lisandro. -- Without us [Free Software developers], people would study computer science and programming without ever having seen a real program in its entirety. That's like becoming writers without ever having read a complete book. Matthias Ettrich, founder of the KDE project. http://www.efytimes.com/efytimes/25412/news.htm Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Mass filing on Python 3.7 async module import?
On 07/10/2018 03:50 PM, Thomas Goirand wrote: > On 07/09/2018 11:03 PM, Adrian Bunk wrote: >> On Mon, Jul 09, 2018 at 02:33:18PM +0200, Thomas Goirand wrote: >>> On 07/08/2018 12:36 PM, Emilio Pozuelo Monfort wrote: List of affected packages: openscap-daemon: /usr/lib/python3/dist-packages/openscap_daemon/async.py pylint3: /usr/lib/python3/dist-packages/pylint/checkers/async.py python3-astroquery: /usr/lib/python3/dist-packages/astroquery/vo_conesearch/async.py python3-celery: /usr/lib/python3/dist-packages/celery/backends/async.py python3-dropbox: /usr/lib/python3/dist-packages/dropbox/async.py python3-exabgp: /usr/lib/python3/dist-packages/exabgp/reactor/async.py python3-gunicorn: /usr/lib/python3/dist-packages/gunicorn/workers/async.py python3-ldap: /usr/lib/python3/dist-packages/ldap/async.py python3-mapproxy: /usr/lib/python3/dist-packages/mapproxy/util/async.py python3-opengl: /usr/lib/python3/dist-packages/OpenGL/GL/SGIX/async.py python3-opengl: /usr/lib/python3/dist-packages/OpenGL/raw/GL/SGIX/async.py python3-pexpect: /usr/lib/python3/dist-packages/pexpect/async.py python3-pylama: /usr/lib/python3/dist-packages/pylama/async.py python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/client/async.py python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/server/async.py python3-raven: /usr/lib/python3/dist-packages/raven/contrib/async.py python3-rpyc: /usr/lib/python3/dist-packages/rpyc/core/async.py python3-tenacity: /usr/lib/python3/dist-packages/tenacity/async.py salt-common: /usr/lib/python3/dist-packages/salt/utils/async.py visidata: /usr/lib/python3/dist-packages/visidata/async.py >>> >>> There's more than this. What you're reporting doesn't seem to include >>> packages defining the async function, for example gevent. I also saw >>> more than this list, just by trying to rebuild neutron-fwaas: >>> python3-oslo.db (we just fixed that one), python3-kafka, python3-pika, >>> python3-dogpile.cache (bug with fix already filled, we'll fix soon). >>> >>> I would anyway very much welcome a mass bug filling, but best would be >>> to try not to forget any package. Note that tenacity is already fixed. >> >> Note that "already fixed in unstable" is only part of the story. >> >> Most important will be Breaks for all affected packages in *stretch*, >> since there might otherwise be nasty problems in stretch->buster >> upgrades depending on the undefined order of package upgrades. > > Do you mean that the interpreter will have to declare Breaks: for the > affected packages? > Yes. Cheers, Julien
Re: A message from CMake upstream: announcing dh-cmake
El viernes, 6 de julio de 2018 12:59:58 -03 Kyle Edwards escribió: > On Thu, 2018-07-05 at 14:04 -0300, Lisandro Damián Nicanor Pérez Meyer > > wrote: > > From what you write above I tend to think that simply by not using > > dh-cmake whatever upstream has defined as packaging it will be simply > > ignored (ie, it will become a "standard" CMake project). > > Yes, this is true. dh-cmake only adds optional new functionality and > doesn't take anything away from existing packages. That's just perfect. > > Now it turns out that you get a bug report where you need to split > > the packaging. It's not an upstream issue per-se, but rather a > > packaging one. Following normal Debian workflow that would mean > > simply creating a new Debian revision. > > In our opinion, this actually *is* an upstream issue. To explain why, I > think it would help if I give a brief explanation of the CMake > philosophy. [snip] That's just perfect. It really sounds like a tool to use if upstream wants to provide a non-official Debian package, and believe me that sounds pretty good. But not for Debian proper, see below. [snip] > This project is meant for the subset of cases where upstream DOES > package it correctly, leaving almost no work for the Debian maintainer > - just add configuration files for dh-cmake and it's ready to go right > away, complete with upstream's dependency graph and project > description. Well, there are cases when upstream is doing things the right way with respect to Debian but... what about derivatives (distributions which base themselves in Debian)? Sometimes they need something different, and even if the package fits perfectly well in Debian it might not be true for them. So they need to either patch CMake files or re do the whole packaging using traditional tools. That's just an example, but I'm sure other will appear. To sum it up: I *do* think there is a *huge* potential for this helper, just not for Debian proper. Of course I would *love* to see it packaged in Debian because it will help projects trying to create their own Debian packages, but I would expect a very clear explanation that this is not a suitable way to maintain packages in Debian proper. Except we can find smart work arounds for this cases, of course. Cheers, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Mass filing on Python 3.7 async module import?
On 07/09/2018 11:03 PM, Adrian Bunk wrote: > On Mon, Jul 09, 2018 at 02:33:18PM +0200, Thomas Goirand wrote: >> On 07/08/2018 12:36 PM, Emilio Pozuelo Monfort wrote: >>> List of affected packages: >>> >>> openscap-daemon: /usr/lib/python3/dist-packages/openscap_daemon/async.py >>> pylint3: /usr/lib/python3/dist-packages/pylint/checkers/async.py >>> python3-astroquery: >>> /usr/lib/python3/dist-packages/astroquery/vo_conesearch/async.py >>> python3-celery: /usr/lib/python3/dist-packages/celery/backends/async.py >>> python3-dropbox: /usr/lib/python3/dist-packages/dropbox/async.py >>> python3-exabgp: /usr/lib/python3/dist-packages/exabgp/reactor/async.py >>> python3-gunicorn: /usr/lib/python3/dist-packages/gunicorn/workers/async.py >>> python3-ldap: /usr/lib/python3/dist-packages/ldap/async.py >>> python3-mapproxy: /usr/lib/python3/dist-packages/mapproxy/util/async.py >>> python3-opengl: /usr/lib/python3/dist-packages/OpenGL/GL/SGIX/async.py >>> python3-opengl: /usr/lib/python3/dist-packages/OpenGL/raw/GL/SGIX/async.py >>> python3-pexpect: /usr/lib/python3/dist-packages/pexpect/async.py >>> python3-pylama: /usr/lib/python3/dist-packages/pylama/async.py >>> python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/client/async.py >>> python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/server/async.py >>> python3-raven: /usr/lib/python3/dist-packages/raven/contrib/async.py >>> python3-rpyc: /usr/lib/python3/dist-packages/rpyc/core/async.py >>> python3-tenacity: /usr/lib/python3/dist-packages/tenacity/async.py >>> salt-common: /usr/lib/python3/dist-packages/salt/utils/async.py >>> visidata: /usr/lib/python3/dist-packages/visidata/async.py >> >> There's more than this. What you're reporting doesn't seem to include >> packages defining the async function, for example gevent. I also saw >> more than this list, just by trying to rebuild neutron-fwaas: >> python3-oslo.db (we just fixed that one), python3-kafka, python3-pika, >> python3-dogpile.cache (bug with fix already filled, we'll fix soon). >> >> I would anyway very much welcome a mass bug filling, but best would be >> to try not to forget any package. Note that tenacity is already fixed. > > Note that "already fixed in unstable" is only part of the story. > > Most important will be Breaks for all affected packages in *stretch*, > since there might otherwise be nasty problems in stretch->buster > upgrades depending on the undefined order of package upgrades. Do you mean that the interpreter will have to declare Breaks: for the affected packages? Cheers, Thomas Goirand (zigo)
Re: workarounds for Planet bugs?
On Mon, Jul 09, 2018 at 08:36:35PM +0200, Daniel Pocock wrote: Yes, I don't think they are all the same problem. For Anisa, Jona and Kristi they are all using Wordpress and it is polled successfully by the version of planet-venus[1] in stretch and by other Planet sites so I didn't want to bother them to try changing their whole blog unless there is a known workaround for the issue that they can enable without too much effort. Perhaps you can get access to Planet Debian's run logs to see what error reporting those blogs trigger, if any. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
