Re: [arch-general] Sha256sum unexpected behaviour

[Tinu Weber]

On Fri, Jan 10, 2020 at 08:27:11 +, Leonidas Spyropoulos via arch-general 
wrote:
> 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

Do you redirect the --geninteg output into the PKGBUILD? If not, the
PKGBUILD is not updated, which would explain all the rest.

Alternatively, have a look at updpkgsums(8).

Best,
Tinu

Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required

[Tinu Weber]

On Wed, Oct 09, 2019 at 09:45:35 -0400, Genes Lists via arch-general wrote:
> My view - be helpful to have a list of packages no longer in base.
> 
> A list of what changed is needed so users can add whatever they deem
> appropriate (presumably a kernel is one)  to their own personal install
> package and ensure installations proceeed as usual.
> 
> So, if somone can provide a complete list of no-longer included packages
> that would be super helpfui so we can all adjust as needed.

https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/x86_64/base/

Re: [arch-general] Does Arch Linux support containers, dockers and Kubernetes?

[Tinu Weber]

On Mon, Sep 30, 2019 at 20:25:40 +0200, Christian Rebischke via arch-general 
wrote:
> What you can't do (at least I don't know anybody who successfully run a
> kubernete cluster):
> 
> * running a kubernetes cluster on Arch Linux.

Well, there is kubeadm and kubelet in the AUR, and I can confirm that
using that to build a Kubernetes cluster with only Arch machines is
certainly possible (even if only by using packages outside the Arch
repos).

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] perl update leaves glade-perl unused, but glade-perl still a dependency of qemu-launcher?

[Tinu Weber]

On Wed, Jun 12, 2019 at 08:10:19 +1200, Joel Teichroeb via arch-general wrote:
> qemu-launcher is in the AUR, so it doesn't look like it has been updated yet.

qemu-launcher probably doesn't even need an update.

David, glade-perl is an AUR package; the rebuild is your own
responsibility.

Best,
--Tinu


signature.asc
Description: PGP signature

Re: [arch-general] Installing base unattended without specific packages

[Tinu Weber]

On Thu, May 16, 2019 at 08:08:19 +0200, Ralf Mardorf via arch-general wrote:
> On Tue, 14 May 2019 23:08:35 +0200, Sefa Eyeoglu via arch-general wrote:
> >The packages linux and linux-firmware still get installed. I would
> >prefer if there would be a way to install base, but without all of the
> >irrelevant stuff for containers.
> 
> Hi,
> 
> first run
> 
> pactree -r linux-firmware
> pactree -r linux
> 
> to ensure that without doubts nothing depends on those packages.
> It unlikely does. If the packages are definitively unneeded, build empty
> dummy packages and e.g. use the year as "epoch".

If nothing depends on linux or linux-firmware, what is the point of
installing dummy packages? Dummy packages are IMHO just a very broken
and hacky way to work around unnecessary dependencies. This doesn't
appear to be the case here.

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] What is a pacman "download library error"?

[Tinu Weber]

On Sat, Mar 09, 2019 at 19:57:11 +0100, Ralf Mardorf via arch-general wrote:
> installing a package with "pacman -U URL" fails.
> Downloading with "wget -q URL" and installing the file with "pacman -U"
> works.

Unless I'm mistaken, pacman uses curl by default (unless XferCommand is
set) (or more precisely, libcurl.so), so it may be worth trying to fetch
that file with curl instead of wget (for further troubleshooting).

That being said, for me, pacman/curl downloads that file just fine, so
I'm not sure whether the choice of curl/wget is the only notable factor.

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] pacman.log has no timezone information in timestamp

[Tinu Weber]

On Sat, Mar 02, 2019 at 01:43:10 +, Juha Kankare via arch-general wrote:
> For some reason, ' $ TZ=UTC sudo pacman' and '$ sudo TZ=UTC pacman' both 
> work, but '$ alias pacman="TZ=UTC pacman"' and then '$ sudo pacman' 
> doesn't, even though (from what I know) it should be practically equal 
> to '$ sudo TZ=UTC pacman'. Not sure why, but it was worth a shot.

If you run a command with sudo, it won't expand aliases. You'd need to
define an alias for sudo itself (see alias(1p), EXAMPLES section,
example 4).

Then again, I'm not sure if defining an alias for sudo is considered
good practice. Also, for this matter, a wrapper script would be cleaner,
as it doesn't depend on which user is running it, in which environment,
in which shell, etc.

> Any other way to automate this TZ=UTC for pacman so you don't have to
> type it every time. Maybe a wrapper script aliased to "upacman" or
> something?

Something like /usr/local/bin/pacman that calls /usr/bin/pacman, for
instance (or more robustly, ../../bin/pacman relative to itself, to also
account for cases where root is a subdirectory/mountpoint) comes to
mind as a not-too-ugly workaround.

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] Participation of Arch in Google Summer of Code.

[Tinu Weber]

