[gentoo-user] Emacs interface for Bugzilla, including bugs.gentoo.org

[akater]

I've written Emacs interface to Bugzilla web-based bug trackers quite
some time ago.  That includes the Gentoo bug tracker bugs.gentoo.org

I can't pay as much attention to this Emacs package as I'd like to, and
not everything is great in it but it seems to work and be useful enough.
Maybe if somebody else finds it useful, I'll work more on it.  So, if
you're interested, you are welcome to

eselect repository enable akater &&
emerge app-emacs/bugz

(Hopefully, that will go without errors.)

See the brief intro at
https://framagit.org/akater/emacs-bugz/-/blob/master/bugz.org

Use at your own risk, I haven't tested it much.  Feedback is welcome.


signature.asc
Description: PGP signature

[gentoo-user] Arranging a specialized instance of emacs --daemon in a Gentoo package

[akater]

I've been running gentoo-managed emacs-daemon because I trust Gentoo to
do the right thing but I never figured out why the procedure is the way
it is.  Now I'm trying to package a “standalone” Emacs application and
the best way to do provide a mainstream entry point to it, is something
along the lines of

cat /usr/bin/my-application.sh

if [ emacs-my-application-running() ] ; then
emacsclient -s emacs-${USER}-my-application
else
emacs -Q --daemon=emacs-${USER}-my-application \
  -L necessary-dirs --eval "(run-my-application)"
fi

but I wonder if I should run a daemon this way in Gentoo, or is there a
more preferrable way?

I don't want to use default daemon setup though because I want to run a
specific instance with named socket, to isolate the application.


signature.asc
Description: PGP signature

[gentoo-user] What files does GNU Emacs 27 load on startup on Gentoo, and in what order?

[akater]

Info node “The Emacs Initialization File” mentions

- init.el which is described in enough detail

- default.el which is found via “the standard search path for libraries”
  — what would that be?

- site-start.el instead of which Gentoo has site-gentoo.el (I guess) —
  but when is it loaded and how does Emacs know to load site-gentoo.el?
  and why isn't it compiled?

- early-init.el, “loaded before the package system and GUI is
  initialized” — is it loaded before or after site-gentoo?

And does Gentoo load anything else, by chance?

Finally, is there a difference in what files are being loaded between 
“rc-service
emacs.user start” and just “emacs” in user's shell?


signature.asc
Description: PGP signature

RE: [gentoo-user] 5.4 kernels won't compile

[akater]

"Pengcheng Xu"  writes:

> A quick Google with keyword "R_X86_64_PC64 uclibc" shows that uclibc is 
> missing some ELF definitions that are needed for newer kernels:
>
> https://gogs.waldemar-brodkorb.de/oss/uclibc-ng/issues/2
>
> You may try the proposed solution there (to insert the definition into 
> /usr/include/elf.h), but IMHO this should be handled by uclibc-ng themselves 
> or a patch in Gentoo.  As it seems like you've packaged uclibc-ng yourself 
> (sys-libs/uclibc-ng:   1.0.33::akater) maybe you would want to add a 
> patch there instead.

Thank you!  I did some web search (DDG) but managed to missed this.


signature.asc
Description: PGP signature

[gentoo-user] 5.4 kernels won't compile

[akater]

Neither linux-5.4.28-gentoo nor linux-5.4.38-gentoo would compile, with the 
following error:

