Hello,
My name is Daniel M. Capella (aka polyzen), and I am applying to be a Trusted User with Ivy Foster's sponsorship.
My current main interest lies in Rustlang-based blockchain/distributed app/cryptocurrency implementations; half for the tech, half so I can escape the world of indentured slavery, fearlessly. My dream for the future is to write software that will help increase the pace it takes science to build the world of tomorrow -- whatever that means. I watch too much sci fi.
I hope you like lists as much as I apparently do.
----
Stats:
- Arch vanilla user since 2013. ALARM user for my home servers since perhaps a year or two before then. For completion's sake, even before that I had used Ubuntu and Archbang. This year I will be getting the LPIC-2[1] certificate (may or may not be related to my LPIC-1 expiring this year ^^).
- Held a workshop called "Git for Gits"[2] with meskarune under the Arch Linux Classroom. The class is (very) slowly being revamped for further sessions.
- Coordinated AUR Cleanup Day 2017[3]. The original plan was for this to occur every other year, but the previous one was in 2010. I hope to continue the tradition of this occurring biennially.
- Co-maintainer of pacman-contrib. Funny story: when I requested Git access, Florian gave it to me thinking I was Kyrias. ^^ I had a habit of nick (IRC) hopping back then.
- Arch Linux Tester when I remember that's a thing I signed up for.
- Relatively active with IRC and bug tracker support.
- Very active with upstreams WRT packaging and then some.
----
Here follows the packages I'd like to move to and/or co-maintain in Community:
- Packages I already maintain:
- Automatic exception:
- espeak-ng (accessibility)
See also https://bugs.archlinux.org/task/60618.
- Popular:
- firefox-ublock-origin - firefox-umatrix
- pulseaudio-dlna
- python-black
Maxim already plans to add this to the repos, but I would like to (co-)maintain this, being the original submitter (before it was merged into python-black due to the naming convention).
- razercfg/razerd
- 1% usage on pkgstats:
- firefox-bookmarkdupes - firefox-multiple-tab-handler - firefox-referer-control - firefox-stylus - firefox-tab-flip-for-tree-style-tab - Firefox-tree-style-tab
- termdown
- tty-solitaire
See https://github.com/mpereira/tty-solitaire/issues/29.
- There was consensus from a few TU's in #archlinux-aur on considering the popularity of release variants:
- Popular:
- shaderc (-git)
See also https://bugs.archlinux.org/task/58582.
- 1% usage on pkgstats:
- gmailieer (-git)
- termtosvg (-git)
- Other users' AUR packages:
- Popular:
- alot
- hsetroot
- python-proselint
- ttf-symbola
- yamllint
- 1% usage on pkgstats:
- python-vint
- skim
- Repo packages:
- Orphans in Extra that I have installed:
- ttf-indic-otf
- vulkan-icd-loader
- Packages I submitted to the AUR that were adopted or were added to the repos without checking the AUR first :p:
- asp
- fd
- newsboat
----
Notes from Ivy that may come up in reviews:
- “These Node.js and mkchromecast packages give me nightmares.”:
..Okay, actually that was my response when he brought them up.
mkchromecast has a setup.py for its next release. npm packages have no hope. I've had to change chown invocations far too many times. Please don't hate me.
- “This isn't a technical critique; more of an aesthetic one that you probably shouldn't listen to. It would be slightly amusing to add firefox as an optdepends to firefox-* (-:”:
firefox was removed as a dep for these to make it easier for people to use them with Palemoon and such.
- Go package LDFLAGS:
Will take care of this.
- “hangups: "sed -i 's/==/>=/g' setup.py" -- why? Also, has that change been submitted upstream? It's minor, but if it fixes something it's probably worthwhile”:
Has to be done for pinned outdated dependencies.
- “razercfg: have you submitted that tmpfile.conf upstream? Also, re: the install file, I'm pretty sure that ldconfig happens automagically, and systemd-udev-reload.hook should handle reloading udev rules”:
Will take care of this.
- “shaderc: there were a lot of patches in prepare(), which I can say from experience probably won't go over super well. I'm guessing these probably are waiting on acceptance or something?”:
See https://github.com/google/shaderc/issues/392#issuecomment-427442293 and https://github.com/google/shaderc/issues/424.
- “no need for install -m755; -m755 is the default”:
Taking care of this.
----
Some notes of my own that could be added to the guidelines:
- My Rust packages use published crates if available, eg.: `source=("diskus-$pkgver.tar.gz::https://crates.io/api/v1/crates/diskus/$pkgver/download%22)%60
`--locked` will be used for those in due time: https://github.com/rust-lang/cargo/issues/5654
- Similarly I source published npm packages, eg.: `source=("https://registry.npmjs.org/$pkgname/-/$pkgname-$pkgver.tgz%22)%60
- The following can be used for GitHub releases (where $url is eg. https://github.com/LegNeato/asciinema-rs):
- Before: `source=("$pkgname-$pkgver.tar.gz::$url/archive/v$pkgver.tar.gz")` - After: `source=("$url/archive/v$pkgver/$pkgname-v$pkgver.tar.gz")`
----
Future activities in mind:
- Automated release notifications, perhaps once we're closer to automated builds. Maybe with https://release-monitoring.org/.
- AL onboarding site, unless a wiki article is sufficient. Could be nice to make https://www.rustaceans.org/findwork work with Bugzilla.
----
Thank you all for your consideration.
Best, Daniel M. Capella / dmc / polyzen
[1]: https://www.lpi.org/our-certifications/summary-of-certifications [2]: https://archwomen.org/media/project_classroom/classlogs/2016-07-16-git_for_g... [3]: https://lists.archlinux.org/pipermail/aur-general/2017-September/033557.html
I confirm my sponsorship; let the games (or discussion, I guess) begin!
iff ("escondida")
The following can be used for GitHub releases (where $url is eg. https://github.com/LegNeato/asciinema-rs):
- Before:
`source=("$pkgname-$pkgver.tar.gz::$url/archive/v$pkgver.tar.gz")`
- After: `source=("$url/archive/v$pkgver/$pkgname-v$pkgver.tar.gz")`
Correction: $pkgname in the after line is only correct if it matches the project name, tense included -- assuming you like it to match the name of the downloaded tarball. Same goes for the version (eg. the "v" some projects use). For ease of use, perhaps best to keep this out of the guidelines.
- The following can be used for GitHub releases (where $url is eg.
https://github.com/LegNeato/asciinema-rs):
- Before:
`source=("$pkgname-$pkgver.tar.gz::$url/archive/v$pkgver.tar.gz")`
- After: `source=("$url/archive/v$pkgver/$pkgname-v$pkgver.tar.gz")`
Correction: $pkgname in the after line is only correct if it matches the project name, tense included -- assuming you like it to match the name of the downloaded tarball. Same goes for the version (eg. the "v" some projects use). For ease of use, perhaps best to keep this out of the guidelines.
Further correction: With the after line, the "v" is always stripped with the downloaded tarball. That would make this example: `source=("$url/archive/v$pkgver/$pkgname-$pkgver.tar.gz")`
The following can be used for GitHub releases (where $url is eg. https://github.com/LegNeato/asciinema-rs):
- Before:
`source=("$pkgname-$pkgver.tar.gz::$url/archive/v$pkgver.tar.gz")`
- After: `source=("$url/archive/v$pkgver/$pkgname-v$pkgver.tar.gz")`
Correction: $pkgname in the after line is only correct if it matches the project name, tense included -- assuming you like it to match the name of the downloaded tarball. Same goes for the version (eg. the "v" some projects use). For ease of use, perhaps best to keep this out of the guidelines.
Further correction: With the after line, the "v" is always stripped with the downloaded tarball. That would make this example: `source=("$url/archive/v$pkgver/$pkgname-$pkgver.tar.gz")`
Update(Correction?): You can put whatever you want between the last "/" and ".tar.gz", and it will be named that.
-- Best, polyzen
Hi Daniel,
Small summary of things I repeatedly noticed:
- # Generated by mksrcinfo v8 Wed Nov 14 05:46:26 UTC 2018 I would say remove this ancient package from your system and use makepkg --printsrcinfo instead
- if a setup.py uses entry_points for scripts that means setuptools is not just a make but a hard dependency
- tests are awesome <3 run them whenever possible! more is better! pulling sources from github is favorable when you get free tests and sometimes manpages/docs
[+] Running xxarhtna --verbose --pedantic
asciinema-rs: - provides asciinema, but where is the conflicts?
black-git: - this should be called python-black - running unit tests is missing - setuptools is a hard dependency, setup.py uses entry_points - python-aiohttp should be a checkdepends otherwise tests deactivate several things
diskus: - we can use --locked for repro as there is a Cargo.lock
espeak-ng: - That shouldn't provide espeak, its not a drop in replacement and breaks stuff, this epoch on espeak is for a reason:
https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/esp... - autogen.sh should be a prepare() thing
firefox-* - i just skip over those, not a fan of repackaging xpi but meh - also meh on the lack of firefox dependency when putting files in /usr/lib/firefox
firefox-bookmarkdupes: - building from source will have nice signatures
gitleaks: - there are tests available for check() - RELRO ldflags
gixy: - setuptools is a hard dependency, setup.py uses entry_points - there are tests available for check() if you pull the real soruces
hangups: - setuptools is a hard dependency, setup.py uses entry_points - there are tests available for check() if you pull the real soruces - you can distribute manpages via docs dir + man target if you pull the real soruces (and add python-sphinx as makedepends)
instalooter - there are tests available for check() if you pull the real soruces - you can distribute manpages via docs dir + man target if you pull the real soruces (and add python-sphinx as makedepends)
mwic - the hack does upstream do, it will create .py files in usr/share/mwic/lib/ that lack the pyo/pyc files and if running as root the imports will create untracked files in that directory that will remain forever
pcaudiolib - prepare() is a better place for autogen.sh
pulldown-cmark - there is a Cargo.lock lets use --locked for reproducible builds this requires to pull unstripped sources from github - there are also tests available but whatever upstream does, some of them seem to fail? investigate?
pulseaudio-dlna: - setuptools is a hard dependency, setup.py uses entry_points
pycoinmon: - setuptools is a hard dependency, setup.py uses entry_points - there are tests available for check() if you pull the real soruces
shaderc: - pacman -Q glslang-git hm no it depends on glslang - build works perfectly fine with python3 - CMAKE_INSTALL_PREFIX must not use $pkgdir, that belongs to DESTDIR for ninja in package() - i'm sorry, i gonna need to pull this into [extra] as part of an update. thanks for the work
pyt: - setuptools is a hard dependency, setup.py uses entry_points
pyt-git: - setuptools is a hard dependency, setup.py uses entry_points
python-black: - setuptools is a hard dependency, setup.py uses entry_points - python-aiohttp should be a checkdepends otherwise tests deactivate several things
python-fake-useragent: - there are tests available for check() if you pull the real soruces needs checkdepends of pytest and mock
python-flake8-bugbear: - setuptools is a hard dependency, setup.py uses entry_points
python-milksnake: - setuptools is a hard dependency, setup.py uses entry_points - there are tests available for check() if you pull the real soruces
python-py-spin: - there are tests available for check() if you pull the real soruces via test_pyspin.py
python-soco: - there are tests available for check() via py.test - maybe distribute some docs as well like manpages from docs dir
razercfg: - razercfg.install could be removed, ldconfig systemd-tmpfiles and udevadm are handled via hooks - do we _really_ need to split razer mouse tool UI and daemon here? doubt it tbh.
rst2ctags: - setuptools is a hard dependency, setup.py uses entry_points
rstcheck: - there are tests available for check() via test_rstcheck.py - setuptools is a hard dependency, setup.py uses entry_points
socos: - setuptools is a hard dependency, setup.py uses entry_points
speedtest-zpeters: - go magic to get RELRO ldflags - whats wrong with the tests? maybe comment?
spotify-adkiller-git: - i dont like file-type postfixes in /usr/bin they should be removed and ADKILLER= be adjusted
spt: - this needs a build() func, don't build implicitly in package() - CPPFLAGS are not respected and should be populated properly an upstream patch for that would be best
termdown: - setuptools is a hard dependency, setup.py uses entry_points
termtosvg: - there are nice manpages for this CLI tool in the upstream sourceso on GH
toastify: - github sources have Cargo.lock that we need for reproducible builds passed via --locked
trust-dns-server: - there are tests that could be run via check()
weather-go: - go magic to get RELRO ldflags
[*] xxarhtna report finished
cheers, Levente
Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
Hi Daniel,
Small summary of things I repeatedly noticed:
- # Generated by mksrcinfo v8 Wed Nov 14 05:46:26 UTC 2018 I would say remove this ancient package from your system and use makepkg --printsrcinfo instead
Done.
- if a setup.py uses entry_points for scripts that means setuptools is not just a make but a hard dependency
Totally forgot about this. Thank you for listing all the packages that need the change; will roll this out.
- tests are awesome <3 run them whenever possible! more is better! pulling sources from github is favorable when you get free tests and sometimes manpages/docs
Will work with the upstreams to distribute these. I prefer to use published offerings as they are what the authors intend to be used. GitHub autogenerated tarballs are also subject to change: https://marc.info/?l=openbsd-ports&m=151973450514279&w=2
For Rust sources there's also this problem: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-v...
Crates explicitly filter out lock files. `publish-lockfile` for binary crates is still only available in Cargo nightly. Communication is already in progress with the relevant upstreams.
[+] Running xxarhtna --verbose --pedantic
asciinema-rs:
- provides asciinema, but where is the conflicts?
Done.
black-git:
- this should be called python-black
- running unit tests is missing
- setuptools is a hard dependency, setup.py uses entry_points
- python-aiohttp should be a checkdepends otherwise tests deactivate several things
Didn't request to be a co-maintainer for this, and haven't looked at the pkgbuild yet. Will pass the notes along.
espeak-ng:
- That shouldn't provide espeak, its not a drop in replacement and breaks stuff, this epoch on espeak is for a reason:
https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/esp...
- autogen.sh should be a prepare() thing
Well then. Done.
firefox-bookmarkdupes:
- building from source will have nice signatures
I check these against upstream checksums: `curl -I https://addons.mozilla.org/firefox/downloads/latest/bookmark-dupes/ | grep Digest`
Building Fx extensions is among the last things I want to do. :p Pretty sure I would have to setup an AMO account to then also sign the extension myself.
gitleaks:
- there are tests available for check()
Done.
mwic
- the hack does upstream do, it will create .py files in usr/share/mwic/lib/ that lack the pyo/pyc files and if running as root the imports will create untracked files in that directory that will remain forever
Will see what can be done.
pcaudiolib
- prepare() is a better place for autogen.sh
Done.
pulldown-cmark
- there is a Cargo.lock lets use --locked for reproducible builds this requires to pull unstripped sources from github
- there are also tests available but whatever upstream does, some of them seem to fail? investigate?
https://github.com/raphlinus/pulldown-cmark/pull/152#issuecomment-435519277
shaderc:
- i'm sorry, i gonna need to pull this into [extra] as part of an update. thanks for the work
C'est la vie.
python-black:
- setuptools is a hard dependency, setup.py uses entry_points
- python-aiohttp should be a checkdepends otherwise tests deactivate several things
Done.
python-soco:
- there are tests available for check() via py.test
Requires jumping through hoops. See the note: https://soco.readthedocs.io/en/latest/development/unittests.html?highlight=t...
- maybe distribute some docs as well like manpages from docs dir
I don't see any manpages there. This is a library.
razercfg:
- razercfg.install could be removed, ldconfig systemd-tmpfiles and udevadm are handled via hooks
Done.
- do we _really_ need to split razer mouse tool UI and daemon here?
doubt it tbh.
The UI is completely optional. ¯_(ツ)_/¯
speedtest-zpeters:
- whats wrong with the tests? maybe comment?
Don't remember exactly. Either way, the packaged release reports the wrong results, and a complete rewrite is in progress.
spotify-adkiller-git:
- i dont like file-type postfixes in /usr/bin they should be removed and ADKILLER= be adjusted
Done.
spt:
- this needs a build() func, don't build implicitly in package()
Done.
- CPPFLAGS are not respected and should be populated properly an upstream patch for that would be best
Will have to figure that out.
termtosvg:
- there are nice manpages for this CLI tool in the upstream sourceso on GH
https://github.com/nbedos/termtosvg/pull/77
Poked upstream for a release.
trust-dns-server:
- there are tests that could be run via check()
Done. \o/
[*] xxarhtna report finished
cheers, Levente
Thank you very much for the review. Go LDFLAGS is still on the todo. Packaging for Go has perhaps been more traumatizing than even Node.js.
-- Best, polyzen
On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote:
Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
- tests are awesome <3 run them whenever possible! more is better! pulling sources from github is favorable when you get free tests and sometimes manpages/docs
Will work with the upstreams to distribute these. I prefer to use published offerings as they are what the authors intend to be used. GitHub autogenerated tarballs are also subject to change: https://marc.info/?l=openbsd-ports&m=151973450514279&w=2
I've seen the occasional *claim* that this happens, but I've yet to see any actual case where this happens and it isn't because of upstream force-pushing a tag.
GitHub is supposed to use git-archive(1) for this, which is guaranteed to be reproducible when generating .tar, although in theory post-filtering this through a compressor like gzip can result in changes from one version of git to another. I say in theory because I don't recall this ever happening, and git-archive uses the fairly boring defaults.
I don't see any reason to use substandard sources in order to avoid checksum problems I don't believe in.
For Rust sources there's also this problem: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-v...
Crates explicitly filter out lock files. `publish-lockfile` for binary crates is still only available in Cargo nightly. Communication is already in progress with the relevant upstreams.
I have no clue what this is even supposed to mean. I'm reading your link and it says that "it's conventional" for upstream developers of rust applications to commit their lockfiles to git, but not to do so for libraries. Given that one builds applications, and not libraries, I'm unsure what the problem is here.
Do you mean to say that crates.io doesn't ship all the files available in git? Okay, I agree that git is the superior source. I don't generally trust "intelligent" tools to decide what's important.
Still not sure what this doc describing the split between libraries and binaries, has to do with anything.
firefox-bookmarkdupes:
- building from source will have nice signatures
I check these against upstream checksums: `curl -I https://addons.mozilla.org/firefox/downloads/latest/bookmark-dupes/ | grep Digest`
Building Fx extensions is among the last things I want to do. :p Pretty sure I would have to setup an AMO account to then also sign the extension myself.
If upstream is dedicated to PGP-signing the sources, maybe they'd be willing to PGP-sign a .xpi file too...
python-soco:
- there are tests available for check() via py.test
Requires jumping through hoops. See the note: https://soco.readthedocs.io/en/latest/development/unittests.html?highlight=t...
Sounds like they have two sets of tests: some unittests for the code correctness, plus unittests to test the interaction with an online server.
Also sounds like the former, which are all we care about I suppose, should be easy to do without any hoops, just by running pytest?
- do we _really_ need to split razer mouse tool UI and daemon here?
doubt it tbh.
The UI is completely optional. ¯_(ツ)_/¯
Why does this mean they cannot be a single package?
On 15-11-18, Eli Schwartz via aur-general wrote:
On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote:
Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
- tests are awesome <3 run them whenever possible! more is better! pulling sources from github is favorable when you get free tests and sometimes manpages/docs
Will work with the upstreams to distribute these. I prefer to use published offerings as they are what the authors intend to be used. GitHub autogenerated tarballs are also subject to change: https://marc.info/?l=openbsd-ports&m=151973450514279&w=2
I've seen the occasional *claim* that this happens, but I've yet to see any actual case where this happens and it isn't because of upstream force-pushing a tag.
See https://bugs.archlinux.org/task/60382 for an example.
I still had the old archive around so I spent some time comparing it with the new one:
- I compared the checksum of each individual file in the archives, and they were all identical
- I compared the raw tar files after decompressing, and there were just a few bytes that were moved around
This really suggests a slight format change in the way the tarball was generated (could be file ordering).
If you want to double check, here they are:
- old archive from May 2017: https://files.polyno.me/arch/kashmir-20150805-20170525.tar.gz
- new archive: https://files.polyno.me/arch/kashmir-20150805.tar.gz
Baptiste
Le 15/11/2018 à 10:52, Baptiste Jonglez a écrit :
On 15-11-18, Eli Schwartz via aur-general wrote:
On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote:
Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
- tests are awesome <3 run them whenever possible! more is better! pulling sources from github is favorable when you get free tests and sometimes manpages/docs
Will work with the upstreams to distribute these. I prefer to use published offerings as they are what the authors intend to be used. GitHub autogenerated tarballs are also subject to change: https://marc.info/?l=openbsd-ports&m=151973450514279&w=2
I've seen the occasional *claim* that this happens, but I've yet to see any actual case where this happens and it isn't because of upstream force-pushing a tag.
See https://bugs.archlinux.org/task/60382 for an example.
I still had the old archive around so I spent some time comparing it with the new one:
I compared the checksum of each individual file in the archives, and they were all identical
I compared the raw tar files after decompressing, and there were just a few bytes that were moved around
This really suggests a slight format change in the way the tarball was generated (could be file ordering).
If you want to double check, here they are:
old archive from May 2017: https://files.polyno.me/arch/kashmir-20150805-20170525.tar.gz
new archive: https://files.polyno.me/arch/kashmir-20150805.tar.gz
Baptiste
But those are not tag tarballs though.
That being said, yes, the tarball format changed once in the past, on purpose, so that it could actually be reproducible and allow things like the “alternative local workflow” of https://wiki.debian.org/Creating signed GitHub releases. I can’t remember when that happened, but per this page that was prior to April 2016. And AFAIK, it is not subject to change again for this exact reason. ;)
Regards, Bruno
On 11/15/18 10:52 AM, Baptiste Jonglez wrote:
On 15-11-18, Eli Schwartz via aur-general wrote:
On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote:
Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
- tests are awesome <3 run them whenever possible! more is better! pulling sources from github is favorable when you get free tests and sometimes manpages/docs
Will work with the upstreams to distribute these. I prefer to use published offerings as they are what the authors intend to be used. GitHub autogenerated tarballs are also subject to change: https://marc.info/?l=openbsd-ports&m=151973450514279&w=2
I've seen the occasional *claim* that this happens, but I've yet to see any actual case where this happens and it isn't because of upstream force-pushing a tag.
See https://bugs.archlinux.org/task/60382 for an example.
I still had the old archive around so I spent some time comparing it with the new one:
I compared the checksum of each individual file in the archives, and they were all identical
I compared the raw tar files after decompressing, and there were just a few bytes that were moved around
This really suggests a slight format change in the way the tarball was generated (could be file ordering).
If you want to double check, here they are:
old archive from May 2017: https://files.polyno.me/arch/kashmir-20150805-20170525.tar.gz
new archive: https://files.polyno.me/arch/kashmir-20150805.tar.gz
Baptiste
GitHub invalidating caches is not the problem here, they should be allowed to do it whenever they wish. The root of the issue is unreproduciblility as already pointed out here.
The tarballs are stable per se if no weird magic applies via git export rules like dates being exported into files or no force pushes are done to the tree, they use git archive via tar which itself is reproducible. In fact, detatched pre-generated tarballs sometimes changes as well so blame upstream for any such happening (at least nowadays :P).
Anyway, the differences we see here are just our digital legacy where the format was not reproducible yet.
The example tarball indeed only contains metadata changes related to ordering of filenames inside the structure. This is definitively stable today.
PS: You can simply use diffoscope for such analysis, it has been invented for this very purpose and is not only content but also meta-data aware.
cheers, Levente
Quoting Eli Schwartz via aur-general (2018-11-15 00:52:50)
On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote:
Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
- tests are awesome <3 run them whenever possible! more is better! pulling sources from github is favorable when you get free tests and sometimes manpages/docs
Will work with the upstreams to distribute these. I prefer to use published offerings as they are what the authors intend to be used. GitHub autogenerated tarballs are also subject to change: https://marc.info/?l=openbsd-ports&m=151973450514279&w=2
I've seen the occasional *claim* that this happens, but I've yet to see any actual case where this happens and it isn't because of upstream force-pushing a tag.
GitHub is supposed to use git-archive(1) for this, which is guaranteed to be reproducible when generating .tar, although in theory post-filtering this through a compressor like gzip can result in changes from one version of git to another. I say in theory because I don't recall this ever happening, and git-archive uses the fairly boring defaults.
I don't see any reason to use substandard sources in order to avoid checksum problems I don't believe in.
"substandard" 🤔 https://wiki.archlinux.org/index.php/Python_package_guidelines#Source
For Rust sources there's also this problem: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-v...
Crates explicitly filter out lock files. `publish-lockfile` for binary crates is still only available in Cargo nightly. Communication is already in progress with the relevant upstreams.
I have no clue what this is even supposed to mean. I'm reading your link and it says that "it's conventional" for upstream developers of rust applications to commit their lockfiles to git, but not to do so for libraries. Given that one builds applications, and not libraries, I'm unsure what the problem is here.
Do you mean to say that crates.io doesn't ship all the files available in git? Okay, I agree that git is the superior source. I don't generally trust "intelligent" tools to decide what's important.
Still not sure what this doc describing the split between libraries and binaries, has to do with anything.
https://github.com/bluejekyll/trust-dns/issues/604#issuecomment-436510626
python-soco:
- there are tests available for check() via py.test
Requires jumping through hoops. See the note: https://soco.readthedocs.io/en/latest/development/unittests.html?highlight=t...
Sounds like they have two sets of tests: some unittests for the code correctness, plus unittests to test the interaction with an online server.
Also sounds like the former, which are all we care about I suppose, should be easy to do without any hoops, just by running pytest?
Yeah, I tried that.
- do we _really_ need to split razer mouse tool UI and daemon here?
doubt it tbh.
The UI is completely optional. ¯_(ツ)_/¯
Why does this mean they cannot be a single package?
-- Eli Schwartz Bug Wrangler and Trusted User
-- Best, polyzen
On 11/16/18 12:51 AM, Daniel M. Capella via aur-general wrote:
Quoting Eli Schwartz via aur-general (2018-11-15 00:52:50)
On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote:
Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
- tests are awesome <3 run them whenever possible! more is better! pulling sources from github is favorable when you get free tests and sometimes manpages/docs
Will work with the upstreams to distribute these. I prefer to use published offerings as they are what the authors intend to be used. GitHub autogenerated tarballs are also subject to change: https://marc.info/?l=openbsd-ports&m=151973450514279&w=2
I've seen the occasional *claim* that this happens, but I've yet to see any actual case where this happens and it isn't because of upstream force-pushing a tag.
GitHub is supposed to use git-archive(1) for this, which is guaranteed to be reproducible when generating .tar, although in theory post-filtering this through a compressor like gzip can result in changes from one version of git to another. I say in theory because I don't recall this ever happening, and git-archive uses the fairly boring defaults.
I don't see any reason to use substandard sources in order to avoid checksum problems I don't believe in.
"substandard" 🤔 https://wiki.archlinux.org/index.php/Python_package_guidelines#Source
Does the wiki really need to be overly specific when its sane to use which source? Especially when you have one that gives tests, docs and signatures and the other not? Or do we really expect to have a paragraph to explicitly allow building python from the original unprocessed main sources as well?
I don't think so.
On Thu, Nov 15, 2018 at 06:51:31PM -0500, Daniel M. Capella via aur-general wrote:
Quoting Eli Schwartz via aur-general (2018-11-15 00:52:50)
On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote:
Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
- tests are awesome <3 run them whenever possible! more is better! pulling sources from github is favorable when you get free tests and sometimes manpages/docs
Will work with the upstreams to distribute these. I prefer to use published offerings as they are what the authors intend to be used. GitHub autogenerated tarballs are also subject to change: https://marc.info/?l=openbsd-ports&m=151973450514279&w=2
I've seen the occasional *claim* that this happens, but I've yet to see any actual case where this happens and it isn't because of upstream force-pushing a tag.
GitHub is supposed to use git-archive(1) for this, which is guaranteed to be reproducible when generating .tar, although in theory post-filtering this through a compressor like gzip can result in changes from one version of git to another. I say in theory because I don't recall this ever happening, and git-archive uses the fairly boring defaults.
I don't see any reason to use substandard sources in order to avoid checksum problems I don't believe in.
"substandard" 🤔 https://wiki.archlinux.org/index.php/Python_package_guidelines#Source
Those guidelines are mainly in the context of the python ecosystem. There are no prefferences, only options. If tests, manpages or sources are missing from the pypi mirrors because of mismanagement from upstream, then they are indeed substandard.
On 11/15/18 5:50 AM, Daniel M. Capella via aur-general wrote:
- tests are awesome <3 run them whenever possible! more is better! pulling sources from github is favorable when you get free tests and sometimes manpages/docs
Will work with the upstreams to distribute these. I prefer to use published offerings as they are what the authors intend to be used. GitHub autogenerated tarballs are also subject to change: https://marc.info/?l=openbsd-ports&m=151973450514279&w=2
Well source tree is the source of truth as that's where processed stuff comes from :P
If you can't convince all upstream do distribute their tests and especially not convince them to distribute the sources for generating docs I would still say please go for source tree instead as the value of such additional content is high. We love tests.
Side note, nowadays there are lots of python and other project that git sign their latest tags and commits but have no other way of detatched signatures, this adds a big gain as well. Remember two of your packages had upstream tag signatures but i forgot to point them out. If I can't convince them to use detatched sinatures as well I nowadays just switch to pull git and use ?signed
python-soco:
- maybe distribute some docs as well like manpages from docs dir
I don't see any manpages there. This is a library.
make -C doc man Manpages are not exclusive for tools, they are for any kind of documentation like library APIs try running: man 3 sprintf
razercfg:
- do we _really_ need to split razer mouse tool UI and daemon here?
doubt it tbh.
The UI is completely optional. ¯_(ツ)_/¯
My point is, its the same source and the packages are not huge and it doesn't have crazy dependency hells. Only split up if it really makes sense, if there is no real reason we keep them combined, like tools + libs + headers and don't go as crazy as debian about splitting up everything.
- CPPFLAGS are not respected and should be populated properly an upstream patch for that would be best
Will have to figure that out.
All you need in the PR is add $CPPFLAGS where you already see $CFLAGS. For time being either backport this patch or just export CFLAGS="${CFLAGS} ${CPPFLAGS} until its done.
Thank you very much for the review. Go LDFLAGS is still on the todo. Packaging for Go has perhaps been more traumatizing than even Node.js.
You're welcome, always a plesure if people are happy about it :-)
Quoting Levente Polyak via aur-general (2018-11-15 05:19:10)
On 11/15/18 5:50 AM, Daniel M. Capella via aur-general wrote:
- tests are awesome <3 run them whenever possible! more is better! pulling sources from github is favorable when you get free tests and sometimes manpages/docs
Will work with the upstreams to distribute these. I prefer to use published offerings as they are what the authors intend to be used. GitHub autogenerated tarballs are also subject to change: https://marc.info/?l=openbsd-ports&m=151973450514279&w=2
Well source tree is the source of truth as that's where processed stuff comes from :P
If you can't convince all upstream do distribute their tests and especially not convince them to distribute the sources for generating docs I would still say please go for source tree instead as the value of such additional content is high. We love tests.
Agreed. Will do.
Side note, nowadays there are lots of python and other project that git sign their latest tags and commits but have no other way of detatched signatures, this adds a big gain as well. Remember two of your packages had upstream tag signatures but i forgot to point them out. If I can't convince them to use detatched sinatures as well I nowadays just switch to pull git and use ?signed
Noted.
python-soco:
- maybe distribute some docs as well like manpages from docs dir
I don't see any manpages there. This is a library.
make -C doc man Manpages are not exclusive for tools, they are for any kind of documentation like library APIs try running: man 3 sprintf
Done.
razercfg:
- do we _really_ need to split razer mouse tool UI and daemon here?
doubt it tbh.
The UI is completely optional. ¯_(ツ)_/¯
My point is, its the same source and the packages are not huge and it doesn't have crazy dependency hells. Only split up if it really makes sense, if there is no real reason we keep them combined, like tools + libs + headers and don't go as crazy as debian about splitting up everything.
It was split for people who don't need to change options on the fly. Also because I thought it would be kinda neat. :p I don't mind merging them back together.
- CPPFLAGS are not respected and should be populated properly an upstream patch for that would be best
Will have to figure that out.
All you need in the PR is add $CPPFLAGS where you already see $CFLAGS. For time being either backport this patch or just export CFLAGS="${CFLAGS} ${CPPFLAGS} until its done.
This took me for a ride until I realized I just needed to switch to `CPPFLAGS +=` in the config.mk. A lesson I won't soon forget.
Thank you very much for the review. Go LDFLAGS is still on the todo. Packaging for Go has perhaps been more traumatizing than even Node.js.
You're welcome, always a plesure if people are happy about it :-)
-- Best, polyzen
The two week discussion period is over! Let the voting period begin!
aur-general@lists.archlinux.org