On Tue, Feb 19, 2019 at 10:22:34 -0500, Eli Schwartz via arch-general wrote:
> On 2/19/19 10:19 AM, Tinu Weber wrote:
> > On Tue, Feb 19, 2019 at 14:10:34 +0100, Robin Broda via arch-general wrote:
> >> remakepkg invalidates .BUILDINFO and breaks reproducible builds as far as 
> >> i can tell.
> > 
> > The semantics of .BUILDINFO in the context of remakepkg were unclear to
> > me, so I chose to simply ignore it. Reproducible builds were not taken
> > into account, so it's indeed very likely that it breaks that.
> > 
> > In the end, remakepkg is a hack. But the underlying concept itself is
> > already a hack, so I'm not feeling too bad, to be honest :-)
> > 
> > (that being said, I'm obviously open for discussing suggestions)
> 
> I see no problem and nothing to fix here. reproducible rebuilding a
> .pkg.tar.xz created by remakepkg, which has as its whole purpose,
> surgery upon a package, seems fundamentally unreproducible to me,
> moreover why would you want to reproduce it -- a reproducible rebuild of
> remakepkg packages should have as its only input, the original .pkg.tar.xz

I was thinking more of: "If I run remakepkg twice on the same package,
with the same rules, do I get the same output package?".

I just checked, and I do indeed modify the timestamp of a file when
patching it (both the file itself and its MTREE entry), and I don't
respect SOURCE_DATE_EPOCH, so I would conclude that remakepkg does not
produce reproducible .pkg.tar.xz files.

Kind Regards,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] Participation of Arch in Google Summer of Code.

[Tinu Weber]

On Tue, Feb 19, 2019 at 14:10:34 +0100, Robin Broda via arch-general wrote:
> On 2/19/19 7:20 AM, Michael Lojkovic via arch-general wrote:
> > 
> > The only thing I can think of, which applies to Arch is implementing
> > remakepkg features in pacman. I was going to add those in when I got
> > around to it, but it's also worth doing for Google Summer of Code.
> > 
> >  https://bbs.archlinux.org/viewtopic.php?id=236076
> > 

Author of remakepkg here. I think that adding such functionality to
pacman would be a bit... backwards.

The forum thread on remakepkg explains why it was originally written; I
hope it is somewhat clear why such a tool or functionality shouldn't
really exist to begin with.

> remakepkg invalidates .BUILDINFO and breaks reproducible builds as far as i 
> can tell.

The semantics of .BUILDINFO in the context of remakepkg were unclear to
me, so I chose to simply ignore it. Reproducible builds were not taken
into account, so it's indeed very likely that it breaks that.

In the end, remakepkg is a hack. But the underlying concept itself is
already a hack, so I'm not feeling too bad, to be honest :-)

(that being said, I'm obviously open for discussing suggestions)

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] circular self-dependency removing evolution-data-server

[Tinu Weber]

On Mon, Jan 07, 2019 at 10:28:04 -0500, Genes Lists via arch-general wrote:
> 
> What am I doing wrong?
> 
> # pacman -R evolution-data-server
> checking dependencies...
> error: failed to prepare transaction (could not satisfy dependencies)
> :: evolution: removing evolution-data-server breaks dependency
> 'evolution-data-server'
> :: folks: removing evolution-data-server breaks dependency
> 'evolution-data-server'
> 
> # pacman -Q pacman evolution-data-server
> pacman 5.1.2-2
> evolution-data-server 3.30.4-1

That is not a circular dependency. Pacman is telling you that evolution
and folks depend on evolution-data-server, so if it were to remove the
latter, it would break the dependency for evolution and folks.

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] Starting 9/15 new error - stat of /var/log/clamav/clamd.log failed

[Tinu Weber]

On Fri, Sep 21, 2018 at 16:48:14 -0500, David C. Rankin wrote:
> On 09/21/2018 02:17 AM, Andy Pieters wrote:
> >>   But the file is there:
> >>
> >> $ l /var/log/clamav/clamd.log
> >> -rw-r--r-- 1 clamav clamav 0 Aug 30  2015 /var/log/clamav/clamd.log
> >>
> >>
> > Could be a permissions issue. If a user cannot access /example/ then
> > it cannot see if /example/test exists and will give a no such file or
> > directory error.
> 
> Well, that what I was investigating, but the log is world readable, so that
> can't be the case -- and the only permissions needed to stat a file is read
> permission.

So *all* the parent directories (/var, /var/log, and /var/log/clamav)
are world-readable?

The permissions on /var/log/clamav/clamd.log don't really matter - it
could have permissions  ({read,writ,execut}able by nobody), and one
could still stat it correctly.

Best,
--Tinu


signature.asc
Description: PGP signature

Re: [arch-general] How to have multiple JDKs parallel?

[Tinu Weber]

On Mon, Sep 17, 2018 at 18:26:04 +0200, ProgAndy wrote:
> This might be a use case for remakepkg to remove the replaces-entry in
> the java10 packages.
>
> https://bbs.archlinux.org/viewtopic.php?pid=1771005

*sees people mentioning that tool in serious discussions*
*slightly panicks*

I see that jre10-openjdk does indeed only replace, but not conflict with
jre9-openjdk, so I guess there should be no harm in installing both (but
I have not tested it, so expect things to break):

 1. Build and install remakepkg from the AUR
 2. Write the following REPKGBUILD file:

repkg extra/jre10-openjdk
remove-replace jre9-openjdk

 3. Run `remakepkg`

Then again, this is just an alternative to just fetching Arch's
PKGBUILD file for jre10-openjdk, editing it, and building the full
package yourself.

--Tinu


signature.asc
Description: PGP signature

Re: [arch-general] systemd --user enable: Failed to connect to bus: No such file or directory

[Tinu Weber]

On Sat, Jun 30, 2018 at 13:34:11 +0200, Bjoern Franke wrote:
> > Are you truly logged in as this second user for whom it does not work,
> > or just su(1)'d, etc?
> 
> Erm, just used "sudo -u user2 -s" to login as user2. I assumed spawning
> an own zsh as user2 would do the right thing.

-s only spawns a regular shell as the user; to get a login shell, it's
`sudo -i`.

That being said, from what I've experienced, sudo on its own (be it with
-s or -i) is not sufficient to control user sessions (I don't know dbus
well enough to explain why, though). What I usually do is:

sudo machinectl --uid user2 shell .host