> CFLAGS="-Wno-error=undef" make && make modules_install
>   HOSTCC  scripts/basic/fixdep
>   HOSTCC  arch/x86/tools/relocs_32.o
>   HOSTCC  arch/x86/tools/relocs_64.o
> In file included from arch/x86/tools/relocs_64.c:18:
> arch/x86/tools/relocs.c: In function 'rel_type':
> arch/x86/tools/relocs.c:201:12: error: 'R_X86_64_PC64' undeclared (first use 
> in this function); did you mean 'R_X86_64_64'?
>   201 |   REL_TYPE(R_X86_64_PC64),
>   |^
> arch/x86/tools/relocs.c:197:22: note: in definition of macro 'REL_TYPE'
>   197 | #define REL_TYPE(X) [X] = #X
>   |  ^
> arch/x86/tools/relocs.c:201:12: note: each undeclared identifier is reported 
> only once for each function it appears in
>   201 |   REL_TYPE(R_X86_64_PC64),
>   |^
> arch/x86/tools/relocs.c:197:22: note: in definition of macro 'REL_TYPE'
>   197 | #define REL_TYPE(X) [X] = #X
>   |  ^
> arch/x86/tools/relocs.c:201:12: error: array index in initializer not of 
> integer type
>   201 |   REL_TYPE(R_X86_64_PC64),
>   |^
> arch/x86/tools/relocs.c:197:22: note: in definition of macro 'REL_TYPE'
>   197 | #define REL_TYPE(X) [X] = #X
>   |  ^
> arch/x86/tools/relocs.c:201:12: note: (near initialization for 'type_name')
>   201 |   REL_TYPE(R_X86_64_PC64),
>   |^
> arch/x86/tools/relocs.c:197:22: note: in definition of macro 'REL_TYPE'
>   197 | #define REL_TYPE(X) [X] = #X
>   |  ^
> arch/x86/tools/relocs.c: In function 'do_reloc64':
> arch/x86/tools/relocs.c:802:7: error: 'R_X86_64_PC64' undeclared (first use 
> in this function); did you mean 'R_X86_64_64'?
>   802 |  case R_X86_64_PC64:
>   |   ^
>   |   R_X86_64_64
> make[1]: *** [scripts/Makefile.host:124: arch/x86/tools/relocs_64.o] Error 1
> make: *** [arch/x86/Makefile:232: archscripts] Error 2

I did not find anything relevant on Gentoo forums or on this mailing
list.  Configuration is a little non-standard.  The first lines of
emerge --info:

> Portage 2.3.99 (python 3.7.7-final-0, 
> default/linux/amd64/17.0/uclibc/hardened, gcc-9.3.0, uclibc-ng-1.0.33, 
> 4.19.97-gentoo-poseidon x86_64)
> =
> System uname: 
> Linux-4.19.97-gentoo-poseidon-x86_64-Intel-R-_Core-TM-2_Duo_CPU_L9400_@_1.86GHz-with-gentoo-2.6
> KiB Mem: 1929164 total,152428 free
> KiB Swap:  0 total, 0 free
> Timestamp of repository gentoo: Fri, 08 May 2020 05:00:01 +
> Head commit of repository gentoo: 92957d0a4e66217194d92beb864ef7b9f2c04cbb
> sh bash 5.0_p17
> ld GNU ld (Gentoo 2.33.1 p2) 2.33.1
> ccache version 3.7.7 [enabled]
> app-shells/bash:  5.0_p17::gentoo
> dev-lang/perl:    5.30.1::gentoo
> dev-lang/python:  2.7.18::gentoo, 3.7.7-r2::gentoo, 3.8.2-r2::gentoo
> dev-util/ccache:  3.7.7-r1::gentoo
> dev-util/cmake:   3.16.5::akater
> sys-apps/baselayout:  2.6-r1::gentoo
> sys-apps/openrc:  0.42.1::gentoo
> sys-apps/sandbox: 2.13::gentoo
> sys-devel/autoconf:   2.69-r4::gentoo
> sys-devel/automake:   1.16.1-r1::gentoo
> sys-devel/binutils:   2.33.1-r1::gentoo
> sys-devel/gcc:9.3.0::gentoo
> sys-devel/gcc-config: 2.2.1::gentoo
> sys-devel/libtool:2.4.6-r6::gentoo
> sys-devel/make:   4.2.1-r4::gentoo
> sys-kernel/linux-headers: 5.4::gentoo (virtual/os-headers)
> sys-libs/uclibc-ng:   1.0.33::akater

Please help.


signature.asc
Description: PGP signature

Re: [gentoo-user] [bug] uClibc-ng-1.0.33 won't fetch

[akater]

Michael Orlitzky  writes:

> www-client/pybugz

