Re: [arch-general] NFS "updates"?
On 29/04/20, Markus Schaaf via arch-general wrote: > Am 29.04.20 um 13:44 schrieb Andy Pieters: > > > While it is relatively trivial to compile your own kernel with those > > options enabled using Arch's build system, I think you'd better talk to the > > actual people that made the change upstream. > > > This change might have slipped through unnoticed. It seems idiotic: > _Add_ code to the kernel, to break users systems, with no benefit > whatsoever. It's clearly against Linus' agenda to not break userland. > But to tell the users to discuss this upstream is bad advice. This is a > situation where a distribution should take corrective action by > reverting this configuration. This would add value and remove some > useless code from the kernel. > > BR Might worth reaching out to linux-...@vger.kernel.org mailing list instead of Archlinux as this is upstream default behaviour. Cheers, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Re: [arch-general] NFS "updates"?
On 27/04/20, Hauke Fath wrote: > Re-reading, this is an Arch decision -- what is the rationale? Can > anybody point me to a related discussion? It's not, it just defaults to "Y", see patch in https://github.com/archlinux/linux/commit/b24ee6c64ca785739b3ef8d95fd6becaad1bde39 There's also a bit of explanation if it's useful Cheers, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Re: [arch-general] NFS "updates"?
On 27/04/20, Hauke Fath wrote: > On Mon, 27 Apr 2020 19:19:21 +0200, Hauke Fath wrote: > > I'll give some of the configuration. > > FTR, the borken system's kernel is > > Linux version 5.6.7-arch1-1 (linux@archlinux) (gcc version 9.3.0 (Arch > Linux 9.3.0-1)) #1 SMP PREEMPT Thu, 23 Apr 2020 09:13:56 + > > while the working system has > > Linux version 5.5.8-arch1-1 (linux@archlinux) (gcc version 9.2.1 > 20200130 (Arch Linux 9.2.1+20200130-2)) #1 SMP PREEMPT Fri, 06 Mar 2020 > 00:57:33 + > > Cheerio, > Hauke > Hi Hauke, It's a kernel configuration which is introduced with 5.6 kernel. In my kernel which is 5.6.7-arch1-1 $ zcat /proc/config.gz | grep NFS_DISABLE CONFIG_NFS_DISABLE_UDP_SUPPORT=y The change happened with commit https://git.archlinux.org/svntogit/packages.git/commit/trunk/config?h=packages/linux=3734fe98a51ca7e776052cdabc80be9885b7d40d Cheers, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
[arch-general] Sha256sum unexpected behaviour
Hello,
I got a weird issue with sha256sum behaviour. When creating the package
with makepkg --geninteg I get a hash and when trying to build it with
makepkg the hash fails. The interesting bit is --ptintsrcinfo comes up
with a different hash.
Anyone got some idea why this might happen?
See below some debugging info
~/linux-gc$ makepkg --geninteg
==> Retrieving sources...
-> Found linux-v5.4.10-arch1.tar.gz
-> Found config
-> Found 0001_bmq_v5.4-r1.patch
-> Found 0002_enable_additional_cpu_optimizations-20190822.tar.gz
==> Generating checksums for source files...
sha256sums=('bd51016d038277d2edd4e6d6def53b0ba24e0b238662d404a07a7d706ad2b5d3'
'aa77f7e3b611787f734c7e7d7503d3debf9af86ac999e8bccf533c5a854ec15b'
'0b770209a72171dfd46401d67d13204a767eb1749ef522df7ea7292b83046537'
'8c11086809864b5cef7d079f930bd40da8d0869c091965fa62e95de9a0fe13b5')
~/linux-gc$ makepkg --printsrcinfo
pkgbase = linux-gc
pkgdesc = Linux
pkgver = 5.4.10
pkgrel = 1
url = https://cchalpha.blogspot.co.uk/
arch = x86_64
license = GPL2
makedepends = bc
makedepends = kmod
makedepends = libelf
makedepends = xmlto
makedepends = python-sphinx
makedepends = python-sphinx_rtd_theme
makedepends = graphviz
makedepends = imagemagick
makedepends = git
options = !strip
source =
linux-v5.4.10-arch1.tar.gz::https://git.archlinux.org/linux.git/snapshot/linux-v5.4.10-arch1.tar.gz
source = config
source =
0001_bmq_v5.4-r1.patch::https://gitlab.com/alfredchen/bmq/raw/master/5.4/bmq_v5.4-r1.patch
source =
0002_enable_additional_cpu_optimizations-20190822.tar.gz::https://github.com/graysky2/kernel_gcc_patch/archive/20190822.tar.gz
validpgpkeys = ABAF11C65A2970B130ABE3C479BE3E4300411886
validpgpkeys = 647F28654894E3BD457199BE38DBBDC86092693E
validpgpkeys = 8218F88849AAC522E94CF470A5E9288C4FA415FA
sha256sums =
1fda6369ec7038c9ca1fe7aa6206977c5b8983c77e9d74e4ba458a4d042d1d31
sha256sums =
aa77f7e3b611787f734c7e7d7503d3debf9af86ac999e8bccf533c5a854ec15b
sha256sums =
0b770209a72171dfd46401d67d13204a767eb1749ef522df7ea7292b83046537
sha256sums =
8c11086809864b5cef7d079f930bd40da8d0869c091965fa62e95de9a0fe13b5
pkgname = linux-gc
pkgdesc = The Linux kernel and modules with the BMQ CPU scheduler
depends = coreutils
depends = kmod
depends = initramfs
optdepends = crda: to set the correct wireless channels of your country
optdepends = linux-firmware: firmware images needed for some devices
provides = linux-gc=5.4.10
pkgname = linux-gc-headers
pkgdesc = Headers and scripts for building modules for the Linux kernel
depends = linux-gc
provides = linux-gc-headers=5.4.10
provides = linux-headers=5.4.10
Thanks,
--
Leonidas Spyropoulos
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Re: [arch-general] NetBeans 9.0 not a drop-in replacement of 8.2
On 12/11/18, Danila Kiver via arch-general wrote:
> Agree, NB 9.0 is a complete headache and probably should not be considered
> an *upgrade* from 8.2. Even upcoming NB 10.0 does not seem to solve
> all the migration issues.
>
> Maybe Apache Netbeans (9.0 and higher) has to be distributed as a different
> package ("apache-netbeans"), conflicting with old "netbeans" package?
>
> This way would allow manual upgrade (by installing "apache-netbeans")
> from old good NB 8.0 to Apache NB when it will be good enough to replace it.
>
> Regards,
> Danila Kiver.
>
Hi Danila,
A package mainatainer should not make such decisions for the users. If
you don't like it you have the option to not update and stick to the
8.2. If you think that this could benefit others then submit a package
in AUR as suggested already. You can use the history of the package to
fetch the 8.2 version of PKBUILD [1] and push it to AUR with netbeans8
name (probably conflicts / provides netbeans).
Cheers,
Leonidas
[1]:
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/netbeans=bfdf023d7e3506227ffed92abaaa7a5e9e5d107d
--
Leonidas Spyropoulos
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Re: [arch-general] Kernel source URL change
On 01/08/18, Andrey Vihrov via arch-general wrote: > Hi, > > Recently the way kernel sources are retrieved was changed in the linux > package [1]. Now the sources are fetched from > https://github.com/archlinux/linux. > > I see a few problems with this: > > - Previously the list of applied patches was very transparent. You could > immediately see that the kernel and kernel patch tarballs come from > kernel.org, and view individual extra patches. Now the code comes from a > non-kernel source, and cannot be verified as easily. > > - Previously, if a new kernel version is released and is not yet in the > repos, you could more or less take the official linux PKGBUILD, change > one number and build it yourself. With the new layout it is not clear > how to achieve this. > > - An often cited Arch policy is to use software as released by upstream > with minimal patching. What becomes of this policy if one of the core > packages builds from a technical fork instead of upstream? > > > If the patches from kernel.org will no longer be signed, as announced in > [2], then an alternative would be git tags from [3] and [4]. It's > understandable if it may make development harder, nonetheless it would > allow for better transparency and follow upstream closer — just one > user's opinion. > > > [1] > https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux=d0c4ab0716e0ae1fc058a83ccb02bde92885ced6 > [2] https://www.kernel.org/minor-changes-to-tarball-release-format.html > [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ > [4] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git > > -- > Regards, > Andrey Also now to build the package locally you download the whole repository (~2 Gb compared to the ~110 Mb previously). What's the reasoning behind this change? Regards, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Re: [arch-general] [arch-dev-public] Switching the bugtracker to Bugzilla
- Replying on arch-general as don't have access on dev-public - I might have missed something or proposed something which is not feasible due to the fact I'm not vary familiar with Archlinux infrastructure. On 14/11/17, Jelle van der Waa wrote: > [..] > # Migration > > There are several options for migrating the bug history to Bugzilla and a few > options are under > debate. (input welcome) > > * No migration at all > * Migrate open bugs > * Migrate open bugs and auto-closing them > * Migrate all bugs > * Migrate all bugs and auto-closing them > No migration & keep flyspray as read-only. People can still reference flyspray bus and copy attachments around. It would be a good clean up for open bugs which are not-reproducable or irrelevant now. > # User migration > > User migration should be possible as well, except migrating the password, a > mass password reset > would be wise. Since I'm not sure what kind of old hashing method / salt > flyspray uses. > Yes, although this might complicate a bit if/when LDAP auth comes in place (since it will mean another migration - not sure). > # Migration Projects > > Bugzilla has a concept of products with components, so for all our packages > we can create a > component counterpart. It should be possible to auto-assign bugs with the > pkgname <-> maintainer > information from archweb. > > Possible products would be. > > # Products > > * Arch packages (core/extra or split this up) > * Community packages (community) > * Pacman > * AURWeb > * Keyring > * Archweb (new) > * Arch VM / Docker images (new) > * Release engineering > Bugzilla products / components: * Core packages * * Extra packages * same as above * Community packages * same as above * One product per "Arch Linux Projects" repo in projects.archlinux.org * AURWeb * Archweb * bbs * wiki (did I miss something here?) * Infrastructure * Arch VM * Docker * admin/maintenance * Release engineering Thanks -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Re: [arch-general] Can we please have a co-maintainer ...
On 13/10/17, Ralf Mardorf wrote: > On Fri, 13 Oct 2017 01:02:54 +0200, Rob Til Freedmen wrote: > >... for these long outdated packages? > > > >https://www.archlinux.org/packages/?sort=-last_update==schiv=Flagged > > > >https://www.archlinux.org/packages/?sort=-last_update==speps=Flagged Hello, I can adopt few if they drop to AUR (of if I get sponsor to apply for a TU). Regards, Leonidas -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Re: [arch-general] Arch Nim package
On 07/03/17, Peter Munch-Ellingsen wrote: > Hi, > the Nim package: https://www.archlinux.org/packages/community/x86_64/nim/ > was marked out of date on 2016-10-24 but it's still not edited to reflect > the new version of 0.16.2. Would anyone be so kind to adopt this package? > If not could the package be dropped to AUR? > > Peter Hello, As discussed in IRC I'd be happy to adopt this once it goes to AUR. Regards, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Re: [arch-general] [arch-dev-public] AUR ToS (aka making AUR user names public)
I was under the impression that the AUR git interface is just one big git repo. Yes it checks out only the package you clone but the references contain all packages (and commits). Am I mistaken to this? Regards, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
[arch-general] Gnome wayland + urxvt
Hello, New Gnome 3.22 which comes with wayland breaks urxvt. I'm using the .xsession to start the daemon (urxvtd) and .Xresources to configure the urxvt. What's the alternative in the new wayland world? How do you configure these now? Thanks -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
