Re: [arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk

[Giancarlo Razzolini via arch-general]

Em dezembro 22, 2020 13:33 Emil Velikov escreveu:

Is there any interest in the bugs opened, or the gvt regression is a
must for those to move forward?
My systems lack gvt support (nor do I have Windows license) to
reproduce the bug(s), yet I'm willing to help to get this moving.



Yes. I haven't got time to proper look at them, but I will. I'm not using 
bumblebee atm as well.

Regards,
Giancarlo Razzolini

pgp2_ApyB5E0g.pgp
Description: PGP signature

Re: [arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk

[Giancarlo Razzolini via arch-general]

Em dezembro 7, 2020 14:24 Emil Velikov escreveu:


Doing GL (primus+bumblebee) as a start, trimmed only to the bare
minimum changes:
https://bugs.archlinux.org/task/68882
https://bugs.archlinux.org/task/68883



Thanks.


Do you have details or a bug report about these? I haven't used intel
gvt-g and on the occasion of skimming through the code - quality was
below i915.



There is a nasty bug where nvidia prime render offload causes the VM to simply 
segfault [0].
But intel gvt-g is better than using virgl for 3D stuff on a VM.

Regards,
Giancarlo Razzolini

[0] https://github.com/intel/gvt-linux/issues/162

pgp1FXwOcDdVx.pgp
Description: PGP signature

Re: [arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk

[Giancarlo Razzolini via arch-general]

Em dezembro 4, 2020 10:04 Emil Velikov escreveu:

On Fri, 4 Dec 2020 at 12:50, Giancarlo Razzolini
 wrote:


Em dezembro 4, 2020 9:27 Emil Velikov via arch-general escreveu:
> I would love to hear the input from the respective maintainers and the
> overall Arch developer base as a whole.
>

As the maintainer for both bumblebee and prime-run, I don't see the need for 
deprecation, yet.
Bumblebee still has some uses and also, the it has the appeal of keeping the 
card completely powered
off, something that doesn't happen with prime render offload.


Thanks for maintaining these Giancarlo.

The power management side of Bumblebee will be untouched - my email
explicitly covers only the file side of things.

I've seen far too many reports of people using primus, on top of GLVND
enabled nvidia/mesa causing all sorts of problems. Since tracking
individual reports does not scale - I've put this proposal.

Note: having a compat primusrun/optirun/pvkrun makes sense - setting
the respective environment variables is annoying.

-Emil



Put your proposal changes and reasoning on flyspray tickets for each package 
and I'll take a look.
I'm not sure all the changes are needed. And, it turns out that, due to some 
limitations/issues
related to intel gvt-g and nvidia with prime render offload, I'm using 
bumblebee currently.

Only issue I had recently was the xorg autodetection issue that they reverted, 
other than that, it
works fine here.

Regards,
Giancarlo Razzolini

pgpE4IxU3PPan.pgp
Description: PGP signature

Re: [arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk

[Giancarlo Razzolini via arch-general]

Em dezembro 4, 2020 9:27 Emil Velikov via arch-general escreveu:

I would love to hear the input from the respective maintainers and the
overall Arch developer base as a whole.



As the maintainer for both bumblebee and prime-run, I don't see the need for 
deprecation, yet.
Bumblebee still has some uses and also, the it has the appeal of keeping the 
card completely powered
off, something that doesn't happen with prime render offload.

Having said that, I do think bumblebee/primus/primus_vk days are numbered.

Regards,
Giancarlo Razzolini

pgpYQ_QXLRvfi.pgp
Description: PGP signature

Re: [arch-general] GNU Guix

[Giancarlo Razzolini via arch-general]

Em setembro 29, 2020 9:19 Bjoern Franke via arch-general escreveu:

Am 29.09.20 um 13:18 schrieb Robin Martijn:
To all readers: as you could've guessed, this is not about GNU Guix. 
Also, it is not safe for work.




May somebody block him?



Already done.

pgpXTd2NtRxXX.pgp
Description: PGP signature

Re: [arch-general] HP Laserjet plus 1020 Problem

[Giancarlo Razzolini via arch-general]

Em agosto 20, 2020 2:28 das escreveu:

On Wed, Aug 19, 2020 at 9:25 PM Giancarlo Razzolini
 wrote:



I believe your printer works without hplip and using the driverless
option. That's something you can also try.


I tried it your way too. I removed hplip. It seemed plausible too.
When the printer was not working in Arch Linux I booted into Debian
and without installing hplip I tried printing. And it worked.

But removing hplip did not help either.




I didn't tell you to remove hplip. Driverless and driver can co-exist
just fine. I have on my machine right now, both a driverless printer
registered to my cups and a version of the same printer using hplip.

I've searched yesterday your printer and it seems it does supports
driverless. Also, some HP printers, if you want to use them on cable,
you have to change an option on EWS, otherwise it won't work.

Regards,
Giancarlo Razzolini

pgp5NjcY7lwXd.pgp
Description: PGP signature

Re: [arch-general] No login after update

[Giancarlo Razzolini via arch-general]

Em agosto 19, 2020 17:04 Yaro Kasear escreveu:


Yes there is. The defaults are literally what's in the config file in
the archive and not on the filesystem. How would that not be a way to
determine default settings?

I'm not suggesting the package manager would have to understand the
settings, but it would be able to tell if the contents of that file are
different from another version. (Which it obviously does already,
otherwise it wouldn't know to make a pacnew file.)

I can't imagine it'd be that difficult for pacman to compare checksums
between files in /etc or /boot between versions of a package (If a
previous version is available.) and what's on /etc and determine if it
really needs to bother putting a pacnew file on the filesystem that
doesn't need to be there. It's already doing some sort of check between
what's in the package and what's on the filesystem already.



How is everything you just said, different than what pacman already does?
How would it determine not to create a .pacnew? If you can answer both these
questions, I'd encourage you to send patches to pacman. Because I couldn't
understand how what you said is any different than the current pacnew logic.

Regards,
Giancarlo Razzolini


pgp4gjuokAph0.pgp
Description: PGP signature

Re: [arch-general] No login after update

[Giancarlo Razzolini via arch-general]

Em agosto 19, 2020 16:37 Yaro Kasear escreveu:


I've always questioned the wisdom of dropping a .pacnew just when the
file is different from the default. There's really no reason for it
considering any changes you made were deliberate and presumably thought
out. The end result is pacman cluttering /etc with a default
configuration file whose only reason for existing is to, if it's used,
clear settings. Why?



The .pacnew is there to indicate that something new exists, or that you changed
something. Most of the time you can remove .pacnew files, but not always. Also,
it's only "cluttering" /etc (and /boot, btw), if you don't handle them.


What pacman SHOULD do is compare /etc files between package versions and
see if there's a change BETWEEN DEFAULTS. *Then* there's an actual
reason to need a new default config file for the user to examine because
then there's an actual indicator some meaningful change in default
configuration or how the package handles configs happened.



That's way beyond the scope of a package manager, and also, there's no way
to tell what "DEFAULTS" (why caps?) should be.


All most pacnew files wind up doing is sitting there for thirty seconds
before being deleted without anyone even opening them because they're
literally just what the file was before the user ALREADY changed it
before... because it's utterly useless to get a default config file when
you've intentionally changed it and there's nothing in the new version
of the package that calls for an examination of the defaults.



I don't know why you said that .pacnew sits for thirty seconds before being
deleted. Are you using a hook that does this? Because nothing handles them
automatically, that's the user's job. There are tools to aid in doing that,
but in the end the user should know what to apply, and what to discard.

Regards,
Giancarlo Razzolini

pgp_77edb9oPm.pgp
Description: PGP signature

Re: [arch-general] No login after update

[Giancarlo Razzolini via arch-general]

Em agosto 19, 2020 16:02 Manuel Reimer escreveu:

Hello,

Some minutes ago I did a regular system update and after that decided to 
reboot. After reboot I was unable to log into my system. After fiddling 
a bit I rebooted to an Arch boot stick to find the following message in 
pacman.log:


[2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login 
installed as

/etc/pam.d/system-login.pacnew



The .pacnew should've been handled *before* rebooting.

As this seemed to be a candidate that may cause login problems, I 
deleted "system-login" and moved the ".pacnew" into place.


After reboot I'm now able to log in again...

IMHO something like this should not happen...

Maybe it's worth a note on the Arch homepage that it is important to 
move this pacnew into place before reboot?




This only affected you and whomever else changed system-login. It's not news
material. Also, if you're messing with PAM, you should be responsible for 
applying
the new stuff, otherwise it'll break, like it did for you.

Regards,
Giancarlo Razzolini

pgpmtnk7IM_k3.pgp
Description: PGP signature

Re: [arch-general] HP Laserjet plus 1020 Problem

[Giancarlo Razzolini via arch-general]

Em agosto 19, 2020 12:17 das via arch-general escreveu:

Dear Friend

I installed the AUR package hplip-plugin.

But still it is not working. No page can be printed. It is getting
detected. And then no print. If it did not work in Debian Surge, I
would have thought there is a problem in the printer.

Can you suggest anything else?




I believe your printer works without hplip and using the driverless
option. That's something you can also try.

Regards,
Giancarlo Razzolini

pgpAaV47cZoSk.pgp
Description: PGP signature

Re: [arch-general] Telinit?

[Giancarlo Razzolini via arch-general]

Em agosto 17, 2020 13:08 David Rosenstrauch escreveu:
???  I always shut down all running daemons when I'm about to update my 
system - seems like standard operating procedure to me:  1) I'd expect 
that it would be completely unpredictable what would happen if you 
updated/replaced an application's files while it was running, 2) there's 
often config file changes that occur; again, I don't want to try to 
update or resolve those while an application is running.




It's not necessary to do so in most cases, but, you might be interested in 
checkservices [0].
We use it when we update Arch servers, but we don't bring the system to rescue 
because, you know,
that would interrupt all the services. And almost all of them (all?), can run 
just fine until they
are restarted. So, my suggestion to you is, run pacman, and optionally run 
checkservices afterwards,
to restart things that might be needed, if you want. No need to put the system 
in rescue mode.

Regards,
Giancarlo Razzolini

[0] https://github.com/archlinux/contrib/blob/master/admin/checkservices

pgpHbUxGhNrAG.pgp
Description: PGP signature

Re: [arch-general] Telinit?

[Giancarlo Razzolini via arch-general]

Em agosto 17, 2020 12:56 David Rosenstrauch escreveu:



Hmmm ... OK.  I wasn't aware that telinit was now being considered 
legacy/deprecated.  I've habitually used it for years to drop to single 
user mode, which I do every time before I perform a system update with 
pacman.  I guess I'll have to find some other command to do the same 
using systemd.  (I think they call it rescue mode, rather than single 
user mode.)


Thanks,



systemctl rescue

But this begs the question, why are you doing this before running pacman?

Regards,
Giancarlo Razzolini

pgp58HiUaCd7S.pgp
Description: PGP signature

[arch-general] R: openvpn-client@ takes long time to start

[Giancarlo Razzolini via arch-general]

Em agosto 14, 2020 9:57 Riccardo Paolo Bestetti escreveu:


The output from OpenVPN indicates that the client is started within the first 
few seconds from when I give the `systemctl start openvpn-client@whatever` 
command (see previous email). The tun interface is created, opened, the routes 
are received and added to the routing table. All the usual stuff. Of course, I 
can also reach remote hosts through the VPN after that.

The exact same thing (& output) happens if I try to start OpenVPN manually from 
the command line. Minus, of course, the two-minutes wait before the command returns.



Again, use the openvpn log capabilities. I'd recommend a verbose of at least 3, 
for starters.



I also forgot to specify it also happens when the system has been up for hours. 
It really can't be that the network is not ready.



Are you using --daemon on your openvpn config file?


I don't think there's anything much that could be disturbing it. I'm using 
systemd-networkd for everything + iwd for wireless.



Well, you can paste your configuration (minus keys and user/auth).

Regards,
Giancarlo Razzolini

pgpO5qaX1fB9h.pgp
Description: PGP signature

Re: [arch-general] openvpn-client@ takes long time to start

[Giancarlo Razzolini via arch-general]

Em agosto 14, 2020 3:58 Riccardo Paolo Bestetti via arch-general escreveu:

After a reboot, the first openvpn-client@ instance I try to start takes almost 
exactly two minutes to start. The instances before that one start just fine in 
a few seconds.



Guess you meant: "The instances *after* ..."


When that happens, I can see from journalctl that the client actually starts in 
the first few seconds after the systemctl command. But then, the command 
doesn't terminate for two more minutes (with no further journal entries).



Openvpn has quite good logging capabilities that you can put to use here.


Has anyone seen this before? What could it be?



Without knowing more, my first guess is that you still don't have connectivity 
when that first openvpn client starts.
2 minutes matches exactly the 120 seconds default ping-restart parameter. So, 
what happens is, the client starts, you have
no connectivity then, after two minutes, ping-restart kicks in, and your 
connection gets through.

So, get a network manager that can properly trigger network-online.target. Or, 
if your network manager is triggering it, then
it means your network is not quite ready when it does.

Regards,
Giancarlo Razzolini

pgpcTqzO7iz2h.pgp
Description: PGP signature

Re: [arch-general] mkinitcpio hook for custom root decryption with systemd boot

[Giancarlo Razzolini via arch-general]

Em julho 23, 2020 7:09 Riccardo Paolo Bestetti via arch-general escreveu:


I would like to change my current crypto setup in a way that would require more 
step to unlock the root than just typing in a passphares. For this reason, 
sd-encrypt clearly cannot serve my use case.



What step would that be? And how it would be secure?


For this reason, I would like to write a custom hook to mount the root volume. 
Now, systemd boot doesn't have a concept of runtime hooks. Thus, I need to make 
a systemd unit that gets pulled in by cryptsetup.target in the place of 
systemd-cryptsetup@.service. (Basically, I need to replace the whole 
systemd-cryptsetup-generator and systemd-cryptsetup logic.)



It doesn't need to be in place of, you can simply have a unit that runs either 
before or after systemd-cryptsetup@. Or you can even override 
systemd-cryptsetup to require your unit.
There are several options.


However, I really have no idea on how to achieve this. Should I write a custom 
mkinitcpio hook which completely bypasses sd-crypt/cryptsetup.target and 
instead starts a different unit with my own decryption logic? Or is there a way 
to hook into cryptsetup.target and instruct it to pull in my logic instead of 
systemd-cryptsetup*?



If you write a unit file and a script, they can probably be added to the FILES 
section and that would be it. Main issue is the enabling of the unit, so, for 
that, you would probably need a custom install hook.


Of course, the other possibility is to just stop using a systemd boot and 
instead setting up a busybox early userspace. Then it's just a matter of 
writing a shell script. However, since I'm already using systemd for everything 
- from the bootloader to userspace - I don't think it makes much sense to do 
that.



If you use the base hook, you already have busybox on the initramfs.

Regards,
Giancarlo Razzolini

pgp4m4MnBHwAJ.pgp
Description: PGP signature

Re: [arch-general] package pages link to github (which is partly broken)

[Giancarlo Razzolini via arch-general]

Em julho 22, 2020 14:31 LuKaRo escreveu:


On 7/22/20 7:18 PM, Giancarlo Razzolini via arch-general wrote:
Also, github is being used as mirror for most Arch Linux projects, but 
they are

being moved to a hosted gitlab instance, at gitlab.archlinux.org.

Thanks for clarifying :) Does that mean that gitlab.archlinux.org is 
meant to replace git.archlinux.org in the long run, and GitHub will be 
just a mirror?


LuKaRo



Yes, although, things are still not fully defined for everthing. I would say,
however, that anything under https://gitlab.archlinux.org/archlinux can be 
considered
the de facto upstream for those projects as of now.

It doesn't mean that mirroring always will be done, or that in some instances 
that the
mirroring won't be done in the opposite direction (ie, from gitlab to github). 
Things are
still evolving.

Regards,
Giancarlo Razzolini

pgpNDIfbKF9Hl.pgp
Description: PGP signature

Re: [arch-general] package pages link to github (which is partly broken)

[Giancarlo Razzolini via arch-general]

Em julho 22, 2020 14:15 LuKaRo escreveu:

On 7/22/20 1:55 PM, Marcus Hoffmann via arch-general wrote:

Hi,

I just noticed the package pages linking to github, instead of
https://git.archlinux.org/.
Is there a reason for that change? I remember a few weeks ago these 
links still pointed to git.archlinux.org, which I prefer over GitHub 
since it has been acquired by Microsoft.




The reason being that git.archlinux.org is being decommissioned at some point
in the future. As of now, the repositories on git.archlinux.org are still being
synced, but I expect that not to be the case soon.

Also, github is being used as mirror for most Arch Linux projects, but they are
being moved to a hosted gitlab instance, at gitlab.archlinux.org.

Regards,
Giancarlo Razzolini

pgpZ9p9ceAuLJ.pgp
Description: PGP signature

Re: [arch-general] package pages link to github (which is partly broken)

[Giancarlo Razzolini via arch-general]

Em julho 22, 2020 8:55 Marcus Hoffmann via arch-general escreveu:

Hi,

I just noticed the package pages linking to github, instead of
https://git.archlinux.org/.

So far, trying to view the commit history for any community package just
resulted in a page with the message:


Sorry, this commit history is taking too long to generate


See, i.e. here:
https://github.com/archlinux/svntogit-community/commits/master/element.io/trunk


I can find the package I'm interested in manually in
https://git.archlinux.org/svntogit/community.git/ but is there a better
solution for this planned somehow?

Marcus



Try using 
https://github.com/archlinux/svntogit-community/commits/packages/element.io/trunk

Regards,
Giancarlo Razzolini

pgpHo8JRVzuZ9.pgp
Description: PGP signature

Re: [arch-general] Multi-threaded mkinitpcio

[Giancarlo Razzolini via arch-general]

Em abril 4, 2020 12:13 Jelle van der Waa escreveu:


multi-threaded compression does not create a predictable reproducible
archive (for xz/zstd).



Zstd is multi-thread safe, as far as I know, xz is not. But the kernel does
not support zstd.



Sure, has nothing to do with reproducibility however.



It has, because lzop is the only algorithm that produces unreproducible builds
due to them adding their own timestamp, which there's no flag to remove. Of 
course
lzop will be faster than xz, but mkinitcpio's default is gz, which should be 
comparable,
at least in speed, with lzop.

Regards,
Giancarlo Razzolini

pgpW22pQ7tQDH.pgp
Description: PGP signature

Re: [arch-general] Multi-threaded mkinitpcio

[Giancarlo Razzolini via arch-general]

Em abril 3, 2020 9:28 Amin Vakil escreveu:

time and saving space. Also I'm planning to read wiki on how to safely
disable fallback. I'm using LVM on LUKS method and I suppose fallback
image cannot boot my Arch, so it doesn't help in case of an accident.



The fallback image does help. But if you keep an arch iso usb stick around,
and make sure you update it every few months, you can disable the fallback.

Regards,
Giancarlo Razzolini

pgp3GDTKQDSKW.pgp
Description: PGP signature

Re: [arch-general] Multi-threaded mkinitpcio

[Giancarlo Razzolini via arch-general]

Em abril 3, 2020 3:17 Pascal via arch-general escreveu:

hi,

change the COMPRESSION variable to lz4 ou lzop in your /etc/mkinitcpio.conf
: it will considerably reduce the compression time.



And break reproducibility. Also, I wouldn't say considerably. Might be faster,
but not leaps and bounds faster.

Regards,
Giancarlo Razzolini


pgpvxCf7l2Bta.pgp
Description: PGP signature

Re: [arch-general] Multi-threaded mkinitpcio

[Giancarlo Razzolini via arch-general]

Em abril 2, 2020 22:28 Amin Vakil escreveu:

So every update of linux kernels and modules which need mkinitpcio to be
executed, takes too much unnecessary time (maybe 2 min) which could be
handled if it executes on multi threads of CPU.



Which compression algorithm are you using?


Actually this 2 minutes bothers me this much that I'm emailing Arch
General Mailing List is because I'm afraid my Arch would be broken if my
laptop shuts down in this process and I have to rescue it by live USB.



As it's true for pretty much all update process for pretty much every OS
in the world, things can break if the update is interrupted.



So my question is why it doesn't execute over all threads or at least
have the option to do that?



mkinitcpio is a bunch of scripts copying files to a temporary dir and then
compressing the result afterwards. I bet most of this time you're seeing is
on compression's fault, not mkinicpio itself.


Does it help if it gets executed over multi threads or the bottleneck is
somewhere else?



Depending on the compression algorithm, reproducibility might not work if
it's using multiple threads. Also, I see multiple issues that could happen
if the build hooks ran out of order.

Regards,
Giancarlo Razzolini

pgpPId6xm3A5S.pgp
Description: PGP signature

Re: [arch-general] nvidia-dkms pkgrel increase after every linux upgrade

[Giancarlo Razzolini via arch-general]

Em março 31, 2020 14:03 Eli Schwartz via arch-general escreveu:


See the broadcom-wl PKGBUILD for how to avoid this. Also note the
wireguard-{arch,lts} packages have adopted this method.

It's up to Sven-Hendrik Haase if he wants to do this, though.



Well, the best way to avoid this is a complete separate package. But also 
increases
the burden on the maintainer. So, it's up to Sven to do this, but I don't think 
it's
strictly necessary.

Regards,
Giancarlo Razzolini

pgpGpqiViDV3v.pgp
Description: PGP signature

Re: [arch-general] kernel full compilation ?

[Giancarlo Razzolini via arch-general]

Em março 3, 2020 10:04 Pascal escreveu:


it's necessary to recompile completely even if the kernel I'm using is the
same as the one I want to apply a small modification on ?



Yes. The wonders of kernel development.

Regards,
Giancarlo Razzolini

pgpPugtAQyGES.pgp
Description: PGP signature

Re: [arch-general] kernel full compilation ?

[Giancarlo Razzolini via arch-general]

Em março 3, 2020 9:54 Pascal via arch-general escreveu:

hello,

I need to introduce a small modification in linux-5.4.23/block/blk-core.o :
do I need to recompile completely (~4 hours) or is there a way to shorten
the compilation time ?

I followed Kernel/Arch_Build_System
.

regards, lacsaP.



If this is a bug, you might want to ask the linux-lts maintainer to include a
patch for this. But, regardless of that, you'll have to compile it, yes.

Regards,
Giancarlo Razzolini

pgp1d8iUIwhPm.pgp
Description: PGP signature

Re: [arch-general] FS#65265 - community/dolphin-emu 1:5.0.r11530.ea9b96370d-1 conflicts with discord-rpc-api (I don't agree with Scimmia decision)

[Giancarlo Razzolini via arch-general]

Em janeiro 29, 2020 16:33 Neven Sajko escreveu:

It is not really fair to say that Krzysztof's bug report was
"incorrect". But, sure it would have been more clear to omit referring
to an unofficial repo.



Don't get me wrong. I didn't even get into the actual packaging. It may well
be the case this is not an upstream issue and it's a downstream poor packaging
issue.

But, framing it in regards with an AUR package will not fly, because we don't
support AUR packages and we (usually) don't change official repositories 
packages
in regards to AUR ones.

Which is why I've told him to fill both upstream (if applicable) and downstream 
bug
reports, but not framing it into AUR terms.

Regards,
Giancarlo Razzolini

pgpZ68X9znOWv.pgp
Description: PGP signature

Re: [arch-general] FS#65265 - community/dolphin-emu 1:5.0.r11530.ea9b96370d-1 conflicts with discord-rpc-api (I don't agree with Scimmia decision)

[Giancarlo Razzolini via arch-general]

Em janeiro 29, 2020 15:46 Krzysztof Krakowiak via arch-general escreveu:

Hi,
I'm Krzysztof Krakowiak (pix3l in archlinux) and I'm new there

https://bugs.archlinux.org/task/65265
I'm very dissapointed by Doug Newgard (Scimmia) bug resolution, who
simply closed my bug report with excuse "AUR packages are not
supported", but the problem is not in the package from 'aur', but from
'community':



Please, don't personify things. There's no need for that and Scimmia didn't
do that when he closed your bug report.


I've made request   to re-open the the bug-report, by he simply
ignored that request



Because your bug report is incorrect.



They should belong to 'discord-rpc-api' (currently in aur), and there
are many packages dependant on it.
Even if 'dolphin-emu' maintainer decides that dolphin-emu wil be built
using internal copy of 'discord-rpc-api', there's no reason to
export/package those header files, because it's for internal use
only(compilation time).



You should report this upstream.


I don't get reasoning that if something is fucked up in upstream, then
it should be fucked up in distro package (because of upstream...)
I was active PLD distro developer (evil_core) and we always had high
standards and main excuse for pour existence was to fix upstream
brakage/incompetence.



We do patch and fix things that upstream doesn't or we need in order for
things to work. Even while we could in theory change our dolphin-emu package
it doesn't change the fact that your specific bug report is incorrect, because
we don't support AUR packages.

You're more than welcome to file this both upstream and again on our bug 
tracker,
but this time, you can make your case for dolphin-emu not having those files, 
*independent*
of your AUR package. If you want, you can even send a patch to the 
PKGBUILD/package doing
that.

Regards,
Giancarlo Razzolini


pgpoAuoBl7yDO.pgp
Description: PGP signature

Re: [arch-general] Why are Archlinux packages stripped of (debugging) symbols?

[Giancarlo Razzolini via arch-general]

Em janeiro 24, 2020 16:41 Eli Schwartz via arch-general escreveu:


Oooh, that's actually a really interesting idea. I bet we could make
this just consume a foo-debug package, then we could just modify
devtools to add OPTIONS+=('debug') in makepkg.conf, and have commitpkg
upload the debug package separately to the symbol server.



I thought more of a "build and they shall come" approach where we put this 
server
out there and create a todo for people to upload symbols. Of course, -any 
packages
don't need any changes, also, I don't think all packages would require symbols 
to
be uploaded.

Of course, if this is a relatively speaking low handing fruit to implement on 
our
tooling, why not?

I'm just not sure yet if tecken is usable outside mozilla things, but let's see.
I have been discussing too with a KDE dev that approached me about this and was
unaware of this thread (and other discussions we had in the past). And he'll 
also
propose that KDE implements a symbols server, regardless of what we do.

But, let me say again, I'm completely against having actual debug packages.

Regards,
Giancarlo Razzolini

pgpORFsyIryyx.pgp
Description: PGP signature

Re: [arch-general] Why are Archlinux packages stripped of (debugging) symbols?

[Giancarlo Razzolini via arch-general]

Em janeiro 21, 2020 20:05 Eli Schwartz via arch-general escreveu:


I'm personally not a fan of bloating packages even by 10% or whatever
for debug symbols that many users don't need.



Me neither.


As I said above, split debug packages need "dbscripts" support to make
sure they are correctly handled by our repository-building scripts.

If dbscripts supported it, we could enable the debug option in devtools'
makepkg.conf and start building all packages with debug info.

(Patches welcome!)



I wouldn't be opposed to have something like tecken [0] or some other software
for this (not sure if there is one) where we would upload all the symbol 
artifacts
for Arch built packages and that users could use when needed.

This wouldn't require changing neither dbscripts nor devtools, but it would be 
helpful
if devtools had some function to facilitate this. This solution wouldn't bloat 
neither
our packages nor our mirrors and would be useful to all Arch users. Of course, 
we could
keep only the last X number of versions on this service, I don't see the point 
in having
something like the Arch Linux Archive where we try to preserve everything.

Regards,
Giancarlo Razzolini

[0] https://github.com/mozilla-services/tecken


pgpATPPW76Feg.pgp
Description: PGP signature

Re: [arch-general] do i need to configure mkinitcpio.conf for my md array ?

[Giancarlo Razzolini via arch-general]

Em janeiro 16, 2020 11:34 Damjan Georgievski via arch-general escreveu:


you need the "mdadm" hook in HOOKS in /etc/mkinitcpio.conf, and
rebuild the initramfs.

the hook would auto-detect the raid setup, but it will also include
/etc/mdadm.conf if it exists.



Actually, the most indicated hook to use is mdadm_udev, not mdadm. But just 
including
either will make sure /etc/mdadm.conf is added to the initramfs.

Regards,
Giancarlo Razzolini

pgpydCvf_Oc72.pgp
Description: PGP signature

Re: [arch-general] Firefox-71.0-1 breaks WhatsApp Web

[Giancarlo Razzolini via arch-general]

Em dezembro 9, 2019 0:55 Oon-Ee Ng via arch-general escreveu:

After more investigation and travelling back and forth, it appears the
issue had at least 2 roots. One is that the update process somehow broke my
existing profile. A new profile solves that. The second is that the latest
version of firefox seems to not be able to authenticate with an NTLM proxy
specifically for web.whatsapp.com.

This has happened before -
https://bugzilla.mozilla.org/show_bug.cgi?id=1536787 shows almost identical
behaviour to what I am experiencing. However I was not using Firefox at
that time. Perhaps I'll just switch back to Chromium for whatsapp web.



You should not upgrade the firefox package while it's open. That's a lesson I've
learned when I've also lost a profile. Everytime you see firefox in the upgrade
packages list, I suggest you close it and then upgrade.

Regards,
Giancarlo Razzolini

pgp2YAajqZs8t.pgp
Description: PGP signature

Re: [arch-general] Firefox-71.0-1 breaks WhatsApp Web

[Giancarlo Razzolini via arch-general]

Em dezembro 4, 2019 1:28 Oon-Ee Ng via arch-general escreveu:

After the update I can't seem to load WhatsApp Web.

If I already logged in (using the QR code) it just doesn't load and
eventually displays the 'connecting to WhatsApp' message which typically
happens when the phone is offline.

If I haven't logged in it will try to load the QR code for authentication
and wait for that forever. The console shows the following:-

Content Security Policy: Directive ‘child-src’ has been deprecated. Please
use directive ‘worker-src’ to control workers, or directive ‘frame-src’ to
control frames respectively.
Firefox can’t establish a connection to the server at wss://
web.whatsapp.com/ws. app.fff9477f997fa1246faf.js:2:783554

Chromium on the same machine has no such issues.



It is working here. I have deauthenticated and authenticated again using the
qrcode.

Try using a clean profile.

Regards,
Giancarlo Razzolini

pgpASJ5ujefVw.pgp
Description: PGP signature

Re: [arch-general] What happened to Arch Wiki recent changes news feed?

[Giancarlo Razzolini via arch-general]

Em novembro 15, 2019 6:07 Georg escreveu:


You can not expect the devs to read this list, and they are the ones to 
decide.


We do read this list.

I'd write a polite inquiry directly to the author of the mentioned 
message.




There's no need. We have disabled the anonymous access to those pages for
a reason.

It doesn't mean it can't be enabled again in the future, but for now they'll
remain like that.

Regards,
Giancarlo Razzolini

pgpufWxHKYYCf.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] New kernel packages and mkinitcpio hooks

[Giancarlo Razzolini via arch-general]

Em novembro 11, 2019 14:00 Damjan Georgievski via arch-general escreveu:

This has been discussed a bit on the dracut thread, as well on some other 
threads over time.
I *personally* don't like the complexity of kernel-install that much.


I've now read this twice on Arch mail lists, so I have to ask, without
any presumptions on my side, what are the arguments against
kernel-install?

I must say, I don't see much complexity in it. It's only a 184 line
bash script[1].
And as added feature, it decouples the kernel install from the kernel
package install (and pacman),
also defines couple of easy-to-use config locations like /etc/kernel/cmdline

But I guess I might be missing something.


[1] especially compared to dracut (not that they do the same thing),
which seems much more complex, and that complexity did introduce bugs
- for which I've sent a PR



As I've said, we don't need to add that *right now*. Anyone can use it though.
It's as easy as overriding the hooks with your own.

I didn't say we'll never consider it, but honestly, I think I'm repeating myself
at this point.

Regards,
Giancarlo Razzolini


pgpzcvdGVR7LV.pgp
Description: PGP signature

Re: [arch-general] New kernel packages and mkinitcpio hooks? What does this mean to the average user?

[Giancarlo Razzolini via arch-general]

Em novembro 11, 2019 13:39 David C. Rankin escreveu:

On 11/11/2019 04:54 AM, Christian Hesse wrote:

That is a change back from March 2017 and appeared in mkinitcpio v24:


POSIX list/bash array ... meh.. both work :)

So I guess the rest of the answer would be that normal users won't have
anything they need to do differently to manage their current hooks as this
change plays out?



The announcement is regarding new libalpm hooks, not mkinitcpio hooks. As I've 
said,
no manual intervention is needed *at all*.

Regards,
Giancarlo Razzolini

pgptnNIjLh1ad.pgp
Description: PGP signature

Re: [arch-general] [arch-announce] New kernel packages and mkinitcpio hooks

[Giancarlo Razzolini via arch-general]

Em novembro 11, 2019 0:08 Kusoneko escreveu:



Hello, in the short time I've been subscribed to a bunch of these archlinux 
mailing lists, I've seen a few threads about mkinitcpio and dracut. What 
exactly are they for and what is the differences between the 2? Should one 
prefer to use dracut when equivalent support for it is implemented?


Hi,

Both are initramfs generators. mkinitcpio is the official Arch Linux initramfs 
generator, while dracut
is the one used by Fedora, Red Hat, etc.

They can both be used right now and I expect mkinitcpio to continue to be 
updated. We are simply giving
the user a choice for now. I'm not sure we will replace mkinitcpio with dracut, 
if ever. This might change
though.

If you don't feel confident choosing, I'd advise you to stay using mkinitcpio.

Regards,
Giancarlo Razzolini

pgphxQYOcKAnS.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] New kernel packages and mkinitcpio hooks

[Giancarlo Razzolini via arch-general]

Em novembro 10, 2019 22:52 Amish via arch-general escreveu:

I am planning to do full system upgrade except linux package.

i.e. pacman -Syu --ignore linux --ignore linux-lts

Would the change in mkinitcpio and /boot create a broken system for me?

You have written it is backward compatible. So do you mean it is 
backward compatible with older linux / linux-lts?



Hi Amish,

Given that that kernel does not have a pkgbase file, if you do a full upgrade,
what's going to happen is that mkinitcpio will ignore that kernel, and will not 
touch
it.

There are some instances where your initramfs might get built twice, but other 
than
that, it shouldn't be an issue.

Also, any kernel that has a pkgbase, but still install the kernel to /boot, 
will get
the kernel installed twice, and the initramfs images generated twice. I think 
we had
a couple of kernel versions that contained a pkgbase file, but still installed 
the kernel.

I have done a few tests with mixing kernels with pkgbase and without them, the 
only side
effect was building it twice on mkinitcpio upgrades (or when a file changes on 
/usr/lib/initcpio).

Regards,
Giancarlo Razzolini

pgp1jSFtOlrBy.pgp
Description: PGP signature

Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod

[Giancarlo Razzolini via arch-general]

Em novembro 4, 2019 0:59 Genes Lists via arch-general escreveu:


  Yeh, that makes sense - plus its very easy to add to dracut.conf



Yes. dracut supports /etc/dracut.d, so there's where they recommend to put
settings.


  Been thinking about that - I've switched to building without -H and
not creating a fallback image - I've also switched to signing all
modules (in and out of tree).

  Not sure what value a fallback image actualy provides at this point?
It takes more space and I don't see it adding much value.



While I agree that they might not be needed that much, it's a good thing to
have, even if you don't use it. I can ship with it enabled and then users can
remove it.



  I that that we would be better with compression being put in
dracut.conf.  Be more flexible that way than the command line which I
assume overides dracut.conf - so a lot less flexible.


Yes, that's the idea.



  Also, is it time to switch from gzip to xz or even to zstd yet?



xz is much slower than gzip, and the kernel does not support zstd.

Regards,
Giancarlo Razzolini

pgprFrL3Qs2Yd.pgp
Description: PGP signature

Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod

[Giancarlo Razzolini via arch-general]

Em novembro 3, 2019 21:05 Genes Lists via arch-general escreveu:


Thank you ... I really like dracut - it works well.
Only suggestion I'd make is adding "--mdadmconf" perhaps by default -
though I can see it both ways for those who don't use RAID - if its easy
to add that would also be totally fine.



That would require having dracut depend on mdadm. I think this is something
to be done by the user. I plan a simple config/preset per kernel that will be
called twice, once with -H and once without, to create the regular/fallback 
images.

Also, I've found out that, for some reason, dracut defaults to creating 
non-compressed
images when nothing is passed, so I'll probably add arguments to make sure they 
are compressed.

Regards,
Giancarlo Razzolini

pgptC3g9x8lIo.pgp
Description: PGP signature

Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod

[Giancarlo Razzolini via arch-general]

Em novembro 3, 2019 12:45 Genes Lists via arch-general escreveu:

On 10/31/19 2:30 PM, Giancarlo Razzolini via arch-general wrote:
...

...  Also, as I've mentioned, dracut should receive
soon, hooks similar to those mkinitcpio did, with a few differences of
course. 


Since Giancarlo brought up dracut in May this year, I've been using this
successfully to boot custom built upstream kernels on about 8 different
systems, including servers running soft RAID. And it works very, very
well - thank you for driving this forward.

Giancarlo is there anything that may need changing to boot using dracut
going forward?



I'm as of now writing hooks for dracut to be able to install the kernel, as
mkinitcpio does, and I'm considering have a preset config, like mkinicpio,
so it gives the user the ability to decide how dracut is ran.

Other than that, given that dracut is slightly different than mkinitcpio, I
don't think these hooks should be overworked. On the other hand, the kernel
installation will be somewhat inflexible if done only to /boot.

I think initially it'll be like that, but then we can use dracut's configuration
for this.

Regards,
Giancarlo Razzolini

pgpBrFDffKObr.pgp
Description: PGP signature

Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod

[Giancarlo Razzolini via arch-general]

Em outubro 31, 2019 16:16 Eli Schwartz via arch-general escreveu:


What was the reason for suggesting to use kernel-install non-standard
Fedora tool that does gross things in a gross way instead of "all those
tools" (all one of them) which do the exact same thing in a more KISS
manner that respects user choice, makes it clear what you're using and
when you're using it, and helps track files properly in pacman?

I don't understand your loaded question, but this game of "let's assume
things and then yell at people for doing things the same way they worked
for many many years" sure is fun!

P.S. Put down your question mark key. There's no need to act quite
*that* shocked that no one drank the Fedora kool-aid.

*steps off soapbox*



Hi Eli,

This is totally uncalled for. Even though I agree that kernel-install is *not*
that great, there's no need to be aggressive.

The question, even if phrased not in the best way, is a legitimate one.

Regards,
Giancarlo Razzolini




pgp22vrbCxYaP.pgp
Description: PGP signature

Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod

[Giancarlo Razzolini via arch-general]

Em outubro 31, 2019 15:28 Damjan Georgievski via arch-general escreveu:

I can make a more general hook,
for example triggering on usr/lib/modules/*/pkgbase (or vmlinuz?) - is
that the recommended way now?



All the official kernels will have pkgbase on them. So, trigger on vmlinuz, 
which is
the actual kernel, but use pkgbase to know which one you're dealing with.

The mkinitcpio hook, as it is now, won't touch a kernel that has no pkgbase, 
but in
some circumstances, if the kernel is a non official one, that has no pkgbase 
yet, the
hook might end up causing the initramfs to be built twice. Other than that, 
there
shouldn't be any issues.

Regards,
Giancarlo Razzolini

pgpTROo4MGg2c.pgp
Description: PGP signature

Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod

[Giancarlo Razzolini via arch-general]

Em outubro 31, 2019 15:11 Geo Kozey escreveu:


What was the reason for not using kernel-install[1] standard instead of all of 
those Arch's exclusive hooks again??

https://www.freedesktop.org/software/systemd/man/kernel-install.html

Yours sincerely

G. K.



There are several reasons for not using it. It's overly complex, it does a lot 
of assumptions for you, among other
things. That doesn't mean it *can't* be used by the users. We are taking baby 
steps on making the booting process
on Arch overall more flexible.

You can *right now* completely override the mkinitcpio hooks and, install and 
deal with the kernel *any* way you want.
Want to not use /boot? Can do. Want to stuff everything on /efi? Can do. Want a 
hook that will build your efistub and
update entries? Can do. This update opens up lots of possibilities, while also 
maintaining (some) backward compatibility.

I'm planning a few changes [0] to mkinitcpio, to make this even more flexible. 
Also, as I've mentioned, dracut should receive
soon, hooks similar to those mkinitcpio did, with a few differences of course. 
But, since the most important part for keeping
most user's systems booting is the actual kernel installation, if you opt to 
override either the mkinitcpio hooks or dracut's,
it will be your job to make sure you install the kernel to wherever you want it.

Regards,
Giancarlo Razzolini

[0] https://github.com/archlinux/mkinitcpio/issues

pgp3LNR9eFr2a.pgp
Description: PGP signature

Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod

[Giancarlo Razzolini via arch-general]

Em outubro 31, 2019 9:46 Damjan Georgievski via arch-general escreveu:

Can someone explain in better detail the changes in
* kmod 26-3
* mkinitcpio 27-1
* linux 5.3.8.1-1
around packaging and pacman hooks?

I can see there's some reorganization of the hooks and scripts, and
the kernel package no longer
installing directly to /boot (which is a welcome change, the kernel is
now only in /usr/lib/modules/5.3.8-arch1-1/vmlinuz)
but it's not easy for me to reverse-understand what the bash scripts do exactly.

I'm asking because I also use pacman hooks on the kernel and some
other files in order to create my combined kernel+initramfs+cmdline
UEFI executable signed for secure-boot, and it seems I'll have to
adopt to a newer setup.



Hi Damjan,

The kernel does not install itself anymore to /boot, as you've noticed. But, 
the mkinitcpio
hook does that. For now, we are replicating the same behavior as before, but 
with a little
more flexibility.

I'm working on dracut hooks for doing a similar job, but the idea is that we 
eventually will
be more flexible with our booting, giving the user more options. Keep an eye on 
the Arch announce
mailing list, as well as the news on the Arch site.

As for your hooks, we made so that the mkinitcpio hook runs at the same step 
the previous linux
hook would. So, there shouldn't be any incompatibilities. But, it depends on 
what your hooks are.
Also, you can completely override the mkinitcpio hooks by linking their 
filenames to /dev/null on
/etc/pacmand.d/hooks directory. But you'll be left doing the kernel 
installation on your own.

Regards,
Giancarlo Razzolini

pgpa0avOjF7IR.pgp
Description: PGP signature

Re: [arch-general] ��� ���������� ���� ������?

[Giancarlo Razzolini via arch-general]

Em outubro 24, 2019 20:17 Jonathan Horacio Villatoro Córdoba via arch-general 
escreveu:

Upon checking the message headers, I found the following:

...

Reply-To: proda...@teleworm.us,

...

On Thu, Oct 24, 2019 at 11:39:12PM +0100, arch-annou...@archlinux.org
wrote:

Вас интересуют базы данных?
___
arch-announce mailing list
arch-annou...@archlinux.org
https://lists.archlinux.org/listinfo/arch-announce


I believe it's safe to say this is a spam message.

AFAIK, teleworm.us is a service that provides anonymous temporary email
addresses.

HTH.

Best,
Jonathan



Not just that, but it seems it allows spoofing the address too. We're working on
a fix to make sure this doesn't happen again.

Regards,
Giancarlo Razzolini

pgpz1SRPoCBBD.pgp
Description: PGP signature

Re: [arch-general] Package guidelines 

[Giancarlo Razzolini via arch-general]

Em outubro 14, 2019 12:41 Alberto Salvia Novella via arch-general escreveu:

As said, blocked the latest three.

We can either have a constructive conversation or it's over, that 
simple. Make your choice.





Please, block me as well. Or, go even further and block anyone with an 
@archlinux.org
email address. Appreciate.

Regards,
Giancarlo Razzolini

pgp5kvziovdgJ.pgp
Description: PGP signature

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

[Giancarlo Razzolini via arch-general]

Em outubro 10, 2019 17:06 John Crist via arch-general escreveu:
I've submitted `base-extras` to the AUR at 
https://aur.archlinux.org/packages/base-extras/ that contains the 
missing packages from `base` if someone REALLY wants it.






And I have removed it. Following the same criteria, I've also removed 
base-devel-meta.

Regards,
Giancarlo Razzolini

pgpp5lcAqbT5m.pgp
Description: PGP signature

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

[Giancarlo Razzolini via arch-general]

Em outubro 7, 2019 1:02 Marc Ranolfi via arch-general escreveu:

The `base` group has been replaced by a metapackage of the same name, we

advise users to install this package (`pacman -Syu base`), as it is
effectively mandatory from now on.

Please, was this discussed somewhere? I want to know the details, and
gather what is needed to update the 'Installation guide' article in the
wiki. In particular, I want to understand why essential packages for new
installations, such as the kernel and a text editor, are not included
(actually I see the kernel is an optional dependency).




Yes, this was discussed over the years in several threads. The most recent 
being [0].

Lacking a kernel is mainly for container based environments. And some 
superfluous
packages were also removed from the group, like an editor.

The necessary changes to the installation guide were already made [1].

Regards,
Giancarlo Razzolini

https://lists.archlinux.org/pipermail/arch-dev-public/2019-January/029435.html
https://wiki.archlinux.org/index.php/Installation_guide#Install_the_base_packages

pgpeIaBUVuZ8v.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Giancarlo Razzolini via arch-general]

Em agosto 22, 2019 17:15 Damjan Georgievski via arch-general escreveu:


Just in case, I'll mention kernel-install [1] once again, it's a nice
central hub where initramfs creators, bootloaders (and optionally signing
of uefi images) can hook into, and then any kernel install can call all the
users hooks with a single command.



[1]
https://www.freedesktop.org/software/systemd/man/kernel-install.html




I've searched the thread and didn't find a previous mention from you about 
kernel-install.
It seems interesting, I'll take a look at it.

Regards,
Giancarlo Razzolini

pgpKIS9BsxgQH.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Giancarlo Razzolini via arch-general]

Em junho 4, 2019 18:08 Genes Lists via arch-general escreveu:

On 6/4/19 4:53 PM, Genes Lists via arch-general wrote:

Forgot to post the boot the boot log which shows the problem occurs
after switching the pivot root:


...
saplinux kernel: md/raid:md127: raid level 6 active with 6 out of 6
devices, algorithm 2
saplinux kernel: md127: detected capacity change from 0 to 12001828929536
saplinux systemd[1]: Started dracut initqueue hook.
...
saplinux systemd[1]: Switching root.
...
kernel: EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts:
data=ordered
systemd[1]: dev-md0.device: Job dev-md0.device/start timed out.
systemd[1]: Timed out waiting for device /dev/md0.
systemd[1]: Dependency failed for File System Check on /dev/md0.
systemd[1]: Dependency failed for /mnt/md0.
systemd[1]: Dependency failed for /srv/nfs4/install.
systemd[1]: Dependency failed for Local File Systems.
systemd[1]: local-fs.target: Job local-fs.target/start failed with
result 'dependency'.
systemd[1]: local-fs.target: Triggering OnFailure= dependencies.
...



Please, report all issues on bugs.archlinux.org with as much information as
possible. As far as I know dracut supports raid. Perhaps this might even be
an upstream issue.

Regards,
Giancarlo Razzolini

pgpvdLYHgrEG2.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Giancarlo Razzolini via arch-general]

Em maio 29, 2019 18:49 Michael Lojkovic via arch-general escreveu:



Should this work with a minimal initramfs, without udev? I don't know
how to transfer the mkinitcpio config to dracut to test this properly.



It would help if you upload your current config/preset somewhere. I'm not
sure anything works properly without udev these days, except for very simple
setups.

Also, if you're talking about non x86_64 platforms, the dracut Arch package
is compiled just for that platform. For others, I guess this question would
be better asked upstream.

Regards,
Giancarlo Razzolini

pgpOSHYuU5YLN.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Giancarlo Razzolini via arch-general]

Em maio 27, 2019 13:45 Damjan Georgievski escreveu:


Thanks,
I've also noticed another issue about the uefi stub and sent a PR:
https://github.com/dracutdevs/dracut/pull/575



Thank you all for testing and also submitting patches to make it work better
not just on Arch, but any other distro too.

Regards,
Giancarlo Razzolini

pgphZyHYsKLta.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Giancarlo Razzolini via arch-general]

Em maio 27, 2019 11:18 Damjan Georgievski via arch-general escreveu:



dracut --uefi




This seems to fail for me:
$ sudo dracut --no-early-microcode --uefi /boot/EFI/Linux/arch-linux.efi
dracut: Executing: /usr/bin/dracut --no-early-microcode --uefi
/boot/EFI/Linux/arch-linux.efi
/usr/bin/dracut: line 1063: arch: command not found
/usr/bin/dracut: line 1069: arch: command not found
dracut: Architecture '' not supported to create a UEFI executable


any ideas why??

dracut 049-3 on an Arch [testing] VM



There are a few more instances where arch must be replaced with uname -m.

I'll deploy a version of dracut with that patch later:

https://github.com/dracutdevs/dracut/pull/573

Regards,
Giancarlo Razzolini

pgpjvOnTU7SIr.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Giancarlo Razzolini via arch-general]

Em maio 26, 2019 0:08 Eli Schwartz via arch-general escreveu:


Anyway I suspect this thread is not the best place to begin a
fundamental discussion about whether GNU bash is allowed to claim it
implements POSIX. Also I doubt dracut does insane things like attempt to
invoke a utility named "^", with or without doing the POSIX thing and
disambiguating it with the use of the command utility.



And, even if it did, dracut gives you the ability to use either dash, busybox
or bash. Perhaps even more. But all this discussion about pure POSIX or not is
not really related to this thread.

My main concerns are: 1) Is dracut a good replacement for mkinitcpio?
2) Can it do everything mkinitcpio do?
3) And, more importantly, does it mount the root fs like it is the purpose of 
all initramfs?

Based on the replies I've got so far, with some minor issues, dracut is working 
on Arch just fine.
I'm working on libalpm hooks for both mkinitcpio and dracut so the image 
creation is done automatically.
Also, both packages now provide a virtual 'initramfs' package, so we can switch 
to this when everything
is ready.

I plan also to provide with the dracut package a configuration similar to what 
we have today, creating
a hostonly image and a fallback image. Once all this is ready, we can start 
deploying dracut on our ISO.
Also, when the kernel packages switch to the 'initramfs' dependency, we'll be 
able to have pure dracut
installations.

Regards,
Giancarlo Razzolini

pgpzJfxITGyC_.pgp
Description: PGP signature

Re: [arch-general] Arch on NVMe ssd

[Giancarlo Razzolini via arch-general]

Em maio 22, 2019 12:42 Daurnimator escreveu:

On Thu, 23 May 2019 at 01:34, Giancarlo Razzolini via arch-general
 wrote:

Just don't enable discards at the fs mount options and you should be fine. 
Install
and enable the fstrim.timer so it runs once a week, which is enough.


Oh? Why is this?
I've had both enabled for multiple years now.



On NVMe Intel recommends to no have continuous discards at the fs level:

https://wiki.archlinux.org/index.php/Solid_state_drive/NVMe#Discards

Regards,
Giancarlo Razzolini

pgpK3eLKj4inK.pgp
Description: PGP signature

Re: [arch-general] Arch on NVMe ssd

[Giancarlo Razzolini via arch-general]

Em maio 22, 2019 12:27 Ram Kumar via arch-general escreveu:

Hello fellow Archers,
I bought a new laptop that has NVMe ssd on it. I would like to install Arch
on that, is there any precautions that i need to take? Also i would like to
get feedback from Archers who already tried this.



Just don't enable discards at the fs mount options and you should be fine. 
Install
and enable the fstrim.timer so it runs once a week, which is enough.

Other than that it is like any other install, only, much faster.

Regards,
Giancarlo Razzolini

pgpFp0BD6HnAn.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Giancarlo Razzolini via arch-general]

Em maio 22, 2019 9:25 Jonas Witschel escreveu:

On 2019-05-22 14:00, Giovanni Harting via arch-general wrote:

Unfortunately this process currently only works for AMD, but not for
Intel, since Arch Linux doesn't package the necessary files standalone:
they are downloaded by intel-ucode and used to produce a CPIO image, but
not added to /usr/lib/firmware/intel-ucode/ separately. If dracut
becomes the default initramfs generator, this should be changed so that
microcode updates work out of the box with dracut.



This is not a huge issue, if the microcode is passed alongside the initramfs
on the cmdline, like we have been doing.

We might also change the intel-ucode package, but it is not a requirement and
will not prevent the move to dracut.

Regards,
Giancarlo Razzolini

pgp4vqf0HXENE.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Giancarlo Razzolini via arch-general]

Em maio 21, 2019 17:29 Bjoern Franke via arch-general escreveu:



Just dracut -f /boot/initramfs-linux.img. It is that simple.


Tried it, the output looked fine:

https://p.rrbone.net/paste/FV7HMpE7#

But while booting dracut hang on "initqueue hooks"



This output is a json file, so I'm not sure what you're outputting there.

Anyway, I got this as well on a VM. You can pass rd.shell, rd.timeout and 
rd.retry
to your cmdline. Please refer to dracut.cmdline man page. Also, make sure you 
have the
proper root= and other arguments as well on your cmdline.

Regards,
Giancarlo Razzolini

pgpF9vEbHMPrB.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Giancarlo Razzolini via arch-general]

Em maio 21, 2019 15:42 Genes Lists via arch-general escreveu:

Early Microcode and initrd.

I notice that the AMD microcode is [1] in the initrd while the intel
microcode is not.

Booting with option:
initrd=/boot/intel-ucode.img
to get the microcode installed early works fine with dracut as it always
has.

Is this something that will remain the same as now or does this
potentially change under dracut?



This probably needs to be changed. No point in having AMD microcode into the 
initramfs
if you have an intel processor. It's wasted space.

Loading the microcode before will probably always work and should continue to 
be the
desirable solution.

Regards,
Giancarlo Razzolini

pgppbqe8Wqzbi.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Giancarlo Razzolini via arch-general]

Em maio 21, 2019 15:15 Andy Pieters escreveu:

What's the rationale for going dracut? I'm quite happy with mkinitcpio



I think I've addressed this in the first email. I'm also quite happy with 
mkinitcpio,
and I myself maintain several mkinitcpio hooks that would need to be re-written 
for dracut.

But, from the mkinitcpio development perspective, it lacks several things that 
would be necessary
to develop it further. We don't have a testing suite, which makes the 
development process quite
tiresome and error prone. Our network booting code is not working for even the 
simplest cases.
We have two ways to boot the system today, and depending on the hooks 
combinations we have issues.

Dracut by default uses systemd and I think that will be the supported way to 
boot Arch. Even though
dracut can use a non systemd initramfs, we should make things more uniform. 
Whomever wants to hack
dracut, will have much more ways to do so than we have with mkinitcpio 
currently.

I know, change is not always good for everyone, but I think that in the long 
term Arch will only
benefit from this change. Also, I believe that people interested in using 
mkinitcpio, will be more
than able to help maintain it, when we eventually (if) remove it from our 
repositories.

Heck, I might maintain it myself on the side, since I have a lot of stuff going 
on for it. But, I
believe that for Arch official initramfs system, we should replace it. There 
are other options too,
I have considered dracut because it currently fills in a gap we have on the 
development process, while
also fixing all the corner cases mkinitcpio doesn't support well today.

Regards,
Giancarlo Razzolini

pgpKX26GCp9qZ.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Giancarlo Razzolini via arch-general]

Em maio 21, 2019 13:24 Genes Lists via arch-general escreveu:

1) Feedback:
Tested one computer and it worked fine.
Used refind to boot - it has encrytped /home but not root.
Got text prompt for passphrase not graphical - think there is a way to
get graphical as well but need to read further how to do that. I prefer
text as I also can see the boot progress details which is helpful.
Still, be good to know how to get the graphical prompt anyway.



I suppose as more and more people start using it, we'll eventually have
instructions on how to do these more custom environments.


Created initrd using
# dracut --kver xxx



No need for using --kver, unless your booted kernel differs from the installed
one. The pacman hooks will have to use kver, most likely.


This seems to contain pretty much everything best I can tell

2) Question:
   Arch typically has used unversioned initrd images which has the
   convenience that the boot standzas don't need updating on new kernel.



Just dracut -f /boot/initramfs-linux.img. It is that simple.


or perhps soft link (ln -s)?



We don't need to make things that complex.

Regards,
Giancarlo Razzolini

pgpAlo4QSl3Qg.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Giancarlo Razzolini via arch-general]

Em maio 21, 2019 12:21 Lone_Wolf escreveu:



from https://dracut.wiki.kernel.org/index.php/Main_Page :


  * Scripts that end up on the initrd should be POSIX compliant. dracut
will try to use /bin/dash as /bin/sh for the initrd if it is
available, so you should install it on your system -- dash aims for
strict POSIX compliance to the extent possible.
  * Hooks MUST be POSIX compliant -- they are sourced by the init
script, and having a bashism break your user's ability to boot
really sucks.


Seems like having dracut depending on bash may not be a good idea.

Or is there a way to make sure dracut scripts & hooks will use bash in 
POSIX-compliant mode ?




If you have dash installed dracut will use it instead of bash. It is *that* 
simple.
But, I'm not much concerned here about POSIX compliance as I'm concerned about 
it
actually being a good replacemente to mkinitcpio *and* actually booting the 
machines
of users.

I based my package on fedora's. So, the dependencies were carefully replicated 
to avoid
issues. But anyone can hack it later to use dash or busybox.

Regards,
Giancarlo Razzolini

pgpUjUthoV3Xo.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Giancarlo Razzolini via arch-general]

Em maio 21, 2019 11:26 Genes Lists via arch-general escreveu:

...

I'm an arch tester and I'd be happy to test dracut.

It would be helpful if you could create a little write-up on 'how to
switch' from mkinitcpio to dracut.


Just run dracut =D. But seriously, I'll work on a wiki page about this.
Dracut has several man pages too, I suggest starting with dracut.cmdline.


And I assume modules now in HOOKS would move to
/etc/dracut.conf.d/hooks.conf
or similar.



I have not yet decided on the configuration, but I think I'll have something
similar to mkinitcpio.conf as /etc/dracut.conf.


All being well, the kernel package will need to be modified to update

/usr/share/libalpm/hooks/60-linux.hook

to now call dracut.



I'll stress this, dracut and mkinitcpio will co-exist for a *long* time. So,
each will have their own hooks for updating the images.

Regards,
Giancarlo Razzolini

pgpWzD8ShnTjf.pgp
Description: PGP signature

Re: [arch-general] steam-native can't find libpcre.so.3, breaks embedded browser

[Giancarlo Razzolini via arch-general]

Em abril 4, 2019 14:11 Maarten de Vries escreveu:


Are you sure you're running steam-native? I get the exact same issue
with `steam-native`, while `steam` has a working browser (but some
games have other issues). It seems unlikely to me that steam would
require libpcre.so.3 only for some users but not for others.



Yes, I am sure. But to be double sure I've ran it from the shell. No issues 
with the store page.


While it is definitely a problem caused by upstream, they officially
only support some Ubuntu distributions. There's no guarantee that
steam will solve this on their end.



If we can argue, I don't see why they wouldn't.


Also, the patch you referred to, is not an actual patch, just a package that 
creates an
ugly fix, by creating a symlink to libpcre. That's not the right way to fix 
this issue.


A better fix is mentioned on the steam forum [1] by a WorMzy:

$ export LD_PRELOAD="/usr/lib/libgio-2.0.so.0:/usr/lib/libglib-2.0.so.0"
$ steam-native


Apparently those libraries still come from the steam distribution,
even with steam-native, and those pull in libpcre.so.3 and
libselinux.so.1. Preloading the system versions avoids that.

[1] 
https://steamcommunity.com/groups/SteamClientBeta/discussions/0/1848072002764995823/#c1769259642875894556



Now a patch I can agree on. Given that steam-runtime is all about LD preloading 
stuff, there
would be the place to fix this, if we can't get this fixed upstream.

Regards,
Giancarlo Razzolini

pgpZUMR8I8mJW.pgp
Description: PGP signature

Re: [arch-general] steam-native can't find libpcre.so.3, breaks embedded browser

[Giancarlo Razzolini via arch-general]

Em abril 4, 2019 0:25 Alexandre Oliveira via arch-general escreveu:

It seems like the steam-native package is broken as of March 21,
according to this bug report[1].

Installing libselinux and pcre seems to fix the issue. I don't know if
it's a good idea to write about it here, but I'd like to get this patch
mainstreamed, instead of having to install another package to workaround
this bug.

[1]
https://bugs.archlinux.org/task/62095?project=5=steam-native-runtime



Hi Alexandre,

As I have just commented on the bug, I cannot reproduce this bug. And I use 
steam on an
almost daily basis.

It looks like it's a bug on upstream steam and does not affect all users. Even 
though we
can patch things on occasion to fix broken packages, we tend to wait for 
upstream fixes
if the issue is not critical or a fix already exists.

Also, the patch you referred to, is not an actual patch, just a package that 
creates an
ugly fix, by creating a symlink to libpcre. That's not the right way to fix 
this issue.

Regards,
Giancarlo Razzolini

pgpsvbVe97Qyz.pgp
Description: PGP signature

Re: [arch-general] Reboot-less Computers

[Giancarlo Razzolini via arch-general]

Em outubro 28, 2018 18:23 Jayesh Badwaik via arch-general escreveu:


Thank you. What are the opinions about kexec? The wiki says
" Note that kexec may not work correctly for you due to devices not fully re-
initializing when using this method, however this is rarely the case. "

https://wiki.archlinux.org/index.php/Kexec



kexec should work just fine on recent hardware. I think the last time I used it,
I had one issue with nvidia, but having bbswitch fixed it. Keep in mind that 
kexec
is a soft-soft reboot, so, it's not like you're not rebooting the machine. And, 
in
some cases it might be faster and safer to actually reboot the machine.

Regards,
Giancarlo Razzolini

pgpWJjlYs17Wj.pgp
Description: PGP signature

Re: [arch-general] Arch branded ODP slide for presentation

[Giancarlo Razzolini via arch-general]

Em agosto 22, 2018 9:35 Ashok Arora via arch-general escreveu:


1) Is there someone I need to seek permission from to use Arch branding?


See the usage cased listed on the wiki page provided by Ashok. From what you
have told us so far, I don't think there's any issue.


2) Does anyone have any good slide templates they can share?



I don't think we have a template. I know some devs have been giving talks
recently, the one that I remember from the top of my head is Jelle. Perhaps
one of them can share it with you. You can also search for past presentations
by devs/tus. I would ask their permission though, before using any of their 
slides
templates.

Regards,
Giancarlo Razzolini


pgpQ7C1zGmuH3.pgp
Description: PGP signature

Re: [arch-general] Kernel source URL change

[Giancarlo Razzolini via arch-general]

Em agosto 7, 2018 23:31 W B via arch-general escreveu:

It isn't an order.

Can you tell us why this change was required, please?



Have you read the original post to the list? Specially this [0]?

Those tar files you just linked are not signed by Linus anymore, they are signed
instead by Greg Kroah-Hartman. You would have known this if you bothered to 
actually
download them and check the signature.

Another reason for this move is to apply our patches as commits. You can use 
any other
kernel if you want.

[0] https://www.kernel.org/minor-changes-to-tarball-release-format.html

Cheers,
Giancarlo Razzolini


pgpr9S6McPgNQ.pgp
Description: PGP signature

Re: [arch-general] ipv6 only half working

[Giancarlo Razzolini via arch-general]

Em agosto 2, 2018 22:53 David Rosenstrauch escreveu:




Any idea what I might look for / where I might look from here to figure 
out what's causing the issue?  My server is running (an up to date) Arch 
installation, and is behind a Netgear WNDR3700 router.  Any suggestions 
appreciated!



It's hard to know for sure without the full capture file. But those errors
*point* in the direction of MTU issues. Try setting your MTU at your interface
level to a value lower than 1500. Try with 1492 first. See if that fixes the 
situation.

You can also try ping to know what is the maximum MTU and also segment size.

Regards,
Giancarlo Razzolini

pgpAWfHHSB4lm.pgp
Description: PGP signature

Re: [arch-general] Unresponsive maintainer

[Giancarlo Razzolini via arch-general]

Em julho 30, 2018 12:52 Levente Polyak via arch-general escreveu:



We had a chat recently as he currently lacks the amount of
time he had before, so we discussed I jump in and help with
the Java things.
I gonna take a look at visualvm as well, if you have important changes
other then just bumping please send me your version.


Hi Levente,

Can you talk with him again and encourage him to resign or clearly state for
how long he will be inactive? This would come a long way to address these 
issues.

Regards,
Giancarlo Razzolini

pgp83ZCOrLZDZ.pgp
Description: PGP signature

Re: [arch-general] Arch Linux PC as a Remote Desktop Node

[Giancarlo Razzolini via arch-general]

Em julho 27, 2018 16:24 ProgAndy escreveu:


The Arctica Project seems to be in the process of implementing exactly 
what you want.


https://arctica-project.org/

https://github.com/ArcticaProject/remote-logon-service




It looks they are using Nomachine's nx libraries, the same x2go uses. And, the 
fact
the transport is over SSH, makes it look a lot like x2go. But, it seems to me 
that the
project is very much on the beginning, I wouldn't use it also for production.

Regards,
Giancarlo Razzolini

pgpkJSEb_PTmJ.pgp
Description: PGP signature

Re: [arch-general] Arch Linux PC as a Remote Desktop Node

[Giancarlo Razzolini via arch-general]

Em julho 27, 2018 14:46 Foxtrot Mike via arch-general escreveu:


The issue with x2go and ltsp is that I'll have to separately manage 
username and passwords for local Linux login. The solution that I'd 
rather prefer would use Active directory authentication so the current 
system administrator won't have to do anything extra. The group policies 
are already there. Once the Arch system is properly configured, I'd 
disable local logins so there will be very limited chance for a user to 
corrupt/modify Arch system. And ideally, the user would have no way to 
interact with the local system. Thats why I want to limit the user to 
freeRDP. Anything else, and the X-session expires.


You have more than one option to authenticate to windows AD servers [0] . You
have PAM Ldap, winbind, making a samba server the secondary controller, etc.

You will probably need a local home dir for storing session data, but this can
be created/destroyed on demand.



Plus, I am very much into embedded linux systems (routers, SBCs, etc). I 
think putting the various pieces together would be give me a lot more to 
learn as compared to using a third party specialized software such as a 
kiosk script.




Why reinvent the wheel here? I understand the need for learning, but I wouldn't
do this on something that is intended as a production system. Again, don't use
plain X protocol over the network, it's very wasteful.

Regards,
Giancarlo Razzolini

[0] https://wiki.archlinux.org/index.php/Active_Directory_Integration

pgpO1oJ1yeqzb.pgp
Description: PGP signature

Re: [arch-general] Arch Linux PC as a Remote Desktop Node

[Giancarlo Razzolini via arch-general]

Em julho 27, 2018 14:07 Foxtrot Mike via arch-general escreveu:


Here are the major tasks:

1- Ask LightDM to use Windows Domain (Kerberos) authentication. I am a 
little confused. There are supposedly many different ways with little 
changes to do this. [1] is one solution. LDAP is also a possibility. I 
need advice from someone who knows this field better than me :p


2- How to ask i3-wm (my default wm) to run freerdp at login? I guess [2] 
will get this done.


3- How to ask freerdp to authenticate using the ticket received from TGT 
during LightDM Domain authentication? If I could somehow configure 
freerdp to use Kerberos Tickets then the user won't have to enter his 
Domain password again.


4- How to ask i3-wm to close the X-session when freeRDP quits? I read 
something a while ago about .xsession files to achieve this 
functionality, but can't find it now.



Hi Mike,

You have some options here. I suggest you look into x2go and ltsp for starters.
I don't suggest you use plain X over the network.

With those 2 options you can have this kiosk mode you want, for the users to 
only
be able to access windows.

Regards,
Giancarlo Razzolini

pgpuzLJY49WNT.pgp
Description: PGP signature

Re: [arch-general] ipv6 only half working

[Giancarlo Razzolini via arch-general]

Em julho 23, 2018 14:14 David Rosenstrauch escreveu:



Makes some sense.  I'll take a look on my router and see if perhaps I'm 
inadvertently blocking some ICMP packets.


That said, one thing doesn't quite seem to fit with this explanation:

Why would "curl -6 ipv6.google.com" while "w3m -6 -dump ipv6.google.com" 
fails?




I think what you have experience with the CTRL+C thing you saw is regarding how
each program treats their buffers. Sometimes programs don't flush and when you
send it SIGTERM they flush the buffer.

Secondly, you might be hitting different routes at times, although that would
point to an even larger issue at your ISP.

Regards,
Giancarlo Razzolini

pgp7bh3EvjIHc.pgp
Description: PGP signature

Re: [arch-general] ipv6 only half working

[Giancarlo Razzolini via arch-general]

Em julho 23, 2018 12:46 David Rosenstrauch escreveu:



I'm really stumped as to how ipv6 could partially fail like this only on 
specific apps.  Seems like it should either completely work or 
completely fail.


Anyone have any idea what might be happening here and/or how to fix?



Hi David,

If ping works, but bigger packet things don't, then you might have some PMTU
issue that is only affecting IPv6. You can confirm this with a tcpdump trace
quite easily. Look at the packet sizes. Both things you've mentioned (opening a
web page and updating antivirus) are http, and it does usually use the maximum
transmission unit.

Regards,
Giancarlo Razzolini

pgpMPIkvKXUK4.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] proposal to add "aurpublish" to community

[Giancarlo Razzolini via arch-general]

Em julho 22, 2018 13:55 Eli Schwartz via arch-dev-public escreveu:


So yeah, it seems like at least in the past there's been a distinction
made between uploaders (burp, aurpublish) and downloaders (cower).

Anyway if no one has a serious objection by the end of the week I guess
I will add it. :)



As long as you don't add downloading and/or packaging functionality in the
future, I'm okay with it being in [community] as well. As side note, I didn't
knew about it, and I'm thing it's great. I had a hack to update all my repos.
Guess I'll start using aurpublish.

Regards,
Giancarlo Razzolini

pgp2_PGOMkV3s.pgp
Description: PGP signature

Re: [arch-general] Distribution license of package information on the website?

[Giancarlo Razzolini via arch-general]

Em maio 29, 2018 8:27 Eli Schwartz via arch-general escreveu:


I'm of the opinion that there cannot be a license requirement for reuse
at all, since it's not original enough, and explicitly clarify this in
https://github.com/eli-schwartz/pkgbuilds#copyright



Well, I never thought about licensing PKGBUILD's. Honestly, I don't think we 
need a license.
But, perhaps, considering the implications of this request, we can discuss 
about one. I'm not
against it, and we currently have ways for someone to do this.

Thinking from the technical standpoint, I just don't want our servers to be 
even more hammered
with API requests than they are, specially the AUR.

Regards,
Giancarlo Razzolini

pgpZibMRys6B2.pgp
Description: PGP signature

Re: [arch-general] How best to adapt grub configuration?

[Giancarlo Razzolini via arch-general]

Em abril 16, 2018 8:20 Jeanette C. via arch-general escreveu:

Hey hey,
how would I best adapt Grub's configuration file (gurb.cfg)?

The usecase: I use Grub's play command to play different melodies for 
different entries and one when Grub is ready to be used. The reason behind it: 
I'm blind and like to know quite early on what is happening.


Where would I best put these changes so they will survive Grub updates and 
regeneration of the config file?


Thanks and best wishes,



Hi Jeanette,

You can use the /etc/grub.d directory for this. Depending on how you implement 
this,
you can use any file that does not come by default.

Regards,
Giancarlo Razzolini


pgpqset8hgjGm.pgp
Description: PGP signature

Re: [arch-general] mythtv

[Giancarlo Razzolini via arch-general]

Em janeiro 8, 2018 12:53 Jameson via arch-general escreveu:

With the mythtv packages being dropped to the AUR, are there any remaining
options for DVR software in the official repos?

=-Jameson



Hi Jameson,

I might be wrong, but I think the only other option is kodi.

Regards,
Giancarlo Razzolini

pgpvMRkXVxVBX.pgp
Description: PGP signature

Re: [arch-general] How to build package in "clean chroot" using the "-U" parameter?

[Giancarlo Razzolini via arch-general]

Em dezembro 22, 2017 15:01 Leonid Isaev via arch-general escreveu:


I'm sorry for an unrelated question, but why is it really necessary to make a
new container for each pkg? It seems lots of unnecessary copies (I think
rsync(1) call in makechrootpkg doesn't do hardlinks)...



A new container is *spawned*, not made. You don't have lots and lots of copies.


I understand the issue about getting unlisted deps in packages, but in my
experience this problem is minor. So just boot a build container and ssh in
there as a non-root user (in fact, you don't even need root inside the
container). And keep it clean. At least this has worked for me for years.



Keep in mind that root inside a container is not equal root outside it. But
we use the build user as well inside the container.


Also, with newer -ARCH kernels, you can do non-privileged containers, so
makechrootpkg should run as a ordinary user to begin with...



It already runs as an ordinary user. The container itself is ran as root,
but the actual build happens as the calling user.

Regards,
Giancarlo Razzolini



pgpy9w2n4qhqO.pgp
Description: PGP signature

Re: [arch-general] No ipv6 address - but only on one machine

[Giancarlo Razzolini via arch-general]

Em dezembro 22, 2017 14:15 David Rosenstrauch escreveu:


1) Wifi router reports an IPv6 address on both the WAN and the LAN 
sides.  (In the 2607: range.)


That's a global address range, for sure.

2) Mac desktop behind the router successfully gets assigned an ipv6 
address.
3) Linux laptop (running Arch) successfully gets assigned an ipv6 
address (using NetworkManager).
4) Linux server (also running Arch) does not get assigned an ipv6 
address.


The server is using netctl for networking, and its profile includes:

## For IPv6 autoconfiguration
IP6=stateless



Try using stateful here.



Yet for some reason, this machine doesn't get assigned an external ipv6. 
  Rather it only gets assigned one in the link-local range.  (I.e., in 
the fe80: range.)


Link-local addresses are assigned to any interface when they are created,
regardless of other IPv6 configuration.



I have to admit this is pretty puzzling.  I can't for the life of me 
figure out why the server can't get an address.  Particular since it was 
able to do so successfully probably about a week or so ago.



Anyone have an idea what could have happened here?  Has there been some 
package update recently that might explain this?  Or any pointers on how 
I might go about debugging this?




Well, stateless configuration, or SLAAC, relies heavily on ICMPv6 and NDP.
A firewall can block these. If you try to use stateful configuration and it
works, then you might be inadvertently be blocking the packets used on slaac.

Regards,
Giancarlo Razzolini

pgp83rkdmZ6Os.pgp
Description: PGP signature

Re: [arch-general] How to build package in "clean chroot" using the "-U" parameter?

[Giancarlo Razzolini via arch-general]

Em dezembro 22, 2017 13:55 Manuel Reimer escreveu:

On 12/22/2017 03:17 PM, Giancarlo Razzolini via arch-general wrote:
Well, so far you said you want to autobuild some packages and that it 
MUST run

as root, with no good reason why.


I have a set of PKGBUILD's (around 40) and a self-made "build system":

http://repo-make.tuxfamily.org/

The autobuild system works completely without user interaction. You just 
call "repo-make" and it will do *everything* that is needed to finally 
have a working local repository.


This is meant to be used on a dedicated build VM and never on any 
productive system.


Now my idea was to improve this process by doing every build in a chroot 
environment.


So far my build system does things like installing packages directly, so 
makepkg never has to do this as this would cause silly sudo password 
prompts that I don't want to have in a fully automated build.




Now that things are a little more clear, I can tell you that, you mixes building
software, packaging software and installing it. Of the three, only the last one
(usually) requires root permissions.



I want to avoid unnecessary work that is not needed on a system that is 
meant only to be used to build some packages. If I ever trash this 
system, I just restore the VM from a backup.




If you build software always as root, you might mask some problems. I
personally wouldn't trust any software that cannot be built as a regular
user.



I have an existing build system that I call with root permissions and 
from this point on it does everything on its own. Including creating the 
required build user, fetching build dependencies, building packages in 
context of the build user, ...


My idea was to make use of "chroot building" to have a clean state of 
packages for every build. If this is possible, I would add this. If 
fully automated processing doesn't work with the existing tools, I'll 
stick with my way and keep building without chroot.




You keep saying chroot and I guess that arises from the name of the tool,
makechrootpkg. But keep in mind that you don't actually use a chroot, you
use a container. There's a difference, and it's not just semantics.

To me, it seems, that all you need is to give NOPASSWD permissions to
whatever user you choose to use on your VM. That way you would not get
any prompts and build everything with the minimal permission set possible.

Regards,
Giancarlo Razzolini

pgpn_tSkIXeLU.pgp
Description: PGP signature

Re: [arch-general] How to build package in "clean chroot" using the "-U" parameter?

[Giancarlo Razzolini via arch-general]

Em dezembro 22, 2017 10:31 Manuel Reimer escreveu:


Question is: What is the intended goal. I guess it is not what I want to do?



Well, so far you said you want to autobuild some packages and that it MUST run
as root, with no good reason why.

My autobuild process runs as root. It also directly updates the chroot 
which also needs root permissions so it's the best to start with "root" 
and then drop privileges for the tasks that shouldn't run with root 
privileges. The whole system is a dedicated build VM, so there is no 
reason to not use "root" for the main purpose of this machine.




There's no reason to change the way the software gets built either. It seems
to me you're trying to avoid some extra work by running everything as root.



That seems to be the one that works for me.



If you share more of what you're trying to do, and your goals, perhaps we can
help more. So far it seems like a mild XY problem.

Regards,
Giancarlo Razzolini

pgpgpQNISLC8R.pgp
Description: PGP signature