Re: [Dev] [abslibre] PR #101: libre/iceweasel 1:129.0-1

the x86_64 build fails - any ideas? | 0:46.59 ./rust_helper.h.stub | 0:47.05 thread 'main' panicked at src/bindgen/config.rs:1125:34: | 0:47.05 called `Result::unwrap()` on an `Err` value: "Couldn't parse config file: TOML parse error at line 363, column 1\n|\n363 | \"Keyframe\" = \

Re: [Dev] libretools 20240327 release announcement

On Sat, 06 Jul 2024 11:26:14 -0600 Luke wrote: > - librerelease: > + Has a new `-C` flag to clean the remote staging area (a > complement to `-c` which cleans the local staging area). i could comment on that one too - ideally, that would not be needed - it is there because if a release

Re: [Dev] libretools 20240327 release announcement

thanks for reviewing those - ive had a lot of that pending for years - just a few explanations On Sat, 06 Jul 2024 11:26:14 -0600 Luke wrote: > - librerelease: > + librechroot.conf:REPODEST got replaced by > TIER0_{USER,HOST,PORT,STAGING}. > Though it is now clear that if we >

[Dev] [dev] restart sshd immediately after upgrade

from arch: After upgrading to `openssh-9.8p1`, the existing SSH daemon will be unable to accept new connections (see <https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5>). When upgrading remote hosts, please make sure to restart the sshd service using `systemct

Re: [Dev] removed expired keys of inactive contributors

there were only a few packages in the repos, all signed by g4jc - i deleted one (qt4-only, inactive upstream) and rebuilt the others ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [PKGBUILD][PATCH] Updgrade ark to 24.02.2

merged thanks On Sun, 05 May 2024 16:28:25 + kwopleq wrote: > I tried to attach a file made by mksource(), but it didn't work. > It's not clear how people should contribute to build recipes > that use files from Parabola as source. just send a patch, the same as any other package `git format-

Re: [Dev] [abslibre] PR #99: libre/iceweasel: 127.0-1.parabola1

i converted iceweasel into a mksource PKGBUILD - that probably should have been done a long time ago, seeing as the PKGBUILD indicates in several places that it is removing "non-free bits", "pre-built bits", and such the PKGBUILD needed to change quite a bit; but it should not add to or impede the

Re: [Dev] removed expired keys of inactive contributors

On Mon, 17 Jun 2024 02:38:27 -0400 bill-auger wrote: > i would prefer to delete the package, in orfder to clean up PCR, rather than > maintain stuff that no one uses assuming that all such packages are in PCR - they probably are - anything in libre may need to be kept - IIRC that is the g

Re: [Dev] removed expired keys of inactive contributors