signature.asc
Description: PGP signature

Re: [arch-general] Upgrading mlocate: /var/lib/mlocate/ Permissions Warning.

[Tinu Weber]

On Sun, Jun 10, 2018 at 10:18:21 -0400, Eli Schwartz via arch-general wrote:
> On 06/10/2018 09:53 AM, Tinu Weber wrote:
> > On Sun, Jun 10, 2018 at 09:20:38 -0400, Eli Schwartz via arch-general wrote:
> >>On 06/10/2018 09:11 AM, Tinu Weber wrote:
> >>> I tried building mlocate myself, but I run into this error with makepkg:
> >>>
> >>> ==> Making package: mlocate 0.26.git.20170220-1 (Sun 10 Jun 2018 
> >>> 15:03:17 CEST)
> >>> ==> Checking runtime dependencies...
> >>> ==> Checking buildtime dependencies...
> >>> ==> Retrieving sources...
> >>> ==> ERROR: /home/ayekat/devel/pkgbuilds/mlocate/trunk/mlocate is not 
> >>> a clone of https://pagure.io/mlocate.git
> >>> Aborting...
> >>>
> >>> Same error with makechrootpkg. I can't find anything weird with the
> >>> mlocate PKGBUILD though.
> >>
> >> The obvious question would be... since makepkg (not makechrootpkg) told
> >> you that that directory is not a clone of that url, then what is it a
> >> clone of instead?
> > 
> > It is not a git repo at all (or rather just
> > https://git.archlinux.org/svntogit/packages.git).
> > 
> >> I'm not sure how much clearer we could make that error message. If
> >> there's something makepkg is doing dreadfully wrong in that error
> >> message reporting, please tell us so we can fix it...
> > 
> > No, the error message is clear so far, but why would that even be an
> > issue at that point? From what I've seen, for git sources, makepkg
> > fetches them into a bare repository. But in the case of mlocate, it just
> > creates `mlocate` and `mlocate/src` (empty directory), and then
> > complains and errors out.
> 
> What src directory???

Ah, I'm sorry, it's:

~/devel/pkgbuilds/mlocate/trunk/mlocate/
~/devel/pkgbuilds/mlocate/trunk/mlocate/src/

rather than:

~/devel/pkgbuilds/mlocate/trunk/mlocate/
~/devel/pkgbuilds/mlocate/trunk/mlocate/branches/
~/devel/pkgbuilds/mlocate/trunk/mlocate/config
~/devel/pkgbuilds/mlocate/trunk/mlocate/... (other bare repo things)

> Hm... oh, wait, this is probably https://bugs.archlinux.org/task/58865
>
> I'm going to take a wild guess that some component of
> /home/ayekat/devel/pkgbuilds/mlocate/trunk/mlocate is a symlink.

Oh, you're right, ~/devel/pkgbuilds is a symlink to
~/.local/var/lib/pacman/pkgbuilds. Building mlocate in the "real" path
works (or at least, it errors out a lot later due to a failing test).

I now also notice that this is actually the case for all other packages
in ~/devel/pkgbuilds that clone a git repo.

> ...
> 
> This does explain why it thinks you've got an invalid clone. It's
> considering that directory to be the already-cloned sources, *because*
> it's an existing directory which is not empty. This despite the fact
> that it's only non-empty due to a makepkg bug from 2012 which only
> recently got exposed.
>
> So instead of cloning the source, it is trying to pull the source, after
> checking git config --get remote.origin.url (which fails because it's
> not a repo, and therefore it's checking the parent repo which is
> actually an svntogit checkout).
> 
> You could work around that by using $BUILDDIR, in which case it will
> create srcdir=$BUILDDIR/mlocate/src as intended (instead of
> srcdir=$PWD/mlocate/src which is not intended)

BUILDDIR works if I give it another directory.

But `BUILDDIR="$(pwd -P)" makepkg` still fails (but to be honest, that's
more me just trying random things I don't really understand, based on
https://lists.archlinux.org/pipermail/pacman-dev/2018-June/022579.html
^^).

But either way, thanks a lot for the support! (also, sorry for sort of
hijacking the thread)

Best,
Tinu


P.S.
To confirm the original assumption: after modifying Makefile.am
accordingly, package() fails here:

...
chgrp locate 
"/home/ayekat/.local/var/lib/pacman/pkgbuilds/mlocate/trunk/pkg/mlocate/var/lib/mlocate"
 \
&& chmod g=rx,o= 
"/home/ayekat/.local/var/lib/pacman/pkgbuilds/mlocate/trunk/pkg/mlocate/var/lib/mlocate"
chgrp: invalid group: ‘locate’
make[2]: *** [Makefile:1455: install-exec-local] Error 1
...

So I second Eli's suggestion to report this upstream as a bug.


signature.asc
Description: PGP signature

Re: [arch-general] Upgrading mlocate: /var/lib/mlocate/ Permissions Warning.

[Tinu Weber]

On Sun, Jun 10, 2018 at 09:20:38 -0400, Eli Schwartz via arch-general wrote:
> It's a fancy way of doing `|| true`.

Yes, that I knew - I just thought that it would make Make stop at the
error (message) rather than continuing (although I admit one could also
just scroll back to see the error).

I only noticed the 2>/dev/null nonsense (which makes my suggestion
useless) after sending my mail and then seeing yours, where you
mentioned that issue.

> > I tried building mlocate myself, but I run into this error with makepkg:
> > 
> > ==> Making package: mlocate 0.26.git.20170220-1 (Sun 10 Jun 2018 
> > 15:03:17 CEST)
> > ==> Checking runtime dependencies...
> > ==> Checking buildtime dependencies...
> > ==> Retrieving sources...
> > ==> ERROR: /home/ayekat/devel/pkgbuilds/mlocate/trunk/mlocate is not a 
> > clone of https://pagure.io/mlocate.git
> > Aborting...
> > 
> > Same error with makechrootpkg. I can't find anything weird with the
> > mlocate PKGBUILD though.
> 
> The obvious question would be... since makepkg (not makechrootpkg) told
> you that that directory is not a clone of that url, then what is it a
> clone of instead?

It is not a git repo at all (or rather just
https://git.archlinux.org/svntogit/packages.git).

> I'm not sure how much clearer we could make that error message. If
> there's something makepkg is doing dreadfully wrong in that error
> message reporting, please tell us so we can fix it...

No, the error message is clear so far, but why would that even be an
issue at that point? From what I've seen, for git sources, makepkg
fetches them into a bare repository. But in the case of mlocate, it just
creates `mlocate` and `mlocate/src` (empty directory), and then
complains and errors out.

I assume that it builds fine on your machine, though, so I will need to
find out how my local setup differs from a more accepted Arch Linux
setup.

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] Upgrading mlocate: /var/lib/mlocate/ Permissions Warning.

[Tinu Weber]

On Sun, Jun 10, 2018 at 12:50:04 +0100, Ralph Corderoy wrote:
> Doesn't PKGBUILD explicitly ensuring `locate' is 750, `mlocate's
> filesystem value, suggest it should do similar for `mlocate' to avoid
> the mismatch?

No idea, but it's possible. Especially because -

> And I think that was correct since the package's `Makefile.am' has
> 
> dbdir = $(localstatedir)/mlocate
> ...
> install-exec-local:
>$(MKDIR_P) "$(DESTDIR)$(dbdir)"
>-chgrp $(groupname) "$(DESTDIR)$(dbdir)" 2>/dev/null \
>   →&& chmod g=rx,o= "$(DESTDIR)$(dbdir)"

What happens if you remove the leading dash from that line? I assume
either `chrgrp` or `chmod` fails at some point...

I tried building mlocate myself, but I run into this error with makepkg:

==> Making package: mlocate 0.26.git.20170220-1 (Sun 10 Jun 2018 15:03:17 
CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
==> ERROR: /home/ayekat/devel/pkgbuilds/mlocate/trunk/mlocate is not a 
clone of https://pagure.io/mlocate.git
Aborting...

Same error with makechrootpkg. I can't find anything weird with the
mlocate PKGBUILD though.

> AFAICS that file hasn't changed between git's upstream/0.26 in the
> Debian repo and mlocate-0.26-14-gc98bf65 in the current one.

It's indeed odd...

> Thus my wondering if the package is faulty for having 755.

Yeah, probably that is not intended.

> If not, then presumably a PKGBUILD function gets added to convert
> existing installations?

I'm sorry, but I don't understand that sentence.

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] Upgrading mlocate: /var/lib/mlocate/ Permissions Warning.

[Tinu Weber]

On Sun, Jun 10, 2018 at 10:51:49 +0100, Ralph Corderoy wrote:
> This morning's `pacman -Su' encountered
> 
> (10/13) upgrading mlocate   [##] 100%
> warning: directory permissions differ on /var/lib/mlocate/ filesystem: 
> 750  package: 755
> (11/13) upgrading xkeyboard-config  [##] 100%
> 
> when upgrading from version 0.26-6 to 0.26.git.20170220-1.
> Sure enough, afterwards
> 
> drwxr-x--- 2 root locate 4096 Jun 10 00:01 /var/lib/mlocate
> -rw-r- 1 root locate 16287372 Jun 10 00:01 /var/lib/mlocate/mlocate.db
> 
> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mlocate#n58
> seems to take care that /var/lib/locate is 750 on line 58, but that's
> `locate', not `mlocate', so perhaps `mlocate' needs a similar set up?

I don't quite see the relation between locate an mlocate here (other
than that they are provided by the same package and are listed next to
each other in the mtree)...

> $ zcat /var/lib/pacman/local/mlocate-0.26.git.20170220-1/mtree |
> > grep '^\./var/lib'
> ./var/lib time=1528233128.0 mode=755 type=dir
>  ✓  ./var/lib/locate time=1528233128.0 mode=750 gid=21 type=dir
>  ✗  ./var/lib/mlocate time=1528233128.0 mode=755 type=dir
> $
> $ tar tvf 
> /var/cache/pacman/pkg/mlocate-0.26.git.20170220-1-x86_64.pkg.tar.xz \
> > --warning=no-unknown-keyword var/lib
> drwxr-xr-x root/root 0 2018-06-05 22:12 var/lib/
>  ✓  drwxr-x--- root/21   0 2018-06-05 22:12 var/lib/locate/
>  ✗  drwxr-xr-x root/root 0 2018-06-05 22:12 var/lib/mlocate/
> $

The package wants /var/lib/mlocate to have 755, but the directory on
your system has 750. I assume this is because the previous version of
mlocate (0.26-6) set the permission that way:

$ zcat .MTREE | tail -n4 
  → /set gid=21 mode=750
./var/lib time=1491283536.20666 mode=755 gid=0 type=dir
./var/lib/locate time=1491283536.20666 type=dir
  → ./var/lib/mlocate time=1491283536.15666 type=dir

I assume pacman never touches permissions on existing directories,
hence the warning.

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] Aur git - missing .SRCINFO hook declined to update refs/heads/master - help?

[Tinu Weber]

On Mon, Jun 04, 2018 at 03:38:08 -0500, David C. Rankin wrote:
> All,
> 
>   I was adding a 4th Aur package, so I cloned an empty directory. Added the
> files, then
> 
> $ makepkg --printsrcinfo > .SRCINFO
> $ makepkg -S --sign -f
> $ git commit -am "console-blanking-0.0.1-2"
> 
>   Then just to make sure .SRCINFO is there
> 
> $ git ls-files
> .SRCINFO   <== It is...
> LICENSE
> PKGBUILD
> console-blanking-0.0.1-2.src.tar.gz
> console-blanking-0.0.1-2.src.tar.gz.sig
> console-blanking.service

It appears you've committed also the built package files into the repo.

While it does not match the exact error message, it might be a reason
why the AUR rejects the commit.


signature.asc
Description: PGP signature

Re: [arch-general] Why no git --depth=1 option for makepkg?

[Tinu Weber]

On Fri, Mar 02, 2018 at 22:52:47 -0900, Adam Levy via arch-general wrote:
> Additional comments about closing:  This has been rejected numerous times:
> https://wiki.archlinux.org/index.php/Use r:Apg#makepkg:_shallow_git_clones
> 
> Which provides a now dead link.

It provides a now dead link because there is a rogue space character
("Use r"). The following link works:

https://wiki.archlinux.org/index.php/User:Apg#makepkg:_shallow_git_clones


signature.asc
Description: PGP signature

Re: [arch-general] libxfont: removing fontsproto breaks dependency 'fontsproto>=2.1.3'

[Tinu Weber]

On Wed, Feb 14, 2018 at 15:32:35 -0500, Kyle wrote:
> I can see a
> whole lot of other explicitly installed packages as well as packages that
> are installed as build dependencies that would also be removed using this
> method, which is unacceptable at least on my system.

If you don't want packages to be removed by the given command, install
them explicitly.

Or better, write a meta-package that keeps them in as a dependency (so
you also know *why* they are installed, and makes system housekeeping
easier in general).

Something like:

pkgname='foobar-depends'
pkgver=2018.02.14
pkgrel=1
arch=(any)

pkgdesc='Dependencies for fooing bars from baz'

package() {
  depends=(git meson libpng12 sl)
}

This way you know that e.g. libpng12 is installed on your system because
you occasionally like to foo some bars from baz.

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] Proposal: add "--disable-modern-top" to procps-ng configure flags

