Bug#994669: ITP: golang-github-pkg-diff -- create, modify, and print diffs (Go module)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-pkg-diff Version : 0.0~git20210226.20ebb0f-1 Upstream Author : Josh Bleecher Snyder * URL : https://github.com/pkg/diff * License : BSD-3-clause Programming Lang: Go Description : create, modify, and print diffs (Go module) Module github.com/pkg/diff can be used to create, modify, and print diffs. . The top level package, `diff`, contains convenience functions for the most common uses. . The subpackages provide very fine-grained control over every aspect: . * `myers` creates diffs using the Myers diff algorithm. * `edit` contains the core diff data types. * `ctxt` provides tools to reduce the amount of context in a diff. * `write` provides routines to write diffs in standard formats. Reason for packaging: Prerequisite for golang-github-rogpeppe-go-internal >= 1.8.0
Re: How to build circular dependant packages in debian
On 2021-09-19 01:24:32 + (+), Paul Wise wrote: > On Sat, Sep 18, 2021 at 2:35 PM Jeremy Stanley wrote: [...] > > http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012058.html > > Hmm, this site has a confusing way of not supporting https. [...] Thanks for the feedback! Other than simply not currently supporting HTTPS (after all, it's an HTTP URL), what was confusing about the way it didn't? Or are you just saying you're confused that there's still a site on the Web which doesn't serve HTTPS? Unrelated to the subject, but asking since I'm one of the sysadmins for the OpenDev Collaboratory which includes this server which hosts a number of Mailman 2.x mailing lists for a variety of F/LOSS projects including StarlingX. We do have plans to switch the static archive sites for them to HTTPS, but it hasn't seemed like an especially high priority because the security model for MM2 is pretty nonexistent, so the idea is to do it while we're rewriting all the configuration management for a migration to MM3 which actually benefits from the additional transport security in meaningful ways. If there's a reason we should prioritize an HTTPS implementation there over other work, then I'll see about separating out that particular task from the larger effort. -- Jeremy Stanley signature.asc Description: PGP signature
Re: How to build circular dependant packages in debian
On 2021-09-19 01:24:17 + (+), Paul Wise wrote: [...] > Jeremy Stanley pointed out that this is for the StarlingX project, > please consider merging StarlingX changes back to Debian and our > upstream projects and contributing new packages back into Debian > itself. [...] According to meeting minutes from last week, it looks like that is either already happening or at least planned/intended: http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012048.html > > * Debian patches going upstream: > > > > https://review.opendev.org/q/topic:%22debian-build%22+(status:open%20OR%20status:merged) [...] > > * Building bridge to the Debian community now that the patches > > are going upstream now that some of the patches are being > > posted to upstream community. > > * Currently will accumlate the technical debt, but will build > > bridge to the community members, and get those technical debt > > upstream. > > * Challenge with pushing patches to Debian community is to get > > the maintainer to understand the why of the patches, or the > > solution of an issue, so that they will accept it. [...] But I agree, if they aren't already it would be great to see them pitch in with maintaining things in Debian they're relying on, as well as posting patches in the BTS or Salsa with rationale for modifications they're carrying. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Future of /usr/bin/which in Debian?
On 2021-08-27 16:48 -0400, Boyuan Yang wrote: > Hi, > > The GNU which package is now in NEW queue: > https://ftp-master.debian.org/new/gnu-which_2.21-1.html Thanks for this. Missing which broke bazel (at least in tensorflow) and the implementation made it fiddly to replace with as recommended. Have a plain which back is much easier than fixing the build mess. I must admit that I have no idea why replacing such a longstanding utility is deemed necessary. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: How to build circular dependant packages in debian
On 9/19/21 2:57 PM, Jeremy Stanley wrote: > On 2021-09-19 01:24:17 + (+), Paul Wise wrote: > [...] >> Jeremy Stanley pointed out that this is for the StarlingX project, >> please consider merging StarlingX changes back to Debian and our >> upstream projects and contributing new packages back into Debian >> itself. > [...] > > According to meeting minutes from last week, it looks like that is > either already happening or at least planned/intended: > > http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012048.html > >>> * Debian patches going upstream: >>> >>> https://review.opendev.org/q/topic:%22debian-build%22+(status:open%20OR%20status:merged) > [...] >>> * Building bridge to the Debian community now that the patches >>> are going upstream now that some of the patches are being >>> posted to upstream community. >>> * Currently will accumlate the technical debt, but will build >>> bridge to the community members, and get those technical debt >>> upstream. >>> * Challenge with pushing patches to Debian community is to get >>> the maintainer to understand the why of the patches, or the >>> solution of an issue, so that they will accept it. > [...] > > But I agree, if they aren't already it would be great to see them > pitch in with maintaining things in Debian they're relying on, as > well as posting patches in the BTS or Salsa with rationale for > modifications they're carrying. > In all logic, considering what starlingx is, if they had the intention to upstream some patches, I should have known, no? Well, so far, they didn't get in touch... My mum always says: the road to hell is paved with good intentions. :) [1] Cheers, Thomas Goirand (zigo) [1] Not sure if I translated this one well. And assume good faith: nothing intended but entertaining the readers here...
Re: How to build circular dependant packages in debian
On 2021-09-19 21:34:43 +0200 (+0200), Thomas Goirand wrote: [...] > In all logic, considering what starlingx is, if they had the intention > to upstream some patches, I should have known, no? Well, so far, they > didn't get in touch... > > My mum always says: the road to hell is paved with good intentions. :) > [1] > > Cheers, > > Thomas Goirand (zigo) > > [1] Not sure if I translated this one well. And assume good faith: > nothing intended but entertaining the readers here... Assuming you mean patches to OpenStack components, they've been working together with the upstream project teams there for a few years to integrate their changes and have mostly reached parity as far as I understand. What's left is changes to system libraries, kernel configurations, and so on, to tune low-level performance characteristics for their specific deployment targets. Up until very recently, they've been purely a CentOS fork, but with Red Hat announcing a shift in focus for CentOS and the fact that they hadn't completed a switch from CentOS 7 to 8 yet, they've decided that having a more stable alternative basis for their distribution might be in their best interests... but they've only just begun to investigate what building a Debian derivative might mean for them (for example, they've been relying on OpenSuse's OBS to build all their distro packages up till now, and that may not be a great fit for trying to build forks of fundamentally interrelated Debian packages). -- Jeremy Stanley signature.asc Description: PGP signature
Bug#994723: ITP: imath -- Utility libraries from ASF used by OpenEXR
Package: wnpp Severity: wishlist Owner: "Matteo F. Vescovi" X-Debbugs-Cc: debian-devel@lists.debian.org, ma...@debian.org * Package name: imath Version : 3.1.3 Upstream Author : Academy Software Foundation * URL : https://github.com/AcademySoftwareFoundation/Imath * License : BSD-3 Clause License Programming Lang: C++ and C Description : Utility libraries from ASF used by OpenEXR Imath is a basic, light-weight, and efficient C++ representation of 2D and 3D vectors and matrices and other simple but useful mathematical objects, functions, and data types common in computer graphics applications, including the "half" 16-bit floating-point type. Imath also includes optional Python bindings for all types and functions, including optimized implementations of vector and matrix arrays. This library is the successor of IlmBase (almost EOL) and it's mandatory for updating OpenEXR to newer versions. I'll maintain this package under the Debian Phototools Team umbrella. -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A signature.asc Description: PGP signature
Re: How to build circular dependant packages in debian
On Sun, Sep 19, 2021 at 12:40 PM Jeremy Stanley wrote: > On 2021-09-19 01:24:32 + (+), Paul Wise wrote: > > On Sat, Sep 18, 2021 at 2:35 PM Jeremy Stanley wrote: > > > http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012058.html > > > > Hmm, this site has a confusing way of not supporting https. > > Thanks for the feedback! Other than simply not currently supporting > HTTPS (after all, it's an HTTP URL), what was confusing about the > way it didn't? Or are you just saying you're confused that there's > still a site on the Web which doesn't serve HTTPS? Normally one would get "Connection refused" when connecting to a port that isn't open, but at this site one gets "No route to host", as if there is no network path to reach the host, which is clearly not true since the HTTP port works. I wasn't aware it is even possible to have different routing for each TCP port, I guess this is a feature of OpenStack? > If there's a reason we should prioritize an HTTPS > implementation there over other [Mailman 2] work, User subscription passwords are transferred to the Mailman subscription/options web interface, which is on the same site as the web mailman archives. -- bye, pabs https://wiki.debian.org/PaulWise
Re: How to build circular dependant packages in debian
On Sun, Sep 19, 2021 at 12:57 PM Jeremy Stanley wrote: > According to meeting minutes from last week, it looks like that is > either already happening or at least planned/intended: > > http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012048.html Excellent, that is good to see. In addition to pushing packaging patches to Debian, they need to work with our upstreams too, especially the Linux kernel community. > But I agree, if they aren't already it would be great to see them > pitch in with maintaining things in Debian they're relying on, as > well as posting patches in the BTS or Salsa with rationale for > modifications they're carrying. It sounds like they are using the Pulp tool for creating binary archives (including apt). I note that Pulp isn't in Debian yet, hopefully they consider packaging it. It sounds like they might also be using Aptly (typoed as Apily?), the upstream project for that was quite unmaintained, some folks stepped in but more are needed. https://wiki.debian.org/DebianRepository/Setup#Pulp https://pulpproject.org/ https://github.com/aptly-dev/aptly/issues/920 -- bye, pabs https://wiki.debian.org/PaulWise
Re: How to build circular dependant packages in debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Paul, On Mon, 2021-09-20 at 02:11 +, Paul Wise wrote: > On Sun, Sep 19, 2021 at 12:40 PM Jeremy Stanley wrote: > > On 2021-09-19 01:24:32 + (+), Paul Wise wrote: > > > On Sat, Sep 18, 2021 at 2:35 PM Jeremy Stanley wrote: > > > > > > Normally one would get "Connection refused" when connecting to a port > that isn't open, but at this site one gets "No route to host", as if > there is no network path to reach the host, which is clearly not true > since the HTTP port works. I wasn't aware it is even possible to have > different routing for each TCP port, I guess this is a feature of > OpenStack? If the packet reached the host that would be strange. Still it is possible to configure that by iptables. But for devices on the path that are configured to do some processing, this is normal behaviour - e.g. Cisco A9K routers would generate a "No route to host" for filtered ports, no matter that there is "Port is filtered" message. Also all kind of re-directors/load balancers/etc. would do the same for ports that are not configured and they do not know how to route the packet. It is a common networking concept to route packets via different paths based on ports, protocols or any other non-destination address based criteria - "policy based routing" or PBR for short... Hope that helps, b. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEumC8IPN+WURNbSUAE2VyCRPS8i0FAmFH99cACgkQE2VyCRPS 8i3GbA//TBkntlkhe0e6mewudnbgy00UW6QMAKRR/EqxnY+0cPtiPUNf7P96Pbkl zW6ztXs24dfijxE8YOyBVGbJ3Yj0lM9hhL5Hf6Dt8i42kSlswYAaf1TC1eKPUbqf QT3Yu092/XWXt0CRW5dJMV2fw2y1vzHyQC5shPxOMnW14JtdSxpqLlsSqkch2VqJ 6fLosSUHzp/55FlxXqsA+BPsNG0PBNILlQl+9KvHdopcTNwGMX3ly0xx67TIUgx1 oMm7LflgfuHtKNGrOqdah/mi383DYtK1/vu++IXqw7+UCm8sQnsIlwovFQ2Oi4Mg ex8UgwMDCGITK/yvavdoCWfXU21Uel/vd2AITgovOBL7A8pXJUpf87ONiWI2AxNU t4+9NfPmsozZpW/tTpsVV4Nbpg4V4yBaaBUh7Vl23fKJRVPXqlHzZHNX3L02BHT5 2lqJzSaVn8woAiJzqmEecVUSrhYR/nL0+m0AubKh+0NNXzifcf2m6m52GJF3XIfU NK4Rffdso5kF+R4yXmXubhlME0uGleSSHZM/qTaUpCfY+qlQ/IwNGuHTHanDfLqp l2mag3Fx7AIdGuLYs4IFvgjmO9qa22rRY/8ztwBrSi35EJXvPAByi55NKsYn77UV 4l/wyws2DUaS659ecm81jp8hGJdpRW6atkgHCmBgwbvEjRUz+5M= =aEjH -END PGP SIGNATURE-
Re: Future of /usr/bin/which in Debian?
On Sun, Sep 19, 2021 at 05:32:04PM +0100, Wookey wrote: > I must admit that I have no idea why replacing such a longstanding > utility is deemed necessary. Maybe this riddle will help. Imagine that you are the product manager for Debian `which`. According to the hatemail in my inbox, this is the most important utility in the history of time, such that even printing a warning to stderr causes global devastation, block hints, and calls for impeachment. So, it makes sense for this to be a full-time job, though perhaps you manage another, less significant utility as well. You go on a Gemba walk, and discover you have several user personas amongst your customers: (a) wants GNU `which`, to have feature parity with Red Hat Enterprise Linux (b) wants FreeBSD `which`, to have feature parity with FreeBSD (c) wants nothing ever to change, and the xiafs removal from Linux 2.1.21 to be reverted (d) wants there to be exactly one version of `which` (except for all the shell builtins) so that alternatives won't confuse and complicate things Wearing your customer-centricity hat, what is the optimal set of personas to unperson so that you can implement a solution that works for everyone who still matters?