those are some very interesting numbers - unfortunately, i think what that really demonstrates more than anything is that there is a lot of cruft in the pool - the true stats need to be against the repo.db files, like my script does i suspect that most of the orphaned packages (the ones actually r

[Dev] very slow builds on beefcake

offhand, i doubt that this is related to the recent makepkg config changes; because that was three weeks ago, and everything seemed fine last week i have been compiling kernels for about 10 days - the last builds were very slow for all arches - i noticed because the ARM build is taking an absurdl

Re: [Dev] removed expired keys of inactive contributors

i have a script for that on the git server `packages-by` https://git.parabola.nu/parabola-maintenance-tools.git/tree/packages-by may as well start with that, enhance it, fix it, whatever ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.

Re: [Dev] libretools changes for review

On Sun, 16 Jun 2024 08:10:02 -0400 bill-auger wrote: > only the key for the libre source-ball is valid during normal makepkg runs more practically i suppose, users building at home only need the key for the libre source-ball - they would not need the upstream's key also, just a note t

[Dev] libretools changes for review

ive made some changes for librestage and librefetch - only one patch for librefetch is significant - "significant", in that i could probably make meaningful tests for these two - the others are minor enhancements (nearby changes i have on my WIP branches) i have many enhancements accumulated over

[Dev] removed expired keys of inactive contributors

my GPG key is due to expire; so i need to rebuild the keyring package this week - i just ran the tool i made that reports the status of the keys in the keyring, and noticed that a newly expired key appeared on the error list; which reminded me that a clean-up is overdue - all of those keys are for

[Dev] [abslibre] PR #99: libre/iceweasel: 127.0-1.parabola1

billauger closed without merging a pull-request against the project: `abslibre` that you are following. Closed pull-request: `` libre/iceweasel: 127.0-1.parabola1 `` https://pagure.io/abslibre/pull-request/99 ___ Dev mailing list Dev@lists.parabola.

[Dev] [abslibre] PR #99: libre/iceweasel: 127.0-1.parabola1

billauger commented on the pull-request: `libre/iceweasel: 127.0-1.parabola1` that you are following: `` merged `` To reply, visit the link below or just reply to this email https://pagure.io/abslibre/pull-request/99 ___ Dev mailing list Dev@lists.par

Re: [Dev] [abslibre] PR #99: libre/iceweasel: 127.0-1.parabola1

also, just wondering, why did these 'REMOTE_STAGE_ENDPOINT_URL' not also get stubbed/spoofed? but furthermore, couldnt you simply delete the entire mobile/ directory? - i would think that the parabola builds would never need nor touch it - why should you need to patch any of that? - gnuzilla keep

Re: [Dev] [abslibre] PR #99: libre/iceweasel: 127.0-1.parabola1

just to note, i deleted that .nvchecker.toml file again, and added them to .gitignore - most packages have that now - ive not been adopting them > we dont need these - they appear to be something that arch uses internally, > or is related to their gitlab instance, to detect new releases upstream >

Re: [Dev] libretools 20240528 release announcement

ok i had time today to nail this down On Wed, 12 Jun 2024 09:53:57 -0400 bill-auger wrote: > PKGDEST contains invalid characters > SRCDEST contains invalid characters that was for the obvious reason - those vars are not necessarily defined in makepkg.conf - those are not defined unt

Re: [Dev] libretools 20240528 release announcement

oh i could add that i made a toy PKGBUILD that exercises mksource pcr-testing/scratch-pkg/PKGBUILD # NOTE: This PKGBUILD is for experiments and for testing libretools. # Packages built with this PKGBUILD are not intended for distribution. # Only the -nonfree source-ball is published,

Re: [Dev] libretools 20240528 release announcement

On Wed, 12 Jun 2024 09:53:57 -0400 bill-auger wrote: > librefetch.conf will > not be installed in any chroot (ive actually experimented with that, and i > believe that it should never be) that did not come out quite right - i mean that the lbretools package should not be install

Re: [Dev] libretools 20240528 release announcement

On Thu, 30 May 2024 19:33:58 -0600 Luke wrote: > On Wed, 29 May 2024 00:51:18 -0600, bill-auger wrote: > > < # > > < #

Re: [Dev] [PATCH] Update gmid to 2.0.4

about the licenses array - we are in the process of migrating to the SPDX schema as arch has done - the licenses listed in almost every PKGBUILD will need to change - we have determined that it is safe to change them now - so for 'gmid', 'ISC' is no longer 'custom'; but is now a standard license ID

Re: [Dev] [PATCH] Update Prosody Modules

there are a few problems with this one - most significantly, you did not update the pkgver or the pkgrel - the repo would not accept that package because it has the identical filename as the existing one - at the very least, the pkgrel needs to be bumped - but it is not obvious what pkgver represen

[Dev] [abslibre] PR #98: libre/iceweasel: 126.0.1.parabola1, sync with upstreams

billauger closed without merging a pull-request against the project: `abslibre` that you are following. Closed pull-request: `` libre/iceweasel: 126.0.1.parabola1, sync with upstreams `` https://pagure.io/abslibre/pull-request/98 ___ Dev mailing lis

[Dev] [abslibre] PR #98: libre/iceweasel: 126.0.1.parabola1, sync with upstreams

billauger commented on the pull-request: `libre/iceweasel: 126.0.1.parabola1, sync with upstreams` that you are following: `` merged - thanks :) `` To reply, visit the link below or just reply to this email https://pagure.io/abslibre/pull-request/98 _

Re: [Dev] libretools 20240528 release announcement

On Fri, 31 May 2024 13:07:54 -0600 Luke wrote: > You can get this in the pacman 6.1.0-3.parabola7 > /usr/share/pacman/defaults/makepkg.conf.armv7h. yes LTGM - most importantly, that same file gets installed to /etc (new librechroots or .pacnew) On Fri, 31 May 2024 13:07:54 -0600 Luke wrote: > I