I have that one installed, actually!  But I'd rather use it through
Elisp interface... which I'm likely to write if nobody else does but
it's unlikely to happen in the upcoming months.  And I'm concerned of
being banned during prototyping.


signature.asc
Description: PGP signature

Re: [gentoo-user] [bug] uClibc-ng-1.0.33 won't fetch

[akater]

tastytea  writes:

> Same here. You should report it to
> .

Thanks for checking.  I'm sorry but the only way I could post to
bugzilla now is from a web browser—which is very unpleasant on its own,
and on top of that I only have graphical browser available on a handheld
device at the moment.  Bugzilla insists that a submitter provides emerge
--info output for any bug report posted.  With a web browser on a
handheld device, I can do it but not today.

There's a python tool that I plugged in but I'm not comfortable with it
in the absence of a proper interface; I'm unlikely to get to writing the
interface in the upcoming months.

If there's an Emacs-friendly way to post bugs, I'd be glad to know:
there are ≈6 bugs and patches waiting in my queue.


signature.asc
Description: PGP signature

[gentoo-user] [bug] uClibc-ng-1.0.33 won't fetch

[akater]

I can't fetch sys-libs/uclibc-ng-1.0.33 from distfiles.gentoo.org (404),
and the file fetched from downloads-uclibc-ng.org has a hash different
from that in Manifest.  Thus, uclibc-ng-1.0.33 can't be installed, and I
guess it's a bug.


signature.asc
Description: PGP signature

[SOLVED] [gentoo-user] Can't boot Minimal Installation CD (ISO loopback; not a UEFI boot)

[Akater]

Mick  writes:

> In the first instance have a look at the 'linux' lines here:
>
> https://gist.github.com/smoke/47f5250b9e6f59a5d172
>
> You've missed some critical parameters, like 'cdroot'.

Thanks a lot, boot completed with the following parameters set:

linux  (loop)/boot/gentoo keymap=dvorak nosound nonfs isoloop=${iso} cdroot 
isoboot=${iso}


signature.asc
Description: PGP signature

[gentoo-user] Can't boot Minimal Installation CD (ISO loopback; not a UEFI boot)

[akater]

I downloaded a recent (20190925) Minimal Installation amd64 image and
tried to boot into it from a USB device. An old version of
SystemRescueCD is installed alongside and boots fine.

The machine is fairly old and has traditional BIOS and 2048M RAM

My GRUB menuentry for the image is

menuentry "Gentoo Minimal Installation CD 20190925" {
search --no-floppy --fs-uuid --set=root 
6dbfd182-36fb-4476-a414-f5a8cca975bb
set iso=/install-amd64-minimal-20190925.iso
loopback loop ${iso}
linux  (loop)/boot/gentoo keymap=dvorak nosound nonfs isoloop=${iso}
initrd (loop)/boot/gentoo.igz
}

Boot fails at determining root device:
!! Could not find the root block device in .

I guess menuentry might be misconfigured but I can't figure out what's
wrong with it. Minimal Installation CD is supposed to be bootable even
in the absence of external storage devices, so everything should happen
inside RAM, right? If so, then I don't get what could possibly go wrong
as long as kernel and initrd are found unless there's an issue with
Minimal Installation CD itself.


signature.asc
Description: PGP signature

[gentoo-user] Note: USE=ffmpeg alsa-plugins-1.1.6 won't build with recent ffmpeg

[akater]

Apparently, this is due to removal of deprecated audio resampling
functions but I didn't check thoroughly.

https://www.ffmpeg.org/doxygen/2.4/group__lavc__resample.html

Whatever the issue is, it is not reflected in ebuild yet. Just FYI.


signature.asc
Description: PGP signature

