Diego Petten

Okay this is not news, but seems like it’s still a problem for someone, so I’m following fox2mike’s suggestion (from yesterday.. I initially forgot about doing so), and I’m blogging about it…

So many people using ~arch or some packages out of ~arch might have seen that a new update to shadow (>=4.0.12-r2) blocks pam-login, and pam-login blocks newer versions of shadow.
Why this? Well it’s simple to say for me, as I know the background, but might be less easy to understand without knowing that.

So let’s start with the reason why /bin/login was not provided by shadow when using pam (thing that happens on most desktop systems)… to be honest, I don’t know that for sure, probably it’s just that shadow weren’t providing a PAM-enabled /bin/login or it had problems in the past.. so we just gone using pam-login package from SuSE (in the good days when people _provided_ the tarballs for other distributions to use), the 3.x series.
This was all good until shadow 4.0.something started providing a valid /bin/login, so we just had pam-login ebuild to build /bin/login from shadow source code.. but that meant we had to build the same code two times, and maintain patches for two packages instead of one.

So as this was planned for a while but Azarah hasn’t had time to handle that, I decided to do the merge between the two: since shadow 4.0.14-r2 the single sys-apps/shadow package replaces both shadow AND the old pam-login package. This means that they block each other now, so you have to do something like:

emerge -C pam-login && emerge -u shadow

if you want to have your system working fine. If you just unmerge pam-login but NOT update shadow, you won’t be able to login in the system if you restart (although already running sessions, already waiting login prompts, xdm and variants and ssh won’t be affected).

Please also note that you need a recent version of util-linux, that dropped the pam useflag, if you want to be sure that it won’t request you to merge pam-login again; ~arch version is fine. For older versions you might want to just set util-linux to use -pam with package.use as it doesn’t change anything anyway.

Now, don’t start asking for better way to handle this, as portage does not provide anything to improve this. This works without strange surprises, so just drop pam-login and you’ll be fine

Update: Comments have been closed because this post had too much spam coming. If you want to say yours, use the repost. Thanks, Diego.

So, up to now I usually responded to strict aliasing breakage from programs with adding -fno-strict-aliasing to be safe.
In the last days I tried, on Donnie’s suggestion, to investigate of possible solutions to those strict aliasing rules breakage and see if I can fix at least some of them.

I found interestingly that most of the cases that can be found patched on google, and that causes the warnings are not actually involving structs and unions as the gcc documentation shows, but rather double pointers. What’s a double pointer? A pointer to a pointer, of course!

Taking a look to XdTV, I found a quite interesting thing: this is a double-linked list implementation that comes out of AleVT code, that is used by XdTV too. The cause of the warnings come out of lines 20 and 22. I’ll look only at line 20:

h->first = (struct dl_node *)&h->null;

well seems fine no? But wait… &h->null is a struct dl_node ** …
And later on, h->first is going to be used as a struct dl_node * …
So for some kind of miracle this seems to work, but I’m not that sure that this is something that’s going to work forever.

And there are other casts that works probably only for sheer luck in AleVT’s code. Upstream seems to be dead sicne 2 years (last update on the site is January 2004), and we don’t have really good alternatives to it…
If someone wants to write something useful to people.. probably a replacement for alevt using zvbi would be useful

It’s not the first time I blog of something just not to forget about that This time it’st he turn of how to set the name of core dump files to something meaningful so that I can know which hell of an app left them around.
I have to thank ehmsen and brix for pointing me to the right directions as I had no clue how to do that before

Why do I need such a name scheme? Well I’m experiencing some strange crashes lately with akregator and a few other programs so I’m tempted to just get a backtrace and then check where the problem is hidden, unfortunately by enabling corefiles for everything you get a lot of files named “core” or “core.<pid>”, nothing useful to recognise what you’re looking for.

So what’s the solution? /proc/sys/kernel/core_pattern is where the kernel take the template for the core files naming… so I just changed that to ‘%e.%p.core’ and now i have the files just called “<executable>.<pid>.core” (so that they don’t overwrite each other). Good eh?