Re: [Dev] libretools 20240528 release announcement

On Thu, 30 May 2024 19:42:03 -0600 Luke wrote: > Reference: abslibre.git c049cb42c (pacman: upgrade to v6.1.0, bill-auger, > 2024-03-19) yeap guiltay as charged - i did not apply it in my chroots until now though i just wanted to discuss it formally, as a well-oiled team should - its g

Re: [Dev] libretools 20240528 release announcement

On Thu, 30 May 2024 19:42:03 -0600 Luke wrote: > Fair enough, I'll push out a new pacman that has the armv7h > makepkg.conf use the ALARM version (zstd -c -T0 --ultra -20 -) plus > --single-thread. i think we want to omit `--ultra -20` - the manual says that will use more memory we do not need to

Re: [Dev] libretools 20240528 release announcement

these are the exact opts i used for armv7h: COMPRESSZST=(zstd -c -z -q --single-thread -) ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] libretools 20240528 release announcement

i think we should revert the package compression change for ARM - the latest change made zstd too hungry libre/pacman/makepkg.conf.archarm: -COMPRESSZST=(zstd -c -z -q -) +COMPRESSZST=(zstd -c -T0 --ultra -20 -) that got me into trouble with the first package i tried - util-linux failed with this

Re: [Dev] libretools 20240528 release announcement

On Wed, 29 May 2024 01:54:49 -0400 bill-auger wrote: > (careful to keep the "modular config" section o/c) on second look, i think i was supposed to delete that entire section, not modify it? - libremakepkg did not complain - this is the diff as i have it now $ diff /etc/makepkg.

Re: [Dev] libretools 20240528 release announcement

On Tue, 28 May 2024 21:26:33 -0600 Luke wrote: > - libremakepkg: The way we adjust the makepkg configuration in the > chroot should no longer result in .pacnew files when upgrading the > chroot's pacman. it did though - i just upgraded my ARM librechroot; and i had to to merge some trivi

Re: [Dev] [abslibre] PR #97: libre/iceweasel 125.0.2.parabola1

> +@@ -200,10 +200,11 @@ export class Downloader { > ... > + avoidDownload = false, > ... > const blob = new Blob([newBuffer]); ewww, such foul language - should we be concerned about this? ___ Dev mailing list Dev@lists.parabola.nu https

[Dev] [abslibre] PR #97: libre/iceweasel 125.0.2.parabola1

billauger commented on the pull-request: `libre/iceweasel 125.0.2.parabola1` that you are following: `` merged `` To reply, visit the link below or just reply to this email https://pagure.io/abslibre/pull-request/97 ___ Dev mailing list Dev@lists.para

[Dev] [abslibre] PR #97: libre/iceweasel 125.0.2.parabola1

billauger closed without merging a pull-request against the project: `abslibre` that you are following. Closed pull-request: `` libre/iceweasel 125.0.2.parabola1 `` https://pagure.io/abslibre/pull-request/97 ___ Dev mailing list Dev@lists.parabola.n

Re: [Dev] [PKG Submission] Submit fsearch

there are built packages in pcr-testing now - plz test at least the x86_64 package to ensure that it behaves correctly - then they can be moved to pcr # pacman -U https://repo.parabola.nu/pool/parabola/fsearch-0.2.3-1-x86_64.pkg.tar.zst ___ Dev mailin

Re: [Dev] Orphan Libre package [tp_smapi] marked out-of-date

'tp_smapi' is at the latest version 0.44, released Jul 31, 2023 is it not working? ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [PKG Submission] Submit fsearch

ok, i took a look at that PKGBUILD - there are several issues to address - i have made all of these changes; but as the maintainer you should be aware of them * PKGBUILDs need a `Maintainer:` line, as someone who is associated with parabola - PKGBUILDs forked from anther source (eg: the AUR) sho

[Dev] Fw: [PKG Submission] Submit fsearch

you sent this to me only; so the mailing list did not get it - when replying to mailing lists, mind that you need to press "reply-all" or "reply-list", depending on your client Begin forwarded message: Date: Sat, 30 Mar 2024 15:18:52 -0700 From: Integral To: bill-auger Sub

Re: [Dev] [dev] [arch-announce] The xz package has been backdoored

FWIW, i found out about this first from the FSF tech team - they pinged me this morning to ask me to check if parabola had a vulnerable build - the arch announcement came several hours later; though the arch maintainer had addressed the issue about 12 hours earlier the warning is only to err on th

[Dev] [dev] [arch-announce] The xz package has been backdoored

From: "Arch Linux: Recent news updates: David Runge" TL;DR: Upgrade your systems and container images **now**! As many of you may have already read [1], the upstream release tarballs for `xz` in version `5.6.0` and `5.6.1` contain malicious code which adds a

Re: [Dev] [PKG Submission] Submit fsearch

as i usually ask with new submissions for PCR, would you be willing to maintain the PKGBUILD? - that entails * to test build each new version for all arches using libretools * submit the updated PKGBUILD to parabola, describing any problems it may have, such as failing to compile for one arch *

Re: [Dev] libretools 20240221.1 release announcement

i am making a new release of libretools (v20240324), mainly for two reasons: 1) one of the changes in the previous release broke mksource https://git.parabola.nu/packages/libretools.git/commit/?id=a623a620f68ba19750fc4feba34d1d2db8cd08dc that reverted a previous change, which was made specifically

