Bug#955468: ITP: ruby-rspec-temp-dir -- create temporary directory for each example automatically
Package: wnpp Severity: wishlist Owner: Anthony Fok -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: ruby-rspec-temp-dir Version : 1.1.0 Upstream Author : GO Sueyoshi * URL : https://github.com/sue445/rspec-temp_dir * License : Expat Programming Lang: Ruby Description : create temporary directory for each example automatically Rspec::TempDir creates temporary directory for each example automatically. . This is inspired by JUnit TemporaryFolder. More information: ruby-rspec-temp-dir is required by ruby-hrx (to be packaged), which in turn is required by sass-spec 3.6.3-1 (to be upgraded). ruby-rspec-temp-dir is to be team-maintained with Debian Ruby Extras Maintainers -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEFCQhsZrUqVmW+VBy6iUAtBLFms8FAl6EPSUACgkQ6iUAtBLF ms/HjQ//c7Evp/IVCIHdcm6fwjSvKVtbSTh3iUrB+yCNc8I8M6lSlebURiwMJWZa HndjLZiiuTjCsxDBFI//vG2aTWPsFGlQAILr9OXKB/IRWd/PNB2quXz3TxxW6yel fIwRAX+uTvt3lsPBuRWLGYj4oIL+22R38t0FYekFlzZhchOsU7QG4KNXQpRJTdI5 aA1oiT8sdJYeE0zeVV0kiuIIVMwVioFSu6pDaeYIeVn40joBrKookmKBeGSCWJVM +HbPuv8RoIrMfErFRObBXp15D6KQHkTrEl4M8VwgxrKnCIG31oLnvAwI8VuG+Get 0IFwBgFWyVWD2XJ667e9L2N+uJsdVxSERlXOA8joNtjpPFO4rq8NIeW75xsd8FP/ z60upWuZne8cngYYOqdFh1mFQgZ0Puem+GPu8N7CU+QtiaEORCulDoz1mn/+o1j9 rGlvEqxRGQ7fTrsAOR/sYKA21BCfR4SmhuVeuK/e+DAV/QtGi8poGUpzz6SAMiGf rMakgqC9vl++MGFzacPttWtG3MD76+RDHgaxHOFWvJJ6Pvp+gX2q+EtZYibeX1k3 GiI07IlSdMbEutyXQBGU0QJxrHFeRRMi7i/20fGh4aaWrZwg/6LV01eAUZgGM7gl WKnuFdy4fcAlF24i0ImGAmGakYRiF1NRvoUF6V6Z2qSiK3PSvF4= =/6Cy -END PGP SIGNATURE-
Nowy laptop w cenie szkolenia
Dzień dobry, Prowadzimy rekrutację na dotowane zajęcia prowadzone w formie telekonferencji, podczas której wszyscy będziemy mogli się widzieć, słyszeć i wspólnie pracować w czasie rzeczywistym. Każdy Uczestnik, który nie posiada sprzętu do komunikacji online może otrzymać nowy, zaopatrzony w niezbędne oprogramowanie laptop. Laptop ten pozostaje na własność Uczestnika do dalszego wykorzystania. Technologia typu Streaming umożliwia przesyłanie fonii, wizji, tekstu czy udostępniania całych aplikacji i pulpitu na żywo, dzięki czemu uczestnik otrzymuje pełnowartościowy trening nie wstając zza swojego biurka. Technologia, z której korzystamy nie wymaga instalowania czegokolwiek na komputerach Uczestników. Wystarczy laptop (który możesz dostać od nas), dostęp do Internetu i miejsce, gdzie będzie można się skupić. Korzystamy wyłącznie z doświadczonych trenerów, praktyków i ekspertów w swoich dziedzinach. Jeżeli temat wydaje się ciekawy, to proszę odpowiedzieć na tego maila wpisując w treści akceptację - wtedy przekażę więcej konkretnych informacji. z poważaniem, Kamil Muszyński Aby nie otrzymywać podobnych zapytań proszę o informację zwrotną. Usunę kontakt do Państwa z bazy. -- Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast. https://www.avast.com/antivirus
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
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
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.
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
Hi, The upstream author responded quickly: https://github.com/pymumu/smartdns/issues/452#issuecomment-606079773 (in Chinese) The center pictures is actually the user avatars. The avatar in alipay_donate.jpg comes from Nentendo game. The avatar in wechat_donate.jpg is a photo taken by the upstream author. On the other hand, I've suggested the author to remove the Nentendo game avatar: https://github.com/pymumu/smartdns/issues/452#issuecomment-607121122 (in Chinese) On Mon, Mar 30, 2020 at 03:01:36PM +, Mo Zhou wrote: > Hi Johannes, > > I opened an issue at upstream: > https://github.com/pymumu/smartdns/issues/452 > (Note, written in Chinese) > > Let's wait to see the answer. > > On Mon, Mar 30, 2020 at 10:49:34AM +0200, Johannes Schauer wrote: > > Hi, > > > > Quoting Paul Wise (2020-03-30 10:20:08) > > > On Mon, Mar 30, 2020 at 7:53 AM Shengjing Zhu wrote: > > > > 1. There's no info loss if you convert from one to another. > > > You definitely lose the (presumably non-free) television/game characters > > > when > > > converting from the original QR codes to plain text. > > > > I think this point is important: are these pictures in the center DFSG free > > or > > not? > > > > lumin, could you answer that question? > > > > Thanks! > > > > cheers, josch
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
On Tue, 31 Mar 2020 at 22:22:21 -0400, Jeremy Bicha wrote: > I think this goes back to the epic "Editorial amendments" GR which, > among other things, applied DFSG beyond code to other things like > image files [1]. Over 15 years later, it's still really hard to figure > out how to apply the aspirational guideline to things that are not > code. The burden of compliance with various interpretations is very > inconsistently imposed on Debian contributors. Note that "preferred form for modification" does not appear anywhere in the DFSG. It's a term borrowed from the GPL, which we sometimes use to try to reason about what "must include source code" really means. I think it might be a more helpful framing, particularly for non-code, to think of the DFSG in terms of *a* preferred form for modification, rather than *the* preferred form for modification. Crucially, unlike licenses like the GPL, the DFSG is a set of self-imposed rules that the Debian project applies to itself, not a condition of license compliance - so it can mean whatever there is project consensus that it means, and we are under no obligation to interpret it pessimistically out of fear that a judge in a copyright lawsuit would do the same. The reason we are distributing source code (in cases where the copyright license does not require us to do so) is to be able to read, understand and modify the software we ship. For executable program code, it's obvious what that means. For non-code files, it's a lot less obvious, but it's perhaps best understood by asking "does this help us to meet our goals?" rather than "does this follow an objective rule?". > I believe that the overwhelmingly majority of people who would want to > update or change a QR code image would create a whole new image from > scratch with one of many QR code generators (some are open source; > some aren't) instead of trying to use an app like the GNU Image > Manipulation Program (or some specialized decoder/recoder app) to try > to tweak the file. If you know out-of-band what string (URL etc.) the QR code encodes, or if you don't care what the string is because the change you are making is exactly that you are replacing that string, then yes, clearly you'd re-encode it from scratch rather than decoding. However, a QR code losslessly and machine-recoverably encodes the string that was used to create it - isn't that the entire point of QR codes? - so if all you have is the QR code, I think that is an *equally* valid form for modification. If you just have the QR code and you've lost the associated string, decoding the QR code gets you back to where you started, the same as if you were swapping backwards and forwards between PNG and XPM versions of the same graphic. smcv
Bug#955476: ITP: ruby-hrx -- a Ruby implementation of the HRX format
Package: wnpp Severity: wishlist Owner: Anthony Fok -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: ruby-hrx Version : 1.0.0 Upstream Author : Natalie Weizenbaum * URL : https://github.com/google/hrx-ruby * License : Apache-2.0 Programming Lang: Ruby Description : a Ruby implementation of the HRX format This gem is a parser and serializer for the HRX (Human Readable Archive) format. More information: ruby-hrx is required by sass-spec 3.6.3-1 (to be upgraded). ruby-hrx is to be team-maintained with Debian Ruby Extras Maintainers -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEFCQhsZrUqVmW+VBy6iUAtBLFms8FAl6EWJQACgkQ6iUAtBLF ms8Skw/6AoJt5Y8BG5Gm10HBD3K1OJLMhOcbZAPx/LI0AVgvRO3WxChKbGq7ZgpW ll5wY4VrYw7YfjqIeXqjierjUxlvwVVLRGqChT2Smy4mi4z+x8Lja4+xp9Ja8PqU yAa80M3Rf3AsiBmu1ombhiLMmx9Wp308Wmu0dPy2OFfUNf5nyLtuvW5Yl1647DQN rKqPg9+rexnafxgnT6kpR7ff60M4e1Tmb/6IOKrXOdd/1XS6+74seyE6ismLdgvB QFz1D6gqUEa4jV5qb6uSN6u5680tHPSceSJ023/L7/89Zi6gXLZB0pdrUA+BClyp HjPwgqkir5VyNsqYGN0a9soEe5GF5geRHxYmTEi7Fm+LGKZaYay+e0VPMRTjRTkD YvejuGlxocjleg1eTqKMuBUwWK9cYpKXdoYaHWgzycGUkeueBPnXK3r8a2iQKurg qHcVSrd5BNQ4nS2bYi+eFY9y5ihVJkFj8Kfc7C6UNEomf2AFKFOSoD1DAHQGyz+m Oc2iYd2m9FpWK42nZ8TcJ2KoUDQY0U9fimgG9v7p2wxaVLA6tPYooAsbd4JUQIK5 qaELFpH8S3v6eRVNzjmdZEDXleseahDRfrmz5ntqyL3amIpBvGnzSsZuxNjuDa4G ffTrYk/Bke9K+NLPrhWSxWVjTz2Xc2TLKrPwoeOAJZ51/jlCdIE= =rsAn -END PGP SIGNATURE-
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
Bug#955495: ITP: orthanc-python -- Develop plugins for Orthanc using the Python programming language
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne * Package name: orthanc-python Version : 1.0 Upstream Author : Sebastien Jodogne * URL : https://www.orthanc-server.com/ * License : AGPL Programming Lang: C++, Python Description : Develop plugins for Orthanc using the Python programming language This plugin can be used to write Orthanc plugins using the Python programming language instead of the more complex C/C++ programming languages. It can be used to gain access to Python modules directly in Orthanc. This plugin can be of great help to anyone wishing to automate her imaging workflow, to design/train new machine learning algorithms, or to deploy AI systems directly in clinical setups. Full documentation is available in the Orthanc Book: https://book.orthanc-server.com/plugins/python.html
