Re: Epoch for node-markdown-it
On Fri, Aug 19, 2022 at 10:00:58PM +0530, Nilesh Patra wrote: > On Fri, Aug 19, 2022 at 09:51:14PM +0530, Nilesh Patra wrote: > > > As Jonas said, an epoch cannot be undone, +really can, regardless when > > > this is going to happen. > > > > I think ignoring when it happens is not the right way to see it. Even if we > > assume that > > upstream is going to work on this with the same effort, we will still end > > up waiting > > for a _decade_ for the +really to go away. > > > > Is tagging this along for so many years really is more worthy than an epoch? > > Note that the package might even go stale in such a long time, thought. > > BTW, Jonas also said, "is it unlikely that they will reach 22 > in the foreseeable future?" Did you consider asking them to advance to 22+ with their next release? Afterall, I read it that way that it that there was some issue with that 22 version, and they might have also interest in putting that into the past? -- tobi
Re: Epoch for node-markdown-it
Tobias Frost writes: > On Fri, Aug 19, 2022 at 10:00:58PM +0530, Nilesh Patra wrote: >> On Fri, Aug 19, 2022 at 09:51:14PM +0530, Nilesh Patra wrote: >> > > As Jonas said, an epoch cannot be undone, +really can, regardless when >> > > this is going to happen. >> > >> > I think ignoring when it happens is not the right way to see it. Even if >> > we assume that >> > upstream is going to work on this with the same effort, we will still end >> > up waiting >> > for a _decade_ for the +really to go away. >> > >> > Is tagging this along for so many years really is more worthy than an >> > epoch? >> > Note that the package might even go stale in such a long time, thought. >> >> BTW, Jonas also said, "is it unlikely that they will reach 22 >> in the foreseeable future?" > > Did you consider asking them to advance to 22+ with their next release? > Afterall, I read it that way that it that there was some issue with that 22 > version, and they might have also interest in putting that into the past? This seems like the most sensible option, given that versions going backwards cannot be great in the node eco-system either. They could possibly use it as an oportunity to switch to date-based versioning to make a clean break from the current confusion, and hopefully this sort of thing in future. Joey's scheme makes a lot of sense: http://joeyh.name/blog/entry/version_numbers/ so if they like that then I guess they'd need to release 22.20220901 (or some such). If they are against bumping the version for whatever reason, it strikes me that this situation is exactly what epochs are for, so we should probably use them for that. Littering the repo with ~really... hacks seems to me to be trading the very minor discomfort that seeing an epoch inflicts on the very few of us that ever see them, against dumping confusion on our users when they have to try to guess which versions of things they're /really/ running. Given that the only time most people get interested in versions is when they've been presented with news of a (probably urgent) bug, we should be trying to make that moment as unconfusing as possible. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1017786: ITP: kokkos -- C++ Performance Portability Programming
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: kokkos Version : 3.6.01 Upstream Authors: Christian R. Trott URL : https://github.com/kokkos/kokkos * License : BSD-3-clause Description : C++ Performance Portability Programming This implements a programming model in C++ for writing performance portable applications targeting all major HPC platforms. For that purpose it provides abstractions for both parallel execution of code and data management. Kokkos is designed to target complex node architectures with N-level memory hierarchies and multiple types of execution resources. It currently can use CUDA, HPX, OpenMP and Pthreads as backend programming models with several other backends in development.
Re: Epoch for node-markdown-it
Hi Holger (2022.08.20_00:04:13_+) > On Fri, Aug 19, 2022 at 06:00:44PM +0100, Simon McVittie wrote: > > Epochs cause problems, [...] > > which are? (I agree they are ugly and should often be avoided, but I don't > see any unsolved problems with them, which is why I'm asking.) The standard one is that people use them to revert an upload. But, epochs aren't used in the upstream tarball filename, so you then easily get a conflict between the old and the new one. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Epoch for node-markdown-it
On Sat, Aug 20, 2022 at 03:29:59PM +, Stefano Rivera wrote: > > > Epochs cause problems, [...] > > which are? (I agree they are ugly and should often be avoided, but I don't > > see any unsolved problems with them, which is why I'm asking.) > The standard one is that people use them to revert an upload. ok, I agree that's bad. (but not the case here.) > But, epochs aren't used in the upstream tarball filename, so you then > easily get a conflict between the old and the new one. I'd replace 'easily' with 'theoretically in rare cases' but I can see how this is a valid point, sometimes. Thanks for the feedback. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ A single bitcoin transaction alone consumes 621 KWh, or half a million times more energy consumption than a credit card payment. The bitcoin network annually wastes 78 TWh (terrawatt hours) annually or the energy consumption of several *million* US households. https://twitter.com/smdiehl/status/1350869944888664064 signature.asc Description: PGP signature
Bug#1017804: ITP: pw -- interactively filtered pipe watcher
Package: wnpp Severity: wishlist Owner: Antoine Beaupre X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pw Version : 2 Upstream Author : Kaz Kylheku * URL : https://www.kylheku.com/cgit/pw/ * License : BSD-2 Programming Lang: C Description : interactively filtered pipe watcher pw can monitor anything that produces textual output. tail -f /var/logfile, tcpdump, strace, ... pw does not show you everything. Of course, it reads all the data, but it does that in the background. It continuously pumps lines of input through a small FIFO buffer. This buffer is sampled, and the sample is displayed. When that sampling occurs is controlled in various interactive ways. What goes into the FIFO can be filtered and the filters can be edited interactively. With pw you can: * Interactively apply and remove filters on-the-fly, without interrupting the source. * Make recurring patterns in the stream appear to "freeze" on the screen, using triggers. * Prevent the overwhelming amount of output from a program from flooding the terminal, while consuming all of that output so that the program isn't blocked. pw can pause its display updates entirely. * Juggle multiple shell background jobs that produce output, yet execute indefinitely without blocking. When pw runs as part of a shell background job, it continues to consume input, process filters and take snapshots, without displaying anything. When put into the foreground again, display resumes. For instance the command "tcpdump -i -l | pw" turns tcpdump into an interactive network monitoring tool in which you can use the dynamic filtering in pw to select different kinds of packets, and use the trigger feature to capture certain patterns of interaction. pw is like an oscilloscope for text streams. Digital oscilloscopes sample the signal and pass it through a fifo, which is sampled to the oscilloscope screen, and can trigger the sampling on certain conditions in the signal to make waveforms appear to stand still. pw does something like that for text streams. I am rather intrigued by this program. It's the sort of "swiss army knife" kind of tool that kind of makes no sense until you find a purpose for it. I've been trying to figure out where this tool fits in my toolbox and, just today, I was trying to find out what this silly Purism Librem firmware upgrade tool was doing in the background, with `ps axfu`. But I was having all this garbage out there, and it was hard to filter things out properly. I might have been able to pull something out with `watch`, but I think pw might have been better for this particular case. I'm also quite interested in using it to analyse logs or packet dumps during attacks or outages. Another similarly named package, already in Debian (and maintained by yours truly) is `pv`, the "pipe viewer". But it has a completely different function; whereas pw shows you the content of the pipe in a specific way, pv just counts lines or bytes going through it, specifically without showing you its content. There is another tool similar to "watch" that overlaps with this a little bit: https://github.com/sachaos/viddy ... it's basically the "watch" command with history. It supports searching (which pw does, and probably better) and going back in history (which pw does not). I had a hard time finding that package name again, for what that's worth... I suspect I could also forget the name `pw` quite quickly, but by packaging it, I guess I'm more confident I will forget it less. :p Probably the worst reason to package something ever, but there you go, that's how I ended up maintaining pv in the first place, so probably that means.. uh... something good something.
Re: Backdoor in Debian (Testing and Stable), X11, Illegal Wiretap, See Image
On 2022-08-20 15:04, michaelb wrote: 8/20/22 Regards, Michael (You should be able to see a white line at the top)
Re: Epoch for node-markdown-it
On ശ, ഓഗ 20, 2022 at 3:53 വൈകു, Holger Levsen wrote: On Sat, Aug 20, 2022 at 03:29:59PM +, Stefano Rivera wrote: > > Epochs cause problems, [...] > which are? (I agree they are ugly and should often be avoided, but I don't > see any unsolved problems with them, which is why I'm asking.) The standard one is that people use them to revert an upload. ok, I agree that's bad. (but not the case here.) But, epochs aren't used in the upstream tarball filename, so you then easily get a conflict between the old and the new one. I'd replace 'easily' with 'theoretically in rare cases' but I can see how this is a valid point, sometimes. I think the only real consequence for this is a dak reject which can be fixed by a new upload with +debian suffix. Say when upstream again release 22.3 version, 1:22.3 orig.tar will have a different checksum from 22.3 orig.tar. If at all dak keeps history of the tar after so many releases. At that point, just uploading 1:22.3+debian will allow dak to accept the new tarball. Am I missing something here? If this is indeed the case, it feels like many people are blindly chanting epoch is evil without really understanding what is at stake really.
Bug#1017808: ITP: zfp -- Fixed-Rate Compressed Floating-Point Arrays
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: zfp Version : 1.0.0 Upstream Authors: Peter Lindstrom URL : https://github.com/LLNL/zfp * License : BSD-3-clause Description : Fixed-Rate Compressed Floating-Point Arrays This is a compressed format for representing multidimensional floating-point and integer arrays. zfp provides compressed-array classes that support high throughput read and write random access to individual array elements. zfp also supports serial and parallel (OpenMP and CUDA) compression of whole arrays, e.g., for applications that read and write large data sets to and from disk. It has bindings for C, C++, Fortran, and Python, as well as a cli tool
Re: Epoch for node-markdown-it
On വെ, ഓഗ 19, 2022 at 6:00 വൈകു, Simon McVittie wrote: On Fri, 19 Aug 2022 at 21:36:24 +0530, Pirate Praveen wrote: Are we going to deny every epoch request or this is going to be subjective? If there was a correct objective rule for what to do, we'd be applying that rule mechanically, not asking our fellow developers for advice. Epochs cause problems, but sometimes the alternatives are worse. Deciding which is the least-bad option is inherently a subjective question and you are not going to get an objective answer to it. I think we can document the most commonly occuring cases and their pros and cons for the epoch, only if something is not covered by the common case we should ask in -devel. Current way of long thread on -devel for every epoch bump is too much demotivating and time draining for very little benefit. People just repeat the same boilerplate arguments without even looking at the specifics of the case most of the time. Is the opinions on -devel binding? What if when conflicting opinions are there? For example I'm convinced we need an epoch here, there are people who objected, can I still go ahead and upload with epoch? I do not have a strong opinion either way on this particular situation without knowing where 22.2.3 came from. As a way to mitigate this sort of thing in future, I'd suggest that maintainers/sponsors should confirm whether upstreams were intentionally doing a multi-version jump like that one before uploading the new version. I don't think this is going to be foolproof. smcv