Re: [Dev] [PKGBUILD][PATCH] Updgrade ark to 24.02.0

it is done, thanks ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [UPDPKG] Update ark to 24.02.0

it is done, thanks ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [PKGBUILD][PATCH] Updgrade okular to 24.02.0

it is done, thanks BTW, you seem to be keen on these KDE things - there is one more 'konqueror' that i would like to rescue from the webengine heap - i tried to build it yesterday but the patch needs re-working, or maybe like the others this week, no longer needed - if youd like to take a stab at

Re: [Dev] [PATCH][UPDATE] Updated zcfan to 1.3.0 (latest version)

it is done, thanks ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [PATCH][UPDATE] gmid, 2.0.1

it is done, thanks ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [PATCH][UPDATE] Unifont 15.0.05

it is done, thanks ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [PATCH][UPDATE] Unifont 15.0.05

it is done, thanks ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [PKGBUILD][PATCH] Updgrade ktorrent to 24.02.0

it is done, thanks ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [PKGBUILD][PATCH] Updgrade kdevelop to 24.02.0

x86_64 is done, thanks ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Fw: [PATCH] fcitx5-chinese-addons: remove qt5-webengine from depends & change cmake args

On Sun, 25 Feb 2024 00:11:00 -0800 Integral wrote: > Yes, the download feature is also working. awesome - it is done ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Fw: [PATCH] fcitx5-chinese-addons: remove qt5-webengine from depends & change cmake args

is the download feature also working? ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Fw: [PATCH] fcitx5-chinese-addons: remove qt5-webengine from depends & change cmake args

the arch PKGBUILD explicitly disables webkit support, suggesting that webkit is supported upstream as an alternative to webengine - i tried that and it compiled i published the package to libre-testing; because i do not know how to use this program - can you test that package to verify that it wor

[Dev] Fw: [PATCH] fcitx5-chinese-addons: remove qt5-webengine from depends & change cmake args

Begin forwarded message: Date: Sat, 24 Feb 2024 22:22:42 -0800 From: Integral To: bill-auger Subject: Re: [Dev] [PATCH] fcitx5-chinese-addons: remove qt5-webengine from depends & change cmake args The original "fcitx5-chinese-addons" which is from Arch Linux has a feature to

Re: [Dev] [PATCH] fcitx5-chinese-addons: remove qt5-webengine from depends & change cmake args

you did not describe the changes or their motivation - eg: why are those changes desirable? what are the consequences? 'qt5-webengine' should not be in depends of any parabola PKGBULD now; because parabola does not have that package - is there a related bug report? _

Re: [Dev] [PACKAGING_REQUEST] freenginx-mainline

just because someone forks a project, even the lead developer, that does not itself suggest that distros should follow the fork this is the email you posted on IRC, as a rationale https://mailman.nginx.org/pipermail/nginx/2024-February/GPXQY27UA5SJJZ2Y6JWTRWJB2TKPTJR7.html > I no longer able > to

Re: [Dev] Out-of-date packages

these are both fixed now - my guess is that it was already flagged but just to be clear - "out-of-date" is not the same as "broken"; and that is usually not a reason why a package may be broken - the "out-of-date" flag is only a reminder that the package can be upgraded - if a package is broken, y