[Tinu Weber]

On Sat, Dec 09, 2017 at 16:31:21 +, Jonathon Fernyhough wrote:
> If anyone is willing to help me contribute in a way that isn't viewed as
> "complaining" please point me in the right direction.

In this particular case, ask upstream (as also pointed out on the bug
tracker). Arch Linux does not patch software or deviate from its default
behaviour unless absolutely necessary (usually in case of bugs that make
an application unusable).

Also, from what I have seen, even Debian and Fedora eventually go with
upstream for these kinds of changes (at least that was the case for the
`ls` output style in coreutils >=8.25 - Debian users only recently also
got to see the super-cool new default for --quoting-style).

An personal advice from my side, as I have also been burnt by that:
Don't try to discuss Arch Linux packaging decisions. There is nothing
you can really do. The least frustrating approach is to simply package
stuff your own and fix the things that annoy you (and from what I see,
you're already doing that).

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] JOB | Permanent Database Engineer (the Netherlands or remote)

[Tinu Weber]

On Mon, Sep 04, 2017 at 10:41:06 -0400, D C via arch-general wrote:
> Tinu Weber- then you lack etiquette- you wouldn't know rude if it bit you
> in the ass.

"Lack of etiquette" as in: people who keep top-posting?

"Rude" as in: people who make random and pointless accusations of
"rudeness"?