[gentoo-user] [SOLVED] Please help with `C compiler cannot create executables'

[Akater]

Martin Vaeth  writes:

> So "normally" the correct solution would be to clean up /usr/local/.
> Of course, if you intentionally installed something there, this
> might be wrong. But your problem is very likely caused by this.
This was indeed the cause, thank you.

Further comments made for the
reference, in case someone has the same issue.

>>> cc1: fatal error: /usr/local/include/stdc-predef.h: Permission denied
>
> It seems that you have this file but that it is not readable
> by user/group portage:portage.
There is no such file. I posted the relevant ls output in the original
message.

> The main question is: Why do you have something in /usr/local/ at all?
> If you did not install anything outside of portage, this directory
> should be empty (up to some perhaps empty directories).
Indeed, I did install something outside of portage. Found no appropriate
ebuilds (ebuild repositories included); instead of writing my own,
just followed the procedure as described upstream. This was likely a bad idea.

Gentoo keeps /usr/local in the list of paths for gcc. If /usr/local is
missing something crucial, gcc becomes broken, I guess. In my case, I
removed directories and symlinks
/usr/local/include
/usr/local/lib
/usr/local/lib64
/usr/local/share
that were all created at the time of outside-portage installation. GCC
works fine now.


signature.asc
Description: PGP signature

[gentoo-user] Please help with `C compiler cannot create executables'

[Akater]