Re: [Dev] [PKGBUILD][PATCH] Flashprog

so this is the same program as 'flashrom-stable'; but with a new name? so 'flashrom-stable' should be deleted? and 'flashprog' should become the libre replacement for 'flashrom' in the blacklist? - i forgot now why we want this - i did not blacklist 'flashrom' - should it be? ive a few comments

Re: [Dev] [PATCH][PKGBUILD] Update ark to 23.08.4

thanks - it is done ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [PATCH][PKGBUILD] Packaging MLMMJ Mailing List Program

the patch in incomplete - it adds only the PKGBUILD - it is missing all of the support files: "$pkgname-$pkgver.diff" "$pkgname-$pkgver-bash.diff" 'sysuser.conf' 'tmpfile.conf' ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/

Re: [Dev] [PATCH][PKGBUILD] Packaging MLMMJ Mailing List Program

just a note > # Maintainer (Parabola): Wael Karram "(Parabola)" there does not serve a purpose - there neds to be at least one entry with Maintainer followed immediately by a colon - that that does, it shows that person as the package maintainer on the packages website - without that the package

Re: [Dev] [PATCH][UPDATE] Unifont

On Thu, 28 Dec 2023 12:50:25 -0500 bill-auger wrote: > your assumption that no > one needs them seems to be far off the mark in this case just to clarify, in this case, the mystery i would try to resolve first, is "why do the TTF fonts have drastically more votes than the OTF fon

Re: [Dev] [PATCH][UPDATE] Unifont

according to the AUR, 'ttf-unifont' is the only package from that upstream with significant interest from users (118 votes, where 'otf-unifont' has only 6 votes, and most of the others have zero votes) - also, 'ttf-unifont' was just upgraded last month, so surely it does compile - i find it hard to

[Dev] [abslibre] PR #90: libre/iceweasel: 119.0-1.parabola1

billauger closed without merging a pull-request against the project: `abslibre` that you are following. Closed pull-request: `` libre/iceweasel: 119.0-1.parabola1 `` https://pagure.io/abslibre/pull-request/90 ___ Dev mailing list Dev@lists.parabola.

[Dev] [abslibre] PR #90: libre/iceweasel: 119.0-1.parabola1

billauger commented on the pull-request: `libre/iceweasel: 119.0-1.parabola1` that you are following: `` merged `` To reply, visit the link below or just reply to this email https://pagure.io/abslibre/pull-request/90 ___ Dev mailing list Dev@lists.par

Re: [Dev] Issues with manual Iceweasel build

On Thu, 26 Oct 2023 20:18:14 -0400 bill-auger wrote: > if i had this motivation, i would get on that > thread and encourage mozilla to implement it for everyone mozilla ... and any of the thousands of other legacy programs which do not respect the FHS

Re: [Dev] Issues with manual Iceweasel build

thats just how the cookie crumbles - programs have been sourcing and creating dotfiles since long before mozilla, the FHS, $XDG_CONFIG_HOME, or the ~/.config directory - most people are not so annoyed by it - that is why programs like `ls`, GUI file managers, and other programs hide dotfiles by def

Re: [Dev] Issues with manual Iceweasel build

On Thu, 26 Oct 2023 15:10:55 +0300 Daniil wrote: > I suppose that I can try to build a package in a clean chroot and it should > help with at least some errors. But I don't think that having a package which > is so reliant on correct environment for proper build is a nice idea. I'm > going > to pu

[Dev] [abslibre] PR #89: [iceweasel] 118.0.parabola1

billauger closed without merging a pull-request against the project: `abslibre` that you are following. Closed pull-request: `` [iceweasel] 118.0.parabola1 `` https://pagure.io/abslibre/pull-request/89 ___ Dev mailing list Dev@lists.parabola.nu http

[Dev] [abslibre] PR #89: [iceweasel] 118.0.parabola1

billauger commented on the pull-request: `[iceweasel] 118.0.parabola1` that you are following: `` merged `` To reply, visit the link below or just reply to this email https://pagure.io/abslibre/pull-request/89 ___ Dev mailing list Dev@lists.parabola.n

Re: [Dev] why do we import the 'alarm' repo?

