Re: Linker fails to find libraries in unstable but succeeds in testing
Hi Andreas, * Andreas Tille [2024-03-15 07:31]: Hi, thanks to the next round of Lucas' FTBFS QA rebuilds (at least) one package of the R pkg team is affected by some strange linker issue #1066409 r-cran-v8: FTBFS: ld: cannot find -lv8: No such file or directory which boils down to[1] g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o V8.so RcppExports.o bindings.o -lv8 -lv8_libplatform -L/usr/lib/R/lib -lR /usr/bin/ld: cannot find -lv8: No such file or directory /usr/bin/ld: cannot find -lv8_libplatform: No such file or directory The Build-Depends libnode-dev provides both libraries and when I try to build the package under testing all is fine. Is there any linker issue involved that might be introduced in unstable? I guess that's the same as #1066399. libnode-dev: libv8.so -> libnode.so libnode.so -> libnode.so.108t64 But libnode.so.108t64 does not exist Cheers Jochen signature.asc Description: PGP signature
Bug#1066922: ITP: python-mercantile -- Web mercator XYZ tile utilities
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-mercantile Version : 1.2.1 Upstream Contact: Sean Gillies * URL : https://github.com/mapbox/mercantile * License : BSD-3-clause Programming Lang: Python Description : Web mercator XYZ tile utilities The mercantile module provides ul(xtile, ytile, zoom) and bounds(xtile, ytile, zoom) functions that respectively return the upper left corner and bounding longitudes and latitudes for XYZ tiles, a xy(lng, lat) function that returns spherical mercator x and y coordinates, a tile(lng, lat, zoom) function that returns the tile containing a given point, and quadkey conversion functions quadkey(xtile, ytile, zoom) and quadkey_to_tile(quadkey) for translating between quadkey and tile coordinates. Note: This is a new build-dependency for networkx so we can continue to build its documentation.
Bug#1066925: ITP: python-contextily -- Context geo-tiles in Python
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-contextily Version : 1.5.2 Upstream Contact: Dani Arribas-Bel * URL : https://github.com/geopandas/contextily * License : BSD-3-clause Programming Lang: Python Description : Context geo-tiles in Python Contextily is a package to retrieve tile maps from the internet. It can add those tiles as basemap to matplotlib figures or write tile maps to disk into geospatial raster files. Bounding boxes can be passed in both WGS84 (EPSG:4326) and Spheric Mercator (EPSG:3857). Note: this is a new build-depends for networkx, so we can continue to build its documentation.
Bug#1066927: ITP: python-momepy -- Urban Morphology Measuring Toolkit
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-momepy Version : 0.7.0 Upstream Contact: Martin Fleischmann * URL : https://github.com/pysal/momepy * License : BSD-3-clause Programming Lang: Python Description : Urban Morphology Measuring Toolkit Momepy is a library for quantitative analysis of urban form - urban morphometrics. It is part of PySAL (Python Spatial Analysis Library) and is built on top of GeoPandas, other PySAL modules, and networkX. Note: this is a new dependency of networkx, so we can continue to build its documentation.
Re: 64-bit time_t transition: cargo needs manual intervention
On Thu, Mar 14, 2024 at 10:03:57PM -0700, Otto Kekäläinen wrote: > Hi! > > Is anyone perhaps planning to fix cargo? > > For example curl isn't building on armel/armhf now and numerous packages > that depend of curl are not building on armel/armhf. > > Thanks in advance to the person who steps up. see the (linked) t64 transition bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036884#197
Re: 64-bit time_t transition: cargo needs manual intervention
Hi! pe 15. maalisk. 2024 klo 6.56 Fabian Grünbichler kirjoitti: > On Thu, Mar 14, 2024 at 10:03:57PM -0700, Otto Kekäläinen wrote: > > Hi! > > > > Is anyone perhaps planning to fix cargo? > > > > For example curl isn't building on armel/armhf now and numerous packages > > that depend of curl are not building on armel/armhf. > > > > Thanks in advance to the person who steps up. > > see the (linked) t64 transition bug: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036884#197 That link doesn't answer my question. The link is to bug report summarizing that cargo is broken and suggesting it needs to be re-bootstrapped. Currently we haven't seen anybody step up to do it. I would be very grateful if somebody with enough expertise would be available to do it and thus help resolve the whole chain of broken builds. > >
Re: 64-bit time_t transition: cargo needs manual intervention
On 2024-03-14 22:03 -0700, Otto Kekäläinen wrote: > Hi! > > Is anyone perhaps planning to fix cargo? Yes. We have been working on it this week (e.g. ema built cargo for armhf), but that is not sufficient to unbung the curl->stunnel4->python->crypography->cargo loop. I tried building the patched stunnel4 last night but got stuck on other missing dependencies, and just about everything being uninstallable (and then my wife made me do something else for the rest of the evening). > For example curl isn't building on armel/armhf now and numerous packages > that depend of curl are not building on armel/armhf. We are well aware that this is broken and blocking lots of things. Co-ordinate efforts on the #debian-arm channel. There are plenty of other loops to unbung too. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: time_t progress report
On Thu, Mar 14, 2024 at 08:42:14PM -0700, Steve Langasek wrote: > On Thu, Mar 14, 2024 at 10:47:02PM +0100, Micha Lenk wrote: > > The time_t transition seems to be stalled due to issues on armel/armhf > > architecture. My understanding is, as long as this transition isn't over, > > uploaders of affected packages are discouraged to upload anything > > unrelated to this transition (to avoid any delays to get it through). > > > Do we have an updated rough idea for how long this transition will take? > > Is it in the range of day, weeks or months? I have no clue... > > Well, I think I should send an update about this probably, because I don't > think you should be discouraged from uploading right now. The source > packages with the renames have landed in unstable, and will take a while > (probably weeks) to get all of the build-dependency loops worked out and the > binNMUs all done. There's no real need to hold off on other uploads at this > point in the face of that, I don't expect it to significantly change the > timeline. That's great to hear. A more visible progress update would be greatly appreciated. > There may be some rare cases of pending transitions that would add to the > set of packages that need to migrate to testing all at once (though this > seems unlikely to me when there are already so many!), so those should still > be coordinated with the Release Team. It would be nice if the update included information on how to figure out whether one's packages are likely to fall into this "rare cases" bucket. Something like that might have provided in the past, but giving it greater visibility would help a lot IMO. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Re: 64-bit time_t transition: cargo needs manual intervention
On Fri, Mar 15, 2024 at 08:16:40AM -0700, Otto Kekäläinen wrote: > Hi! > > pe 15. maalisk. 2024 klo 6.56 Fabian Grünbichler > kirjoitti: > > > On Thu, Mar 14, 2024 at 10:03:57PM -0700, Otto Kekäläinen wrote: > > > Hi! > > > > > > Is anyone perhaps planning to fix cargo? > > > > > > For example curl isn't building on armel/armhf now and numerous packages > > > that depend of curl are not building on armel/armhf. > > > > > > Thanks in advance to the person who steps up. > > > > see the (linked) t64 transition bug: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036884#197 > > > That link doesn't answer my question. The link is to bug report summarizing > that cargo is broken and suggesting it needs to be re-bootstrapped. > > Currently we haven't seen anybody step up to do it. I would be very > grateful if somebody with enough expertise would be available to do it and > thus help resolve the whole chain of broken builds. it does (the replies afterwards are about people stepping up, the coordination then shifted to IRC where it is still ongoing..). it will take a bit though, there are very large and intertwined dep chains to analyze and unwind (and/or temporarily break), as well as lots of manual rebootstrapping along the way..
Re: Package marked for autoremoval due to closed bug?
Hi, Disclaimer: exception only valid while the time_t transition is ongoing. On 15-03-2024 6:15 a.m., Steve Langasek wrote: Migration to testing is largely out of control of the maintainers at this point, it's very much dependent on folks rebootstrapping armel and armhf against the new library names. Should these bugs be downgraded again to important severity? As I'm normally watching out for out-of-sync packages, I'm fine (with my Release Team hat on) with maintainers downgrading RC bugs in testing that have been fixed in unstable and that don't require a quick update in testing (e.g. security issues probably warrant discussing the tpu path with the RT). Once time_t 64 bit is done, I'll be filling bugs for packages that don't migrate again, so the lack of the fix in testing won't go unnoticed. For bookkeeping purposes, please usertag downgraded bugs with user release.debian@packages.debian.org and usertag time_t-downgrade. Please be careful with downgrading RC bugs. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Package marked for autoremoval due to closed bug?
On 3/15/24 21:52, Paul Gevers wrote: Hi, Disclaimer: exception only valid while the time_t transition is ongoing. On 15-03-2024 6:15 a.m., Steve Langasek wrote: Migration to testing is largely out of control of the maintainers at this point, it's very much dependent on folks rebootstrapping armel and armhf against the new library names. Should these bugs be downgraded again to important severity? As I'm normally watching out for out-of-sync packages, I'm fine (with my Release Team hat on) with maintainers downgrading RC bugs in testing that have been fixed in unstable and that don't require a quick update in testing (e.g. security issues probably warrant discussing the tpu path with the RT). Once time_t 64 bit is done, I'll be filling bugs for packages that don't migrate again, so the lack of the fix in testing won't go unnoticed. For bookkeeping purposes, please usertag downgraded bugs with user release.debian@packages.debian.org and usertag time_t-downgrade. Please be careful with downgrading RC bugs. Paul Hi Paul, I leave this to your own judgement, of course (with your "release team hat"). But when the AUTORM period was announced as reduced, I thought like it was probably a bad call, and that the previous AUTORM was aggressive enough. I didn't dare to express myself about it at the time, as maybe you knew better. My thinking was: after all, people should fix their bugs, no? Plus release team people must know better... But after a few months with the shorter AUTORM period, my opinion is growing firmer: the previous one (whatever it was) seemed more appropriate to me with the way Debian is being developed (ie: largely by volunteers on their free time), and for those of us in charge of maintaining a long (and sometimes complicated) chain of dependencies. Now, with this type of (breaking) transition, would growing back the AUTORM period (to what it used to be) help? Or are you still in the opinion making it shorter was a good move? Your thoughts? Cheers, Thomas Goirand (zigo)
Re: Package marked for autoremoval due to closed bug?
On 3/15/24 07:14, Andreas Tille wrote: I simply remove all those testing removal warnings in my mailbox to cope with this and by doing so I'm probably missing real issues I should rather care about. I know what you're talking about: anyone that maintains a lot of packages always receive waves of multiple dozens of email, and often, it's hardly actionable. Then I just end up ignoring them, hoping the fix is already under way by the person in charge of that new dependency I never heard of before. I hope one day, someone will have the skill/time/courage to refactor these messages into something humanly readable. One message per day per DD, with a summary of the possible AUTORM pointing at the list of RC bugs with links, would be a way more useful than ONE message per package, for example. Thanks to all who are involved in this complex migration Yeah, +1 Thomas Goirand (zigo)