This came unexpectedly. An excerpt from compile.log is posted
below. (I'll post more if necessary of course.) I'm not very experienced
with C compilers in general and gcc in particular so I hope for some
directions on what the cause of the issue might be. I tried removing
CFLAGS settings from make.conf, to no effect.
(CFLAGS is `-march=native -O2 -pipe')

I upgraded GCC recently; world, kernel rebuilt successfully and gcc had
been working just fine for some time since then.

I did not do anything particularly weird with the system that could
cause this. However,
(1) I do use a somewhat old profile:
hardened/linux/amd64 (stable).
(2) I recently had a build conflict with
util-linux and rfkill: the latter had been included in the former but I
was not aware of that at the time and updated some packages (don't
remember which ones) while masking the corresponding util-linux version
and newer versions. Still, it was a normal portage update and no
warnings were issued.
(3) The kernel sources used are non-standard.

A relevant bit from compile.log (the package is sys-apps/file):

> gcc version 7.3.0 (Gentoo Hardened 7.3.0-r3 p1.4) 
> configure:3711: $? = 0
> configure:3700: x86_64-pc-linux-gnu-gcc -V >&5
> x86_64-pc-linux-gnu-gcc: error: unrecognized command line option '-V'
> x86_64-pc-linux-gnu-gcc: fatal error: no input files
> compilation terminated.
> configure:3711: $? = 1
> configure:3700: x86_64-pc-linux-gnu-gcc -qversion >&5
> x86_64-pc-linux-gnu-gcc: error: unrecognized command line option '-qversion'; 
> did you mean '--version'?
> x86_64-pc-linux-gnu-gcc: fatal error: no input files
> compilation terminated.
> configure:3711: $? = 1
> configure:3731: checking whether the C compiler works
> configure:3753: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe  -Wl,-O1 
> -Wl,--as-needed conftest.c  >&5
> cc1: fatal error: /usr/local/include/stdc-predef.h: Permission denied
> compilation terminated.
> configure:3757: $? = 1
> configure:3795: result: no
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "file"
> | #define PACKAGE_TARNAME "file"
> | #define PACKAGE_VERSION "5.33"
> | #define PACKAGE_STRING "file 5.33"
> | #define PACKAGE_BUGREPORT "chris...@astron.com"
> | #define PACKAGE_URL ""
> | #define PACKAGE "file"
> | #define VERSION "5.33"
> | #define BUILTIN_ELF 1
> | #define ELFCORE 1
> | /* end confdefs.h.  */
> | 
> | int
> | main ()
> | {
> | 
> |   ;
> |   return 0;
> | }
> configure:3800: error: in 
> `/var/tmp/portage/sys-apps/file-5.33-r4/work/file-5.33-abi_x86_64.amd64':
> configure:3802: error: C compiler cannot create executables

Note:

> ~ $ sudo ls -la /usr/local/include
> total 12
> drwxr-x--- 3 root root 4096 Jul 24 02:12 .
> drwxr-xr-x 8 root root 4096 Jul 24 02:12 ..
> drwxr-x--- 2 root root 4096 Jul 24 02:12 ykpers-1

Thank you.


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Would unmerging xorg-server certainly help it?

[Akater]

Ian Zimmerman  writes:

> On 2018-03-25 17:49, Martin Vaeth wrote:
>
>> It should be scrnsaverproto-1.2.2-r2 which is pulled in.
>> Maybe you sync'ed at an unfortunate moment. Try emerge --sync again.
>
> In my case at least, the root cause was this: in the nightly webrsync
> snapshot (which I prefer to use instead of rsync),
> scrnsaverproto-1.2.2-r2 is keyworded and not stable.  Adding it to
> portage/package.use magically unblocks everything.

Yep. webrsync here too. Adding

> =x11-proto/scrnsaverproto-1.2.2-r2 ~amd64

to package.accept_keywords unblocked everything for me. Thank you.


signature.asc
Description: PGP signature

Re: [gentoo-user] Would unmerging xorg-server certainly help it?

[Akater]

The subject question of my message is stated in the last paragraph.

Helmut Jarausch  writes:

> Try to emerge x11-base/xorg-proto and x11-proto/scrnsaverproto  
> simultaneously.

I just tried

> emerge --ask --verbose --update --oneshot x11-base/xorg-proto 
> x11-proto/scrnsaverproto

and it didn't work:

 > * Error: The above package list contains packages which cannot be
 > * installed at the same time on the same system.

 >  (x11-proto/scrnsaverproto-1.2.2-r1:0/0::gentoo, installed) pulled in by
 >x11-proto/scrnsaverproto

 >  (x11-base/xorg-proto-2018.4:0/0::gentoo, ebuild scheduled for merge) pulled 
 > in by
 >x11-base/xorg-proto

Note: I have a fairly nonstandard setup, and have not yet migrated from

> hardened/linux/amd64 (stable)

to

> default/linux/amd64/17.x/hardened (stable for x=0, exp for x=1)

but despite having a specific setup, I seem to have the same issues as
OP.

Can you (or anyone reading this) confirm from first-hand experience that
unmerging xorg-server would help? It won't be a problem for me as long
as it is certain that I'll have xorg-server back by tomorrow and would
not, say, find out that due to some interesting turn of events I'm going
to spend an indefinite amount of time in console. Note: I'd rather not
mess with binary packages, either.


signature.asc
Description: PGP signature

[gentoo-user] mesa 17.1.10 update caused slight tearing for Firefox context menu

[Akater]

After a recent mesa update on gentoo-hardened, Firefox context menu
fades in with artifacts, as if fade-in effect was drawn too slowly. It's
not a big deal but it's certainly visible.

I can't be absolutely sure it's mesa. Looks like that.

Info from eix output:

 Installed versions:  17.1.10^d(01:53:11 2017-12-05)(classic dri3 egl 
gallium gbm nptl pax_kernel pic vaapi -bindist -d3d9 -debug -gles1 -gles2 -llvm 
-opencl -openmax -osmesa -selinux -unwind -valgrind -vdpau -vulkan -wayland -xa 
-xvmc ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" 
ABI_X86="64 -32 -x32" VIDEO_CARDS="i965 r600 -freedreno -i915 -imx -intel 
-nouveau -r100 -r200 -r300 -radeon -radeonsi -vc4 -vivante -vmware")

No other rendering issues were observed. However, I don't use demanding
graphics all that much; it has always been Firefox that produced
artifacts.

Not sure if this can be helped easily, unless there's something with my
USE flags that more experienced mailing list readers would find
suspicious.


signature.asc
Description: PGP signature

[gentoo-user] Why do systemd scripts get installed with USE="-systemd"?

[Akater]

It looks like systemd scripts often (always?) get installed, regardless
of USE flag settings.

Why would they? Is this a policy?

E.g., in

cat /usr/portage/net-p2p/transmission/transmission-2.92-r2.ebuild | grep 
systemd_
systemd_dounit daemon/transmission-daemon.service
systemd_install_serviced "${FILESDIR}"/transmission-daemon.service.conf

why not

if use systemd ; then
   systemd_dounit daemon/transmission-daemon.service
   systemd_install_serviced "${FILESDIR}"/transmission-daemon.service.conf
fi

instead?



signature.asc
Description: PGP signature