just looking for opinions, whether or not it is worth preserving, or is more trouble to filter than it is worth - archarm has no documentation; and it was never documented on the parabola wiki https://wiki.parabola.nu/Repositories i will check it against the blacklist - maybe there are some packag

[Dev] why do we import the 'alarm' repo?

does anyone known what the 'alarm' repo is for? - it is not listed in the default pacman.conf; but it is imported at first glance it appears to be board-specific tools, firmwares, and applications (eg: ffmpeg-rpi, kodi-rpi, and VLC-rpi) - probably some, many, or most of those are non-free; and pro

Re: [Dev] [REMOVAL] Quassel Client Small

On Sun, 17 Sep 2023 19:38:20 -0400 bill-auger wrote: > ok, it looks like quassel-client-small was renamed to quassel-client-qt ok so i knew that already - looks like i changed the name in 'your-freedom' back in februaryl but arch32 still has not renamed the package, so i

Re: [Dev] Orphan Pcr package [thinkfan] marked out-of-date

On Sun, 17 Sep 2023 21:26:10 -0400 bill-auger wrote: > is this program broken? ok i guess we have an answer to that question https://labs.parabola.nu/issues/3531 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Orphan Pcr package [thinkfan] marked out-of-date

> distorto wants to notify you that the following packages may be out-of-date: > > * thinkfan 1.3.1-1 [pcr] (armv7h): > https://parabolagnulinux.org/packages/pcr/armv7h/thinkfan/ > * thinkfan 1.3.1-1 [pcr] (i686): > https://parabolagnulinux.org/packages/pcr/i686/thinkfan/ > * thinkfan 1.3.1-1 [p

Re: [Dev] [REMOVAL] Quassel Client Small

ok, it looks like quassel-client-small was renamed to quassel-client-qt ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] [PKGBUILD][PATCH] kinfocenter update

thanks - just some notes for the next time you do this for most packages, it is usually not enough to bump the pkgver and checksums - even when that is all of the needed changes, it is never the time-consuming part of an upgrade we try to keep the recipes as close to the arch upstreams as possibl

Re: [Dev] Issues related to nonsystemd base and your-init-freedom packages

On Wed, 6 Sep 2023 20:49:30 +0300 Daniil wrote: > - The new version of base creates /usr/bin/init, which conflicts with > openrc-init which already owns the file. i and megver looked into this - that is true, but it is not a problem - it should not prevent anyone from upgrading - during upgrade,

Re: [Dev] Issues related to nonsystemd base and your-init-freedom packages

thanks for noticing these things your-init-freedom was published; but was not in the DB for some reason - that should be fixed now 'base' should not create any files - im not sure what your problem actually is i will look at that later ___ Dev mailing l

Re: [Dev] [UPDPKG] nonsystemd/pipewire: 1:0.3.77

david upgraded pipewire this week - can ppl plz conform that the problem is solved probably related: https://labs.parabola.nu/issues/3416 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

[Dev] [dev] budgie-desktop >= 10.7.2-6 update requires manual intervention

from arch: When upgrading from budgie-desktop 10.7.2-5 to 10.7.2-6, the package mutter43 must be replaced with magpie-wm, which currently depends on mutter. As mutter43 conflicts with mutter, manual intervention is required to complete the upgrade. First remove mutter43, then immediately perfor

Re: [Dev] Discussion about package "discover"

ok, this seems like a good solution then - so you have tried this with discover? it works properly? - i supposed you have not tried it with gnome-software? ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] Discussion about package "discover"

On Fri, 21 Jul 2023 20:39:19 + kwopleq wrote: > There were webview support and TPPM functionality in discover, but now, > hopefully it's removed (https://pagure.io/abslibre/pull-request/82). > There's still flatpak support in "discover" that might result in nonfree > packages. It could be pat

Re: [Dev] Fw: [GNU-linux-libre] third-party package managers

if license compatibility is a concern, i would suggest CC-zero, just like we did for the PKGBUILDs - that article is not a work of creativity or a specification, but a dry collection of facts that anyone could collect in other words, like the PKGBUILDs, i dont think it meets the threshold of creat

[Dev] [abslibre] PR #78: libre/parabola-appstream data without info about nonfree packages

billauger commented on the pull-request: `libre/parabola-appstream data without info about nonfree packages` that you are following: `` depends on PR #82 `` To reply, visit the link below or just reply to this email https://pagure.io/abslibre/pull-request/78