This is getting off-topic, so I will stop feeding you. Have a nice day.

Tinu


signature.asc
Description: PGP signature

Re: [arch-general] JOB | Permanent Database Engineer (the Netherlands or remote)

[Tinu Weber]

On Mon, Sep 04, 2017 at 10:11:51 -0400, D C via arch-general wrote:
> You don't have to be such a dick about it, Florian.
> 
> On Mon, Sep 4, 2017 at 8:43 AM, Florian Pritz via arch-general <
> arch-general@archlinux.org> wrote:
> 
> > On 04.09.2017 14:33, James Tobin via arch-general wrote:
> > > Hello, I'm working with an employer that is looking to hire
> >
> > This is not a recruitment list. Please take such mails elsewhere.
> >
> > Florian

From the Arch Linux CoC [1]:

> Registering just to promote your issue/cause, FOSS-related or not,
> treats the community as a resource and is not acceptable; [...]

It's pretty clear IMHO, and pointing it out is not "being a dick".

Best,
Tinu


[1]: 
https://wiki.archlinux.org/index.php/Code_of_conduct#Spam.2FAdvertising.2FSolicitation


signature.asc
Description: PGP signature

Re: [arch-general] arch health

[Tinu Weber]

On Thu, Apr 20, 2017 at 16:10:18 +0300, Francisco Barbee via arch-general wrote:
> > IMO it's unhealthy to be in a hurry, apart from
> this seemingly not everybody needs those security
> features.
> 
> [...]
> 
> > Arch isn't ill, there seems to be no foreseeable
> risk that Arch could become ill. If somebody
> should really experience some illness, then please
> don't be vague, post a pointer to the illness.
>
> [...]
> 
> > I only claim that I don't experience illness and
> that my impression is, that Arch is distinctly
> healthy. In my experience more healthy, than any
> other distro I experience/experienced.
> 
> [...]
> 
> > Imagine everybody who wants something, Arch
> doesn't provide, would argue with being "a little
> concerned about arch's overall health", to get it
> into Arch.

