Re: Y2038 - best way forward in Debian?
On Sat, Feb 15, 2020 at 11:41:32PM +, Steve McIntyre wrote: > Hey John, > > John Goarzen wrote: > >On Tue, Feb 04 2020, Steve McIntyre wrote: > > > >The thing that we have to remember is that an operating system is a > >platform for running software. This problem is rather thorny, because: > > > >1) Some software is provided in only binary form and cannot be > >recompiled > > Oh, absolutely. In that situation there's not a lot we can sensibly > do, modulo telling people to run such things in a time-shifted VM. I'm > more worried about making *our* software work in the future. This feels like a waste of effort, then. The only reason why people want to run i386 is "multiarch, because I have this old binary that won't go away". For all other stuff, there's amd64. Especially since RHEL doesn't even do i386 anymore these days, so ISVs will have to compile for amd64 if they want it to work on whatever their customers run. In my opinion, there are really only two viable options: - Throw away the i386 port, and tell people that we no longer support it; - Figure out a way for 32-bit binary-only programs to keep working when they touch a time_t beyond 2038. Everything else feels like a waste of effort. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Re: Can Debian packaging changes require a CLA?
On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote: > It would also make the package unmaintainable if the original packer > loses interest, so the package would not be suitable for inclusion in > a stable release. Eh, it doesn't? A CLA is "you're allowed to change this, but if you want us to accept it then you have to give us these rights, otherwise we'll reject your contribution". If the original packager loses interest, that becomes moot, because he's not going to accept *any* patches anymore, anyway. You can fork, and you can do whatever you want from then on. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Re: Can Debian packaging changes require a CLA?
* Wouter Verhelst: > On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote: >> It would also make the package unmaintainable if the original packer >> loses interest, so the package would not be suitable for inclusion in >> a stable release. > > Eh, it doesn't? > > A CLA is "you're allowed to change this, but if you want us to accept it > then you have to give us these rights, otherwise we'll reject your > contribution". Ordinarily, yes. But I think here the request was that Debian would only make changes (“packaging changes”) if they were made by someone who has been subjected to a CLA.
Re: moving mg from salsa to github?
Hi Marco, On 2020-02-15 20:44, Marco d'Itri wrote: On Feb 15, Harald Dunkel wrote: I am maintainer for mg, currently on salsa. Problem is, upstream doesn't release tar balls anymore, but moved the code to github. I plan to do something like this for ppp, which now has a proper upstream git repository but no actual releases in a long time: mkdir /dev/shm/ppp/ cd /dev/shm/ppp rsync -aH .../ppp-2.4.7/ ppp-2.4.7/ cd ppp-2.4.7/ git branch -m upstream tarupstream git checkout tarupstream git remote add upstream https://github.com/paulusmack/ppp.git git fetch upstream git checkout remotes/upstream/master git switch -c upstream git merge tarupstream --allow-unrelated-histories git branch -d tarupstream git tag ppp-2.4.7+20191019 git checkout master git merge ppp-2.4.7+20191019 dch --preserve --version 2.4.7+20191019-1+1 "New upstream snapshot." cat << END > debian/gbp.conf [DEFAULT] upstream-tag = ppp-%(version)s pristine-tar = False compression = xz [pq] patch-numbers = False END gbp export-orig Cool, thanx very much. I have tons of this kind of self-made recipes in my doc folder. Very helpful. Harri
Re: Can Debian packaging changes require a CLA?
On Mon, Feb 17, 2020 at 09:45:32AM +0100, Florian Weimer wrote: > * Wouter Verhelst: > > > On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote: > >> It would also make the package unmaintainable if the original packer > >> loses interest, so the package would not be suitable for inclusion in > >> a stable release. > > > > Eh, it doesn't? > > > > A CLA is "you're allowed to change this, but if you want us to accept it > > then you have to give us these rights, otherwise we'll reject your > > contribution". > > Ordinarily, yes. > > But I think here the request was that Debian would only make changes > (“packaging changes”) if they were made by someone who has been > subjected to a CLA. I didn't interpret it this way. And even if that is what the question was, I don't think it's a valid question in Debian's context :-) There is no ownership of a package in Debian other than "X is currently the maintainer, and we don't usually take packages away without cause". But if "X" doesn't actually continue maintaining a package properly, then NMUs (in most cases) and/or package hijacks (in more extreme circumstances) are part of our procedures and "not maintaining" would be plenty of cause for such an action. The package as part of Debian will remain, and can be modified by anyone in Debian, as per the license applied to it if it is in main. Without a signed CLA, such changes just won't be applied to the *current* maintainer's git repository, but that doesn't matter as far as Debian is concerned; if the original maintainer loses interest, then the CLA-requiring git repository becomes utterly irrelevant to Debian. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Re: Y2038 - best way forward in Debian?
On Mon, Feb 17, 2020 at 09:03:22AM +0100, Wouter Verhelst wrote: >On Sat, Feb 15, 2020 at 11:41:32PM +, Steve McIntyre wrote: >> Hey John, >> >> John Goarzen wrote: >> >On Tue, Feb 04 2020, Steve McIntyre wrote: >> > >> >The thing that we have to remember is that an operating system is a >> >platform for running software. This problem is rather thorny, because: >> > >> >1) Some software is provided in only binary form and cannot be >> >recompiled >> >> Oh, absolutely. In that situation there's not a lot we can sensibly >> do, modulo telling people to run such things in a time-shifted VM. I'm >> more worried about making *our* software work in the future. > >This feels like a waste of effort, then. The only reason why people want >to run i386 is "multiarch, because I have this old binary that won't go >away". For all other stuff, there's amd64. Especially since RHEL doesn't >even do i386 anymore these days, so ISVs will have to compile for amd64 >if they want it to work on whatever their customers run. > >In my opinion, there are really only two viable options: > >- Throw away the i386 port, and tell people that we no longer support > it; >- Figure out a way for 32-bit binary-only programs to keep working when > they touch a time_t beyond 2038. Right, that's it for our existing i386 port then. But we do have other 32-bit ports with different ecosystems and requirements - hence why I started this thread. -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Bug#951489: ITP: arpeggio -- parser interpreter based on PEG grammars
Package: wnpp Severity: wishlist Owner: Philipp Huebner * Package name: arpeggio Version : 1.9.2 Upstream Author : Igor R. Dejanović * URL : http://textx.github.io/Arpeggio/stable/ * License : MIT Programming Lang: Python Description : parser interpreter based on PEG grammars Arpeggio is a recursive descent parser with memoization based on PEG grammars (aka Packrat parser). I intend to maintain this package in the Python Applications Packaging Team (PAPT).
Bug#951501: ITP: xr-el -- convert string regexp to rx notation
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: xr-el Version : 1.15 Upstream Author : Mattias Engdegård * URL or Web page : https://elpa.gnu.org/packages/xr.html * License : GPL-3+ Programming Lang: Emacs Lisp Description : convert string regexp to rx notation XR converts Emacs regular expressions to the structured rx form, thus being an inverse of rx. It can also find mistakes and questionable constructs inside regexp strings. It can be useful for: * Migrating existing code to rx form * Understanding what a regexp string really means * Finding errors in regexp strings It can also parse and find mistakes in skip-sets, the regexp-like arguments to skip-chars-forward and skip-chars-backward.
Bug#951503: ITP: pmemkv-python -- key:value data store for persistent memory (Python 3)
Package: wnpp Severity: wishlist Owner: Adam Borowski * Package name: pmemkv-python Version : 1.0~rc1 Upstream Author : Intel * URL : https://github.com/pmem/pmemkv-python/ * License : BSD-3 Programming Lang: Python Description : key:value data store for persistent memory (Python 3) This library provides a Python API for pmemkv -- a data store optimized for persistent memory, but functional on traditional storage media as well. These are bindings for pmemkv for snake-lovers.
Re: call for ftpmaster's transparency
> "Sean" == Sean Whitton writes: >> Also you never know how long your package will stay in the NEW >> queue and during this time lack of ITP could affect developers >> priorities. Sean> Well, I always look at the current NEW queue before packaging Sean> something. I do not. I trust the wnpp package to be reasonably accurate.
Bug#951518: ITP: golang-github-fatih-set -- Set data structure for Go
Package: wnpp Severity: wishlist Owner: Alois Micard * Package name: golang-github-fatih-set Version : 0.2.1-1 Upstream Author : Fatih Arslan * URL : https://github.com/fatih/set * License : Expat Programming Lang: Go Description : Set data structure for Go This package is needed for advancedlogic/GoOse Thanks in advance. - Aloïs Micard GPG: rsa4096/A5999EBDFC063F1F
Bug#951520: ITP: golang-github-gigawattio-window -- Golang package for iterating through a rolling window size of string tokens.
Package: wnpp Severity: wishlist Owner: Alois Micard * Package name: golang-github-gigawattio-window Version : 0.0~git20180317.0f5467e-1 Upstream Author : * URL : https://github.com/gigawattio/window * License : Expat Programming Lang: Go Description : Golang package for iterating through a rolling window size of string tokens. This package is needed for advancedlogic/GoOse Thanks in advance. - Aloïs Micard GPG: rsa4096/A5999EBDFC063F1F
debian/*.symbols files for C++ libraries
Hi all, (please Cc: me when replying. Thanks.) I'd like to warm up an old topic regarding creation of *.symbols files for shared libraries implemented in C++. I have followed all links in [1] and esp. read Russ Alberries experiment results [2,3]. All writing are quite old and I wonder if something new has come up meanwhile (improved tool chains, etc). Until now, I mostly avoided writing .symbols files for C++ shared libs. However, here comes the question: How do people handle .symbols files these days if they originate from C++ code? How do people make sure the .symbols files are correct for all supported architectures? What tool chains are used? Are there other good reads about the topic? My current context: I want to fix various build failures of lib-cpp related packages relevant for upcoming Unity8. Thanks + Greets, Mike [1] https://wiki.debian.org/UsingSymbolsFiles [2] https://www.eyrie.org/~eagle/journal/2012-01/008.html [3] https://www.eyrie.org/~eagle/journal/2012-02/001.html -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpycGvnjRKal.pgp Description: Digitale PGP-Signatur
Re: debian/*.symbols files for C++ libraries
On February 17, 2020 9:23:39 PM UTC, Mike Gabriel wrote: >Hi all, > >(please Cc: me when replying. Thanks.) > >I'd like to warm up an old topic regarding creation of *.symbols files > >for shared libraries implemented in C++. > >I have followed all links in [1] and esp. read Russ Alberries >experiment results [2,3]. All writing are quite old and I wonder if >something new has come up meanwhile (improved tool chains, etc). > >Until now, I mostly avoided writing .symbols files for C++ shared libs. > >However, here comes the question: How do people handle .symbols files >these days if they originate from C++ code? How do people make sure >the .symbols files are correct for all supported architectures? What >tool chains are used? Are there other good reads about the topic? > >My current context: I want to fix various build failures of lib-cpp >related packages relevant for upcoming Unity8. > >Thanks + Greets, >Mike > >[1] https://wiki.debian.org/UsingSymbolsFiles >[2] https://www.eyrie.org/~eagle/journal/2012-01/008.html >[3] https://www.eyrie.org/~eagle/journal/2012-02/001.html Here's what the QT/KDE team use: https://qt-kde-team.pages.debian.net/symbolfiles.html https://manpages.debian.org/testing/pkg-kde-tools/pkgkde-symbolshelper.1.en.html I've used it for other C++ packages with pretty good success. Scott K
Bug#951539: ITP: bruteforce-wallet -- Try to find a password of a encrypted wallet file
Package: wnpp Severity: wishlist Owner: Francisco Vilmar Cardoso Ruviaro * Package name: bruteforce-wallet Version : 1.5.2 Upstream Author : Guillaume LE VAILLANT * URL : https://github.com/glv2/bruteforce-wallet * License : GPL-3+ Programming Lang: C Description : Try to find a password of a encrypted wallet file The program tries to decrypt one of the encrypted addresses in the wallet by trying all the possible passwords. It is especially useful if you know something about the password (i.e. you forgot a part of your password but still remember most of it). Finding the password of a wallet without knowing anything about it would take way too much time (unless the password is really short and/or weak).
Bug#951540: ITP: golang-github-go-resty-resty -- Simple HTTP and REST client library for Go
Package: wnpp Severity: wishlist Owner: Alois Micard * Package name: golang-github-go-resty-resty Version : 2.1.0-1 Upstream Author : Go Resty * URL : https://github.com/go-resty/resty * License : Expat Programming Lang: Go Description : Simple HTTP and REST client library for Go This package is needed for advancedlogic/GoOse Thanks in advance. - Aloïs Micard GPG: rsa4096/A5999EBDFC063F1F
Re: debian/*.symbols files for C++ libraries
HI Scott, On Mo 17 Feb 2020 22:32:18 CET, Scott Kitterman wrote: On February 17, 2020 9:23:39 PM UTC, Mike Gabriel wrote: Hi all, (please Cc: me when replying. Thanks.) I'd like to warm up an old topic regarding creation of *.symbols files for shared libraries implemented in C++. I have followed all links in [1] and esp. read Russ Alberries experiment results [2,3]. All writing are quite old and I wonder if something new has come up meanwhile (improved tool chains, etc). Until now, I mostly avoided writing .symbols files for C++ shared libs. However, here comes the question: How do people handle .symbols files these days if they originate from C++ code? How do people make sure the .symbols files are correct for all supported architectures? What tool chains are used? Are there other good reads about the topic? My current context: I want to fix various build failures of lib-cpp related packages relevant for upcoming Unity8. Thanks + Greets, Mike [1] https://wiki.debian.org/UsingSymbolsFiles [2] https://www.eyrie.org/~eagle/journal/2012-01/008.html [3] https://www.eyrie.org/~eagle/journal/2012-02/001.html Here's what the QT/KDE team use: https://qt-kde-team.pages.debian.net/symbolfiles.html https://manpages.debian.org/testing/pkg-kde-tools/pkgkde-symbolshelper.1.en.html I've used it for other C++ packages with pretty good success. Scott K Thanks! Will try it out (inital upload just happened). Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpWqP125mJAR.pgp Description: Digitale PGP-Signatur
Bug#951547: ITP: libzt -- libzt is a simple and robust unit test library for C
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki * Package name: libzt Version : 0.1 Upstream Author : Zygmunt Krynicki * URL : http://github.com/zyga/libz/ * License : LGPL Programming Lang: C Description : libzt is a simple and robust unit test library for C The library provides functions for common checks and assertions, which produce readable diagnostic messages that integrate well with "make check" and programming editors, such as vi. - Robust, allowing you to focus on your code. - Simple and small, making it quick to learn and use. - Doesn't use dynamic memory allocation, reducing error handling. - Equipped with useful helpers for writing test cases. - Portable and supported on Linux, MacOS and Windows. - Documented and fully coverage and integration tested. This package may be useful to projects that want to write C unit tests but don't want to depend on glib or roll their own solution I would like to maintain it myself or in a team. The package needs to be sponsored.
Bug#951551: ITP: httpx -- fully featured HTTP client, with sync and async APIs, and support for both HTTP/1.1 and HTTP/2
Package: wnpp Severity: wishlist Owner: Sandro Tosi * Package name: httpx Version : 0.11.1 Upstream Author : Encode OSS * URL : https://www.python-httpx.org/ * License : BSD Programming Lang: Python Description : fully featured HTTP client, with sync and async APIs, and support for both HTTP/1.1 and HTTP/2 HTTPX is a fully featured HTTP client for Python 3, which provides sync and async APIs, and support for both HTTP/1.1 and HTTP/2. HTTPX builds on the well-established usability of `requests`, and gives you: * A broadly `requests`-compatible API * Standard synchronous interface, but with async support if you need it * HTTP/1.1 and HTTP/2 support * Ability to make requests directly to WSGI applications or ASGI applications. * Strict timeouts everywhere. * Fully type annotated. * 99% test coverage. Plus all the standard features of `requests`: * International Domains and URLs * Keep-Alive & Connection Pooling * Sessions with Cookie Persistence * Browser-style SSL Verification * Basic/Digest Authentication * Elegant Key/Value Cookies * Automatic Decompression * Automatic Content Decoding * Unicode Response Bodies * Multipart File Uploads * HTTP(S) Proxy Support * Connection Timeouts * Streaming Downloads * .netrc Support * Chunked Requests
Suggestions to increase your business.
Dear Webmaster, I am Deepak Nayak, sales manager export located in Delhi India. It has come to my notice that you’ve got website links on Google, you must be paying Google a substantial amount of money for these links. Google programs of various search engines offer you more disadvantages than advantages. In addition making a hole in your pocket, these programs display your ads for a limited period of time. Furthermore, more than 90 percent of potential customers for your products and services target organic and free search engine results for your keywords. So most of the time, your ads will go unnoticed. We offers an effective and long-lasting alternative to Google For a nominal price, you’ll see your targeted keywords on the first pages of major search engines for many years to come. Our 30 dedicated and experienced SEO,SMO professionals can analyze your site and provide you customized SEO,SMO services at affordable prices. So if you think our proposal profitable to you then kindly come back to us. We will then provide you our SEO,SMO plans and pricing so that we can move ahead with the business. Below you can find my online chat details to have a frequent communication with me. Thank you and waiting for your reply. Regards Deepak Mn-7982232952