[Dev] [abslibre] PR #82: libre/discover without nonfree webview support and TPPM functionality

billauger commented on the pull-request: `libre/discover without nonfree webview support and TPPM functionality` that you are following: `` depends on PR #78 like i noted on #78, it is not obvious if we can use them, or what is their value if all they can do is install the same packages that

[Dev] [abslibre] PR #78: libre/parabola-appstream data without info about nonfree packages

billauger commented on the pull-request: `libre/parabola-appstream data without info about nonfree packages` that you are following: `` this is related to multiple open tickets on the bug tracker and an ongoing discussion on the FSDG mailing list https://labs.parabola.nu/issues/813 https://lab

[Dev] [abslibre] PR #76: libre/ktorrent without qt5-webengine

billauger merged a pull-request against the project: `abslibre` that you are following. Merged pull-request: `` libre/ktorrent without qt5-webengine `` https://pagure.io/abslibre/pull-request/76 ___ Dev mailing list Dev@lists.parabola.nu https://lis

[Dev] Fw: [GNU-linux-libre] third-party package managers

just to note that i moved the tables of evaluations and proposals to the wiki, to make it easier reference and to maintain https://wiki.parabola.nu/TPPM_Liberation_Project ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/list

Re: [Dev] [PKGBUILD][PATCH][UPDATE] Prosody Modules 0.12.3

this is what i am suggesting - note how much smaller the comment has shrunk - that is generally a good smell diff --git a/pcr/prosody-modules/PKGBUILD b/pcr/prosody-modules/PKGBUILD index e95ed62c1..29a3b983e 100644 --- a/pcr/prosody-modules/PKGBUILD +++ b/pcr/prosody-modules/PKGBUILD @@ -3,51 +3

Re: [Dev] [PKGBUILD][PATCH][UPDATE] Prosody Modules 0.12.3

On Sun, 09 Jul 2023 12:08:30 +0300 Wael wrote: > Hence, the upstream doesn't have proper releases as such and tagging cannot be > done. tagging is always possible - it takes only seconds - i would ask the upstream to do it, and i would probably reject their software if they refused per that descr

Re: [Dev] the case for terse 'pkgdesc'

it appears that "keeping an eye out on any changes in the situation" is the most important part of that explanation - in my experience, that explanation suggests to me that flashrom-stable will be very short-lived - most new software projects lose momentum or are abandoned within six months; and th

Re: [Dev] [PKGBUILD][PATCH][UPDATE] Prosody Modules 0.12.3

i also set wael as the Maintainer instead of "parabola hackers" i think we should consider it a matter of policy not to accept anything into PCR without a dedicated maintainer - the reason is that most packages in PCR got there because a very small number of users requested them, perhaps only one

Re: [Dev] [PKGBUILD][PATCH][UPDATE] Prosody Modules 0.12.3

signature is important - source=(https://repo.parabola.nu/other/${pkgname}-libre/${pkgname}-libre-${pkgver}) + source=(https://repo.parabola.nu/other/${pkgname}-libre/${pkgname}-libre-${pkgver}.tar.xz{,.sig}) + validpgpkeys+=('3954A7AB837D0EA9CFA9798925DB7D9B5A8D4B40') #

Re: [Dev] [PKGBUILD][PATCH][UPDATE] Prosody Modules 0.12.3

that comment in the PKGBUILD is confusing: > # The prosody-modules repository doesn't have tags that correspond to > # the prosody releases. So we used the commit right before June 09 > # to correspond to the prosody release. if the upstream does not tag the VCS properly, then where does pkgver='0

Re: [Dev] the case for terse 'pkgdesc'

actually i sent that to soon - there are two other things i would make issue of 'flashrom' is an arch package, so we can not modify the pkgdesc without adopting the package - i assumed that the pkgdesc of 'flashrom' in this thead was the one arch uses; but it is not so we can not use it for compar

Re: [Dev] the case for terse 'pkgdesc'

ok so there is something different about them - the remaining thing to nit-pick is that arch policy suggests the pkgdesc should not self-refer to the name of the software, and should be as terse as possible - i will make only these changes: - Flashrom is a utility which can be used to detect, + Ut

  1   2   3   4   5   6   >