To make this a stable change, just put at the end of /etc/sysctl.conf the line
kernel.core_pattern = %e.%p.core
Now, I just need to remember how to enable core files for my user to be always generated …
IIRC it should be something like
flame C204800
in /etc/limits (limiting to 20MB of dump). But I still have to try

Ok today here in Italy is holiday and I stopped working on the translation I’m paid for (it’s also sunday so it’s “double holiday” ).
The day is good and the sun is shining so I’m out on my garden with my iBook working on gentoo via ssh to the main box and screen. X-Chat Aqua let me maintain the link with #gentoo-dev and other chans.

The cell phone is off an I feel more free than usual. So I’m in a good mood for a blog entry

One of the most annoying task when maintaining packages on gentoo is maintain clean the patches which, by version to version, doesn’t apply and needs to be re-created mainly manually. This task is needed because sometime we have to change the way packages works to make them follow gentoo’s structure in installing files or other things.
Other usual patches you need to prepare are when upstream didn’t cared about 64-bit architectures (which were pretty rare until a few monhts ago we can say, as amd64 (Athlon64 and Opterons), ppc64 (G5) and ia64 (Itanium) are recent processors. In those case you can have a lot of warnings about int casted to pointers and the other way ’round. The problem here is that the size of a pointer in a 64-bit arch is 64-bit instead the size of int is just 32-bit. long type is usually the same size of the pointers, and ptrdiff_t should be used to do arithmetic computation with pointers.
Also with the newest gcc (4.0.0) most of those warnings are became erros and need a complete fix. This is good as code ingoring those warnings usually produce wrong binaries.

Another kind of problem is when borked configures doesn’t like passing –enable to commandline (for example when they consider every –enable|disable-something as a –disable) or when they just use automagical test for libraries presence, which makes useflag not honourable.
In video category there are many apps which has a lot of dependencies in external libraries to mangle file formats, and many of them doesn’t provide enough configure params to satisfy our useflags needs, so I have hacked most of those configure scripts to add params and sent them upstream. Most of them was applied upstream, a few weren’t and I’m still hoping for them being applied as they are a big pain.

One of the package for which I’m having most patches is xine-lib. Mainly because it’s a popular package which is installed in a lot of different machines with different setups, but also because its configure.ac was really messy, and for a long time the package wasn’t able to exclude some plugins and the ebuild used to depend on something line aalib which was useless for most users. Then there was my rewrite which used autoconf cache tricks, but it was probably not working with confcache so I preferred to patch xine-lib to add the needed params. Still the patch is not applied and it needs a lot more work to have it clean anyway.

But it’s onot only the configures which are a pain to fix because they aren’t complete or just suits the setups of the developers, there is also the PIC __PIC__ stuff: libtool used to define -DPIC to select between PIC and non-PIC stuff, but gcc already defines __PIC__ if -fPIC is passed, and sometimes the -DPIC is simply missing for some reasons and the things need to be changed accordlinh.

Most of those errors are things which gots warning or which needs to pay attention to to be sure that they works, but they can be real pain when the complier start to be stricter (which occours every gcc release).

Now, I hope the new patches I’m working on for xine-lib can be applied upstream so next release would simply drop the patches.. it’s being a few versions in which the patches aren’t being dropped but added (well, a part from the security fixes and the wma stuff added in -r2, -r4 and removed in 1.0.1.

Oh I forgot to say what I’m working on at the moment… it’s just a little little patch to enable vidix support on amd64 (I had a report for a gcc4 problem in vidix driver, I fixed it and tried to compile it but vidix support wasn’t being built at all, then I started looking at it and I found out that it wasn’t supported on amd64, and I’ve make it be accepted and compile. Now the vidix output plugin is on my system, but it seems not to work at runtime. I’m investigating this.

Oh you’ll find that post in an hour not suited to be outside in my timezone (20:30), but that’s because I had a friend here and stopped blogging.