Hello, this is unrelated, but it appears that your MUA or MTA screws up
the formatting of your mails, making it difficult to follow this
conversation, as I have to figure out for each line whether it's part of
a quote or not.

Also, it's hard to read, like in this example:

On Thu, Apr 20, 2017 at 13:14:08 +0300, Francisco Barbee via arch-general wrote:
> > On 20 April 2017 at 03:23:04, Ralf Mardorf wrote:
> > I would be concerned, if too many security
> features not everybody needs,
> > would become default. Why not dropping security
> features completely and
> > instead making real-time optimised features the
> default? This is a
> > rhetorical question, but actually I would prefer
> the latter.

Would you mind finding out why that is so, and try to fix that?
Thank you in advance!

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] [arch-dev-public] AUR ToS (aka making AUR user names public)

[Tinu Weber]

On Sun, Mar 05, 2017 at 18:14:02 -0700, Leonid Isaev wrote:
> Isn't Arch BBS already providing list of usernames?

The BBS's user list is only available to logged-in users. Although that
is certainly not an extended privacy measure, it still prevents random
people who just "pass by" from extracting the user list.

> In general, though, I'd say follow the principle of least effort. Why just not
> publish the list of usernames and that's all? This way, new users can easily
> grep for them and don't need scrapers, and "researchers" can have fun...

Because anonymisation: even if one dataset in isolation may look
unsuspicious from a privacy POV, if combined with other datasets, it may
suddenly reveal information that was not intended to be public.

I admit that a simple one-column list of user nick names may probably
not really be joinable with other datasets or -tables in any useful
manner, but it is still not always obvious how data can be (ab)used
(see also [1]).

I would not give out the user list. Even if there are means for
everybody to somehow obtain the data (with enough effort from their
side), it is not the same thing as simply handing it out conveniently
prepared and formatted.

Best,
Tinu


[1] 
http://archive.wired.com/politics/security/commentary/securitymatters/2007/12/securitymatters_1213


signature.asc
Description: PGP signature

Re: [arch-general] After upgrade

[Tinu Weber]

On Sun, Dec 04, 2016 at 09:29:00 +0100, Ralf Mardorf wrote:
> On Sat, 3 Dec 2016 22:22:16 +0100, Martin Kühne via arch-general wrote:
> >We're having extreme gravity fluctuations, please move your pc to the
> >floor rapidly.
>
> It was in the news today. At CERN by accident a black hole was
> produced. It expands, Switzerland already is lost, now the black hole
> eats words from emails, since it has got impact on German Internet
> nodes. If we don't stop replying, the black hole will grow by eating
> word by word and soon it will suck under the third stone from sun.

I'm in Bern, and I'm still perfectly alive.

Although, the Swiss government may have taken precautions to ensure the
survival of their people, so perhaps they transformed the country into a
giant floating ship and bailed, explaining why the news reports us as
"gone".

The air is cold and the Sun is low on the horizon. I might be on to
something... I may need to take a trip to the borders and check that.


signature.asc
Description: PGP signature

Re: [arch-general] snapcraft.io IMO gets across the message that snaps are appropriate for Arch Linux

[Tinu Weber]

On Thu, Nov 24, 2016 at 14:40:14 +0100, Ralf Mardorf wrote:
> An excerpt from
> https://lists.ubuntu.com/archives/ubuntu-users/2016-October/287739.html
>
> o...@ubuntu.com is deeply involved in working on snappy.
>  ^^
>  ^^
>
>   Date: Sun, 09 Oct 2016 14:40:32 +0200
>   Subject: Re: Question about Snaps
>   To: ubuntu-us...@lists.ubuntu.com
>   From: o...@ubuntu.com
>
>   [snip]
>
>   snaps are the future in the ubuntu ecosystem (and most likely also in
>   many others, when looking at the consortium of different distros and
>   projects that decide on their direction now in the technical oversight
>   board [1]) [snip]
>
>
>   [1] appstream, Arch, debian, elementary, KDE, Ubuntu, VLC, Fedora
>  
>  

So there is somebody out there claiming that Arch Linux, Debian, Fedora
and whoever else will replace their own packaging ecosystem by something
like that, and the sensation media is picking it up and spreading it all
over the intertubes.

So what?

All we can do is:

* Remove snapd from the repos and piss off everyone. As stated above,
  there are no technically valid reasons to do so; AL supports it, and
  it's fine.

* Make a "public statement" (who? where?) that AL does not intend to
  move to snaps in the future. If one thing is dead-sure, it's that
  Debian will not replace their sophisticated software packaging
  infrastructure by something like this, but I couldn't find anything
  resembling a statement by the Debian folks on the web, so I don't
  think the situation is that severe. Again, this would just be pissing
  off people, nothing more.

* Let them have their little moment of euphoria and see where it goes.
  Most likely nowhere. The majority of upstream devs will keep on
  writing software the way they've done so far and let the distribution
  maintainers do the rest (because that's easier for everyone).

As you may have noticed, I vote for option 3 :-)

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] snapcraft.io IMO gets across the message that snaps are appropriate for Arch Linux

[Tinu Weber]

On Thu, Nov 24, 2016 at 13:42:26 +0100, Ralf Mardorf wrote:
> On Thu, 24 Nov 2016 13:22:49 +0100, Jelle van der Waa wrote:
> >On 11/24/16 at 12:18pm, Ralf Mardorf wrote:
> >> My opinion is, that it would be better, if the Arch Linux logo
> >> would be removed from http://snapcraft.io/ , because I guess it
> >> gets across a wrong message.
> >
> >You are aware that we package snapd in [community]? [1]
> >
> >I'm not sure why ask for the logo to be removed from the website,
> >technically we support the snapd package.
> >
> >[1] https://www.archlinux.org/packages/community/x86_64/snapd/
>
> Yes, I've tested building a snap and also installed snapd. Developers
> using Arch Linux could be interested to provide their software by
> snaps and might want to have a complete environment. There's nothing
> wrong with providing it, for those who have the opinion, that it is a
> good approach. However, the message of Ubuntu's http://snapcraft.io/
> is ambiguous. To install software on Arch Linux installs, even AUR
> helpers aren't official supported,
> https://wiki.archlinux.org/index.php/AUR_helpers , so I assume that
> snaps are also not supported.

