Re: xz backdoor
On 31 March 2024 12:39:55 CEST, Johannes Schauer Marin Rodrigues wrote: > >Another example is when I wanted to run a GUI program inside an unshared chroot >environment. Wayland does not seem to be happy about that and I didn't find a >way to test my GUI application successfully. But maybe my container environment >just fails to set up some things? Does there exist a way to test GUI >applications inside a container without requiring superuser privileges to run >the container? Hi, At least with (unprivileged) Podman containers, I have success with just passing the host's Wayland socket as a volume with the -v switch. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Understanding what's missing for Rust dynamic linking (was: Proposal for how to deal with Go/Rust/etc security bugs)
Hello. Paul Wise writes: > On Thu, 2024-01-25 at 00:24 +, Wookey wrote: > >> People keep telling us (@ARM) how marvellous Rust is, and we keep >> telling them that it's useless in the real world until it sorts out >> the stable ABI/dynamic linking problem. > > IIRC that has been worked on for some years now, and IIRC > the static linking wiki page has some references about this. > > https://wiki.debian.org/StaticLinking This reminded me that I'm not even sure that I fully understand what Rust's remaining technical obstacles to achieving dynamic linking (at least within Debian) are. I'm ignoring the potential cultural or political issues that have been alluded to by others. My understanding – and please do correct me! – has been that three components are missing: (1) A stable ABI. (2) A way of dealing with generic types/functions across dynamic linking boundaries. (3) A way of dealing with macros across dynamic linking boundaries. From Debian's perspective, is really (1) all that important given that a stable release only has to deal with a specific version of the compiler? Could we not live with every new version of *just* rustc in sid introducing a transition with a rebuild of every Rust package? As for (2): Since Debian has the privilege of having a complete overview of the "closed system" of all Rust packages that we need to consider, could we not conceivably make a pass across all Rust packages in the entire archive and record every concrete version of every generic type/function ever used? Then when a particular library package is built, we would force the monomorphization of all the relevant types/functions in that shared library's public interface. This would require tooling support from upstream to force generation of monomorphized versions of types/functions when building each shared library, but that in itself does not seem impossible. (As a curious effect, the introduction of a new package may then trigger the need to rebuild some of its own dependencies due to new monomorphic versions of functions being needed that had not been seen in the archive before.) Similarly, for (3), could we expand every macro in every library as needed by every depending package in the archive? Just trying to get a handle on how far we are from a solution of sorts, apologies for any stupid questions. Best, Gard signature.asc Description: PGP signature
Re: Bug#1041731: Hyphens in man pages
On October 16, 2023 2:41:08 AM GMT+02:00, "Trent W. Buck" wrote: >FWIW, there are lighter alternatives than pandoc: > >pandoc:After this operation, 174 MB of > additional disk space will be used. >sphinx-doc (sphinx-build -b man): After this operation, 140 MB of > additional disk space will be used. >rst2man (python3-docutils):After this operation, 37.6 MB of > additional disk space will be used. >pod2man (perl):perl is already the newest version > (5.36.0-9). > >I'm not going to bother measuring docbook ;-) I've also found scdoc to be a quite pleasant and very lightweight alternative: https://tracker.debian.org/pkg/scdoc -- Gard
Re: allow missing description fields and empty long descriptions for Rust/etc packages?
Hi Johannes, Johannes Schauer Marin Rodrigues writes: > Quoting Gard Spreemann (2023-09-20 09:26:58) >> Paul Wise writes: >> > […] since the Rust packages are basically only used as build-deps and >> > therefore have no human users. >> I just wanted to raise awareness that some of us humans do use librust-*-dev >> packages directly, having put cargo in permanent offline mode and having >> swapped out its cargo.io package source for Debian's packages on the local >> filesystem. > > do you have more details on how you achieve this? > > I'm using Debian's rust packages instead of creates.io using this wrapper > script to cargo: > > https://salsa.debian.org/josch/nocrates.io/-/blob/master/cargowrapper.sh > > How do you do it? My ~/.cargo/config.toml reads: [net] offline = true [source] [source.crates-io] replace-with = "debian" [source.debian] directory = "/usr/share/cargo/registry" This works really well in my case. As far as smooth solutions for opting in to crates.io in particular circumstances, I and others have collected some notes on [1]. But in reality I get very far with the above Cargo config + manually adding the odd crate (or crate version) when it's not available in Debian. [1] https://stackoverflow.com/q/69802360/453616 Best, Gard signature.asc Description: PGP signature
Re: allow missing description fields and empty long descriptions for Rust/etc packages?
Hi, Paul Wise writes: > […] since the Rust packages are basically only used as build-deps and > therefore have no human users. I just wanted to raise awareness that some of us humans do use librust-*-dev packages directly, having put cargo in permanent offline mode and having swapped out its cargo.io package source for Debian's packages on the local filesystem. Otherwise no objection to your overall point here. Best, Gard signature.asc Description: PGP signature
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
"M. Zhou" writes: > On Sat, 2022-08-27 at 09:50 +0200, Gard Spreemann wrote: >> >> I humbly disagree. Even from my own point of view, I may well be very >> motivated to package something I use seriously all the time, >> seriously. But then I see its dependency chain of 10 unpackaged >> items, >> start thinking about the probability that they'll *all* clear the NEW >> queue, and how long that would take, and I give up. And then there's >> the >> problem of attracting smaller contributions, as mentioned above: I >> really believe that people get put off from putting in 30 minutes of >> work for a nice MR on Salsa if they can't expect their work to hit >> the >> archives for months and months (suppose for example they contributed >> to >> a package whose SONAME is being bumped). > > I agree with your disagreement but I keep my opinion. My track record > involves maintaining loads of reverse dependency libraries. I've > already gone through all kinds of pains from the NEW queue and > eventually learned to take a break immediately after uploading > something to new. > I consider you quite the hero for your massive contributions to the Debian deep learning ecosystem. But I do worry that there aren't enough Mo Zhous in the world ;-) > That said, if someone presents a GR proposal I'll join. In Debian, > it is not that easy to push something forward unless it hurts everyone. > Our NEW queue mechanism has been there for decades, and people are > already accustomed to it (including me). From multiple times of > discussion in the past, I don't see the NEW queue problem hurting > too many people. If nothing gets changed in the NEW queue mechanism, > people may gradually get used to it, following the "do not fix it > if it ain't wrong" rule. The voice will gradually vanish. … or people quietly vanish from contributing. Best, Gard signature.asc Description: PGP signature
Re: Current NEW review process saps developer motivation
Gard Spreemann writes: > Oh no, then we instead insist that related work stops Sorry, this was imprecise of me. We of course don't insist that related work stops. But I really fear that that is the consequence in a great many cases. -- Gard
Re: Current NEW review process saps developer motivation
Paul Wise writes: > There are a lot of examples of busywork in Debian, such as documenting > licenses, packaging dependencies, removing non-free files that are only > in source packages, runtime selection of correct CPU instructions, > fixing build failures, porting reverse dependencies to newer versions > of APIs etc. All of these are things that contributors complain about > and get burned out by us requiring or even suggesting. All of them > however are necessary in some way. I think the requirements around > source and building are just another example of this. Indeed. But is it necessary that this busywork be checked in the way it's currently checked, as the package passes through NEW? Why does it only have to be checked this way when a package name changes or there's a new binary being built? The rest of the time we seem fine catching all of these kinds of things through bug reports. We trust each other not to violate Policy. If we do find violations, we file serious bugs, and expect those to be acted upon. But not if there's a new package name! Oh no, then we instead insist that related work stops, and have the developer wait for months for detailed manual review by overworked reviewers. Best, Gard signature.asc Description: PGP signature
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
"M. Zhou" writes: > To be honest, in terms of volunteered reviewing work, waiting > for several months is not something new. In academia, it may > take several months to years to get a journal paper response. Sure, but (1) that situation isn't popular in academia either, (2) at least you can put your work on arXiv or similar and have it be useful to people right away, and (3) a paper that's finally accepted (usually) doesn't ever have to be updated, and doesn't risk needing to go through the process again. And new papers don't require updates to old papers, usually. An analogy following from (3): how great fun it would be if a substantial paper correction would require no review from the publishing journal, but a title change would require a completely new peer review process! (Yes, the idea of a title change is far fetched, but still.) Seems a bit arbitrary to me. > I've ever tried to think of possible ways to improve the process, but > several observations eventually changed my mind, and I'm willing > to accept the status quo. > > * there is a trade-off between rigorousness and efficiency. > Any change in the process may induce disadvantages, where > the most difficult thing is to reach an agreement. > * we will add more work for ftp team if we get them involved in the > discussion of possible (but unsure) ways to improve NEW. > > My ultimate opinion on NEW processing is neutral, and my only > hope for ftp team is to increase the pace of hiring new members. > To be concrete, it is much harder to write a concrete proposal > to debian-vote@l.d.o than discussing possibilities. > > I understand we may have the enthusiasm to sprint on something. > However, in terms of the long-term endeavor on Debian development, > the negligible popcon number won't be less disappointing than > a long-term wait to clear the NEW queue. I don't think I'm worried about people being disappointed (by say an RC bug being filed due to a copyright issue – correctness is far more important than not being disappointed). I'm worried about the extremely long time horizons putting people off from contributing in the first place, because it requires focus and planning across a time gap that is so many orders of magnitude longer than the time spent doing the actual contributing work. In some sense, contributing to Debian becomes mostly about waiting. (Sure, there is something to be said about extremely short, fragmented attention spans being unhealthy – but some contributions are naturally short and easy, and we certainly don't want to drive those away.) > If one's enthusiasm on working on some package is eventually > worn out after a break, then try to think of the following question: > > Is it really necessary to introduce XXX to Debian? I hope we won't try to define what "necessary" means, or have it become a criterion for inclusion :-) > Must I do this to have fun? I don't think Debian contribution has ever been a necessary condition for fun. That's an incredibly high bar. If we were only to attract people whose only idea of fun was contributing to Debian, I think we'd become a very unhealthy project (and one severely lacking in contributors). > Strong motivations such as "I use this package, seriously" are not > likely to wear out very easily through time. Packages maintained > with a strong motivation are better cared among all packages in our > archive. I humbly disagree. Even from my own point of view, I may well be very motivated to package something I use seriously all the time, seriously. But then I see its dependency chain of 10 unpackaged items, start thinking about the probability that they'll *all* clear the NEW queue, and how long that would take, and I give up. And then there's the problem of attracting smaller contributions, as mentioned above: I really believe that people get put off from putting in 30 minutes of work for a nice MR on Salsa if they can't expect their work to hit the archives for months and months (suppose for example they contributed to a package whose SONAME is being bumped). > Why not calm down, and try to do something else as interesting > as Debian development when waiting for the NEW queue? Sure. That's what I do. My list of joyful and less joyful things to fill my days with is enormous. **BUT: I worry for the project if our solution to the problem at hand is "maybe just contribute less to Debian".** Is that really what we want? Best, Gard signature.asc Description: PGP signature
Re: Current NEW review process saps developer motivation [Was: Looking for new maintainer(s) for GStreamer packages]
Jonas Smedegaard writes: > Quoting Gard Spreemann (2022-08-26 08:49:21) >> On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge" >> wrote: >> >PS: To preempt any questions as for why, the background for my decision >> >to stop maintaining any packages is this thread, but it's really just >> >the straw that broke the camel's back >> > >> > https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html >> > >> >> A bit off-topic, but I think we really ought to discuss (address?) >> this elephant in the room once more. I don't have the answers, but >> Sebastian's email yet again clearly illustrates how the status quo >> is hurting the project. This clear example comes in addition to >> worries raised before about what the status quo does to recruitment >> of new developers. >> >> PS: I do not imply that the elephant in the room is the >> ftpmasters. I'm thinking of the *process*. The people involved put >> in admirable work in carrying out said process. > > The way I see it, the process is clear: provide *source* to build from. > > If there is "source" built from another source, then that other source > is the true source. > > If ftpmasters sometimes approve intermediary works as source, then that > is not a reason to complain that they are inconsistent - it is a reason > to acknowledge that ftpmasters try their best just as the rest of us, > and that the true source is the true source regardless of misssing it > sometimes. > > Yes, this is painful. Yes, upstreams sometimes consider us stupid to > care about this. Nothing new there, and not a reason to stop do it. > > If you disagree, then please *elaborate* on what you find sensible - > don't assume we all agree and you can only state that the process is an > elephant. Apologies, I should have been a lot clearer. I did not mean the exact issue of what is the "true source" of something in a package. Rather, I was referring to the process itself (looking in particular to the last three paragraphs and the PS in Sebastian's linked email [1]). Whatever the correct answer to what a "true source" is, in the current process, a developer has to make an attempt at doing the right thing, and then wait *weeks or possibly months* to know for sure whether it was OK. And if it's deemed not OK, the reasoning may be entirely specific to the exact package and situation at hand, and therefore extremely hard to generalize and to learn from. (Do not construe the above as "ftpmasters should work faster and give more lengthy reasoning!" – adding *more* work to the process would make things even worse in my opinion.) Although I maintain a very small number of packages, and ones that also very rarely have to re-clear NEW, even I feel sapped of motivation from the process. And I read Sebastian's email partly as an expression of the same thing (apologies if I misconstrue your views, Sebastian). I do believe similar points of view have been aired on the list before by others too. As to your last point, elaborating on what I find sensible: I sadly don't have a good suggestion. I do believe it is possible to point out that the status quo is harmful without knowing how to sensibly fix it, though. That's what discussions are for :-) I am presently unable to find the message I'm thinking of, but I seem to recall one proposal being raised in the past: trust that a developer has done everything right, and introduce a class of bugs that can cause complete removal from the archive instead. Afterall, we do assume that the developer does the technical things correctly, until such a time as a bug is filed. Could we not also make the same assumptions for Policy and Social Contract things? [1] https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html Best, Gard signature.asc Description: PGP signature
Current NEW review process saps developer motivation [Was: Looking for new maintainer(s) for GStreamer packages]
On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge" wrote: >PS: To preempt any questions as for why, the background for my decision >to stop maintaining any packages is this thread, but it's really just >the straw that broke the camel's back > > https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html > A bit off-topic, but I think we really ought to discuss (address?) this elephant in the room once more. I don't have the answers, but Sebastian's email yet again clearly illustrates how the status quo is hurting the project. This clear example comes in addition to worries raised before about what the status quo does to recruitment of new developers. PS: I do not imply that the elephant in the room is the ftpmasters. I'm thinking of the *process*. The people involved put in admirable work in carrying out said process. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#1017994: ITP: zigpy -- Python Zigbee stack
Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org Owner: Gard Spreemann Severity: wishlist * Package name: zigpy Version : 0.50.1 Upstream Author : Russell Cloran and contributors * URL : https://github.com/zigpy/zigpy * License : GPL-3+ Programming Lang: Python Description : Python Zigbee stack zigpy is a hardware independent Zigbee protocol stack integration project to implement Zigbee standard specifications as a Python 3 library. Zigbee integration via zigpy allows you to connect one of many off-the-shelf Zigbee Coordinator adapters using one of the available Zigbee radio library modules compatible with zigpy to control Zigbee based devices. There is currently support for controlling Zigbee device types such as binary sensors (e.g., motion and door sensors), sensors (e.g., temperature sensors), lights, switches, buttons, covers, fans, climate control equipment, locks, and intruder alarm system devices. The package is useful for interacting over the increasingly widespread Zigbee home automation and IoT protocol. An RFP was made last year [1]. I intend to maintain the package myself. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002638 signature.asc Description: PGP signature
Re: Bug#1012712: ITP: ai -- PHP library to develop easily SQL queries usable in web pages
Georges Khaznadar writes: > Package: wnpp > Severity: wishlist > Owner: Georges Khaznadar > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name: ai > Version : 0.03 > Upstream Author : François Élie > * URL : https://gitlab.adullact.net/felie/ai > * License : AGPL > Programming Lang: PHP > Description : PHP library to develop easily SQL queries usable in web > pages > > AI is an Allmighty Intelligence: just think about the SQL query which > you would use in MySQL's command line, or in phpmyadmin, and AI offers you > the right code to display its results in a web page. Unfortunately, AI > can not yet read your mind directly: you've got to type the query. Hi, The proposed very generic, two-letter source package name "ai" seems like too prime namespace real estate for something like this, being an established initialism for a well-known and entirely unrelated concept. How about something along the lines of "allmighty-intelligence"? Best, Gard signature.asc Description: PGP signature
Re: isa-support -- exit strategy?
Bastian Blank writes: > On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote: >> SIMDe (or similar approaches) could be used to build variant(s) of the >> library that have compile-time emulation of SIMD instructions in the >> lower baseline builds of vectorscan. > > But why? Who in their right mind would ever try to use those aweful > slow implementations? I don't know in this particular case, but somewhat analogously: Very few people in their right minds do deep learning on CPUs. Yet, I'm extremely happy that PyTorch is in Debian (thanks to the hard work of Mo Zhou!), even if it's CPU-only. It means that I can develop and test-run code on my machine using just Debian packages, before shipping it off to the actual compute infrastructure where GPUs do the heavy lifting on a GPU-enabled non-Debian PyTorch. I can imagine that there are people who do the same with lacking SIMD instructions. Best, Gard signature.asc Description: PGP signature
Re: No mips64el porterbox?
Julien Puydt writes: > Hi, > > one of my package has a failure on mips64el and upstream is ready to > help me find the cause and debug the issue. > > Unfortunately, on https://db.debian.org/machines.cgi I only see five > developer machines on this architecture -- all buildd! > > Is there really no mips64el porterbox, or is it only a transitory > situation? Hi, How about eller.debian.org? $ uname -a Linux eller 4.19.0-18-octeon #1 SMP Debian 4.19.208-1 (2021-09-29) mips64 GNU/Linux $ lscpu Architecture:mips64 Byte Order: Little Endian -- Gard signature.asc Description: PGP signature
Re: LESS copyright, not more!
Adam Borowski writes: > Guys, once again we had a complaint about forcing people to waste their time > on copyright matters then wait months or years for review of said matters > -- just for the discussion degenerate into a proposal to bring even MORE > copyright into our life! > >> - What is REUSE? >> The REUSE specification [1] is a specification to make copyright >> machine-readable in the source files itself. It is straightforward to >> implement, add (e.g.) "SPDX-FileCopyrightText: 2019 Jane Doe > [...] >> The spec is made by the Free Software Foundation Europe (FSFE) and is >> already implemented in several projects [3]. > > ... and this proposal includes gems such as an extra copyright-only file per > every image. Dᴏ ɴᴏᴛ ᴡᴀɴᴛ! > > The Social Contract says clearly: > "Our priorities are our users and free software" > -- NOT copyright lawyers. > > I, and probably others, consider copyright to be a crime against humanity > -- and this is not just a figure of speech[1]. We are forced to comply > with these laws, risking fines and violence if we don't, but why should > we put more effort than the minimum necessary? To better protect our users as they exercise point 1 of the DFSG, obviously! We can disagree about what the right amount of such effort is, and its diminishing returns, but I don't see how the intention/objective itself is at question here. -- Gard signature.asc Description: PGP signature
Re: Please participate in Debian Med sprint (Was: 20 years of Debian Med list :-) and suggested sprint date)
Andreas Tille writes: > Hi again, > > I've just created a preliminary Sprint page[2]. At the top I've added a > table to summarise first responses of participants about the date. > Seems we have a vague preference for the date 2022-02-18 - 2021-02-20. > > I'd be really happy if more interested people would show up and add > the prefered date to get a final decision about the sprint date. I don't have push access to the repo, but feel free to add that I can probably join on the 18th and on the 20th of February, if you end up picking 18-20. -- Gard signature.asc Description: PGP signature
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
Adam Borowski writes: > On Tue, Jan 25, 2022 at 09:38:01PM +0100, Vincent Bernat wrote: >> For me, the copyright check is just a bad excuse. People upload >> non-distributable stuff everywhere and it seems the world continue to go >> round. What amount of non-distributable packages is stopped by the NEW >> queue? >> >> I think we should forego the NEW queue. If people want to check >> packages, they can do it once they are in unstable with regular bugs. > > Without the NEW queue, there would be no point at which packaging receives > any sort of review. I'd prefer Debian to deliver at least some level of > quality. > > Otherwise, we'd fall to the level of NPM. And there's ample examples what > that would mean. Is this not the job of the Policy and of community self-policing by means of RC bugs? Best, Gard signature.asc Description: PGP signature
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
Jonas Smedegaard writes: > Quoting Vincent Bernat (2022-01-25 21:38:01) >> I didn't comment at first because I thought someone else would raise >> the idea. But it seems people still like the idea of a NEW queue. Not >> me. The NEW queue is a hindrance. > > For the record, I don't "like" the NEW queue. > > I don't like current copyright laws, and I suspect a fair amount of > people involved in Free Software doesn't. > > I just don't think the solution is to ignore copyright or licensing > statements. To me, the elephant in the room is this question: Does the way the NEW queue currently works provide good (good enough?) assurances to ourselves that we are *not* ignoring copyright or licensing? It feels like we are answering "yes" based on the amount of heroic work the FTP masters put in, and the amount of waiting developers have to suffer through. We're gauging our solution to a problem solely by the amount of effort, sweat and tears we put in, so to speak. Best, Gard signature.asc Description: PGP signature
Re: What are the most important projects that Debian ought to work on?
Sébastien Delafond writes: > Hello, > > As part of an upcoming survey that we are preparing, we plan to ask > Debian developers to rank, by order of importance, the most popular > ideas of improvements for Debian. > > However, there's no easy way to identify what are the most popular ideas > of improvements that Debian ought to make. We know of the > "grow-your-ideas" project on Salsa, but it's far from exhaustive: > > https://salsa.debian.org/debian/grow-your-ideas > > That's where you come into play: it would be nice if you could share > what are — according to you — the most important projects/improvements > that Debian ought to make. You can share your ideas here by replying to > this email, but it would be interesting to file them as new issues in > the "grow-your-ideas" project and then reply here pointing to your new > issue: I've added https://salsa.debian.org/debian/grow-your-ideas/-/issues/11 about the NEW queue. Best, Gard signature.asc Description: PGP signature
Re: uscan roadmap
Jonas Smedegaard writes: > Quoting Gard Spreemann (2021-12-02 13:09:17) >> >> Jonas Smedegaard writes: >> >> > Quoting Gard Spreemann (2021-12-02 12:31:30) >> >> >> >> Paul Wise writes: >> >> >> >> > I also wonder if it is time to split debian/watch out of Debian >> >> > source packages, since upstream download locations generally >> >> > change independently of the Debian package and so information >> >> > about upstream download locations probably should be maintained >> >> > independently. >> >> >> >> I very much agree. I don't understand the logic of tying upstream >> >> checking to a particular version of a source package. The fact that >> >> some version of a package once upon a time could locate and >> >> download new upstream versions using a particular recipe is of no >> >> use if said recipe becomes outdated at any later time. >> >> >> >> It makes a lot more sense to provide this service in a way that >> >> allows it to be modified/updated/improved/fixed with no regards to >> >> the actual packages that may use it. That could be as simple as a >> >> uscan service with watch files that can be individually and >> >> independently modified. >> > >> > I find it helpful for our packages to include information about >> > where and how (at the time of its release) that package was >> > monitoring for upstream releases. It helps working decentralized - >> > both for preparing packages for Debian and for working on >> > Debian-derived packages, both without needing access to somewhere >> > central for this "watch" information. >> >> Would it make sense for a package to contain a snapshot of the >> relevant metadata in the hypothetical "centralized-and-often-updated >> watch service" at the time in enters into the archives? > > Not _instead_ of current location: What I find helpful is to have the > watch file available with the source package. I am unaware if there > would be some benefit of _additionally_ embedding the watch file in > binary packages (if that's what you meant). > > >> > Therefore I like the proposal to have Debian project scanners >> > aggressively look for _newest_ watch file for a packaging project, >> > including looking up declared Vcs-* hints for not-yet-released work. >> >> Indeed, that sounds like a better idea than what I suggest above! > > Not sure if you noticed, but (since I won't steal credit) I basically > emphasized Pabs' suggestion in last paragraph of what you previously > quoted: > > Quoting Paul Wise (2021-12-02 00:47:44) >> Alternatively, perhaps we could workaround outdated debian/watch files >> by having vcswatch extract debian/watch files from the repo specified >> in the Vcs-* URLs. Apologies; I somehow thought that he meant auto-generating watch files from *upstream* VCSs. My bad, and thanks for clarifying! -- Gard signature.asc Description: PGP signature
Re: uscan roadmap
Jonas Smedegaard writes: > Quoting Gard Spreemann (2021-12-02 12:31:30) >> >> Paul Wise writes: >> >> > I also wonder if it is time to split debian/watch out of Debian >> > source packages, since upstream download locations generally change >> > independently of the Debian package and so information about >> > upstream download locations probably should be maintained >> > independently. >> >> I very much agree. I don't understand the logic of tying upstream >> checking to a particular version of a source package. The fact that >> some version of a package once upon a time could locate and download >> new upstream versions using a particular recipe is of no use if said >> recipe becomes outdated at any later time. >> >> It makes a lot more sense to provide this service in a way that allows >> it to be modified/updated/improved/fixed with no regards to the actual >> packages that may use it. That could be as simple as a uscan service >> with watch files that can be individually and independently modified. > > I find it helpful for our packages to include information about where > and how (at the time of its release) that package was monitoring for > upstream releases. It helps working decentralized - both for preparing > packages for Debian and for working on Debian-derived packages, both > without needing access to somewhere central for this "watch" > information. Would it make sense for a package to contain a snapshot of the relevant metadata in the hypothetical "centralized-and-often-updated watch service" at the time in enters into the archives? > Therefore I like the proposal to have Debian project scanners > aggressively look for _newest_ watch file for a packaging project, > including looking up declared Vcs-* hints for not-yet-released work. Indeed, that sounds like a better idea than what I suggest above! -- Gard signature.asc Description: PGP signature
Re: uscan roadmap
Paul Wise writes: > I also wonder if it is time to split debian/watch out of Debian source > packages, since upstream download locations generally change > independently of the Debian package and so information about upstream > download locations probably should be maintained independently. I very much agree. I don't understand the logic of tying upstream checking to a particular version of a source package. The fact that some version of a package once upon a time could locate and download new upstream versions using a particular recipe is of no use if said recipe becomes outdated at any later time. It makes a lot more sense to provide this service in a way that allows it to be modified/updated/improved/fixed with no regards to the actual packages that may use it. That could be as simple as a uscan service with watch files that can be individually and independently modified. Best, Gard signature.asc Description: PGP signature
Re: Looking for DDs to sign my keys in Norway, Bergen area
On November 22, 2021 5:24:57 PM GMT+01:00, Marius Gripsgard wrote: >Hi, > > >I am looking for someone to sign my keys, but due to covid this has not >been easy to do, so im looking for someone in my local area that would >be up to do a key signing. I have already looked at the offering page, >but none is close to me. (closed is oslo, this might be an option, but >its a 8H drive/train). If you are close to bergen, norway and are >willing to sign my key, please hit me up. > > >Thank you, > >Marius Gripsgard > Hi Marius, I'll be in Bergen the week before christmas, from Wednesday at least. I'm happy to sign your key if we can meet downtown at a reasonable hour. Let me know! Best, Gard -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
Andrey Rahmatullin writes: > On Thu, Nov 18, 2021 at 04:08:23PM +0100, Stephan Lachnit wrote: >> > > I don't know if that has been proposed before, but how about waiving >> > > the NEW queue requirement for experimental packages as a start? >> > > [...] Since packages in experimental will never land in any >> > > official release, I think dropping the NEW queue requirement has no >> > > negative impact. >> > This makes no sense as NEW is mostly about checking licenses. >> >> I think this is exactly why it makes sense. I think we can trust the >> DDs to not make any large mistakes (e.g. putting steam in main). > The existence of NEW means we currently don't, for completely new > packages. > >> Since packages in experimental aren't supposed to be used by anyone else >> but the DDs themselves, the "damage" of a potentially missing / wrong >> license is minimal, considering that DDs are aware of the fact that the >> packages aren't "official". > The "damage" that's usually being discussed is Debian distributing > something we can't, not users e.g. getting non-free software thinking it's > free. Packages in NEW aren't even publicly accessible because of this, > and discussions of switching to git-based source packages end with "we > can't publish git history of random repos as we don't want to review > and rewrite it". > >> However I find that view a bit weird. Any update can change the license >> or add new files with different licenses, nothing is ever checked by the >> ftp-masters (that would be insanity). > Sure. And in light of the above, assume: - Source package foo with a single binary package foo, entered Debian under thorough FTP Masters checking 20 years ago, has had a very active upstream and rapid development (including numerous rewrites and language changes) since then, but always just that single binary package. - Source package bar that ships a binary libbarN, entered Debian under thorough FTP Masters checking a few weeks ago after NEW queueing for months. Slowly developing upstream with few, very limited and organized, changes over time. Needs a SONAME bump. Or needs to add a new bar-utils binary, or something. If the goal is to maximize our users' confidence that foo and bar can be assumed DFSG-compliant, then it does not to me seem like the best use of our (FTP Masters') limited resources to subject bar to another thorough review (perhaps having it spend another 4 months in NEW?), while trusting the maintainer of foo with no further scrutiny. I'd go as far as to say that if we could not trust the maintainer of foo the way we do, we could not reasonably make Debian work. And if we can trust the maintainer of foo with a task where it's arguably easier to make a mistake than it is for the maintainer of bar, and we cannot trust the maintainer of bar in that safer case, then we are quite inconsistent. I would argue that this inconsitency is problematic, both because it leads to a misapplication of resources, because it may well convey a false sense of safety onto our users, and because it may be detrimental to attracting new volunteers. -- Gard signature.asc Description: PGP signature
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
Simon Richter writes: > Hi, > > On 11/18/21 4:08 PM, Stephan Lachnit wrote: > >> I guess this raises the (maybe already answered) question if the >> additional license QA from NEW is for the end-product (i.e. Debian >> stable) or for the servers that run the Debian infrastructure, which >> of course includes experimental. > > The latter. > > The license must allow Debian to redistribute the package. This is > checked very thoroughly on the initial upload, and updates are > expected to keep the same licensing. Whether that expectation still > holds with upstreams who prefer vendor copies over using external > packages is another matter, but in general these packages require more > handholding anyway. I struggle to see how this assumption is reasonable at all, even keeping vendoring upstreams out of the picture. It is hardly uncommon for non-giant projects to re-license themselves one or more times after the initial Debian package has cleared the NEW queue. The larger our archive, and the more time passes, the more packages we can expect to be shipping whose d/copyright's relationship with reality was never checked by the FTP Masters. -- Gard signature.asc Description: PGP signature
Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
Hi all. Johannes Schauer Marin Rodrigues writes: > slightly related question: if I upload a new version to NEW, will the Age of > the package be reset? I'm asking because my package has been in NEW for four > months already and I'd like to avoid loosing that place by an upload of a new > upstream version. Every time I see stories like this, I wonder what the consequences of the NEW queue's current workings are. This is *not* criticism of the heroic work of the FTP Masters, nor is it criticism of the objectives they have in processing the NEW queue. I do, however, worry that months of waiting to see the fruits of one's labor might be detrimental to attracting new contributors, or indeed to motivate already active ones. It also seems to be a not insigificant impediment to getting useful work, such as a SONAME bump, done quickly. At least personally, I find it harder to put in small pieces of work that result in incremental improvements if the result is having to wait months – with the added uncertainty of having to do it all again (for good reasons, but nevertheless). It may well be that I'm asking the impossible here, but it does seem to be a problem that other distributions don't suffer under to the same extent. Is it merely a matter of their standards being lower, or is there some room for improvement on our part? Apologies in advance if this is something that has been discussed a lot in the past. I'd be very interested in being pointed in the right direction in that case! Best, Gard signature.asc Description: PGP signature
Re: Have the watch file checks stopped?
Mattia Rizzolo writes: > On Mon, Aug 23, 2021 at 12:59:39PM +0200, Gard Spreemann wrote: >> Have the uscan watch file checks that feed qa.debian.org stopped? Is it >> on purpose? Perhaps a consequence of the recent release? > > That's one part that's included in the UDD downtime reported here: > https://lists.debian.org/debian-qa/2021/08/msg0.html Thanks, and sorry for the noise - I should have checked the QA list. -- Gard signature.asc Description: PGP signature
Have the watch file checks stopped?
Hi list, Have the uscan watch file checks that feed qa.debian.org stopped? Is it on purpose? Perhaps a consequence of the recent release? Best, Gard signature.asc Description: PGP signature
Re: Cancel "culture" is a threat to Debian
Dmitry Smirnov writes: > Nobody is perfect. Everybody said a foolish thing at least once in a > lifetime. If we cancel those who love what they do, those who are good > with what they do, those who are passionate and caring for what they do > for something they have said somewhere else then eventually there will > be nobody left. In order to calibrate what is considered merely "a foolish thing said" from your perspective, I feel a need to ask: what is, from your perspective, the least of the sufficiently bad things that a person can do in order for Debian to officially call out said person's behavior? What is (roughly) the smallest offense that *you* would consider too bad for Debian to accept? Best, Gard signature.asc Description: PGP signature
Re: Changed Github download URLs are affecting lots of existing watch files
Phil Morrell writes: > Sounds like you're asking for a new github redirector on qa.debian.org > as there is for sf.net, which could use the official api for stability. This got me thinking: the version checking mechanism of d/watch files is useless if the outside world changes, i.e. if upstream's URLs change. Why do we then ship this logic with the packages at all, when packages are meant to be useful for an extended amount of time? Would it not be better to decouple the version-checking aspect of d/watch entirely from the actual package tarball? Uscan could then unconditionally pull version information from something à la det the sf.net and PyPI redirectors. The data in that system is then kept updated when upstream changes. -- Gard signature.asc Description: PGP signature
Re: I'm orphan my packages and leave the project as maintainer
Timothy M Butterworth writes: > The FSF with out RMS would be like the Linux Foundations with out > Linus. To me, and I dare guess, to most people, the actions of RMS are not being weighted against the important contributions he has made. Many of us believe that he has crossed certain lines that cause his behavior to be a problem nomatter how enormous his contributions are. > With their personality quirks it is sometimes hard for some people to > like them but at the end of the day they get the job done. I hope that you do see that there is not a general agreement that the term "personality quirks" covers the behavior being dicussed. > RMS has done alot for FLOSS it would be sad to see his contributions > come to a halt but he can always write software and contribute that > way I guess. This is not a debate about whether or not RMS has done enough for free software for his behavior to be excused. -- Gard signature.asc Description: PGP signature
Re: Fixed release dates are hurting quality
Adrian Bunk writes: > On Sun, Feb 07, 2021 at 05:19:17PM +0100, Gard Spreemann wrote: >> and instead try to track positive attributes like fitness for >> release, though? > > Can you provide a less lofty description of what you want to implement? I didn't suggest that anything be implemented. I (mis-)read the parent message as suggesting that instead of absence of bugs being sufficient for release, we should consider instead "presence of quality" (anti-bugs, if you will). That felt like a major paradigm shift, but I was misunderstanding. -- Gard signature.asc Description: PGP signature
Re: Fixed release dates are hurting quality
Andrey Rahmatullin writes: > On Sun, Feb 07, 2021 at 02:20:28PM +0100, Samuel Thibault wrote: >> > the packages being untouched for a long time in some cases meaning there is >> > no guarantee for quality. >> >> Sure, but if there is no serious issue left with the package, we can as >> well ship it. > Strictly speaking, there is a big logical error here. > If a package doesn't have RC bugs that doesn't mean it's fit for a > stable release, doesn't have serious issues, or even is usable. Wouldn't it be quite the massive paradigm shift to give up on the notion of tracking problems (= bugs), and instead try to track positive attributes like fitness for release, though? -- Gard signature.asc Description: PGP signature
Bug#977907:
Package: wnpp Severity: wishlist Owner: Gard Spreemann X-Debbugs-Cc: debian-devel@lists.debian.org, g...@nonempty.org * Package name: CLBlast Version : 1.5.1 Upstream Author : Cedric Nugteren and others * URL : https://cnugteren.github.io/clblast/clblast.html * License : Apache-2.0 Programming Lang: C++ Description : Tuned OpenCL BLAS library CLBlast is an OpenCL BLAS library that often can sometimes offer better performance than the clblas that's already in the archive. I will maintain the package, although I might also reach out to the science team.
Bug#972680: ITP: eagerpy -- Wrapper around various Python multidimensional array types
Package: wnpp Severity: wishlist Owner: Gard Spreemann X-Debbugs-Cc: debian-devel@lists.debian.org, g...@nonempty.org * Package name: eagerpy Version : 0.29.0 Upstream Author : Jonas Rauber * URL : https://eagerpy.jonasrauber.de/ * License : MIT Programming Lang: Python Description : Wrapper around various Python multidimensional array types EagerPy is a Python framework that lets you write code that automatically works natively with PyTorch, TensorFlow, JAX, and NumPy. The package is useful because it allows you to abstract away various types of multidimensional arrays and write common code. I will maintain the package, although I might also reach out to the science team.
Re: how to add small console application to debian linux distribution?
pe pi writes: > 1) Open Terminal > > 2) Type: sudo nano /etc/default/grub > > 3) Find the line starting with GRUB_CMDLINE_LINUX_DEFAULT, and add > video=hyperv_fb:[the resolution you want]. >So my line ends up looking like this: > GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=hyperv_fb:1366x768" > > 4) Write the changes and quit nano > > 5) Run: sudo update-grub > > 6) Reboot the virtual machine run: sudo reboot > > ... and i have developed console application which do it this way ... > > sudo hypervscrres --set grub 1366x768 update reboot yes > > ... and all application variants of use looks like this ... > > sudo hypervscrres --help > sudo hypervscrres --get grub > sudo hypervscrres --set grub 1366x768 > sudo hypervscrres --set grub 1366x768 update > sudo hypervscrres --set grub 1366x768 update reboot > sudo hypervscrres --set grub 1366x768 update reboot yes > yes | sudo hypervscrres --set grub 1366x768 update reboot Hello, Are you sure that potential users of your program will find it easier to install your program and run it than it is to perform the original task that your program is meant to replace? -- Gard
Problems with the CI infrastructure?
Hi, I must admit I don't know much about the CI/autopkgtest infrastructure, but I've noticed over summer that the frequency at which my packages are being tested has decreased a lot, especially when it comes to ordinary tests in unstable (as opposed to tests that pick a few packages from experimental). Has there been some change to the CI infrastructure? Is it experiencing problems? Am I just missing something? Best, Gard signature.asc Description: PGP signature
Re: Nitrokey for DDs
Zlatan Todorić writes: > I saw there was mention of GNUK and Yubikeys but I didn't see anyone > mentioned Nitrokey. > > https://www.nitrokey.com/ > > They are a small German-based vendor, producing some nice products > (among other "keys") and they (AFAIK) are doing it all in FLOSS spirit > (aka they released everything in open). > > https://github.com/nitrokey I'll throw in my personal anecdote about Nitrokey. I've used their NitroKey Pro (first gen.) for many years now, and I continue to be very happy with the product. Most importantly, I found the people very helpful: I once lost the cap that protects the plug (it didn't fall off, I left it behind on a train), emailed them and was promptly supplied with several replacements for free without even being charged for international shipping. -- Gard signature.asc Description: PGP signature
Re: DEP-14: renaming master to main?
Michael Biebl writes: > there has been a lot of talk recently about how master is a loaded term > that should be avoided. > If I read the news correctly, github and others are going to change the > default master branch to main. > I don't really have any strong opinion on that matter myself. > > That said, what I care about is consistency and predictability across > the archive. > If we deem that "main" is a better term, should we change the defaults > in salsa/gitlab and maybe update DEP-14? Since DEP-14 already accepts naming according to release codenames, perhaps recommending debian/sid for the main development branch would be a better course of action? Best, Gard
Lintian status reporting on packages overview broken?
Hello list, It seems to me that the "Lintian E+W" column on the QA packages overview page currently incorrectly shows a checkmark even when there are Lintian warnings for a package. Is this a known bug? Best, Gard signature.asc Description: PGP signature
Bug#961784: ITP: hera -- Library for computing bottleneck and Wasserstein distances between persistence diagrams
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: hera Version : 0~git20200309 Upstream Author : Arnur Nigmetov * URL : https://github.com/grey-narn/hera * License : BSD-3-clause Programming Lang: C++ Description : Library for computing bottleneck and Wasserstein distances between persistence diagrams Hera is a header-only library that implements algorithms from Michael Kerber, Dmitriy Morozov, and Arnur Nigmetov, "Geometry Helps to Compare Persistence Diagrams.", Journal of Experimental Algorithmics, vol. 22, 2017, pp. 1--20. (conference version: ALENEX 2016). that exploits geometry to compute Wasserstein and bottleneck distances between persistence diagrams much faster than plain matching-based algorithms. The library is being packaged because it is now an upstream dependency of GUDHI (src:gudhi). I intend to maintain the package myself.
Re: Temporary(?) bundling of code that may not warrant its own package
Adam Borowski writes: > If, for whatever reason, you feel urgency, the ftpmasters are very good at > prioritizing your needs. There's just no information attached to packages > normally -- you need to let them know. One way is popping up in #debian-ftp > and whining. > > I've never had them refuse a request to speed up a review. A package stuck > in NEW is stalling further work? Ask to prioritize. A package is job > related and your manager wants it in? A derivative is about to freeze? A > customer requested a backport? All of these are valid reasons. I had no idea. I guess I'll try to ask them nicely. Thanks! -- Gard
Re: Temporary(?) bundling of code that may not warrant its own package
Wookey writes: > On 2020-05-20 13:42 +0200, Gard Spreemann wrote: >> >> Wookey writes: > >> Is there any community consensus on putting the bundling in place >> temporarily while the separate package is held up in NEW? Being the >> maintainer of both, I would be able to quickly react to the separate >> package having cleared NEW, and rid the other package of its bundled >> copy. > > Would you not just put them both into NEW at approx the same time, > library first? In practice no-one will stop you bundling in the > initial upload, then uploading the separate library, then removing the > bundle in a second upload of the main package once the library is > through NEW. But that's more work that just doing it right in the first > place. Ah, but one of the packages is in Debian and has been for a while. It's just that the latest upstream version of *that package* has started bundling a third-party library that wasn't used in any way before. Now the question is do I package the software the upstream bundles (the one without proper releases or documentation)? If so, may I allow the bundling until such time as that package (the one that is bundled by upstream) clears NEW? Sorry for the confusion. Best, Gard
Re: RFC: threading-aware virtual BLAS/LAPACK
Mo Zhou writes:
> Hi fellow devs,
>
> I've suddenly got some inspiration on this problem, which resulted in a
> much better solution for the problem the original proposal confronts.
>
> I like this overhauled solution.
>
> No extra shared libs, no extra SONAMEs. No extra burden for the
> BLAS/LAPACK maintainers. Minor patching work for maintainers with
> special demands.
>
> --- New solution ---
>
> 1. BLAS providers create new directory under
> /usr/lib//libblas-/
>and put another copy of their alternative symlinks into the
>directories.
>
>e.g. libopenblas-pthread provides the extra symlink:
> /usr/lib//libblas-pthread/libblas.so{,.3}
>
> 2. Maintainers of reverse dependencies, when they have specific
>requirement on the threading implemetation, add the
> /usr/lib//libblas-/
>directory to the RPATH property of the resulting ELF binaries.
>In that way the programs can use the BLAS implementation without
>worring about the uncertainty of the alternatives configuration.
>
>Other packages insensitive to the threading implementations will
>use the libblas.so.3 in the global scope:
> /usr/lib//libblas.so.3 (a symlink)
>
> --- end solution ---
>
> That's it, much simpler and much more efficient than my first version.
>
> Comments please?
Would it make sense for DH to acquire functionality to automate dealing
with this?
> On Wed, May 13, 2020 at 10:54:00PM +0200, Gard Spreemann wrote:
>>
>> An aside: do autopkgtest or other CIs currently test packages with
>> varied combinations of BLAS/LAPACK providers?
>
> No. But that's easy to implement.
>
> For example, we can add the following test cases in the autopkgtest
> control file of openblas:
>
> Test-Command: run-numpy-unit-test.sh
> Depends: libopenblas-pthread-dev
>
> Test-Command: run-numpy-unit-test.sh
> Depends: libopenblas-openmp-dev
>
> Test-Command: run-numpy-unit-test.sh
> Depends: libopenblas-serial-dev
>
> In this way we BLAS/LAPACK maintainers can immediately spot regressions
> in important packages. (adding these tests seems like my work)
D'oh, I should have thought of that. Thanks!
-- Gard
Re: Temporary(?) bundling of code that may not warrant its own package
Wookey writes: > On 2020-05-20 10:16 +0200, Gard Spreemann wrote: >> Hi list, >> >> Upstream for a package I maintain has as of its latest release started >> bundling and requiring a third-party header-only library. I am >> considering packaging that third-party library (it's useful to me, at >> the very least) but I think it's a borderline case of whether it >> warrants being a package on its own. In particular, it does not do >> versioned releases, and it comes with no documentation > > I don't think those are reasons particularly in favour of > bundling. Plenty of software doesn't do proper releases any more. Just > use 0~ type versioning to allow for them eventually doing a > release 0.1 or whatever. Again obscure software is quite often poorly > documented - you are expected to know the field. Thanks your feedback. Is there any community consensus on putting the bundling in place temporarily while the separate package is held up in NEW? Being the maintainer of both, I would be able to quickly react to the separate package having cleared NEW, and rid the other package of its bundled copy. > If it is useful beyond this one package (and it sounds like it is) I'd > just package it. A headers-only library is relatively quick and easy to do. > >> I would track the bundling as a bug and act on it when/if a separate >> package enters Debian. > > Would you necessarily notice when another package using this > dependency enters the archive? Another package using another bundled copy of the package-to-be, or another package using my package's bundled copy? In the former case I'd hope that that package's maintainer would notice and keep track of my ITP. In the latter I'd hope they'd be aware of my package's bundling bug. Best, Gard
Temporary(?) bundling of code that may not warrant its own package
Hi list, Upstream for a package I maintain has as of its latest release started bundling and requiring a third-party header-only library. I am considering packaging that third-party library (it's useful to me, at the very least) but I think it's a borderline case of whether it warrants being a package on its own. In particular, it does not do versioned releases, and it comes with no documentation (though its use is clear if one is well-versed with the academic side of what the library does and one inspects the header files). In light of this, I am tempted to – at least temporarily – accepting the bundling from upstream until such time as the bundled library becomes more fit for separate packaging, or I go ahead package it anyway. I would track the bundling as a bug and act on it when/if a separate package enters Debian. Is this within the realm of acceptable bundling? Best, Gard
Re: RFC: threading-aware virtual BLAS/LAPACK
Mo Zhou writes: > Please comment: > 1. Do we have a better solution where we can retain high performance and > avoid threading trouble at the same time? > 2. If we don't have a better solution, is my proposal acceptable? > 3. In which way can my proposal be improved? Hi Mo, Your proposal seems sane to be, and a real service to the users! However, I am a little bit worried about the maintenance burden you are setting up for the future; may it be promising too much to the users to provide every single combination? Since this is BLAS, one could imagine adding yet another couple of versions for each of the options, targeting ever fancier vector instructions, etc. – at what point are special needs best left to the user to cover? I wish I had more constructive criticism. Thanks for the work! An aside: do autopkgtest or other CIs currently test packages with varied combinations of BLAS/LAPACK providers? Best, Gard
Re: Salsa update: no more "-guest" and more
Bernd Zeimetz writes: > On 4/25/20 10:05 PM, IOhannes m zmölnig (Debian/GNU) wrote: >> On 4/25/20 8:34 PM, Bernd Zeimetz wrote: >>> Hi, >>> >>> https://docs.gitlab.com/ee/security/two_factor_authentication.html >>> >>> Enforce that (if Salsa is doing that in the meantime, ignore me). >> >> i hope you don't suggest to enforce 2FA system-wide for all users of salsa. >> i read you original mail as a requirement to enforce 2FA for users who >> want to use salsa as an authentication provider for their own >> applications (which is fine with me) > > > Actually I think 2FA should be enforced for everybody. > Even debian.org related passwords might get lost. Right, but what's the threat model here? For some of us, losing the Salsa password is essentially only possible if we have had our PGP dongle or offline private key backup compromised. In this case, the attacker can sign uploads to the archive anyway, which is arguably more serious than a compromised Salsa account. -- Gard
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
Mo Zhou writes: > On Wed, Apr 01, 2020 at 10:37:07AM +0200, Gard Spreemann wrote: >> Or, another example that I can imagine plausibly arising in practice: >> suppose a terrabyte of raw data was collected from a scientific >> experiment or simulation in order to produce (among other things) a plot >> in the form of a 100 KB image that it is useful to distribute in >> documentation that goes along with some DFSG-free code. Clearly the >> "preferred form of modification" is the raw data, together with the code >> that processed it, but it seems unpractical to expect the maintainer to >> go through a laborious process that perhaps even requires highly >> specialized expertise in order to distribute the raw data and reassemble >> the plot from it. > > In this case I agree that distributing the resulting image as is, is the > sensible thing to do. Another thing came up in my mind, quite > interesting, is that if the resulting product is a pre-trained neural > network, I get completely reversed conclusion ... > > Further, some neural networks are trained from the wikipedia dump > (CC-licensed). Are we uploading wikipedia dumps to the archive when our > users need to use these models? > > What's the essential difference between a jpg picture and a pretrained > neural network then? They are both multi-dimensional numerical arrays > from an abstract perspective, but a normal human can understand and > modify the picture pixels, while not being able to understand or modify > the network prarameters. Indeed. So we have a situation where there's 100% DFSG free code, 100% DFSG free data, and 100% DFSG free output produced with those, using perhaps vast and expensive computational resources. It seems to me to be a bit of a shame if this overinterpretation of the DFSG, or perhaps the lack of an update to the DFSG to account for this reality, would mean said output cannot be distributed and duplicated for the greater good in Debian. -- Gard
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
Jeremy Bicha writes: > Let's say I take a photo of myself to include in an app so that users > can appreciate what I look like. What is the "preferred form of > modification"? If it's 15 years later and I no longer look the same, > would I edit the photo with free software to make it look like me or > would I just take another photo? Or, another example that I can imagine plausibly arising in practice: suppose a terrabyte of raw data was collected from a scientific experiment or simulation in order to produce (among other things) a plot in the form of a 100 KB image that it is useful to distribute in documentation that goes along with some DFSG-free code. Clearly the "preferred form of modification" is the raw data, together with the code that processed it, but it seems unpractical to expect the maintainer to go through a laborious process that perhaps even requires highly specialized expertise in order to distribute the raw data and reassemble the plot from it. -- Gard
Bug#950783: ITP: python-cdsapi -- Python interface for the ECMWF CDS API
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: python-cdsapi Version : 0.2.5 Upstream Author : ECMWF * URL : https://pypi.org/project/cdsapi * License : Apache-2.0 Programming Lang: Python Description : Python interface for the ECMWF CDS API Python library for the API of the European Centre for Medium-Range Weather Forecasts' (ECMWF) Climate Data Store (CDS). More information about the CDS can be found on https://cds.climate.copernicus.eu I plan to maintain the package myself.
Accepted gudhi 3.1.0+dfsg-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 22 Jan 2020 11:16:38 +0100 Source: gudhi Architecture: source Version: 3.1.0+dfsg-2 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Changes: gudhi (3.1.0+dfsg-2) unstable; urgency=medium . * Require PyTest for autopkgtests. Checksums-Sha1: 883c6b0e069a9b8f49fef7cc591791dc2b8a88b1 2987 gudhi_3.1.0+dfsg-2.dsc 11b140f54ede7964ad14281a226ec5a67c9b8815 9976 gudhi_3.1.0+dfsg-2.debian.tar.xz 6065543ad39d7219e5c95e63a6e51faa6defea8f 13600 gudhi_3.1.0+dfsg-2_source.buildinfo Checksums-Sha256: 9781a6472eb7c967bcf0df205cc154ca177e9d1d9bfcd978a886a9c58da5f831 2987 gudhi_3.1.0+dfsg-2.dsc c9f6dfaf6195bdb9e4757fd98fdb7e431f36ab5ec3ccf069c5bbd6ce3513e810 9976 gudhi_3.1.0+dfsg-2.debian.tar.xz 56771931345262bf4792955534acdfa58fdd019cfe578a7701f595f961601e64 13600 gudhi_3.1.0+dfsg-2_source.buildinfo Files: e93254de2c0ad14594dbcf63856e5b05 2987 math optional gudhi_3.1.0+dfsg-2.dsc a102540035f063dc4143d7b36066e7a4 9976 math optional gudhi_3.1.0+dfsg-2.debian.tar.xz c3c480dacbf3b1b68634b6faf28bc8be 13600 math optional gudhi_3.1.0+dfsg-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl4oIjMSHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz60oMQALHkuSXOSOq1y1nw9BNrPREq641Nqvpf G63ZhXkFaR/HlqUrjVKKbz6wwg7xHqwldCzcmmgGhkaRmnNVgNBRCWJROO5B/cY9 x0qIc5205SJ+mG6UdaDUSMk17VW/yO1mz1yMLULBaJ5Z1AMlfiNO94l4bvaaQmrh Bym/L0/5DDgCLNCLjln6dg64mb5Ds+OYxAO9dp17kJOE3vOYRKpeQYmXMyursBUm J5QY539kni4IcX2B/39VAfZmBWVyqgCXoXdq1fLVGJ6cmbn4AMZsEv9jL6dj7Q5g vqn5VGTxC/llQqosoArbP5IiF4v8WeVMDVZX5r5/EGUAFmhFPIIgwXmcfjIApENe eVuu0R3eF3b5yQ1ZATHKWLEnDkkXFffmq2DfSE/bCROGpJ4ZzniIc9NEgTiCdU4k 7wPrZSHv0kqYtPgz8N1w+r5Ez/gbhTN7hY5debGm883lydLjXsLrs+O7qxpbPsT/ YVxB/pSb/Mt7nDJ3PXZHYZTqWRbT/UDbClkaRdI2CarTBOXwjLRbeTKkrWsMNkt4 CVMnTHKG3dAgJFpwKagPm8twxFO6MbCaZXwigI8R9J9N0xbLiKsYDKh7KcZ9MZzt i2fazk4YS8Ra9dVtsBP9wYnNk4RIydyTVvPlNaU00nF2IC3CZEGrjSxcz+te7OBq SxGbU3UjWzWa =lkW/ -END PGP SIGNATURE-
Accepted gudhi 3.1.0+dfsg-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 21 Jan 2020 10:26:33 +0100 Source: gudhi Architecture: source Version: 3.1.0+dfsg-1 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Changes: gudhi (3.1.0+dfsg-1) unstable; urgency=medium . * Allow forcing parallel builds for local use. * Standards-version 4.5.0.0. No changes needed. * New upstream release. Checksums-Sha1: bf0508472a7519767af2b1a897e1cec1597fbeec 2971 gudhi_3.1.0+dfsg-1.dsc 477a04294306cd7f75a35eaddb8f1a7966f1809f 17703150 gudhi_3.1.0+dfsg.orig.tar.gz 56b0a59553fefdf1e5802331910d0380754530aa 9948 gudhi_3.1.0+dfsg-1.debian.tar.xz 942e7756cc7193003492436cee02315c60769540 9754 gudhi_3.1.0+dfsg-1_source.buildinfo Checksums-Sha256: 6d11f151ec24ac30302e646ffd5c18549da6eb52a9f20ee68dca3dad49ca06b6 2971 gudhi_3.1.0+dfsg-1.dsc a3f9bcc3deecc3509637c06de726ffc8054c79097618855218918fccbc411208 17703150 gudhi_3.1.0+dfsg.orig.tar.gz f4ae0578c9552d06fa65b26d1b1166f0bea11c4c4d7fdf2aa4d71571a4146fdf 9948 gudhi_3.1.0+dfsg-1.debian.tar.xz 1f3606f84bae142803d5bf199d13c4ca3ef4a052a03f25244d35422cad58b692 9754 gudhi_3.1.0+dfsg-1_source.buildinfo Files: 1c68a4255e2a763753479b203a4b 2971 math optional gudhi_3.1.0+dfsg-1.dsc 7cfccb537a70262e1096a9c7528395c3 17703150 math optional gudhi_3.1.0+dfsg.orig.tar.gz 1a012aadd62d01357ad96a9e4b07f98a 9948 math optional gudhi_3.1.0+dfsg-1.debian.tar.xz 963a2ef66ee462debb922d2b2b31ceeb 9754 math optional gudhi_3.1.0+dfsg-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl4m0PcSHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz6sL4QANhA1CPgvvc/ayYCQ4RE/49+Zx1ZmFaW 6C4op7x0RS0aUaUlUzeMfsgblVnR+0wHbviWIYiYSs4/BfzC7nQMEp/MGoOk95eA 9YCoZNpfBjFZz1l7nvquACanS8ZYRHPaNryNpab68AMyGQcCw0sR3Iij/zs502dR 4u8ptKO2997p9nBFbnZBvNeH8xPCi7QF02r/6aUKLL7FN1HsBOXAYpZ3wlxlWUFP BXAgcLtat3UtNrh+7K+NnKFbjb+tZ3WDGe5N7A+QCPmRg8ALxOhYaaYQh9wD3NXl YQL3p+9rpQBr/fBaLbpsx5Bh89LDIxnAVENycHASpk6JWDi/ezGrRlQZUJnoKmdd n7dtgC0vP45b8mqVepQAlmc4/FpXzb0FnDT1ay0iUKGhIC+VW/JYp1udExa7SsRM dwD7c0aWpt9YMbW8/QE/9i5oMzo1iXgVeZI2gfG0kX7wF8dss3tSnUeFv18oQCT0 w+LgGDn7pnhpvKIKW6yUkNsKtqaI4fGj8hNb8+KwvdUfZlo4+Pure3XwX4qVrZAH t4LtLjGB3/G+XtlgXgGYaqlPfhzUIcdBeE+mOeXTPoJwE9f8L+0F49zb5h0/Hmv3 aPzvTYzncVmfHV6pKHwnvlwkuxjO6KOzWofYJ99Y7PQ2hVcwbkWX/J0bNdR7GXC+ Rz8XdEv3DwVu =kWu0 -END PGP SIGNATURE-
Bug#949381: ITP: python-pot -- Python optimal transport library
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: python-pot Version : 0.6.0 Upstream Author : Rémi Flamary * URL : https://github.com/rflamary/POT/ * License : MIT Programming Lang: Python, C++ Description : Python optimal transport library Python library with solvers for optimization problems related to optimal transport. The library seems useful in its own right. My primary motivation for packaging it will become a dependency of GUDHI [1] as of that package's next upstream version. I will maintain the package myself. I currently would require a sponsor. However, my DD process is almost complete, and if the outcome is positive I would not require a sponsor to upload. [1] https://tracker.debian.org/pkg/gudhi
Accepted tikzit 2.1.4-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 28 Dec 2019 16:50:53 +0100 Source: tikzit Architecture: source Version: 2.1.4-4 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Changes: tikzit (2.1.4-4) unstable; urgency=medium . * Depend on tex-common. Checksums-Sha1: 0b7fce1692bf3cfa1849d7261b54e997678ae10b 1926 tikzit_2.1.4-4.dsc 6d349c619668a4ed7afd39b8d727f92e1ec4a220 8972 tikzit_2.1.4-4.debian.tar.xz 9bc4923efa26609da717cbac2f17a6b720511882 11233 tikzit_2.1.4-4_source.buildinfo Checksums-Sha256: 97be183e9209ff9f99923f3ac5e51521d4e591d00b0495cc9a8305a5f6bda1b5 1926 tikzit_2.1.4-4.dsc ef04fa1bf49016ed163c493f15b184da463a2ab8a34a07ea14bf3e09958fc527 8972 tikzit_2.1.4-4.debian.tar.xz c2f05cda9766ef39ee11fcdbe5cc5c75924c270d859697a2ed2b037388b77a51 11233 tikzit_2.1.4-4_source.buildinfo Files: dd9cae634010edd3cd5d80914782e914 1926 tex optional tikzit_2.1.4-4.dsc 648dac79249f5a7419e27132e7a8f09e 8972 tex optional tikzit_2.1.4-4.debian.tar.xz 9e9704803156abb5fcd9da3d6e292827 11233 tex optional tikzit_2.1.4-4_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl4Hev8SHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz63fUP/2k/cAJhY5zVixB2oLzqYQwEVM7BtXGb Th8bv7hvjKp09ktK8KslE6zMHImcnhXWY2haM+6ICbeKu/5CtSnX8qBoTEspNaJ0 zPet4Qkg7EgAcEJF4DY2b9xqAM2ji3WJnPtOYi0hc9lIdKowXXVGQWjaJO20AZqL aH7iObfDJT14AsZd3bGN/XMiQk4+xTfRUc4hLbR8HvftsLJXEeo2kyTx3/IDe/qI O0A2Kqd3RThlNMpSJx+EN/egwzRRNgOnNpewtQKHSbep7rt7SsEBYg3/5boArFPQ LrqpWl7+adpIUgmSMKb9u/EO0HcBWHxRZg6gctENKsjuSKrusQf8X7NfZ7z/teGC KWgzjb7aUlo/6O+wA8+JZpc+6ulySA+ZmCJ7oGeZlK3Y9VvyzExAMLQMovAUoci6 lqJZzEgnS0PESktaGxllkCPosKspzc2dOsl7m+I79S+y//eljkdAE3C1Bh9FIept 0RdjJzq7kbEQbbOe3nAQHb9neNFbVq0WZUiABsOhMJ7dfHjbW6ghHBIWzkrKlxEJ PcjmMjfab6JKg1AcM84e3UXKR/W1cq8Ed4q+BUcyYon4RNroHvXi8LWm9BgTzOJT U9tlptYiS8BZEw0z0Qr96Q/oRdG9QdH8F4ApSOwbyq9z2Iyir5s1TLxSDUMPA93m oipO8b4VN9wH =y9w5 -END PGP SIGNATURE-
Accepted tikzit 2.1.4-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 28 Dec 2019 15:39:24 +0100 Source: tikzit Architecture: source Version: 2.1.4-3 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Closes: 947517 Changes: tikzit (2.1.4-3) unstable; urgency=medium . * Install style file. Thanks to ael for reporting. (Closes: #947517) * Standards-version 4.4.1. No changes needed. Checksums-Sha1: f801768dfdfaa76e588cc6e42981aae34f2716a4 1926 tikzit_2.1.4-3.dsc 6f3018b989cf108aa29366e444339018530cc4cc 8952 tikzit_2.1.4-3.debian.tar.xz c8d1867ff5d8a673813ae36b4a7bf63f3b7ea0c9 11233 tikzit_2.1.4-3_source.buildinfo Checksums-Sha256: 55b94f16812aa47c62572747e1eac6731f40a73c9e4b84ea0843c959508ebebe 1926 tikzit_2.1.4-3.dsc 5b7aec25f67e9dd2e42577a1b8b152237477e3cc7f4c92bab57c520a0c1b972f 8952 tikzit_2.1.4-3.debian.tar.xz 5eff15481002c1b649fd3060738305ec798e340ec3d989cac5623db630e68e4f 11233 tikzit_2.1.4-3_source.buildinfo Files: 942a77080fdbf7d37e96000f8a6e430d 1926 tex optional tikzit_2.1.4-3.dsc 1d86cbc501de64be2de9bf04f375b80e 8952 tex optional tikzit_2.1.4-3.debian.tar.xz d4c3fecbbbc2f00e179a11aaf97ddced 11233 tex optional tikzit_2.1.4-3_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl4HaUoSHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz6weQQAM6ymqP0pweHyo6UfuWyx+Lr0dqSSPXl zNWZmLSpmIfFQbFwEVZC57S4zaw1z1XoIyj1dyHCbOUo7W6dxXyOu7hqE375ggF8 cicX2ViiLeo6e98fbHy8l9MOYqJWz2HN18E+zoVUBUeoFihtV6WNO4PNoKMDj1rH p1Elyu8jlMcC3dYEHZXsZNPQdUCYJVri2Tb1tGmKqi+85t/+OfiB6wNy9KHChRGK MlflXc1RXkHEEaT3HsUon0icRIGcUb+U8WkC4WwJavUSooAFWKJLex4WiwO37w5z d8XHYjK1cJXoWgPQg5H+GfTYK0sYq/UhPllM6+89+VbeGFbqt4xfAt2iTvBb9pPQ hyeNwtO/OyD6je1OGCukNtAHfcDMZsjQ8x/NVKamGZQ0hMaCL6yfXg3WhF2DHWMp L2V1Oqnq/+BxcyuFgjdtHccve1nc4tM6HeohyGyi6MIjH4h0pA+0NDk2uYz1PtL1 vmHS0yB8ObdwpMAqoZjOk8B8JXnlochqYDQaGu1RGw1ot0dhuTgldBnKKAsxPoEA /Epm1hSiMi50y9npclnzsRa7G2cZek1thc50R+hcR2QApHiU+tfsgoo6MtoHxLsC nywUfHOLo6z19tblbBwHAgUBnwUKzxfxSiPRkX2Bkj0UlPOw0efP5vSgpUGWjL4F gZK+L81ZCCCx =U9HR -END PGP SIGNATURE-
Accepted proofgeneral 4.4.1~pre170114-1.2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 16 Dec 2019 17:50:59 +0100 Source: proofgeneral Architecture: source Version: 4.4.1~pre170114-1.2 Distribution: unstable Urgency: medium Maintainer: Hendrik Tews Changed-By: Gard Spreemann Closes: 941544 Changes: proofgeneral (4.4.1~pre170114-1.2) unstable; urgency=medium . * Non-maintainer upload. * Build-depend on texlive-plain-generic instead of texlive-generic-recommended. Thanks to Steve Langasek for patch. (Closes: #941544) Checksums-Sha1: ef3552e140ca2fc5c396d930ab1f5fc9a549ec79 1983 proofgeneral_4.4.1~pre170114-1.2.dsc ebb27ec63fa5f6bb89725df5fdd3ee86c9ef9a28 19908 proofgeneral_4.4.1~pre170114-1.2.debian.tar.xz 41752a7b34c7c95663457c7d908aead7183f0b7d 10964 proofgeneral_4.4.1~pre170114-1.2_source.buildinfo Checksums-Sha256: c466855c5f38e46b3b8eed4cd8e83817ce16de4a6330c8d2fc8503d7f8a4d05a 1983 proofgeneral_4.4.1~pre170114-1.2.dsc 184d07cc7aaa1dc58928b30639668d87d996c64c1e508f4f7259613acc298cd5 19908 proofgeneral_4.4.1~pre170114-1.2.debian.tar.xz 9c1a69d8828fd853e69adc4b02cb0f92de4274a09ef3c2d58843d2e940bfa946 10964 proofgeneral_4.4.1~pre170114-1.2_source.buildinfo Files: 21b7565fce5cb4e7ac1144322e733d49 1983 editors optional proofgeneral_4.4.1~pre170114-1.2.dsc f93803a132978a784df69075beb0b89a 19908 editors optional proofgeneral_4.4.1~pre170114-1.2.debian.tar.xz 458b06b53393cada191f8cfc4d7313e2 10964 editors optional proofgeneral_4.4.1~pre170114-1.2_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEESYqTBWsFJgT6y8ijKb+g0HkpCsoFAl37LXoACgkQKb+g0Hkp CsorpxAAuJLzsfBADr2NicLyQjRmH47lOdSK96oXtfUH+IpAFfWJInBFhMcWNBGZ LrOI6X5odQwhT/tVSuhF/Hr9XsSo99Av/x2rya6TvUxGGix4BYPHRqC57E3OhE5E /8040d0g83WjE5oG/vGdvOS3weCEovHu9mUz/FdGH1NdbAjxRsMHM0n4p3kp3G90 0ByKz1Iq4JyOP0zxiOgnrzq0iCayEkM6F1GrAFwB8ixTHsndEBZZvaRq2PwY4pzQ dtEEtxmW8+C7gIMIs6/DNbh4eIg+KbedzPIsCmf5Gi6+WfmOh3OrMIbj0Wwwh+4t WYmbuZNQqQY+7vx8IjJXehygUOlUafzbJPw3UU4sg1LlR9MZ3gym0iW0Hts0lDkL IFzeVSba5JSEQ6R6KPAPNo62pxve8v/4c3N6VWpuY7zFKbBnWwHKNEFl96bf1fSn PMX8vlNeMKb2sN4Xt/aJJOEkhiM5a4EOA6dnDWT4BpP7izJjOyhNS6w/z0RXR42c NnNpo71a1jFaEtOdcbmcMOPAlcibpgYAKUmlcNBhGP0GjTAoRQr5NOJbV64rQEK+ UDxx9kWsju5IwKm638DicKs5ScfLXCbO1mgw5JuZ4YgAHNFeRQ1lOpVzR8QjiCug vnYy1HsAZyx5jpe9YLRm94E1pPDmWBaiS4UnaO3XUU/sIe7CleU= =FTuA -END PGP SIGNATURE-
Accepted gudhi 3.0.0+dfsg-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 10 Dec 2019 14:33:51 +0100 Source: gudhi Architecture: source Version: 3.0.0+dfsg-4 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Closes: 945226 Changes: gudhi (3.0.0+dfsg-4) unstable; urgency=medium . * Drop 0003-Don-t-set-runtime-library-dirs-for-Python-extensions.patch in favor of CMake option. * Disable parallel builds. A lot of buildds seem to be swapping out, and some Ubuntu ones run out of memory outright. (Closes: #945226) * Standards-version 4.4.1. No changes needed. * Drop 0004-Force-linking-of-Python-module-with-CGAL.patch since CGAL is now header-only. * Add 0007-Move-towards-reproducible-builds.patch to move towards reproducible builds. Checksums-Sha1: 685fd27d2fbbbddc97baa05f3a38580b3b308529 2957 gudhi_3.0.0+dfsg-4.dsc cfcf9fbac1676b9fdc55d2a2a80caeaee3917a38 9796 gudhi_3.0.0+dfsg-4.debian.tar.xz 9ed41128839dd5bbe919f73220c1175617ba6d8f 13510 gudhi_3.0.0+dfsg-4_source.buildinfo Checksums-Sha256: 59990308d264388f5b556d8d82b495a7f9efd5c68af429449ff6e235d7d667d8 2957 gudhi_3.0.0+dfsg-4.dsc 392127a1176db72ce1f87f63a33723482eb51dce3325ed24c98b58b49da062f4 9796 gudhi_3.0.0+dfsg-4.debian.tar.xz 6cac933d5923b25a72e7dfed260b5669193fc6a0163e8d4b33d83468b8464030 13510 gudhi_3.0.0+dfsg-4_source.buildinfo Files: 1fd799333f19fea381b3be3cf8e29823 2957 math optional gudhi_3.0.0+dfsg-4.dsc 9768431cc5a323f6f21c6aed39e3d98c 9796 math optional gudhi_3.0.0+dfsg-4.debian.tar.xz 5cddfa981b6ebe3784bd32f7e623eef0 13510 math optional gudhi_3.0.0+dfsg-4_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl33XVMSHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz69JsP/R8BbplCtg1oLXNOcT04avmKLwNvb4r3 4Cp9V5qNsVDOsxM5zsW7X2mG16LvH+Zjn8gHZDqpzIE++jZJPVtlIiuOJgl3d/1F Arlhsg2sCKIpLVESocvyFTIkuaYcYmTnd8HMIX0dzL8pnV+gOCQTRfkL4ohcL/Jx 0tfuvcoBRQ1nf7EaHIH3nkXkFy4Y/9u2w4KS4R+qclF7QC+FzgK+9RokYr1c4EZe szP779AMtjwJbHHQM8NyJnMjqbu8746QSjMEee1tGFYmL34DD2Aa8Hqjak2Te+gJ DnH0QIHTLQJEI7Y2PTSt3b7JA7I9GcRcELjJjO+rsHXL2lFKAtg0/XeaqsLRsmiU k4GEqNRmRrNeP4R1omY1zI4zoTGRhXjNsG6EL1o2ay99R0DdtuZnowO2suRmeWw7 bsePr4hAPrC9+b4uoVlGD6k2+pBx9++iESVQO9iFWy2mH/x8QTubOm07qrDbqaKY sVF11WJK1qOP5Rggb8+xde8YT786Ty8Sm89iCDDbEGbAaT/tmbFDSQnN9hyrTQ7V J5Ta1XfRXFPFq1lsFi2aFQwkZNHRn1MUHMbU93in7pXK+ImnkT/ID2rrZ/OTs4T6 HpF1BZUALZAA6PO2ucbCg1ZWIr5Bie8rg8pXUhJPViAjBT3m4gdHuhkPtslxcW6f zedUArxSM5gl =PjEH -END PGP SIGNATURE-
Bug#943817: ITP: ripser -- Fast computation of persistent homology of Vietoris-Rips complexes
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: ripser Version : 1.1 Upstream Author : Ulrich Bauer * URL : http://ripser.org * License : MIT Programming Lang: C++ Description : Fast computation of persistent homology of flag complexes Ripser computes persistent homology of flag complexes (such as Vietoris-Rips complexes) only, allowing significant gains in computation time and memory usage. See https://arxiv.org/abs/1908.02518. The package is widely used in the field of topological data analysis. It is mature, slow-moving and has very few dependencies. I will be maintaining the package for myself. I would currently need a sponsor, but I am in the process of becoming a DD.
Accepted gudhi 3.0.0+dfsg-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 30 Oct 2019 09:27:19 +0100 Source: gudhi Architecture: source Version: 3.0.0+dfsg-3 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Changes: gudhi (3.0.0+dfsg-3) unstable; urgency=medium . * Disable build-time tests on i386 and s390x. * Drop support for mipsel due to failure to build because of too little addressable memory. This introduces an explicit architecture list for the packages. Checksums-Sha1: 0074a1785dbf4a34ed0ba9b04adf2b82994a950f 2957 gudhi_3.0.0+dfsg-3.dsc a402cc53d34143c579e3d1f809d82f2836981992 9748 gudhi_3.0.0+dfsg-3.debian.tar.xz 76908a466cb5fe5df5761bff05ae24c75309d9f2 13382 gudhi_3.0.0+dfsg-3_source.buildinfo Checksums-Sha256: ef413d623d31c8e8515591f0006f33627dac4a8497c81e99c5a64d9bdf93317e 2957 gudhi_3.0.0+dfsg-3.dsc 24074092b3834fdd6e615d145ba48fab438b980d0cb70bb35eb50d64fac92614 9748 gudhi_3.0.0+dfsg-3.debian.tar.xz 7c10821f1e12ed5d9a259e234f4ab16d12856d8c64a8f18c8f326fdafc79c5f1 13382 gudhi_3.0.0+dfsg-3_source.buildinfo Files: b6316cf292f114984a1c2f83fb572537 2957 math optional gudhi_3.0.0+dfsg-3.dsc 5cd9a9e589ee7fa404b2d28ed1ec14f8 9748 math optional gudhi_3.0.0+dfsg-3.debian.tar.xz a7d8d95295c5a27dd8a896ed6aa90f24 13382 math optional gudhi_3.0.0+dfsg-3_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl25Sc0SHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz65ToP/3nU8OllkJEcqfxeUsQven+/5KeXN79+ vStuaRee+vktG1LfGeXu69O88+68sSZVJnT4bXDzS1hRviMLWe2vO7GhMVRG9Rg7 sLA+gi1FSJ0KvnGgj5RF9FrJ6HfN02FKcwnzvx5vH8dkfrimx8r69CXWNpb6XjAs a7jtNMrXVXinKfRcJdzJsithvhx5kvgRawsqbPahdozedHkAs/2iBmrUElL3v4Nv 72XX0HzoHuTfVnUM98kd99E3veDZa9BiUtG7oTes7E1kgSaWO7dFoqJfOeUIKTkC FWdYfypw/LFvvAZX/Dd+1wMhnW9wxXXfWnutONBvs+EtCKe2PuPl442vp2bFo3Je HUb6FZ/UudpWRo89671vtKxHiCJnDo8gPU/5R1Fyom7gfaljJqarb9VQClmtdlKN Yp1BvoA0bw01Wykt6kuCXdazZYWHTmfUobDeYKQjRVS4J3Wkw5hYb2XxV0h9CZ92 2wyl6FOgk48arNCkrftRNRu3m93BjTwCp3/GwtfQtVkPmzzSDrtrStvhKC9Docyt MqYu+kBhV2evS8iGZF1mGwJcV7cYoJwoOEZAqIpZvmIxXKmhd9Boi3YV1Q6PwM44 e9BosPm8pOhtmBJ1QXRrBncdBQPijbdEPHQGE8R2Yd+T91LqfLTFzOpkDWhNgL6c gwGIAzEij+gh =x/E3 -END PGP SIGNATURE-
Re: doxygen 1.8.16 is ready for unstable, 10+ packages will FTBFS on amd64
Hi, Paolo Greppi writes: > The 10 remaining packages all fail with latex-related errors. > Unfortunately I know nothing about latex so I cant' help with those. > But I filed bugs or updated the existing open bug: > - ccfits, "Overfull \hbox" latex error, see: https://bugs.debian.org/943423 > - fltk1.3, "! Undefined control sequence." latex error, see: > https://bugs.debian.org/943426 > - frobby, LaTeX Error: File `listofitems.sty' not found, see: > https://bugs.debian.org/921300 > - lapack, easy to fix by just removing one line from d/rules, see: > https://bugs.debian.org/943431 > - librostlab, LaTeX Error: File `listofitems.sty' not found, see: > https://bugs.debian.org/943420 > - libstxxl, LaTeX Error: File `listofitems.sty' not found, see: > https://bugs.debian.org/921298 > - openms, "! Undefined control sequence." latex error, see: > https://bugs.debian.org/943450 > - ppl, "! Undefined control sequence." latex error, see: > https://bugs.debian.org/943451 > - qevercloud, LaTeX Error: File `listofitems.sty' not found, see: > https://bugs.debian.org/921297 > - sdformat, LaTeX Error: File `listofitems.sty' not found, see: > https://bugs.debian.org/943421 Do the listofitems.sty-related errors go away if you build-depend on texlive-plain-generic? Best, Gard
Accepted gudhi 3.0.0+dfsg-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 23 Oct 2019 22:18:22 +0200 Source: gudhi Architecture: source Version: 3.0.0+dfsg-2 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Changes: gudhi (3.0.0+dfsg-2) unstable; urgency=medium . * Fix binary-arch build. * Disable parallel building also on i386. Checksums-Sha1: fc72f1de18ab1d1d817cb89ca8117d0acacfa130 2689 gudhi_3.0.0+dfsg-2.dsc 774d1bf1eea2e09ef1124d27f6e8d19bd3eb70bf 9404 gudhi_3.0.0+dfsg-2.debian.tar.xz 1e62fe7754db7a7847c826f6f0a646367c08e839 13358 gudhi_3.0.0+dfsg-2_source.buildinfo Checksums-Sha256: a07293362db231dcf0b9c730297bfe80affeb04ae2f3c1a686bf0f41bff8fe9b 2689 gudhi_3.0.0+dfsg-2.dsc 372655e7a807e727e368b2ab8e5e606b2d1b41f9bfa4ae5b3e795b06ccc7f0df 9404 gudhi_3.0.0+dfsg-2.debian.tar.xz faae14ae58ba14879387afb44f1f74ffcc3eee470c7cb3971467d2c985f6e564 13358 gudhi_3.0.0+dfsg-2_source.buildinfo Files: 3c4df7b28267e4f2820e9e6a09a38efd 2689 math optional gudhi_3.0.0+dfsg-2.dsc d36df30d1af9ad6876913ea42741fc50 9404 math optional gudhi_3.0.0+dfsg-2.debian.tar.xz 9b000161b86b70ed57bb3624345be3ed 13358 math optional gudhi_3.0.0+dfsg-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl2wtisSHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz6Bj4P/3zrH0QWx5HVkkWjorzwtwEJanW++za3 GiSkBUR3PeUHrfjaYkKBdi1xDgOl+TMu8fF9KCoa5fCZrUrNwIC0r1YTNATCavs2 ThV5C7FgXSx+BRp+sPqDXPc8YEkto+z2pispxJHxfWtiOKXxCmkFTsx1+5k9SQ7O 79e6cskXUZIvDVV7DehloZNXVAJYmU0PP2B7/8GVSBARiotqsxicDBZo1UV65ySl t5jMwukfOVgAsyBYXxI9W1HzT3Aaz4UgKswybYHpebOez7FEqigcAyBmVjR1xVar aukUdDKpLuZQjHC/yVEMDLB8/49wXn2BhSgfedS+kqb6XbR73HIudsGnetqIiJop MK4yfZntm6JOxEWqAS31R44VwGNcumwAF0PO2dqN3bKS9SHfsokLsocth73jRFgh 6qx8zNckuy38VMySJX0vUWYbM/HztKcJIlg+lFKN9UZtPgAmBf/S6SQL8d54FTI0 dRblphYsXl04ln2xLoHbG9aQslI3xpa6Wi7+fUXF891UkLOl4k6dwSz7squ/pwMC XtB2NrSdzkK4E3F2CHyAV+1YFeoqIe/wPiREGJcx36rNOLBk/Dmz+/wVKMOS2tRG w0su9yY5rvGoWSvqAwYUC2zt2lmXbZjSCQagVn+ZPRC1ceirzp7D9iInpJ3+XpAp 8F0hO1jk3vR6 =YL6e -END PGP SIGNATURE-
Accepted gudhi 3.0.0+dfsg-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 23 Oct 2019 11:47:25 +0200 Source: gudhi Architecture: source Version: 3.0.0+dfsg-1 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Changes: gudhi (3.0.0+dfsg-1) unstable; urgency=medium . * New upstream: - Python interface for sparse Rips complexes. - New C++ interface for alpha complexes. * Standards-version 4.4.0. No changes needed. * DH compat 12. * Declare Rules-Requires-Root: no. * Change maintainer email address. * Refresh patches for new version. - Drop 0008-Propagate-CXXFLAGS-when-building-Python-modules.patch, seems no longer needed. - Add 0008-Install-Python-module-in-correct-location.patch to install Python modules in correct location. Checksums-Sha1: 77492e9608b3434dc37be42e53b07d449d50018b 2689 gudhi_3.0.0+dfsg-1.dsc 11bcb061e18a480a8094ff45ce9e1221b445900f 17302661 gudhi_3.0.0+dfsg.orig.tar.gz 824785768f38246d121ea5a1e91f5ddf70078598 9348 gudhi_3.0.0+dfsg-1.debian.tar.xz 95e412ebc24d5e120d9fb14093ecd62b8a812e19 13358 gudhi_3.0.0+dfsg-1_source.buildinfo Checksums-Sha256: e28c9a0bc0beafd1949670a75dba70282084bf488c55b4509c5d2c006e907e5c 2689 gudhi_3.0.0+dfsg-1.dsc 3853403c78b4ec5f64b4870844ad71be14b8a17d7bf5bf2ba66d86b2cba22fc2 17302661 gudhi_3.0.0+dfsg.orig.tar.gz 4d1c030ee8aa0be45c13ffce7d951ad9ea5f7a5f2b6f885d6f168af40a470b4e 9348 gudhi_3.0.0+dfsg-1.debian.tar.xz 7c60d5e2c1f46d35e7078cf1b5ec74b63e8985e33890d499c2b8e4a877930671 13358 gudhi_3.0.0+dfsg-1_source.buildinfo Files: 1df3e265acca7aca1a0b8ce4d6f43d0e 2689 math optional gudhi_3.0.0+dfsg-1.dsc f6c615f0cd265d44a9bd0ea687fd7f57 17302661 math optional gudhi_3.0.0+dfsg.orig.tar.gz 4abc6bd64634becdb091a5814704ab6e 9348 math optional gudhi_3.0.0+dfsg-1.debian.tar.xz a77419c10306128799ba77a158b07110 13358 math optional gudhi_3.0.0+dfsg-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl2wSCUSHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz6vC8P/jhVL5LAWoJw7Covtqovk3DFHZYq+w7R JPyogxqT1327EgFkUfSuMCJRgmTG8NPICJVqZo2mBcc+dXWX2ml03TJzJFJWJH+7 mOo9+VIFZvJeFQl+oJzc/MKc+GMzkaWmNG8VeE3sfuodBXG4c/z54zZs3God4hvS 5HzwKG1972hH7zSTwryLpMCKWeTLdaUroSCsd3OKFuylUGea+VyIdMQAzyvdINXP hgXHJt/Zy8Bjbwa5VViKlhOi6avLEJFbGhdu9oRFtHv6bjEP+LkTaVUzgCdP5Dkr Q0PvLcud0XN80MeFcnuwP1odMXOk65NmkilJFwKP+81QltN/18hFZFTat0tr4/EW YShkuyv4MxUwJXwSbaI7aDdV31zLtyb3DhvhQ/i4+gZMO1yoUCMqu4HPrU/7anPm UJL2OGt2NOy4glgb/T7gwAsIP0TxMp8U1ukBlIiWbOQbcycF8tqtw/QAgFeZD8jx M+dbpIRmzMCo15nKD3pL7CGazqoU4ZodiyaeVaUx1K+4W3OoLj0awiDgin9EMA3y EpTFmUXwRuefYiOfVwdbn7gUOBsoFSjJCsbMK1jGjz0lDv2e5DVM//OnioBP1eXc XN4gEttXt9T+o6FYPL2gzY6osQnkxsn7uc5FLkBkXfbw6mZE4uBAmiILSu1KYOHc UHYSLySnjSQ0 =Qz/f -END PGP SIGNATURE-
Re: GPL for package under MIT license upstream; repack?
Colin Watson writes: > On Tue, Sep 24, 2019 at 10:41:07AM +0200, Gard Spreemann wrote: >> A package I maintain (src:gudhi) was mostly under GPL-3+ up to and >> including the current version in the archives. Since then, upstream has >> switched to an MIT license, but with the caveat that many parts of the >> code has GPL dependencies and that "for practical purposes this code is >> GPL-3 for the user" [1]. >> >> Instead of having to carefully figure out precisely which parts of the >> code should be considered GPL for the Debian package, I'm tempted to >> consider the whole codebase GPL for this purpose. >> >> Does this sound sane? Are there some particular steps I should follow? >> Should I create a Debian repack of the source where every file's >> copyright header reflects the above, or do I only need to do this for >> (header) files included in the binary packages? Or does it suffice for >> d/copyright to reflect it? > > I don't think you need to (or even should) change the licence notices on > individual files. But if I don't even change this in the header files (installed with libgudhi-dev), isn't there a significant risk that I will mislead Debian users into thinking that they may use every part of the GUDHI library under the MIT? Best, Gard
Re: GPL for package under MIT license upstream; repack?
Filippo Rusconi writes: > Greetings, > > On Tue, Sep 24, 2019 at 10:41:07AM +0200, Gard Spreemann wrote: >>Hello, >> >>A package I maintain (src:gudhi) was mostly under GPL-3+ up to and >>including the current version in the archives. Since then, upstream has >>switched to an MIT license, but with the caveat that many parts of the >>code has GPL dependencies and that "for practical purposes this code is >>GPL-3 for the user" [1]. > >From the page you provide a link to, the following shows little understanding >of > licensing issues: > > 8< > > GPLv3 is a Copyleft license that gives the user the right to use, copy and > modify the code freely for non-commercial purposes. > > >8 Oh, yeah, I missed that on the license page. I'll raise it as an issue with upstream. > Maybe you would like to ensure with them that they understand what they are > doing with this mixing of modules/licenses. I did have a short discussion with them regarding the topic in general [2]. [2] https://lists.gforge.inria.fr/pipermail/gudhi-users/2019-September/000320.html Thanks for your feedback. Best, Gard
GPL for package under MIT license upstream; repack?
Hello, A package I maintain (src:gudhi) was mostly under GPL-3+ up to and including the current version in the archives. Since then, upstream has switched to an MIT license, but with the caveat that many parts of the code has GPL dependencies and that "for practical purposes this code is GPL-3 for the user" [1]. Instead of having to carefully figure out precisely which parts of the code should be considered GPL for the Debian package, I'm tempted to consider the whole codebase GPL for this purpose. Does this sound sane? Are there some particular steps I should follow? Should I create a Debian repack of the source where every file's copyright header reflects the above, or do I only need to do this for (header) files included in the binary packages? Or does it suffice for d/copyright to reflect it? Any advice is appreciated. [1] http://gudhi.gforge.inria.fr/licensing/ Best, Gard
Re: Clarification regarding Qt 4 removal (and #875036 in particular)
Scott Kitterman writes: > On September 5, 2019 7:36:01 AM UTC, Gard Spreemann wrote: >>Can someone help clarify why the Qt 4 removal causes all of >>src:libqglviewer to be marked for removal? Surely its Qt 5 binaries >>could stay? > > All binaries from a source package are removed as a set, so if the Qt4 > packages are RC buggy, they all have to go. Ah, of course, that makes sense. Thanks. >>Is there any course of action I should take as maintainer of gudhi? I >>tried contacting the maintainer of libqglviewer a few weeks ago, but >>got >>no reply. > > You might investigate if there are remaining rdepends for the Qt4 > packages and if not, an NMU to drop them might be in order if you > continue not to hear from the maintainer. I see. The problem with that is I'm only a DM with uploading rights for a few packages. I'll try to contact the last uploader as well. Best, Gard
Clarification regarding Qt 4 removal (and #875036 in particular)
Hi, I maintain src:gudhi, which build-depends on libqglviewer-dev-qt5 and depends on libqglviewer2-qt5. Because of the Qt 4 removal, src:libqglviewer, which provides the two aforementioned binaries, seems to be marked for autoremoval (#875036), and thus src:gudhi too has been marked for autoremoval according to the tracker. Can someone help clarify why the Qt 4 removal causes all of src:libqglviewer to be marked for removal? Surely its Qt 5 binaries could stay? Is there any course of action I should take as maintainer of gudhi? I tried contacting the maintainer of libqglviewer a few weeks ago, but got no reply. Thanks for any pointers. Best, Gard
Re: tag2upload service architecture and risk assessment - draft v2
Scott Kitterman writes: > Several time people have said they feel it's important to be able to verify > from contents of the archive. Hi all, Please forgive my ignorance if this is stupid, or if it's already been discussed and I overlooked it. I'm not posing this as a suggestion, but rather as a way for me to help myself understand the technical aspects of this very interesting debate better. Why could there not be specified new (complementary, not superseding!) formats of .dsc and .changes files wherein those files are not expected to be signed themselves, but instead are expected to refer to signed git tags? When ftp-master sees this particular format, it could perform a shallow git clone of the required tag, verify it, and consider that as the source of the package. That source object in the archives is then verifiably from the signer, and requires no intermediate service (apart from the current problems of people changing keys etc.). Obviously I'm missing something here, and I feel I'd learn something interesting if someone could explain. Thanks, and sorry for the potential small distraction from the conversation. -- Gard
Accepted lbfgsb 3.0+dfsg.3-7 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 26 Aug 2019 17:20:47 +0200 Source: lbfgsb Architecture: source Version: 3.0+dfsg.3-7 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Changes: lbfgsb (3.0+dfsg.3-7) unstable; urgency=medium . * Man page stub for -examples package. * Add superficial test that just checks that the upstream examples run. Checksums-Sha1: 46aacac525a348dc2eebafb8f33c05f046acbaed 2217 lbfgsb_3.0+dfsg.3-7.dsc e8b8d577dc35655be4d4aba8f5a99b881e5423e0 7492 lbfgsb_3.0+dfsg.3-7.debian.tar.xz 5db32d46280923b1bc86f772dfa40a8cd0e90023 5605 lbfgsb_3.0+dfsg.3-7_source.buildinfo Checksums-Sha256: 7825c70be5fb5436bc751b6a730a6940f86d0e3ebe1d84513587d2d43fd7e5b2 2217 lbfgsb_3.0+dfsg.3-7.dsc aa2e7dfe04f906f40b0ab7830e4b2f38098d855bf97ec07fe0e448c5773afe1f 7492 lbfgsb_3.0+dfsg.3-7.debian.tar.xz 02da7d145450125ff7fd2c0cbb5a4056c30a39a157de4343282ec2dd8f404c4a 5605 lbfgsb_3.0+dfsg.3-7_source.buildinfo Files: 1e5a9d2771101f42101baf00b7f5cf82 2217 math optional lbfgsb_3.0+dfsg.3-7.dsc f4ac64516c664aa61c52b00eacafa054 7492 math optional lbfgsb_3.0+dfsg.3-7.debian.tar.xz e2ca22d0d846df924df8ed93cd306d9e 5605 math optional lbfgsb_3.0+dfsg.3-7_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl1j+RQSHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz67coP/125+j/hQsqvj1QSuRPS7tfamv9TOfS6 KnNJJEu4QoCFXQSsuqjjyMV1eejOf4cGNmAVbj1uk13mYYJ0SdZzBNnV9BjbCBbN EBX6Z/Hw3STR6GgxB6eMimSmuhMbNqfBJVJ5OJC/gs9S/R+RgMXGP8Lp21S2XiJx Ms1Rin0azL0UwbmmnHsUJeUxpXzWnv46gNFXfMUXVd8Hc8c95yhUBfTo3KdaE4xT 2jZIOHcx8zLZ1rH4WqFj9gNsa6IUrOYmvec2efgqyDSWtWJ47QJHFneSB24gSS72 z/Ni37QXg0zTZXqDZVFR3MXurJCOFM3arKdnuNGVDBfvZU6/G74EXU3xu0KHQ37n YOyBU6fCATdSdFCv8bh8UzJcXagg4BuWxAcwrEL9OsXTq7W2Mv4F8O3fIv+7sCaH 490M67HoqufG+pY1ouEDE7nyAJEGMZEtYgEME+P1nd+mWOpXEmxT8jKdF3AuiXa5 asm7Zoo1prrTzFbm54mttRcz6PpLJOj+hQkt7nZIXCjSVJoHnLG9sZivhA4tjPwZ B0MUzZCvzAUqymar0AepNuGg1SwiWLVKmtcDODNy/Lgzdca4Mr2/fU/VsEZX7Q9U zEOdpIMBOnS0f+Jpb88ky3VMVZauobXT9/Xyl7RL3fq3CDUsGLMD9aeBjWVYjPOZ /jXBIRueh/gz =ZnuW -END PGP SIGNATURE-
Accepted lbfgsb 3.0+dfsg.3-6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 21 Aug 2019 09:55:26 +0200 Source: lbfgsb Architecture: source Version: 3.0+dfsg.3-6 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Changes: lbfgsb (3.0+dfsg.3-6) unstable; urgency=medium . * Reorder linking flag for tests. Checksums-Sha1: 7bbb8c32314f082304eb2fd51d9274701caa3ffc 2217 lbfgsb_3.0+dfsg.3-6.dsc e13050d89ca008cdf8364b2643f4c8101aea7684 7084 lbfgsb_3.0+dfsg.3-6.debian.tar.xz 60978fb726de1d26d2b5e1a6a38e5fdb852ece26 5605 lbfgsb_3.0+dfsg.3-6_source.buildinfo Checksums-Sha256: 8931052b6fe0184375a76a5aa2b5c3cb02b2952bc4093c886b85113822624c35 2217 lbfgsb_3.0+dfsg.3-6.dsc fa2f8f0b7e2d463d8419ac07932463fb4562f900459efcbc5d5ef196fe8e6c55 7084 lbfgsb_3.0+dfsg.3-6.debian.tar.xz 4215687929a05ef84fc55acc3aab081d37e7d2b96a990350747c47c941c22298 5605 lbfgsb_3.0+dfsg.3-6_source.buildinfo Files: 17c6256c445c8b74d396474ec2e1276b 2217 math optional lbfgsb_3.0+dfsg.3-6.dsc 317d05758b0c2370aa7850f4f5bfe459 7084 math optional lbfgsb_3.0+dfsg.3-6.debian.tar.xz ef6784ad1bdf09daacc0750c7d22ba43 5605 math optional lbfgsb_3.0+dfsg.3-6_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl1c+VYSHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz6RtcQANJ2fjBn6a1qQ1pzysVRLhlJrwixFz8a +IIftxeA3prgBPo3WVmbUyxBAEfb/Ugyg+0Uoih9L90Fk93DHVNhMFEtu8NVT4Tm zsqoS3/kUDIcAWMKIpOB/VbSuUmknwIzeNuGX3kXmpUAuxNd6H0aeDtSwN7Elr2P AxM+Nzi1fUqI2i7kkiQTBn0V6JpenM142DsoMuO1J8Jp9N1prbCt6yyUTzBSYAAC 2lWkezoDI9TBLLTKt6EyfaRxHZBBNnVYIu/MBftKifR0SJxRZd149vLrp1BGJiJr 7kzHEkWaqmEnvT9KUJH1NZ1A1Pn3y3CpRUiExSp6pM4F55+a892Brb+oUwwPP4Pt NYhzgVKKu+X/wVweRT4RSeD6ft/yOzWWkIVXODTxvGpiZLELDhX8SVk+hs7x4ZtZ qL4i5mP/4OkrnlxxzBXpkIQwlMB4h8MDXTKg6+RJA78MmsU4Ak8QrFtSw9BO2BZJ NuAyxVhUABRGCYpB2SSpmjfSKRbx5f/IL8QEzGStDma9hYx8h9io3weUbSQZ7kJa 56MUUBdFV8y1l+pExjiNQASbD4GeyNSMr9295oLyrVa6LMniiqnW9t5k+GOrBNIZ HPRxivnjI5X9NeNoWt9LVwUntnyss5L9W8B1sjz63B7qdElp9WAk2HzuQ5rl0i8c YLOxFF+iSy1d =PN1t -END PGP SIGNATURE-
Accepted phat 1.5-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 15 Aug 2019 11:05:29 +0200 Source: phat Architecture: source Version: 1.5-3 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Changes: phat (1.5-3) unstable; urgency=medium . * Add NEWS entry describing reused package name. Checksums-Sha1: 472446e6267b2eebd8d8d044c64bdd04fd501928 2003 phat_1.5-3.dsc 701e997e2bc56769bbd93ad6016a47003c1f61c1 3284 phat_1.5-3.debian.tar.xz ef43964d8da2d742889696e93739a37a83e29cff 6644 phat_1.5-3_source.buildinfo Checksums-Sha256: 1d19c4341cf0d98b6be2667017e66100b3f517a14a47f1d002207ea9ba0d920c 2003 phat_1.5-3.dsc d8a4a3d1272d344c11b663fcf0dcb54deab081dc895b484cc13120a9a963679d 3284 phat_1.5-3.debian.tar.xz 1590fe2ecf6ef2ebbf0274e58541d6c57d19eb741dce8843d3165e4145a27679 6644 phat_1.5-3_source.buildinfo Files: b9abccbeef40c866188b8e8cf6c17dbc 2003 math optional phat_1.5-3.dsc 3094b04cfa7dc9db42241c88b57077ac 3284 math optional phat_1.5-3.debian.tar.xz 4c996f599d4556a94a21f4406a09b1d9 6644 math optional phat_1.5-3_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl1VIJwSHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz6k5UP+wdCSvaLStUpV6hxMP2hRmmWKi/4WyFd 8ScaU9VvyKzVch5ZDjRp8kIRE+EprMUWDjWBWy8nUydaNnAkL/aQGP+n7FanxCMK R0bqxcOGYIHpvqzDBISWlFvl9qJjjQf1RfuPWlOuJPHI4DKstX1dHV+cgb/FJSSj av7etWYExjHpmRi3f/eAeHQGWn7zBXr16tj7pLzKgS8OljPjrFmTLv7tDkjVGBl9 KJhieqLYXOKoVcmji6EZkA+C8/ijGnAvdASzCTTYdIjvoQJDT2xoEjh/VVdlXQDZ JbhyV9QHWO/VVVWpEA6UlUV34ltcUq6+ctTMoUEoOUjU4rcrMaCRZ0Smp+uV4mkZ W5jvd3fykZehO9hSbEib1MXrDb4JkID+hIPdaiIFqljCRE+GFYF7fQqj0GoVCzRY SsEoV6Ydnp7Emd7Mui3zIhJv6Y+vdyZgXnKMqRAWfzYhns5dkN1kPltI9w6kAfHc r2ltYZOSeQAG6cT8pkeoWUTv8usEOmIv/RVTSAye36PgyJjjgv8CLgQq3t4OFzGP kpz7tAeMWUNxgc+gQwWBbkeAvr83vZD2dZY/VVzvlKxPtZIaouZL/4gjvHLE1t6u 4OILB/9YBx40ATIy+EJrQ37GYTGWRYkMyIar/JIvb5XtaxqeRM175R4NQtFF4ui8 YBeWjVfHLszQ =ox5D -END PGP SIGNATURE-
Accepted phat 1.5-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 15 Aug 2019 09:36:51 +0200 Source: phat Architecture: source Version: 1.5-2 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Changes: phat (1.5-2) unstable; urgency=medium . * Standards-version 4.4.0.1. No changes needed. * Update maintainer email address. * Re-upload as source-only. * Remove Lintian override that's no longer needed. Checksums-Sha1: b5b3793d3959c49e7b5c602608c52d9613ffb322 2003 phat_1.5-2.dsc 408bf814e29250097e876689a657ab1043040495 2956 phat_1.5-2.debian.tar.xz fb09e423f1278ae1b9fd5f3a0d6b236cc8ea04d8 6644 phat_1.5-2_source.buildinfo Checksums-Sha256: 6f0a3eb9151c4187214d85ab5f22870d6e1b027c45dbcc9c25aadaf71355eb98 2003 phat_1.5-2.dsc d792c375d03c9c785f72ab3c4c5f70f00061bef292f4e44c4b07a225703f5403 2956 phat_1.5-2.debian.tar.xz 597e51b14fd4d74a0b8b777d31b4b76b5d5b0fecda735c4a39a1b8cfb5e446a2 6644 phat_1.5-2_source.buildinfo Files: d5aa11a78fe7e69ff4565a7ad2ea46e1 2003 math optional phat_1.5-2.dsc 3314bb9ac839b57106f4792b95cb02ad 2956 math optional phat_1.5-2.debian.tar.xz 5d6c5718f19ee0fc3b6af1b4ea5d4d68 6644 math optional phat_1.5-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl1VDdMSHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz6MD4P/iWgqHvA8UZiwc7ricMq6P359/B8K7qO PRh+Wy8QMrjkjr9sFrgOc4xwdDPx9YXJmmlN2q2kVS3/VvVB2uZpYHXhkMT6YTbu EW+ntIy4I+N/pdGJ12MlHJKFmWmCV0HivDCXViPjB95Wr6o1y7r+J0eJ/TQtvAmx B6UyjDxZnWFl3AfncDeVJKvZ631iz4csfdr2dqHRT0ar+WgXel9Umm3QzEwZbtuB x8kGJpphH3pIyzLhtQnR4AsnNhaiOsZ/25nchDugq02i7LZqmo/mHis5zO7JH9pb qT0qD41Srh4xbwKw3HRhpMg2ah79fKFbZjn32kcrqWi11+d9ou9BtNFhkM3GTJW0 /A2pqyd58sQX8TM5128EjdE1oVVgbEIvWqn5BMDzxqXn5MopP8I5Gsyj/2K7FZ76 EXddnqpgLjaBRgdp6D6gfERxa1DOBMuCGg4hDz0qMA7geOKi5kO+pKn9X/OfWudv otBTKN6H4mFJlpLmGstfnjfCmvyVanqewlETzctnQ+6vG2MJRrSkPHTxKHBCf0SY 49wDUWKKLwWHLFnXLEvQ29/CWygmfDv+MuaJ51nFJ7EH8zmBeB7Eyevh5ERg0UYE 0HFeHA1mpsmDyGf7/rlcA3jrrEjHJWn/Xp8+IviHisuH3AHVYH/sGgQcMrYCHoQT SJqYCrFrEfmI =W8tr -END PGP SIGNATURE-
Bug#932726: ITP: python-pyspike -- Python library for the numerical analysis of spike train similarity
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: python-pyspike Version : 0.6.0 Upstream Author : Mario Mulansky * URL : https://mariomulansky.github.io/PySpike/ * License : BSD-2-clause Programming Lang: Python, C Description : Python library for the numerical analysis of spike train similarity PySpike is a Python library for the numerical analysis of spike train similarity. Its core functionality is the implementation of the ISI-distance and SPIKE-distance as well as SPIKE-Synchronization. It provides functions to compute multivariate profiles, distance matrices, as well as averaging and general spike train processing. Mario Mulansky, Thomas Kreuz, PySpike - A Python library for analyzing spike train synchrony, SoftwareX, (2016), ISSN 2352-7110, http://dx.doi.org/10.1016/j.softx.2016.07.006. The library seems simple and mature, and I will be capable of maintaining it on my own. I will need a sponsor, and will enquire with the DDs that have sponsored packages for me in the past.
Accepted lbfgsb 3.0+dfsg.3-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 18 Jul 2019 13:48:32 +0200 Source: lbfgsb Architecture: source Version: 3.0+dfsg.3-5 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Changes: lbfgsb (3.0+dfsg.3-5) unstable; urgency=medium . * Remove broken symbols file. Checksums-Sha1: d2543e92d28627643e4f8fdc1c61aa2e896382b4 2217 lbfgsb_3.0+dfsg.3-5.dsc e38f9abcf5e89e0aa9e84952f2c3a987060871fa 7060 lbfgsb_3.0+dfsg.3-5.debian.tar.xz 0f6965ce40a258698e897c40651741f9ade40a89 5589 lbfgsb_3.0+dfsg.3-5_source.buildinfo Checksums-Sha256: 8fcdfaecb77a2609795aa79c08055d8946b03b9ed0029c694a9b499e29d5783e 2217 lbfgsb_3.0+dfsg.3-5.dsc d8d80b284cc310ff31ec755c6c6338571ebb9b48936331e2bfe0dc97ed49cddb 7060 lbfgsb_3.0+dfsg.3-5.debian.tar.xz a823ca40ef73cd202a02a271d8957e6baa6b494578e3dc6a9b5bcb1ad1849ff4 5589 lbfgsb_3.0+dfsg.3-5_source.buildinfo Files: 633226b0c55f718d83b0e2cca06643aa 2217 math optional lbfgsb_3.0+dfsg.3-5.dsc 333d6d78ed01afef97d7c502e7da6301 7060 math optional lbfgsb_3.0+dfsg.3-5.debian.tar.xz 559706fba926118b35b3aca37aac9ecf 5589 math optional lbfgsb_3.0+dfsg.3-5_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl0wXNcSHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz6/pMP/iwkCg8JWesosjx4W04TIajjzhCUGLRv 8fVVldZvrFn3O0bEUbD4Jj0l/hlXaAKrf2C2IEujdf1GVCDbvc7ZVf8ENkX88eEQ FgGzsYbEuLi2H+vv34sdlnUF3yB53zKb261h2F5FTUcWW7snorbTTVCS4SeHWMCX 9H8PQ72W4z9kC51eMDbkmDp3KlpoB295XhtbrlkFJ5Rlw37Oe9jf87TL9bzvqG8Y Up0Q0Y2WCdxzl6M11oH5spuYERg7ty5bC/xEaAu0lqD+eyWWTGrTcaI55Qae5kG4 c4B4AutFbHkwjC4IvLRL9JvivMTAMZoUKaKBWH3KhXuEUWngXVM16rK4ALyaem0l 1qz4uan9fI2kTrYPFkXpMcMXCViC6tgJoodLD0ph6fB+2wDkiwTQlrLQIagOgEMf cx7tlahW5wQh/7cH/YZjNKjy+qSHr9r4x6swKQ+sFjl6/YRVzXRoe9JZ6s6eW3Vy 2T0V8HXqykr8xfAKW7/abIXMVg5czILqfrV9CaWfjUG2K6hPCP7twkmztjOdM8Ii HqQkQO+ksD3Qrc5PB7JCxAchPj95RPIMU3N85iyxKZq5YtqMnG/DFDn0vvIjqNp4 Os5+2eK0kVdj8Wb6LOtqpnbaW4WX7/343YRKafAc4v4V3NbsoKXv2uFx5B5a7X7m 81pQeOOe5JfP =Af/e -END PGP SIGNATURE-
Accepted lbfgsb 3.0+dfsg.3-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 17 Jul 2019 09:03:37 +0200 Source: lbfgsb Architecture: source Version: 3.0+dfsg.3-4 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Changes: lbfgsb (3.0+dfsg.3-4) unstable; urgency=medium . * Standards-version 4.4.0. No changes needed. * Compat level 12. * Add symbols file. * Rules-Requires-Root: no * Change maintainer email address. Checksums-Sha1: bb90b1cf147f4d2e6464de440df8bc56f4395f72 2217 lbfgsb_3.0+dfsg.3-4.dsc dbffa2d00192cad0af0854d6eb93bc6f72255a82 7168 lbfgsb_3.0+dfsg.3-4.debian.tar.xz 654eb6e65502cfdfd19de071690e97755fccb39f 5589 lbfgsb_3.0+dfsg.3-4_source.buildinfo Checksums-Sha256: f123163985a08f682b43758384e70de6b2477f9e2653d6c3327906f5fafbb9d5 2217 lbfgsb_3.0+dfsg.3-4.dsc d744e5ec47adcd13daf9f87c49d06a9992d675c6a2077b8fee3addb91a30dbd2 7168 lbfgsb_3.0+dfsg.3-4.debian.tar.xz e94288788037c94b98600d244d9d85ff162e2448708d78b35ec14207cd6edeaa 5589 lbfgsb_3.0+dfsg.3-4_source.buildinfo Files: 23c381ac2ee74c761a76d39a06b08bd1 2217 math optional lbfgsb_3.0+dfsg.3-4.dsc 513f7f4a2ac749a2a4c699fff9a2db9b 7168 math optional lbfgsb_3.0+dfsg.3-4.debian.tar.xz a14a86e86e9d161f202d7961c2993d41 5589 math optional lbfgsb_3.0+dfsg.3-4_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl0uyKQSHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz6lo8P/ijnsx0OFBU8IV0VDmkkiL32Couvk1jp aWgRFASajWiuT05Icm5sEMV/8pIslcmHcPxjxVsVb9d4INcjyyZQIf7rpHl4Py3J WqsbO+r+MM5X6JyCvWVRTz/J6AfFgYVNkAxEGVHb2WfFbj357xe2oC5KCVyLZHPD EsZd0kvA+nuLIcmzraEtPXShPtvGPKnehf4c42EN5JVhzPijpgxJ4mFShlCQDmE2 zJueSo33k7oYhl0IJL+HwNCfTQLHvx1TKPUcmL8+74NnqaBXPfFyLV3G8nqGCmGG ONFgZSdR/Q1EBHB30em6XIk1cxNNh3eCavxeCCBD7W5eSRcalgSA5VphL0jYwhhA L8bFiSqYvtZPZMNAHVDI/zyWSVK6D3KJWSUABlObaqJtX73ZiuC7LMAzY17Jl7zj CNM3wm/9F8qWvp6yj7k4Msst5w3UveTLhKV7RjPCzFNMB1Z2N2YfkkkmQbmfH+OG 6FAN6gjcwm8Ksi7NdsnzsNQ5jfrb1LXI8mNXNt2N08CDx9wd0F1//lsDbLIzTWZD RfB9x78NTdcGHzBBXRgNwNDSCG5tpdhpMh7JZlF77MgVD9z7IyuBn/LkPqG5uvXE Fco2LvoBUCLaSwu4mTY91j4FeJlGjZRcPWhEO10BDTaLL2qL8hoK1QnnSXPVBM8l yf7to0m8QGsT =3ghc -END PGP SIGNATURE-
Accepted tikzit 2.1.4-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 16 Jul 2019 12:35:16 +0200 Source: tikzit Architecture: source Version: 2.1.4-2 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Changes: tikzit (2.1.4-2) unstable; urgency=medium . * Add rules-requires-root: no. * Standards-version 4.4.0. No changes needed. * Change maintainer email address. * Recommend preview-latex-style. Checksums-Sha1: 12f854d9ca0b151a22971b1bee60cc9014eac8d1 1882 tikzit_2.1.4-2.dsc 1155f0fa26558bc79805606f44a5e62a527ad1b6 8788 tikzit_2.1.4-2.debian.tar.xz 97ea3fc65cf117d1d7cea791529e126c304d12ca 9799 tikzit_2.1.4-2_source.buildinfo Checksums-Sha256: be19bef1160a26f4d104b9678c6cdf515dad0f3b997733be7b4d46e4da5c4812 1882 tikzit_2.1.4-2.dsc 2561ac74ae1bab4980c2a79110ec40df9b1867520bcd77b6e975b6068a680b31 8788 tikzit_2.1.4-2.debian.tar.xz 72458e904f7248d53f4a4999df32358d9a90f674803e50d2cb3dd431a70dbf2e 9799 tikzit_2.1.4-2_source.buildinfo Files: 44f3791dafff619dcc210b790c9f16db 1882 tex optional tikzit_2.1.4-2.dsc 65b261d661da6c658137fb0893270cb5 8788 tex optional tikzit_2.1.4-2.debian.tar.xz 6c36cfff6ba0da21ef1938a2d01a75a5 9799 tex optional tikzit_2.1.4-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAl0tqYESHGdzcHJAbm9u ZW1wdHkub3JnAAoJEJ0RWCr9VIz6fKwP/0HbKrjtRRMIn5KpN+ITPGjjNrkmfnLD /oBulBgr4wGIJEArOAO0zegyaNvaIZA9UIVyGpdUzbukEoNKF0M1+oaXkV4TlW2B KAz52Rg45BcdpZ88NKvpHUdv6HP6uBrx7s6zeRYLeut6i97B/soxiD9fH1C7TLLj p9/CsM+qUht18Wx16EK90+jSmDq+AD0sc5o7vk92UnZAdq2s49lf+s03cRop5aQw ZfEzwybAX1Tq23gukyu57dnv9RxnBNuLl6Auejx9IlF7Hjp76KxiEHtVzE2Qufo+ /4R650HUD6yOyYlf+ZA2j/nUk35q7BU9qciB1xZgpHa/DaQ908eYHe6NDVaT/TZX tPa7AGbuYL/gWm7PsZUJWGl2L4zDukseFFzVk/WmdfI1qEKwNu+qmUrtK0dI4kd0 O7ap/nN5+eI/UJpreBga5/7JLTZig0qHfOCLQ1lUG2epdD3NMMnrA0gjoq/OHOjl xURG2bPLUGOFvoe0w4Kb3JiI1L8qg/ZK+tbZTJsXUYQPY+dVuKsy9LYco7eIQrcC TgBifhKgHcREIc+Bj5nUierZqDbuq+7QZzVohpmGFNxTAkuopyo2OjP18CB2QhQQ Xa8VYf52BGIhBmtdS2QnQN6n0QGzqVJiEEBFG+3a5oD5kHlGV3zMC6eILr+/U6Gt vCgvldqVw3Ua =DICD -END PGP SIGNATURE-
Re: Content Rating System in Debian
Bagas Sanjaya writes: > Regarding freedom, yes it can be affected by CRS because CRS can limit > freedom to use programs for some users > (particularly non-adults). But CRS limit such freedom in order to protect > psychology users for long term from negative > impacts of programs they used. Surely this would be a direct conflict with the DFSG? Best, Gard
Re: Towards lapack / lapack64 packaging
Hi, Incidentally, and somewhat off-topic: Do you know if a similar effort is being made for the PETSc and SLEPc packages (src petsc and slepc)? Best, Gard
Re: Preferred git branch structure when upstream moves from tarballs to git
My initial question resulted in a lot of useful advice and opinions, and spurred quite an interesting discussion. Thanks to everyone who contributed, and apologies for not contributing myself.
Preferred git branch structure when upstream moves from tarballs to git
Hi, For one of my packages, I maintain two public git branches: one is upstream/latest, where I've been importing upstream's released tarballs, and the other is debian/sid that contains the packaging. Recently, upstream has finally started using git. What is the recommended way for me to maintain a sane branch structure for the packaging repository while starting to use upstream's git master as the upstream branch to follow? (My first thought is to track upstream's master as upstream/latest-git or something, and start merging from that into debian/sid, but I don't know if there's a better way.) Best, Gard
Accepted phat 1.5-1 (source all amd64) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 20 Feb 2019 13:03:51 +0100 Source: phat Binary: libphat-dev phat-utils python3-phat Architecture: source all amd64 Version: 1.5-1 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Description: libphat-dev - C++ library for boundary matrix reductions over Z/2Z phat-utils - Utilities from the PHAT library python3-phat - Python 3 interface for the PHAT library Closes: 920912 Changes: phat (1.5-1) unstable; urgency=medium . * Initial release (Closes: #920912) Checksums-Sha1: f41b228fc0c2774d46d6aeade502d3dafa4c761f 1981 phat_1.5-1.dsc 6e2f4e74e60152eff657af6802d08a5d923d277a 4759057 phat_1.5.orig.tar.gz 3129762252e2e3dfa7c2959f6018510993f8b73e 2944 phat_1.5-1.debian.tar.xz 1d9b0ecf42daa11b4594045406f18adcfd367774 13680 libphat-dev_1.5-1_all.deb 04ab21e67a4250b1a3572d3f8d7323dd38decd3d 1292660 phat-utils-dbgsym_1.5-1_amd64.deb 5a982a992a0f3229ed65521694dae585e9d3178a 92308 phat-utils_1.5-1_amd64.deb 2ff8b30b0cfee782e1c0001c20c4f1262d36e7d4 8151 phat_1.5-1_amd64.buildinfo 6daa76b34ce077ec106f062f8623c76d6d51e7f3 5125088 python3-phat-dbgsym_1.5-1_amd64.deb e5e89a7db6f4901d43eccb24c9fe3ccabc838d01 186524 python3-phat_1.5-1_amd64.deb Checksums-Sha256: 4f35d4762969e791d7ab01e4bcae22fcf9f28c0e21be819a3a2f4b1f113b5d58 1981 phat_1.5-1.dsc ccbecbed7c5d3f3bbedd978ac3d8d9216399e0fd542d51c353cf4b5093187eda 4759057 phat_1.5.orig.tar.gz a165ef437968a99a494bee99a243afce917a68a8ebcba2995ce2e68ea3f2c3bd 2944 phat_1.5-1.debian.tar.xz 759ee52d0dbee1049d4a41ffc6cc68139b9fd6d5722046669036984ed8497258 13680 libphat-dev_1.5-1_all.deb 1fda4e46298d113b636dab866bb7d547da522711444151f4642f7f27300f8824 1292660 phat-utils-dbgsym_1.5-1_amd64.deb 9af70ac71b0f699c6fa83ea96d2078745fd32c521c214b9fe342cb2207bae5c7 92308 phat-utils_1.5-1_amd64.deb cf289becafa1630978e5b9c7d9423bdee9c65499cdf3b912705c5a9bf847601f 8151 phat_1.5-1_amd64.buildinfo 8f85fadcd32dc482524cb07cfbda6766ba02b4bd3896b4a992646d6776119fc8 5125088 python3-phat-dbgsym_1.5-1_amd64.deb 51d24179608727538066d7c8c5c43c808aa6c5ac09543c7d356043d036f36a1a 186524 python3-phat_1.5-1_amd64.deb Files: a9cd19a630b9185188f8f8c48b49e9f9 1981 math optional phat_1.5-1.dsc 47f60aff64399b553edc19d816ea1e03 4759057 math optional phat_1.5.orig.tar.gz 9abcc8279ddb9a8f5afc389104f56246 2944 math optional phat_1.5-1.debian.tar.xz 83d4f791deeef12de2c91243bbd30bd7 13680 libdevel optional libphat-dev_1.5-1_all.deb a47fcfd5a4c0e0fdee1bab82a79022a1 1292660 debug optional phat-utils-dbgsym_1.5-1_amd64.deb 7d6f1314985140d4cedf18f208a71d63 92308 math optional phat-utils_1.5-1_amd64.deb fd37990a3330e9336151982afa04fb71 8151 math optional phat_1.5-1_amd64.buildinfo 3696eb7f834bf8cf53f34a66136c90d5 5125088 debug optional python3-phat-dbgsym_1.5-1_amd64.deb cf5e3c1dcb932887a099ff649e31a0c3 186524 python optional python3-phat_1.5-1_amd64.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE/d0M/zhkJ3YwohhskWT6HRe9XTYFAlyQGPMACgkQkWT6HRe9 XTZg9BAAxmswqYlmZXegxXA1ZWnPLJWVVgCpkfimAe3WVMla5BIXtCaen3WPvNFj JelkQ2K8L72UzpyBNfoLcInmOnIqJn10XwEjJ+0lbw8bYe3qSmeQJdHGdVxxsp5a DrY/mzgdwou3JkW3B/WgR46Z91RukELw1tT1pScf+xEPlbALL8vtmBX4bkCpXSXH nvo2WaQw6gNaw6mtv2LK2PNrvHbu/mZd0cQHp/bluELcIV/zW8z1cuuAwRExRQlW DrgWdkIHurNKt9QZVJE1M+B7olh9+Pmqp/b0QvUZA9zR+cnfFD+jFhTeeNXWiTkd +dRSvqdk+trb+YmHDumx8WFDcSzdBnzBte7LFKJ/X4U8sq2JKEpkKmZl2PA5MExp gVxp8OYbxZqPiKEKpLl3q1hx85tPgHvQn/W4bW97Aq7BYIsDGiYCs4LW1ohcxMWl H/7264QGOZuzVOdF4ULg0CWyahmrjOhAWvOqmwDK9RkVSUHUQi4QYJM20sMiR6YW gyj1QHuXpJsYjb8EDk1kl6ICw2Qjw+via1LqXCtN5sWtp+X9oqkOIbENZA+jPfrX EIQak8BEUwr/XCgpCbHna2BRCfKqGY4CLCjGoa2jvy3HFJ8wuUOF08YEwBiyNC9s /DBcw5L7wEwnHf0h/gE4wxVgfNyctXeUzvs8ZgchgHr+Iwd+T0s= =+I3S -END PGP SIGNATURE-
Re: Reusing source package name of long-removed, unrelated package
Ian Jackson writes:
> Julien Cristau writes ("Re: Reusing source package name of long-removed,
> unrelated package"):
>> I would say reusing binary package names is usually worse than reusing
>> source package names, in that it's a lot more likely to affect users.
>> Sometimes it happens anyway, but IMO it's best avoided.
>
> To an extent that depends how many people are likely to have had the
> previous binary package installed, still, and where it might be
> referred to (eg in dependencies). So the problem with reusing a
> binary package name becomes less severe, the longer the gap between
> the two uses of the name.
FWIW, popcon suggests the number of users declined steadily after the
removal, and has now plateaued at 15 [1].
> To Gard: waiting for a few more opinions and then deciding is a good
> plan.
Will do. Thanks for your feedback so far, everyone.
[1] https://qa.debian.org/popcon.php?package=phat
Best,
Gard
Re: Reusing source package name of long-removed, unrelated package
(Apologies if you receive this message twice; I dropped a ball juggling
e-mail identities).
Ian Jackson writes:
> Julien Cristau writes ("Re: Reusing source package name of long-removed,
> unrelated package"):
>> I would say reusing binary package names is usually worse than reusing
>> source package names, in that it's a lot more likely to affect users.
>> Sometimes it happens anyway, but IMO it's best avoided.
>
> To an extent that depends how many people are likely to have had the
> previous binary package installed, still, and where it might be
> referred to (eg in dependencies). So the problem with reusing a
> binary package name becomes less severe, the longer the gap between
> the two uses of the name.
FWIW, popcon suggests the number of users declined steadily after the
removal, and has now plateaued at 15 [1].
> To Gard: waiting for a few more opinions and then deciding is a good
> plan.
Will do. Thanks for your feedback so far, everyone.
[1] https://qa.debian.org/popcon.php?package=phat
Best,
Gard
Re: Reusing source package name of long-removed, unrelated package
Ian Jackson writes:
> Gard Spreemann writes ("Reusing source package name of long-removed,
> unrelated package"):
>> I understand that 3.3.2 of the policy mandates that I at least bump the
>> epoch, but I wanted to ask the list to make sure: is reusing the source
>> package name of an unrelated, long-removed package like this OK, or
>> should I consider using a different name?
>
> I would recommend using a different source package name.
Thanks for your input. I'll wait a bit and see if there are other
opinions before renaming the source.
By the way, is it OK if the (renamed) source package produces a binary
package with the same name as one of those produced by the old source?
Thanks.
Best,
Gard
Reusing source package name of long-removed, unrelated package
Hello, I filed an ITP (#920912) regarding a package I'm preparing. The upstream name for this package is "phat", which doesn't appear in the archives from jessie to the present day. After filing the ITP and uploading my package to mentors, I realized that there was an unrelated "phat" with a different upstream present in the archives from 2005 to 2014 [1]. It was removed from the archives because it was abandoned by upstream (#751276). I understand that 3.3.2 of the policy mandates that I at least bump the epoch, but I wanted to ask the list to make sure: is reusing the source package name of an unrelated, long-removed package like this OK, or should I consider using a different name? [1] https://tracker.debian.org/pkg/phat Best regards, Gard
Accepted tikzit 2.1.4-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 05 Feb 2019 14:09:02 +0100 Source: tikzit Binary: tikzit Architecture: source Version: 2.1.4-1 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Description: tikzit - visual PGF/TikZ graph editor Changes: tikzit (2.1.4-1) unstable; urgency=medium . * New upstream. Checksums-Sha1: dc59dff0a589b9caf736b6d59bca4bc58fd40f1b 1862 tikzit_2.1.4-1.dsc 2fd664449cb4ca310497568a71674554ec132ab1 456442 tikzit_2.1.4.orig.tar.gz 95643e14742757927d050c15b2810633eeebe51b 8688 tikzit_2.1.4-1.debian.tar.xz abf1906eeabff3d79df40a08b32ae4d86a56b3f9 9814 tikzit_2.1.4-1_source.buildinfo Checksums-Sha256: 3329dd2bb0c4fd60781757c9b31001627247708ff5663c24eec15b34193ab18b 1862 tikzit_2.1.4-1.dsc 14443ab430ff20e5c3b185a704932858afb3d776aa9b3a54e1b9898d5b9c13a8 456442 tikzit_2.1.4.orig.tar.gz b6e5815e80ff2ebbc780934376f3c21bda690992da73ec6dfb2cbdecdee2a8ca 8688 tikzit_2.1.4-1.debian.tar.xz 694a42f256cdf14fd496c298c6c357a76bccb86cbdd558d1da6b52e4fc924fc3 9814 tikzit_2.1.4-1_source.buildinfo Files: f4cb76703c1620dc42be7f673e31e8dc 1862 tex optional tikzit_2.1.4-1.dsc fbcf38903e52eadf7c6ac9639aab6649 456442 tex optional tikzit_2.1.4.orig.tar.gz 9679e1d32d30c7e25b57aa12ab605684 8688 tex optional tikzit_2.1.4-1.debian.tar.xz cafa006ed28ec1bc3b457014843444bf 9814 tex optional tikzit_2.1.4-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAlxZi28ACgkQnRFYKv1U jPoY0hAAuV3ruu+TAoTvKatxolNvUxP5dROluMh/vhIibdHPkLEAltjacLlXA+ts 2nVyvdarqNdJ9lmoPJg+B5Kz21uT8fLE8wZCjx5fZQCOf1AgEi8P3AnsChbqKKYu eYwH+zYXA+fftrWIu98mQRT6NLAsGLkZ9PcIeqqIaemMxoYM0jjDelQH7JvIhhB/ KfpETgyQfaKmg2SK4gUTm/d/8SXCyDpiOwaImdEEH48jY0eObUqoAvXgYy3EsoRX /UmKoiJzhhwmnICUD1PMBeF3h+Yz2QQlwms26l6TBF3cHUM2ly+nyE71ztKFpZI9 3iE06IjAofmT10a+wL0P3Q4GVJH1rtUOQlqA3DlHx2SM031lWgJ1gTCflT8r7s6X M+Odp3wV2anUaCOTCirjitOJq5eYa8NmgNoBZN5QQ3rnuoBNblTFuh/38MzOC3YN bLG9mK40is6g2J1A7J0Vmoo87RGp6Cxcbotm6xXS84WGNdn43+YwpTqauAH8T+0h mSR18mXvNFKH4my68fTLjIM0CZ9zrkmDM+2+P81puu360YLl47cJYFB44TU2NIFF KibqNjqNMIYvrtnntDFUB9B1v8qR0LYFq82Ll60qrp6F6jEoS89TpbQKUjQoP9zO hUYX6tjYUOSTTboyPE/naE/eCEKZsKOtjw/mP6fb7xHCsSYIiSg= =C1OR -END PGP SIGNATURE-
Bug#920912: ITP: phat -- header-only library for boundary matrix reductions over Z/2Z
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: phat Version : 1.5 Upstream Author : Ulrich Bauer, Michael Kerber, Jan Reininghaus * URL : https://bitbucket.org/phat-code/phat * License : LGPL-3+ Programming Lang: C++ Description : header-only library for boundary matrix reductions over Z/2Z PHAT is a C++ library for performing the filtered Z/2Z (co)boundary matrix operations commonly needed when computing (persistent) (co)homology in topological data analysis. The library implements several of the state-of-the-art algorithms in the field of topological data analysis. As of version 1.5, the library seems to be slow-moving and solidified upstream. The package is useful as a fundamental tool in the mathematical field of topological analysis. Having stabilized upstream, and consisting only of headers and a simple standalone binary built from those, it should be easy to maintain by myself. I do need a sponsor. I will inquire with the sponsors of other packages I maintain.
Accepted tikzit 2.1.3-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 25 Jan 2019 11:38:43 +0100
Source: tikzit
Binary: tikzit
Architecture: source
Version: 2.1.3-1
Distribution: unstable
Urgency: medium
Maintainer: Gard Spreemann
Changed-By: Gard Spreemann
Description:
tikzit - visual PGF/TikZ graph editor
Changes:
tikzit (2.1.3-1) unstable; urgency=medium
.
* New upstream version:
- Merge nodes with ctrl + m.
- Display contents of label={...} property above nodes.
- Fixed ctrl key bug for edge bending with the keyboard.
* Remove leftover stuff in d/clean.
Checksums-Sha1:
8538706ec93c7b630cd9638f6b9988c3397fcd2e 1862 tikzit_2.1.3-1.dsc
7baf1c81047964fc866e4213ae98c172347a92b7 455286 tikzit_2.1.3.orig.tar.gz
1d4f4ae6c34100b9f7cd8e4ee1a06ad2d103cf50 8684 tikzit_2.1.3-1.debian.tar.xz
c2f2f3923670b706da3e216275e198ea87affa83 9822 tikzit_2.1.3-1_source.buildinfo
Checksums-Sha256:
7413b66a598e3789aa13803fd14a826ea2f68e5c44dbafcdb6aae5c66f928cdd 1862
tikzit_2.1.3-1.dsc
01638ea9e2f883f33f282f681bddc21410ea6b5c7709647bd6eb61dca0d7c1c7 455286
tikzit_2.1.3.orig.tar.gz
3fcd2b9a9bd609ec5de87957a5b1108c28b6e5c13508ebf4154c95a7e80a75cc 8684
tikzit_2.1.3-1.debian.tar.xz
5d8a1f3196121a1eaf95bd38e660cc1f03399308c60c0f830c332845ddd7ccaf 9822
tikzit_2.1.3-1_source.buildinfo
Files:
bf16989db089a1a257fa263b567ddb61 1862 tex optional tikzit_2.1.3-1.dsc
833e36bffce601bd5df9e92b5eaba401 455286 tex optional tikzit_2.1.3.orig.tar.gz
031f06512eabcda76ee700b90d428600 8684 tex optional tikzit_2.1.3-1.debian.tar.xz
eb5ba947844c884b6b27c8987e1e8a44 9822 tex optional
tikzit_2.1.3-1_source.buildinfo
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAlxK7kwACgkQnRFYKv1U
jPoO/xAApKb2OspHjOLgYwg5Frx42JBLtZc1f7KbWEOUQTiFIbRf6a8I9v+QnYoG
W8lFavXM1Bdhjnym9UsIVv6qutKiiZSdRaPIo2CjmGKG9LNjTd8FQ9PVbpJ6QbzN
OBEnQD9jrbtkU8bL3ERTV+cAYrRzvGdDBIR4d8HngenVhYLMaZd4+QIVeeoj7gXo
KbOiwcPcF/pEKLKN0a3MVQD7ujgGGJwkpvgV3LTX8R9NN6s3nOJOxhhimudaTgyb
QYP5UGIhsnBn1RLwhC9jFXxAfORIHKj96OuNul7NaAzflV+Re/LJCM+1cwLUWbse
hLbzCitRThsr//mLHl7TMCxs7JPRDZY9unxowuwdkNys4RlLZFEbzJId/ckpeKmQ
0QFdkmFKl0DZoEFSvCB4a0yNDcatU/L/W5alLMisao8UR+06hyg6mOfcOiZH6eH4
MRVBzyG1OfvwRQOIFpgZ+9vQ5SbyDerkOwqLk63e0eZ6PJGouaK1IwJy8g3kOsqY
xTX1CS4GJscghZ/Fxpjm5tdhrNi9eKwCYZUNnd42hWKBUUASqECI8mUi1ijGeWZ+
kCC6uFJiPZFC0B5NJfF16QL/7CgHCBMmOn/nYwOwHgqbpZRg8ieF+4XVuKK0cXCD
JwSX/XJzLreImi3KnMeKiFxOr+Z/EN+t87ri+YlYc5Wwf3WVs+I=
=PMMo
-END PGP SIGNATURE-
Accepted tikzit 2.1.2-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 17 Jan 2019 10:06:57 +0100 Source: tikzit Binary: tikzit Architecture: source Version: 2.1.2-1 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Description: tikzit - visual PGF/TikZ graph editor Changes: tikzit (2.1.2-1) unstable; urgency=medium . * New upstream version with minor bugfixes: * Package description updated after suggestion by upstream. Checksums-Sha1: c42f8b21719e59f89f0ca573c75d14588548118b 1862 tikzit_2.1.2-1.dsc 4567e8e79dd9e2257c1bcbdec28b54442893ed50 454367 tikzit_2.1.2.orig.tar.gz ce1584da9c29d91de6b284edd8ec09c74dd15201 8604 tikzit_2.1.2-1.debian.tar.xz 67839c85b33562beae26e8b04dedbf3e80079f8b 9776 tikzit_2.1.2-1_source.buildinfo Checksums-Sha256: 5bd3ab310bc52d8064ba1cc411a48fa2d564c559c08897ad16befa43cf89b008 1862 tikzit_2.1.2-1.dsc ab396c1562df1ceebf97c70deaa02f87bad44450ab1d89ace0c35183e0ca1565 454367 tikzit_2.1.2.orig.tar.gz 71d210eb5df23444efc4da9e6622af1fbf353e719885b8fea7d93f6eda0ac972 8604 tikzit_2.1.2-1.debian.tar.xz e5643c5af9d9f6e8661a0cd09fc67b67dc3ee633ba30a3cfcc4d40ff36dd4deb 9776 tikzit_2.1.2-1_source.buildinfo Files: b301c1ae59fc8f797e9c730da80f58d3 1862 tex optional tikzit_2.1.2-1.dsc 8c88be04bd29c9d2bfdc949c16eba52c 454367 tex optional tikzit_2.1.2.orig.tar.gz ec5db8e6ded054e6978933ffe7347dd2 8604 tex optional tikzit_2.1.2-1.debian.tar.xz 2591dfb020c0515757edb4a86ff98d36 9776 tex optional tikzit_2.1.2-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAlxARlwACgkQnRFYKv1U jPqyAg//YjvFnyIMWRcywY2oVPPXeKrwlExrMG78Qbn/QoEPjTQvtsOlwkpyN+J6 Yrb64+LMQjsAQFU6zQ6ZK2pRr8MGAA0ijFs/7DJjXyk9nbBYG/y0fDJKsI9sTFr+ xBVYzO8VnoykF4EGLO+szwokT9WYpsiLKelbxQMHcqRDbqUojZFCQtBio3NXK94A lpY/mAM9uViC0voO3vHal+rkEkQ6WiWhfof2781Shy/zTZq646xauzQeS1DqDBmK Ya0vMDvVodlnlAmLDteEIQlTYC9lD18Q175kKGnySOlIsYZy5s/T5GoKwOnSWLZ1 bpYh1Mo8WN4XzsYtv9nbMUvAkvFLl4+tL9YNFMmbUclnUZVHj2C2izG5cY27bTjD Q6dzABYUaUOjD7q8iX6CIxmbWMg+p263Sj1bvc9TOtj5lPEHz4625c4U0dpOM2zo LJIbxBBCslW+Pk6ckTpNHvZbyUDB51sjuDMABvSOS9iemN0xUfCg26eI+eH00suo ajaMiWMrknQUw7a2d458ogYX2F0Sk+hlfrvp72lytc5bdYAR4O/M8pt84yjAbAFd G5GvJwIN/EC++OQAxXV6yFn4Fe5vePR7WLr8shc23+eQn2Mj4OtPCxbfDasfvBRU nTWNdEW+GpwsRt17pIrJ3ilrKAjG/CRcP1YchWJEA2ffHuvsARU= =iZpD -END PGP SIGNATURE-
Accepted tikzit 2.1.1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 12 Jan 2019 08:42:08 +0100 Source: tikzit Binary: tikzit Architecture: source Version: 2.1.1-1 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Description: tikzit - visual PGF/TikZ graph editor Changes: tikzit (2.1.1-1) unstable; urgency=medium . * New upstream version with bugfixes. Checksums-Sha1: 5e10ac831a55869a221fa1b9159267721fe0504b 1862 tikzit_2.1.1-1.dsc 84b55583a40fd9d23b59c66bf05dfb4291695445 452388 tikzit_2.1.1.orig.tar.gz c49fb8dcbdc304ec2a4d2c060dab23c33e2dc5e8 8620 tikzit_2.1.1-1.debian.tar.xz 2ac2599ba314632978237a149e8d629ccfd39771 9780 tikzit_2.1.1-1_source.buildinfo Checksums-Sha256: 81fce8c47c5380866332ad2748cab453a4be1634a8f12c707a06e8c25475d222 1862 tikzit_2.1.1-1.dsc 01db33efcdc3fcee01aaac9a15a6d51c9dccb41da091eb0e2df351ef16d0d6c6 452388 tikzit_2.1.1.orig.tar.gz 627ca26256eaa26a09f2cbd142bc67b178d2fc331ef5a7d478239d7cc2d21dda 8620 tikzit_2.1.1-1.debian.tar.xz 4dbbe8ccd37b4c40c5790a5b13b452b04f27466398a1752eae33f876606c41da 9780 tikzit_2.1.1-1_source.buildinfo Files: 144bf28dadf9118fcc3222ab7117775c 1862 tex optional tikzit_2.1.1-1.dsc d388431289d09d47f4f9a1afdb1e8238 452388 tex optional tikzit_2.1.1.orig.tar.gz 69f3bb7f4c3bcbcc1a1d89c7eb342cdd 8620 tex optional tikzit_2.1.1-1.debian.tar.xz 6cfb2af723bfc1c4d6625748d97c5939 9780 tex optional tikzit_2.1.1-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAlw5mugACgkQnRFYKv1U jPpFEhAAprwVSOMEyPLbFJ4QN+zfyS9tclp1nU1+j+SVFISNUQmFFmHoMrxsuxz7 pD0PYER6i/XXjkv6OhPScb2Zo99896q0IErESlPI4i6bobJF2znipZOfrMfUpHbo HLOyoE7YxaGkLSQEsM7EN6JReRa8u06lvUiKfj3sCCDvxuopn1yAsjnXIgCLnMEF cdOWiqWafv8fOP3K8Tu6eEPvh0ivnpv0+vok2dYhmrSEUDrH/u+s8ip6Cr3WbvIk OCUJY+DfO0H/Tox3pm1vvo4Deue0YBRKUt7T3v2aQepBVlzvRvEUmHt2rNGpc8pB ZhQBF1U/Jez2ywaVw6bJbRDo6H3B1sl4vdtYEfix2cbDbPY7YT03NSehRfwJdKj1 v2+XamI2GIeT3zyc/W60apqPqr9w/ULtORLxPddSluRR7lbfgpCQWfQqyfDrjF/g gj2NONaoojn07ZWbs2AilnmF0kNP2rCtha9avne0LHbEJh432czpvVyOJ/MazbAu pH98Mz6Tx7N+ccJXROCc1FSwHz+q4GYdfArWnHD8usk4v27+SR/TbEoY9HdJ7Ys/ ga01QPV662dLYyL7FENx/GuSXIdCQqk3+KMCEu8Rgf6mHV4NV5B7KdrOcsKU/jW1 hUfF6ZmWwTma5S4ncNDn3rAjlekbIgZqR1iml688MrJnUi7hEUc= =PyEl -END PGP SIGNATURE-
Accepted tikzit 2.1+git20190109.97c2a2-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 09 Jan 2019 08:39:30 +0100 Source: tikzit Binary: tikzit Architecture: source Version: 2.1+git20190109.97c2a2-1 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Description: tikzit - visual PGF/TikZ graph editor Changes: tikzit (2.1+git20190109.97c2a2-1) unstable; urgency=medium . * New upstream version. - Preview of compiled PDF. - Export diagrams as images or PDFs. - Miscellaneous minor features. * Debhelper 12. * Standards-version 4.3.0.1. No changes needed. * Advance one upstream commit from release for correct version number. Checksums-Sha1: d7cb54eb0d2efc953a956dea3dd99bc49f13cdb9 1981 tikzit_2.1+git20190109.97c2a2-1.dsc 8aabace8d66928ab13db8c14880526e79f9e8f95 450654 tikzit_2.1+git20190109.97c2a2.orig.tar.gz 9c056778e89137fa189a91685a8692bd95ba39c5 8596 tikzit_2.1+git20190109.97c2a2-1.debian.tar.xz 30b7bb3f9510b1716c8fa632bfafc308ca462323 9832 tikzit_2.1+git20190109.97c2a2-1_source.buildinfo Checksums-Sha256: 5dfad27e021afe06b63c75b92abb688955e034343bf883f26a84a3729ee3844f 1981 tikzit_2.1+git20190109.97c2a2-1.dsc ff8e9d3eea45bad08556bb8632768d4ab199877205ec89fa06445c9d20c94460 450654 tikzit_2.1+git20190109.97c2a2.orig.tar.gz 8e13cddc55fb6a3aa53f590a05cc5c70717834565db13bdcc1257406340d039f 8596 tikzit_2.1+git20190109.97c2a2-1.debian.tar.xz 379b6172b391c7d7d2c45307138c4fc5790f88fc2eb564c6db3d352db8de752b 9832 tikzit_2.1+git20190109.97c2a2-1_source.buildinfo Files: 8347432c7d2f5b2fcc87a7295fdca27e 1981 tex optional tikzit_2.1+git20190109.97c2a2-1.dsc 629434620b90cea9afcb43fc77636f23 450654 tex optional tikzit_2.1+git20190109.97c2a2.orig.tar.gz f7e3a7953f3988b75c97e1ac5bd377a1 8596 tex optional tikzit_2.1+git20190109.97c2a2-1.debian.tar.xz a555023dc9405af109e3f06fb3ed7a67 9832 tex optional tikzit_2.1+git20190109.97c2a2-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAlw1p0wACgkQnRFYKv1U jPocGg/+PoKonE7Au5bxKL+uokuYphFiiJKpaH7/FtIwuSWBRJ4BIUy3VsUmhXgf PhkweQpHSmCNPDm25IbxXAuHYC1N4TMs61plFbXXmn6Z85bqGbN/PC9OGxT+RNus YhRY5rSynEfa8NE/RFpSZBLMqH0TUC9oB8DZnSGvzRIZfWX0IidxdJO7KL2xLv+h Z1sRaPp2uLr9DLkd/FSvbMlz6dfsj8dduorHd5pZC2cxn4YCV9SY4ybJF3iEyTSE fJ+SFzL3FpMYBEh+zk0VfqZCrKgGIpYq+S1fWIh78LxOvI0WTRYPs+ehBM32tok2 rGxrnkFv95nWUKKaZT2udTCYgXzTUfyR08QfkeRaR9blXFR5W2o1iJTk39cdc1Eu P3yXOoe4Y42N8IgbYj/uoq8Y9V82cxLB9zAu5IxeYYD9nutFEgdZ8VP9z5ErsIwO Apy9wgyp8TCxVO2mvH9ygoxq5QIeE9/ZvwhWoJ2Ko3NTp5JytovUqezQrEex0v8M QIkH+lt4FDw2Q+97BciTEJMMiq6csutp19DaKx+Y4JvLP0eu6mXP+W0P/nbDd8BZ ktfl4mUFyx0Jepr/KY+Jb77G08hmiCgpR9I1y7lcbqI6r3K4eUH2Rn6EZAWG2X4z gpPue0o55c3QijRVN1AxpDFKXFBYj207mPZenBKCR+erVH+Z5Ww= =NAYC -END PGP SIGNATURE-
Accepted tikzit 2.0+git20181101.87b50b-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 01 Nov 2018 12:01:25 +0100 Source: tikzit Binary: tikzit Architecture: source Version: 2.0+git20181101.87b50b-1 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Description: tikzit - visual PGF/TikZ graph editor Changes: tikzit (2.0+git20181101.87b50b-1) unstable; urgency=medium . * Advance a few very minor commits upstream: - Man page upstreamed. - Categories added to .desktop file. Checksums-Sha1: 41df369438f602a262bf0a2d2858eeb424f0f2f9 1943 tikzit_2.0+git20181101.87b50b-1.dsc df46697e85d869ff8f327dc7a2c242b8913beea7 432186 tikzit_2.0+git20181101.87b50b.orig.tar.gz 4122580d4698a721f84aa9b9dce8b9e5e9aa6a0f 2524 tikzit_2.0+git20181101.87b50b-1.debian.tar.xz cfef7122fcbbd8d6cc7c077832c95b7be3e8eafb 9884 tikzit_2.0+git20181101.87b50b-1_source.buildinfo Checksums-Sha256: 008e813ac2c8aab63fcd1f245ff1817fca2afee675622412f6ab1e476c08a373 1943 tikzit_2.0+git20181101.87b50b-1.dsc 336c0469d33f6d9cec3a5b23105856e87484004e7182256ad83847790f0a2bab 432186 tikzit_2.0+git20181101.87b50b.orig.tar.gz 5602294ac72c9e568c74228e14e5c091feed016aacac793c6710802a261de3bc 2524 tikzit_2.0+git20181101.87b50b-1.debian.tar.xz 1a10b801420d1fa57d31020c6afa592e269042bc9a6ca8c0ddad97460b7d6500 9884 tikzit_2.0+git20181101.87b50b-1_source.buildinfo Files: eccbdca4273a6f747256e0c87e330276 1943 tex optional tikzit_2.0+git20181101.87b50b-1.dsc 3e889d12f6ab64c044f3d0505309560a 432186 tex optional tikzit_2.0+git20181101.87b50b.orig.tar.gz d878736459d4dd7d07a3c767689b9a87 2524 tex optional tikzit_2.0+git20181101.87b50b-1.debian.tar.xz 5d7c8bc7caf9e45c82e9df83982390f0 9884 tex optional tikzit_2.0+git20181101.87b50b-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAlva3XcACgkQnRFYKv1U jPrSdxAAmqjQMPcFx7BU8Y6V1y2iT6C/aFuUMSkHkPWrFJBL7+DFM9JDB3tiRbhT GogKwG5nzWCDEU5vYJy7i/uUzT7KQE6sE4HDuVmTEBofqqlqMKOlbErakUuSHfx7 Mv5qgAeSFKYKUuhsh481lKH7tNXnZj/gZOVgIu/dIAlrQR1lfkDJNrxoxtgR7t8Q 9fKwoBU1MNf+uejCeX0sLR+qWHg/yjcMk+g8Kl3WLWpZA0kq99T4RE2ypG9X/GzC tPrcxp0S7nXR6q32KRUqJunc+asfrH5A9D48waLlVxO9URESMZ2+Jt4EPZm9wuzT trtLwTbMhw6I+lkKmzpROIozM8NMh9zS8DZl9nvUyjddoImhQEy+ikBDoOOO2F3O x+5pZrFAE7faKW1TQQI/BG6E3qvVbX5Xo3Vq9pKwla3quOgpJCSIUCCAnTJfRFmd NU2pqnlcPG4oe2sl5uFi4pKNEctgbG3MQnIQOQE3eJ611gg1Nk42NnAL6z/icRR+ bYlvuQK7VwaY6gVfqLRg8HNkJ33LEHqaL7it4IqaDf+KZbWL4RjiV1QKc+4OtpCC HlWVPXJoecsTG6YGPTAUGQJAdGbD6Kxk1+RKLEEptxZLHuN7SQcWJuu8zp25VZnB aDmb2xG8S/M+x2/uqmm1U6QbKg31ZqLsDZIqTY1u4LCY3rcwRN4= =Y/R3 -END PGP SIGNATURE-
Accepted gudhi 2.3.0+dfsg-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 05 Oct 2018 17:05:03 +0200 Source: gudhi Binary: libgudhi-dev libgudhi-examples libgudhi-doc python3-gudhi gudhui gudhi-utils Architecture: source Version: 2.3.0+dfsg-2 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Description: gudhi-utils - Utilities from the GUDHI library gudhui - GUI for some of the functionality of the GUDHI library libgudhi-dev - Generic open source C++ library for topological data analysis libgudhi-doc - Documentation for the GUDHI library libgudhi-examples - Example programs for the GUDHI library python3-gudhi - Python 3 interface to the GUDHI library Changes: gudhi (2.3.0+dfsg-2) unstable; urgency=medium . * Disable parallel building on certain architectures to avoid buildds running out of memory. * New patch to properly propagate CXXFLAGS when building the Python modules. Checksums-Sha1: 8b04e6dc446a865da093006fdf01841e68feeb96 2600 gudhi_2.3.0+dfsg-2.dsc 22f314eeefb727f8b3633ec9a0ba5163d43758e5 9320 gudhi_2.3.0+dfsg-2.debian.tar.xz a92e5176a9bd6ffa81ebc7d0a272fb88570b0f87 7986 gudhi_2.3.0+dfsg-2_source.buildinfo Checksums-Sha256: 246df30879f01b679f5c5e04e62ba25a2e7916035d43b74c0a3001258809b7c0 2600 gudhi_2.3.0+dfsg-2.dsc 7eec9fe93a6db1b81b9d2c2a7c66232adff02f877eb4c8b37ed3fae75eece63e 9320 gudhi_2.3.0+dfsg-2.debian.tar.xz dc3859d620021edb2a4e0c01a85f5f70094e94bc4f04bd11d8b73a5f58732663 7986 gudhi_2.3.0+dfsg-2_source.buildinfo Files: 6474d852d5c8af0d333cd29350ed1071 2600 math optional gudhi_2.3.0+dfsg-2.dsc 268d6d90693d742241561b5e7e69da8f 9320 math optional gudhi_2.3.0+dfsg-2.debian.tar.xz 38f97d691d64ea6079fc9ea4c12501b3 7986 math optional gudhi_2.3.0+dfsg-2_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE/d0M/zhkJ3YwohhskWT6HRe9XTYFAlvPeLsACgkQkWT6HRe9 XTZaDBAAh/kr1TdxrRpSHQicjVeZeNCRKIJTyWhwyh4qQZ64YhrL+yjHUUrajwlc capJ3O9db73IIRE4F+L6PKOk6ExE5bXBRu2KOh4/Xq7Ijfi/kH+grm8qmKMC+l0e OLQHxmeKER13X7zzJpw8OSsjNY9OAVYC09kHvohHfmMS73yN4Lz0ZZzsqC38AhPB M/71jnjf/0oiu2bugxnS54paJMPesqBc2G6jtGslNBvrZzdQySP0h5PFnLBMKHn/ E1fq/Stw9NZf3N3iuouLRfhHRS2nOVf+i9DRorYcbFeZ9GP6j6HaCQib40kE50v+ FPIVKasV9VwkeSQ8ndaL11qJqKFbchy3VRxDMv4UpY6QNwYsni+Ngq4EtYodAW1W N1aVNT4iiOMn6u1AQ+//5xrNzSV/5ChbIl4LiQ8pXzFLOp/5ke4QZ6+Qt+63Bdjv SYJkTBdcBFjo4ouz3tpWBoi4TWqo0mRXnEVTDt94c8Tao5bszm0rguwcbRqDsPmW dcd3k4B6y7T6pfPPKfkxaBMAlvqEtmtFNMO4C3KJljqLJe9yqSjZv6pkd8suLNRK J05uTRWuMuJJ/Hf4CCrkSYhiE+9q/6i9afIlotT8kf0uiLc1ZRDJQiWxp9IDW/5i TGwyhUiZN6Djc0gaEY+6q+WTVugl+y1inMXS8XpuiF+MHEW5g70= =k3iT -END PGP SIGNATURE-
Accepted tikzit 2.0-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 23 Oct 2018 17:51:00 +0200 Source: tikzit Binary: tikzit Architecture: source Version: 2.0-1 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Description: tikzit - visual PGF/TikZ graph editor Changes: tikzit (2.0-1) unstable; urgency=medium . * Completely rewritten upstream version. - The GUI toolkit has changed to Qt. - No DFSG-removed files in the source tree anymore. - All Debian patches dropped. * VCS on salsa. * New project homepage. * Debhelper 11. * Bump standards-version to 4.2.1. No changes needed. * Introduce watch file. * Don't recommend preview-latex-style, as there currently is no PDF preview functionality anyway (slated for 2.1). * Add a man page. Checksums-Sha1: 0a3151b7560934f7d8bfd9b422adc84ff0f4aa0b 1575 tikzit_2.0-1.dsc 7507aa7b1bc2e217ebffc1d0685a7eae56181667 431803 tikzit_2.0.orig.tar.gz 1f1d0f1932987bf532c3278c8938708012c0ced2 2672 tikzit_2.0-1.debian.tar.xz Checksums-Sha256: 7d614b627376052c0f9bf20996e1f826cfd134f6afecb2ec439598ce0338989d 1575 tikzit_2.0-1.dsc d1a84531b8ac2298c140217267423cd9ce4d84ee443b5deb4aa47e4beab4f295 431803 tikzit_2.0.orig.tar.gz 48668ae15ac18d3fc6f535f0437bf4dac40a96819cd08b3d31992e7133981287 2672 tikzit_2.0-1.debian.tar.xz Files: 6bcc5632f4abf8068251bc88113004fd 1575 tex optional tikzit_2.0-1.dsc 383fbb6f0d3b52bb18fd22cd8a88ad4b 431803 tex optional tikzit_2.0.orig.tar.gz 3172ec2f1700f4a68b11e253ccdbdb44 2672 tex optional tikzit_2.0-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAlvPU7wACgkQXkCM2RzY OdL+XQgAnfukR/2T6aKjRUihrCbwuj/8vu9MCpjwnRfeXYt1+u73adgkGvnE5nwR 5qrsJpRTbwy5j46W7BtQXu23J4TIydwEoYLlwFKK1EMV6mO6balGpoGbuD+zsE1H ajcixwJydrQ49uRJw/WcCZXkdTfwrQkA9KgAfanHUPuwp7dlvGHJQxAzjRqb3KRP zQ7P2RMeNP7/OJwlDM5t8erSgwHOqS/Ad/LWhJEPHtzlVwaWGKP92/CFxcVhYL5E h1O9toFuaXbbKmF8ajh1m97+Uba1vtH0sEd/IpODrmx3to7+RU8WNlf1TTthMCgp 9qF/8YzbAsvHqZo5tl95rgWOrM4kdQ== =Ss// -END PGP SIGNATURE-
Accepted tikzit 1.0+ds-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 08 Jan 2018 14:05:45 +0100 Source: tikzit Binary: tikzit Architecture: source Version: 1.0+ds-3 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Description: tikzit - visual PGF/TikZ graph editor Closes: 883544 Changes: tikzit (1.0+ds-3) unstable; urgency=medium . * Build-depend on libgnustep-base-dev instead of libgnustep-gui-dev (Closes: #883544). * Correct libgnustep-base-dev dependency version per upstream. * Bump standards-version to 4.1.3. No changes needed. Checksums-Sha1: 98577345f278fd06d059ce950337321e47ebae67 1702 tikzit_1.0+ds-3.dsc 86ef9ba94f4caca442e3f0d805ed7805f8de298d 5324 tikzit_1.0+ds-3.debian.tar.xz Checksums-Sha256: 7370669b7d7093e07a2db7fbd17364b584e8f81a46840c5c0a2e94f6db448e1e 1702 tikzit_1.0+ds-3.dsc f3bcf2155235f2d7f9e4e57f97c62ecbc9266154bff7d1d7204b3569bab67c49 5324 tikzit_1.0+ds-3.debian.tar.xz Files: 4d78fe1595194a75d7da9e581c4fa862 1702 tex optional tikzit_1.0+ds-3.dsc 5aa454fc24840fa426b85eb5399c7261 5324 tex optional tikzit_1.0+ds-3.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAlvF2dcACgkQXkCM2RzY OdIHVAf9HIAZCTvYtXl8YTwTuReWT7nVfsf1AoxZxoMbhCMgG03jSvNMPMkl4k9A FvhXbHj46ye5pT1p1+Uc1xjHV1YIigb/fIT1U3+FzcBBjp1Ff1z7eP1g57kzpJS+ 3GtP/ECSsLiE1wrF4KAbF/WrMDL9WNmX7JEhVE+aYHdysi2+ry5kBbE3/jKAmBby DlLOI2ZKNn4wKM6ZeTyvxdJak/HxMChBNC3bYma2hMdEBVBTjxi92NY9NHp88JPz A387EWMe99E4gB0PSHfTdC04M42MVk9zqc6cT0FhpDbhuXInEehgqj8wNW2ELFiO jEzVBez+8tYcMyNOiXYKY0HlAHiHUQ== =Xzns -END PGP SIGNATURE-
Accepted gudhi 2.3.0+dfsg-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 11 Sep 2018 16:10:44 +0200 Source: gudhi Binary: libgudhi-dev libgudhi-examples libgudhi-doc python3-gudhi gudhui gudhi-utils Architecture: source Version: 2.3.0+dfsg-1 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Description: gudhi-utils - Utilities from the GUDHI library gudhui - GUI for some of the functionality of the GUDHI library libgudhi-dev - Generic open source C++ library for topological data analysis libgudhi-doc - Documentation for the GUDHI library libgudhi-examples - Example programs for the GUDHI library python3-gudhi - Python 3 interface to the GUDHI library Changes: gudhi (2.3.0+dfsg-1) unstable; urgency=medium . * New upstream release: - Python interface for GIC. * Refresh patches: - Expand patch to disable new tests that rely on DFSG-deleted data. * Standards-version 4.2.1. No changes needed. Checksums-Sha1: 8417cfe133834c87815716330797c486a95cae40 2600 gudhi_2.3.0+dfsg-1.dsc 25d3773a117728e0141a5c044a80b8310a913a95 5492859 gudhi_2.3.0+dfsg.orig.tar.gz 37d4d423966a1657c3839c625c38e871171a5a0c 8860 gudhi_2.3.0+dfsg-1.debian.tar.xz 6e999d48f20eab183ad64e32945750a9393143bd 8042 gudhi_2.3.0+dfsg-1_source.buildinfo Checksums-Sha256: 6fb711f72420dd236b2153be15a5cc29d1435e4220f992b5c9e92563421711aa 2600 gudhi_2.3.0+dfsg-1.dsc 7400042238a2aa22e7948cd50ccc75ec1b0a76a1d1fad145769a2fb1fde6a970 5492859 gudhi_2.3.0+dfsg.orig.tar.gz f2dee9733cc1b043ab51c8623e8223a233d6914b21646bee178ea1feb5384d5c 8860 gudhi_2.3.0+dfsg-1.debian.tar.xz 50b7ba5239b828f9d99217d849b231e4856c46235ac93f82180a39b47413e569 8042 gudhi_2.3.0+dfsg-1_source.buildinfo Files: 0ba371f59fbc305dd1b635f0127a4f08 2600 math optional gudhi_2.3.0+dfsg-1.dsc 3dbc3b4b7ff334914473f63a0276b0fa 5492859 math optional gudhi_2.3.0+dfsg.orig.tar.gz 616d04543f8e38f3794f4d670ed2ff13 8860 math optional gudhi_2.3.0+dfsg-1.debian.tar.xz 85b7de68aaf9c2b5b26a510744af92ee 8042 math optional gudhi_2.3.0+dfsg-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE/d0M/zhkJ3YwohhskWT6HRe9XTYFAluefzoACgkQkWT6HRe9 XTZkGxAAqNZ4bxhetbtASqrXwn13PgLVLXFTyMP52FZwoOtEIV1byKvYjKxM2RoT o7KVB75QT2jeRmrsrX6hllL5Y0MNqVZ4m2u4ABruLl2cYVXBtJpmNIgHqlAfYJOO qpQ1v35ZtCBlaWcC5oP0W6Owt6WdqNRhcB71pnItYVafaH00+5DtpcLfR5pAXG6F CWDo+Bv2yvNHE93iq3CDQTusAt/EFxTCuXh2T16rONnHxC4Rm7PKef6J8NO7qQLP wdjYBEy0BnghKbZFpIID/65Wk20GRx0XpIeTgxIDYACA0s4PEIq72qVm1g8SS2hh ZwcZssZX2Diz+BnTY1y1s6WaH6pWVUEGEdwDVp0xSw0MajZyPlpAAyY4Z7y9nCXf tmHGoNMrO+GvlYd/fgjrVHNDVnbvQbCieCl4erfvphQMd1kpum2YkW4YyX6YlajG wK4YkSQH1cUz+iktMsdVpzwV/GvNDcENQ7e5jVXzzo0vaGijGWiDOZe/EIHGPPx2 bKCidoe4xLfBA0MM5ye9RGCoy3Y8fykWXEb+40se7RyNkIb5wUv2X2ZrEuok0m/7 yyv5yUQ8ZFWzWil7PJQ4EVZzlTeQGdwKOujdsjZB4TvHgCGoGnmNeInGRleMcj4M xJlU0Upv0P//W5YLH7+hCaTQs5zzJG5xn7vnLeJgzNN6mglAIhk= =vUt8 -END PGP SIGNATURE-
Accepted gudhi 2.2.0+dfsg-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 14 Aug 2018 13:45:43 +0200 Source: gudhi Binary: libgudhi-dev libgudhi-examples libgudhi-doc python3-gudhi gudhui gudhi-utils Architecture: source Version: 2.2.0+dfsg-3 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Description: gudhi-utils - Utilities from the GUDHI library gudhui - GUI for some of the functionality of the GUDHI library libgudhi-dev - Generic open source C++ library for topological data analysis libgudhi-doc - Documentation for the GUDHI library libgudhi-examples - Example programs for the GUDHI library python3-gudhi - Python 3 interface to the GUDHI library Changes: gudhi (2.2.0+dfsg-3) unstable; urgency=medium . * Fix build of bindings for multiple Python versions when building just binary-arch. * Test all supported Python (3) versions. Checksums-Sha1: 8f5afe14a3a743bbb17cb9987f84aa5b1c4cc9e1 2600 gudhi_2.2.0+dfsg-3.dsc 94281bfd1eb3c39d37627e09c05149e2f1618242 8860 gudhi_2.2.0+dfsg-3.debian.tar.xz 6d2eabc2c3dac235a0f1b01e9e5540710883edd0 8252 gudhi_2.2.0+dfsg-3_source.buildinfo Checksums-Sha256: e8729a3cefa10ed9fceff0d1eaad7194aceac33e69d178e22ad8760a2a20968a 2600 gudhi_2.2.0+dfsg-3.dsc dd1b49eef31b33e7ef52d11b5fb2b9164b7eb70ec46518c54c3737deca7d7dcc 8860 gudhi_2.2.0+dfsg-3.debian.tar.xz 3aa8453d7fdc7dbc7ac8de0a09a246d32f37060487772e56a61432bf107c640f 8252 gudhi_2.2.0+dfsg-3_source.buildinfo Files: ff858c619472c5d72e35f9befe04e92a 2600 math optional gudhi_2.2.0+dfsg-3.dsc 7a9b429c37d53e55163caeb67159cf58 8860 math optional gudhi_2.2.0+dfsg-3.debian.tar.xz e730cfe131ec19399a933bcf66b66f08 8252 math optional gudhi_2.2.0+dfsg-3_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE/d0M/zhkJ3YwohhskWT6HRe9XTYFAlt2wkYACgkQkWT6HRe9 XTbJ2RAAn+g3eC4bjKBSaZnRkuA/5H0Do3dBcXC0rOWmI53mWqK4zQSLS74WyWg5 XeZy/9m6LPQEc/PtzjlJ9HXd+NPjsQd3k19ZUac5h4WGyoA3tdnPvbPfOWF58SpD obvo4M04W4D7RuhFqW74N4Q/i3nG0A+IoLubeY6KZoHa6xnqw7gTjOkWilZ9yFtC TMNWFMPv0bxFGMTo0NwfO4y16xFRj1rDQagz2i/LWBkYETAysQUi7YcOqhc2/5dQ Ldqt3E5dYthoAC4voFHiflT1o1FmQ0mFVTJ0kQZfeYWPAilL3ty4DpucMGAKDeCI qQvCFSCLHrYEN/7IN4GRpHddIB2ejTA2Vl1rFeBAm5rleqAq0GN0bbTXV+7twwEL dS8PCaIs0oyK5Xjr7DqzjeykXjwVoeLb3izo7hnK+PbbhweL7VuEdMawZuNtVLD9 z2ZgdirTkMqDKYdNWhRCZA5oUInmrmNBZ+LFaZ9Ak4Pn5xuTUgTmMsAhkhlcXQPf g1nCaquy6FR4x6Pm/Ce57Olj/83B+hkTBBFIiLxKXKuOsvdiSbSvyggk64gQZMsy CXXc8qfuXGWHKotsazB8ZSI36gFgeU2W0Hi4f8m59GZa8Z6sBBsow/nliI+w5OGh W3xRBh9Fs1oM3WLv4ItAMCkGjlI4PvYwgT9DWXlyD5VVoABxeCw= =WddR -END PGP SIGNATURE-
Accepted gudhi 2.2.0+dfsg-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 07 Aug 2018 13:47:38 +0200 Source: gudhi Binary: libgudhi-dev libgudhi-examples libgudhi-doc python3-gudhi gudhui gudhi-utils Architecture: source Version: 2.2.0+dfsg-2 Distribution: unstable Urgency: medium Maintainer: Gard Spreemann Changed-By: Gard Spreemann Description: gudhi-utils - Utilities from the GUDHI library gudhui - GUI for some of the functionality of the GUDHI library libgudhi-dev - Generic open source C++ library for topological data analysis libgudhi-doc - Documentation for the GUDHI library libgudhi-examples - Example programs for the GUDHI library python3-gudhi - Python 3 interface to the GUDHI library Changes: gudhi (2.2.0+dfsg-2) unstable; urgency=medium . * Build Python bindings for all supported Python (3) versions. * Drop patch forcing Python 3 detection. Upstream has cmake option for selecting Python version. * Standards-version 4.2.0. No changes needed. Checksums-Sha1: d2aa31cb533d1d634799ac89f2a26587ff18213a 2587 gudhi_2.2.0+dfsg-2.dsc f5df1fbec1ed88d8ba43027412b0f98e14c34095 8704 gudhi_2.2.0+dfsg-2.debian.tar.xz 99863e0b0f9427ec5688f2b40be55a8a305c0c5e 8246 gudhi_2.2.0+dfsg-2_source.buildinfo Checksums-Sha256: ad311292ccb0fff94bfd8abc84d3f4277f390c76cdb0483fdb1912b2ccfab765 2587 gudhi_2.2.0+dfsg-2.dsc 7f6e66c7111a2689af4d7214fcfb5eafa21a7e71a26b1d26c9823f306555e1a9 8704 gudhi_2.2.0+dfsg-2.debian.tar.xz d6342fbdc0986725a68495bf9f89b3c279d11603e92e89514c035beba29adc52 8246 gudhi_2.2.0+dfsg-2_source.buildinfo Files: 375972474848d939f12f5601d6d4f4cd 2587 math optional gudhi_2.2.0+dfsg-2.dsc 18b85b8d15a9a467200fe7802b985924 8704 math optional gudhi_2.2.0+dfsg-2.debian.tar.xz 7e223d046f4ab6ed7d13975d95869dbf 8246 math optional gudhi_2.2.0+dfsg-2_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE/d0M/zhkJ3YwohhskWT6HRe9XTYFAltt8y0ACgkQkWT6HRe9 XTZzPBAApUMx7YffJj8Lu/jwVkQuhyypa/D8jPP9v0+dRlvSQVq5t3DTOud64Cj1 Tpy+bV5YD3ZyfoTLFMS65N+rf9IfSpXC9LRfZmrKdeqyalqCdGB/xsBm027LIkIH EnejQw5iBW6UdXo62ZTooEcQ2Xi9CYDYMIi9QLKuhRvZl2HRZQuGWx5ulvHS03FP mEU/7bI8l2UdBVUsUOkBL37NMo1w5RKMQ6SqQ2vo3asL4Zi15aK4eREBfukU66X+ /3KKLMGXpjgEgLoJYi5naAgOa7BQqtD92C5+bAnE/1y9Gq6VQOt+6RhfO1pfZ+ai gqpGaBORYvdwj7s3qtVZhJWE/4RZRQ0W12U/WxSiRtMc0Q/j5PKPQM6CyLoWYPCc HSU3wUT0yt44TQubFqqXlhHnFfPUP2zDXE5wm1NVNAuRdlH2EV7blwmfuHXghmYs /KzijD9icXBvS5Ye1zvKt3uAWaWnQ9lqIpK9dgpdgXaCD8zBaEXrgdsZoWqxbz+P oLgR738DwkT3JVITRmueBTBEWIRowez2C+sTruUThwHX4Sryfv8zjzZDuYlgYbjN 9cb2JR534yN4peupTOvuHI06mIYXELxj+M/6vp83sOGn+mdyGejnsztYgxUD6JiX e1GU2mmriz2Dfx3KiMasoYhharK5u8Wk1fqcZlr13w3IeCZhq+0= =1kNv -END PGP SIGNATURE-