Snaps (and other applications like pip, gems, cabal, docker, ...) do
have capabilities to install additional data to the system. But they do
not interfere with pacman's package/software infrastructure like AUR
helpers and pacman wrappers do.

I don't like the idea behind this "universal package manager" approach
either, but from a strictly technical point of view, it is no different
than any of aforementioned tools. What they install may not be supported
by the community/maintainers, but the tools themselves are.

My 5 pedantic cents.

> Again, if others don't share my opinion it's ok, no need to discuss
> it, now I only try to clarify my point of view.
>
> Regards,
> Ralf

Best,
Tinu


signature.asc
Description: PGP signature

Re: [arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?

[Tinu Weber]

On Sat, Nov 19, 2016 at 08:31:22 +0900, Ken OKABE via arch-general wrote:
> > The kernel is a different, as it can cause an unbootable situation.
>
> [...]
>
> On what reason or scenario, some LTS(maybe incompatible to the kernel)
> will break kernel or make the system unbootable?

Ideally never. The unbootable situation may be caused by the *kernel
itself*. I admit I'm a little amused about my forum post sparking a ML
discussion, but to quote another post on that same thread (by Jason):
https://en.wikipedia.org/wiki/Straw_man

Best,
Tinu a.k.a. ayekat


signature.asc
Description: PGP signature

Re: [arch-general] Implement sql/sqlite database for pacman local database

[Tinu Weber]

On Fri, Oct 21, 2016 at 17:20:53 +, Alive 4ever wrote:
> [...] It seems that the local pacman databases are just subdirectories
> with text files (desc, files) and gzipped text (mtree).
> No wonder why local pacman databases tend to slow down over time and
> need to be optimized periodically.
This is a little contradictory: if it is just directories with text
files (plain or compressed), how does it need "periodical optimisation"?
What is optimised? And how?

> This would provide faster access for local database as sql databases
> are optimized for fast access.
This just adds complexity, and for what? Marginal performance gain (if
at all? honestly, `pacman -Q` runs almost instantly here).

Best,
Tinu/ayekat


signature.asc
Description: PGP signature

Re: [arch-general] Arch GNU/Linux install for beginners and new users

[Tinu Weber]

On Thu, Sep 22, 2016 at 18:10:43 -0400, Francis Gerund via arch-general wrote:
> Freedom of speech means being able to say whatever you want to say,
> without interference from self-appointed sidewalk supervisors or other
> members of the Peanut Gallery.

The linked comic points out exactly *that*: "Free speech" only means you
can't be legally punished for saying/writing something - but it doesn't
mean that a community must accept it if they consider it stupid.

Furthermore, Jason isn't "self-appointed", so
https://wiki.archlinux.org/index.php/Code_of_conduct#Respect_the_staff

Re: [arch-general] Arch GNU/Linux install for beginners and new users

[Tinu Weber]

On Thu, Sep 22, 2016 at 17:22:57 -0400, Francis Gerund via arch-general wrote:
> > There have been some pretty specious comparisons in this thread, but
> > having the gall to mention slavery in the context of an online
> > community for a computer operating system would have to rank as one
> > of the most offensive and moronic, not just for this thread, or this
> > ML but for the community.
> >
> > Don't post anything like this again. It is not welcome.
> >
> > /J
> >
> > --
> >
> > http://jasonwryan.com/
> > GPG: 7817 E3FF 578E EEE1 9F64 D40C 445E 52EA B1BD 4E40
> >
> >
>
> Dear, sweet Jason,
>
> Thank you for your interest.
>
> But telling someone else what to post or not to post (not to mention
> sophomoric name-calling), might be considered impropriety at the very
> least.
>
> I ask that you please refrain from posting anything like this again.
> It might not be considered welcome.
>
> With warmest regards,
> y'r obd't srvt., F.G.

https://xkcd.com/1357/

Re: [arch-general] What happened to the Beginner's Guide?

[Tinu Weber]

On Thu, Sep 22, 2016 at 09:46:30 +0200, Alessio 'Blaster' Biancalana wrote:
> While I agree with the guys saying the Beginner's Guide was harmful to the
> distro making lazy noobish users choose the wrong distribution for 'em, I
> strongly think that the Guide was pretty helpful as a quick setup checklist
> to seniors too.

Honestly, the Installation Guide does a tremendously better job at
acting as a "checklist" than the old Beginners' Guide, which was filled
with lots of additional noise concerning (arbitrarly chosen) special
cases.

Just take a look at that beautifully concise "Contents" table on
https://wiki.archlinux.org/index.php/Installation_guide.
That's one perfect checklist :-)

More seriousyl, I think it's a healthy approach to first give an
overview of what is required for the installation, and then let the
user/newcomer search the information in the wiki on their own (rather
than giving them one big chunk where they miss the forest for the
trees).


signature.asc
Description: PGP signature

Re: [arch-general] Opinions on PowerShell?

[Tinu Weber]

On Fri, Aug 19, 2016 at 11:39:11 +0200, Jeroen Mathon via arch-general wrote:
> Using powershell as your default shell will be a total disaster.
>
> A lot of standard scripts will not function correctly.

Scripts are supposed to have a shebang, so I don't exactly get your
problem.

People are also using fish, whose syntax is quite a bit different, and
they don't seem to have any issues either (apart from the locale part,
but that's something different).


signature.asc
Description: PGP signature

Re: [arch-general] recent archlinux installation

[Tinu Weber]

On Sun, Jul 17, 2016 at 11:36:27 -0700, jordan via arch-general wrote:
> Jesus fuck. I unsubscribed why am I still getting these God damn emails? If
> I keep getting spammed, I'm going to spam back

If only you had *read* that spam:

https://lists.archlinux.org/pipermail/arch-general/2016-July/041558.html
https://lists.archlinux.org/pipermail/arch-general/2016-July/041561.html

Re: [arch-general] What is aclocal?

[Tinu Weber]

On Wed, Apr 20, 2016 at 09:31:37 +0200, Gerhard Kugler wrote:
> "[...] error while loading shared libraries: libncursesw.so.5: [...]"

> ncurses is existing here of course

In addition to Antonio's response, the `ncurses` package does not
provide libncursesw.so.5. You should instead look for the AUR package
`ncurses5-compat-libs`. Also, if urlview depends on ncurses5, the
package should state so (and you might probably want to notify the
maintainer).


signature.asc
Description: PGP signature

Re: [arch-general] wireless driver broadcom b43 random success or failure

[Tinu Weber]

On Sun, Apr 10, 2016 at 11:50:44 -0500, Doug Newgard wrote:
> On Sun, 10 Apr 2016 18:44:07 +0200
> Dieter Wirz  wrote:
>
> > sudo echo b43 >> /etc/modules
>
> First, don't top post.
>
> Second, what is /etc/modules?

Third, the >> redirection happens as a regular user, regardless the
`sudo`, so the command wouldn't work (even if /etc/modules existed).

You should use `tee` instead.


signature.asc
Description: PGP signature

Re: [arch-general] Sysctl.d configuration ignored (possible pebkac)

[Tinu Weber]

On Fri, Apr 01, 2016 at 11:03:33 +0200, Garmine 42 wrote:
> I have this file:
> -rw-r--r-- 1 root root 17 Mar 23 02:05 /etc/sysctl.d/10-sysrq.conf
> 
> With this content:
> kernel.sysrq = 1
> 
> Yet any time I log in the `kernel.sysrq = 16` parameter from
> /usr/lib/sysctl.d/50-default.conf overrides the one I defined above.

According to the sysctl.d(5) manpage, the files are processed in
lexicographic order, so the variable assignment in `10-...` gets
overwritten by the variable assignment in `50-...`.

You should probably set a number prefix that is at least 50 (I usually
go into the 90s with my own files), e.g. `/etc/sysctl.d/90-sysrq.conf`.


signature.asc
Description: PGP signature

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

[Tinu Weber]

On Wed, Nov 11, 2015 at 09:35:05 +, Ben Oliver wrote:
> On 11 November 2015 at 09:18, Ludwig Zins  wrote:
> 
> > On 11/11/15 09:47, Bennett Piater wrote:
> > > Hello!
> > > I installed Arch on my new Thinkpad T450s over the weekend.
> > > Everything works well, but I have a question:
> > >
> > > I use systemd-networkd to manage my network interfaces and netctl for
> > > the connections. I set everything up according to (this)[0] and
> > > (this)[1] to get automatic activation of wifi via netctl-auto and
> > > netctl-ifplugd.
> > >
> > > My question is as follows: I use i3wm, and i3status shows *both*
> > > ethernet and wifi as connected if I plug in the cable while having a
> > > wifi connection. What does this mean exactly, and how is my traffic
> > routed?
> > >
> > > Thanks in advance for clearing that up.
> > >
> > > Cheers,
> > > Bennett
> > >
> > > [0]:
> > >
> > https://wiki.archlinux.org/index.php/Systemd-networkd#Wired_and_wireless_adapters_on_the_same_machine
> > >
> > > [1]:
> > >
> > https://wiki.archlinux.org/index.php/Netctl#Automatic_switching_of_profiles
> > >
> > > --
> > > GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
> > >

I don't use netctl, but you can usually see what default route it uses with

ip route

I have made the experience that newly configured interfaces "steal" the
default route (although this can usually be configured - again, I don't
use netctl).

I can imagine the default route passing through the WiFi interface in
your scenario.

~Tinu


signature.asc
Description: PGP signature

Re: [arch-general] systemd-networkd and netctl with multiple interfaces

[Tinu Weber]

On Wed, Nov 11, 2015 at 16:06:18 +0100, Bennett Piater wrote:
> They have different metrics as per the example from the wiki.
> 
> However, no wiki article or manpage that I encountered explained what
> exactly the metric does. Could you explain that to me?
> 
> Cheers,
> Bennett
> 
> > If there are multiple default routes with the same metric, this might
> > cause issues, as packets might be sent randomly through one of the two
> > interfaces (thus with different IP addresses), leading to packet drops.
> > 
> > If the metric value is different, this shouldn't be a problem, though.

The idea is that if none of the routes match the destination, the
default route is used. If there multiple of them... well, nobody can
tell you what happens.

Usually the kernel chooses the route with the lower metric (to "break
the tie"), but I cannot tell you exactly what it signifies.

I'd suggest to try to find out why netctl makes it possible to have
multiple default routes (however, as I don't use netctl, I'm not able to
answer this), as this is usually a bad idea.

By the way, I'll redirect this discussion back to the mailing list,
maybe someone can answer this.

Best,
Tinu


signature.asc
Description: PGP signature