Re: [arch-general] About cron utility

[gt]

On Sat, Jan 07, 2012 at 05:50:06AM +0100, Heiko Baums wrote:
> Am Sat, 7 Jan 2012 11:49:48 +0800
> schrieb 郑文辉(Techlive Zheng) :
> 
> > Which cron utility should I use,cronie or dcron?
> 
> I would still recommend fcron.

I am using dcron, and am quite satisfied with it. Can you elaborate why
you recommend fcron, i might switch.

-- 
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Re: [arch-general] linux-api-headers in core is 3.1.5 while linux is 3.1.6

[Patrick Buddeberg]

Thank you.

-Patrick

Re: [arch-general] About cron utility

[Gour]

On Sat, 7 Jan 2012 05:50:06 +0100
Heiko Baums  wrote:

> I would still recommend fcron.

+1


Sincerely,
Gour


-- 
As the ignorant perform their duties with attachment to results, 
the learned may similarly act, but without attachment, for the 
sake of leading people on the right path.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature

Re: [arch-general] PKGBUILD question

[Magnus Therning]

On Fri, Jan 06, 2012 at 07:41:32PM -0800, Don Juan wrote:
> I am trying to update a AUR pkgbuild I found and the source file
> when I download it has a - in the file name
> 
> name_2.0.1-beta1
> 
> I figure out using ${pkgver//_/-} converts it properly when listing
> it as name_2.0.1_beta1.
> 
> The problem I have run into and can not seem to find info about or
> something I have ever run into is that it seems bsdtar when
> extracting is making the name as name_2.0.1-BETA1 and not making it
> name_2.0.1-beta1 and makepkg fails saying it can not find the proper
> file of name_2.0.1-beta1.
> 
> I have it as so in my PKGBUILD
> package() {
>  cd ${srcdir}/${pkgname}_${pkgver//_/-}
> 
> also as
> cd ${srcdir}/${pkgname}_${pkgver}
> 
> the tarball being downloaded converts properly and dl's fine, it
> just seems to be in the next step for package, unless I just really
> am not grasping this yet. If so feel free to say I need to read
> more. But I think its something easy I am just looking over.

You do realise there is no *requirement* to use $pkgname and $pkgver,
right?  You can just hard code the correct names into the PKGBUILD
and be done with it.  The only drawback is that you need to modify a
few more places when updating the package in the future.  That is a
*very* minor drawback in the vast majority of cases.

Also, in the future consider uploading the PKGBUILD you are working on
to a pastebin.  It will likely make it much easier to ask you
question. :-)

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4 
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus


Perl is another example of filling a tiny, short-term need, and then
being a real problem in the longer term.
 -- Alan Kay


pgpecMAcO9dRt.pgp
Description: PGP signature

Re: [arch-general] PKGBUILD question

[C Anthony Risinger]

On Fri, Jan 6, 2012 at 9:41 PM, Don Juan  wrote:
>
> the tarball being downloaded converts properly and dl's fine, it just seems
> to be in the next step for package, unless I just really am not grasping
> this yet. If so feel free to say I need to read more. But I think its
> something easy I am just looking over.

paste the PKGBUILD in it's entirely somewhere for review.

-- 

C Anthony

Re: [arch-general] linux-api-headers in core is 3.1.5 while linux is 3.1.6

[C Anthony Risinger]

On Jan 6, 2012 9:52 PM, "Patrick Buddeberg" @
gmail.com > wrote:
>
> Honestly, even a "Let Me Google that For You" link would be useful to
> my mental blocked self right now.

http:// 
lmgtfy.com 
/?q=sanitized+kernel+headers+stable+
libc 
+
abi 

;-)

http:// 
lkml.indiana.edu
/ 
hypermail
/linux/kernel/0007.3/0587.
html 

[ http:// 
lwn.net
/Articles/434318/  ]

"The most common way to invoke the kernel is by using GNU libc (glibc).
Glibc has a set of "sanitized" kernel header files that are used to build
the library, and distributions typically provide packages with those header
files to be installed into /usr/include.  Programs can then be built by
using those header files and linking to glibc. While "sanitized" may sound
like it refers to the removal of GPL-covered elements from those files, the
main reason it is done is to remove kernel-specific elements from the
files. The kernel headers have lots of kernel-internal types, constants,
and functions that are not part of the kernel interface.

It isn't really correct to call the interface that the kernel provides to
user space an API (i.e. application programming interface), as it is really
an application binary interface (ABI), and one that the kernel hackers
strive to maintain for each new kernel release. Removing something from the
kernel ABI almost never happens, though new features expand that ABI
frequently. The ABI is what allows binaries that were built on an earlier
kernel to run on newer kernels. The API, on the other hand, is provided by
glibc or some other library."

(kernel can generate its own sanitized headers since 2.6.18)

... so in my understanding, glibc can take advantage of new kernel features
simply by being rebuilt -- when you invoke syscalls/etc from userspace, you
call them THRU the libc library -- libc can do whatever behind the scenes
to make use of additional features other user space programs are unaware
of, so long as the expected return types match.  Without this, binaries
would break all the time because the perceived API would be in constant
flux, even though the ABI is back-compat ... all of user space looks to
glibc to access kernel, so the API files update when glib updates, and do
not correlate with the actual kernel in-use (please anyone expand/correct
as needed ... my knowledge is only ~30 min old)

C Anthony [mobile]

Re: [arch-general] About cron utility

[Heiko Baums]

Am Sat, 7 Jan 2012 11:49:48 +0800
schrieb 郑文辉(Techlive Zheng) :

> Which cron utility should I use,cronie or dcron?

I would still recommend fcron.

Heiko

Re: [arch-general] linux-api-headers in core is 3.1.5 while linux is 3.1.6

[Patrick Buddeberg]

On Fri, Jan 6, 2012 at 00:12, Allan McRae  wrote:
> On 06/01/12 18:00, Patrick Buddeberg wrote:
 Maybe is my little understanding of the situation, but isn't
 linux-api-headers behind what it (appears to me that it) should be?
>>
>>> The linux-api-headers package is entirely unrelated to the running or
>>> installed kernel. It contains the headers that give glibc the API to the
>>> Linux kernel, and must never (NEVER NEVER NEVER) be different from the
>>> version that glibc was built against.
>>>
>>> Please, someone give me a cent for every time this question is asked.
>>>
>>
>> It may help if this information is in an easily reachable area, as I
>> couldn't find it anywhere after searching the wiki and forums followed
>> by the internet as a whole. The closest thing that I found was from
>> LFS, but this actually makes it seem like it is very closely bound to
>> both kernel and glibc.
>>
>
> https://bbs.archlinux.org/viewtopic.php?pid=955909
>

Thank you. I derped and didn't check the Newbie Corner but only the
Kernel section. And of course I am just now reading "If no forums are
selected, all forums will be searched." I failed pretty hard there.

Is there somewhere anyone would recommend for getting a more in-depth
understanding of why the API header can be divorced from the kernel.
Honestly, even a "Let Me Google that For You" link would be useful to
my mental blocked self right now.

My guess is that there is an internal symbol table that the API
headers uses, and that they also don't necessarily support the newest
things in the kernel, if there are new things that are being exposed.

Thank you,
-Patrick

"If you tell me that curiosity killed the cat, I say the cat died
nobly" Arnold Edinborough

[arch-general] About cron utility

[Techlive Zheng]

Recently, I noticed that my laptop and server are using different cron
utility.My laptop is using dcron while server using cronie.

Then,I did some digging about the Arch default cron utility.I found a
[discussion](http://mailman.archlinux.org/pipermail/arch-general/2011-April/019282.html)
happend on this list in April 2011. It said that dcron is dead, so
cronie was choosen as default cron utility.Just before I am planning
to use cronie replacing dcron on my laptop, I found that dcron has
released a [update](https://github.com/dubiousjim/dcron/blob/master/CHANGELOG)
on May 1st 2011 just after the discussion with some bugfixes and
improvements like anacron support.

What happend at that time? Is Jim Pryor responded the discussion in
the maillist? Any link?

Which cron utility should I use,cronie or dcron? Cronie in base group
seems has a separate anacrontab in /etc which is not kiss I think? If
anacron functionity has been included in dcron by default, May be dron
is a good choice?

It seems Jim Pryor is using Arch bug tracker as its official place of
dcron development.Is this project dead or alive?

So,what is the official recommendation on this point?

[arch-general] PKGBUILD question

[Don Juan]

I am trying to update a AUR pkgbuild I found and the source file when I 
download it has a - in the file name


name_2.0.1-beta1

I figure out using ${pkgver//_/-} converts it properly when listing it 
as name_2.0.1_beta1.


The problem I have run into and can not seem to find info about or 
something I have ever run into is that it seems bsdtar when extracting 
is making the name as name_2.0.1-BETA1 and not making it 
name_2.0.1-beta1 and makepkg fails saying it can not find the proper 
file of name_2.0.1-beta1.


I have it as so in my PKGBUILD
package() {
 cd ${srcdir}/${pkgname}_${pkgver//_/-}

also as
cd ${srcdir}/${pkgname}_${pkgver}

the tarball being downloaded converts properly and dl's fine, it just 
seems to be in the next step for package, unless I just really am not 
grasping this yet. If so feel free to say I need to read more. But I 
think its something easy I am just looking over.



Thank you for any time and help understanding this.

[arch-general] Perl dependencies

[Qadri]

Below is an excerpt from the integrity check results from arch-dev-public.
It seems like most (if not all) of these are provided by perl, though the
actual packages are in AUR. What is the appropriate solution (before anyone
says the bugtracker, there are already two bugs about this [1] and [2]). I
can think of a few solutions:

A) Making sure packages in the provides array are also in the repository
B) Checking for dependencies (in just the integrity check, if it's not
already in pacman) in the provides array of packages
C) Shifting the set of packages below to depend on perl instead

If the appropriate answer is not C), I'd be interested in adjusting the
Integrity Check code. Just let me know the appropriate solution.

MAQ.

[1] https://bugs.archlinux.org/task/27111
[2] https://bugs.archlinux.org/task/27109

Missing Dependencies
--
community/cpanminus --> 'perl-extutils-install>=1.46'
community/cpanminus --> 'perl-extutils-makemaker>=6.31'
community/cpanminus --> 'perl-module-build>=0.36'
community/perl-data-optlist --> 'perl-scalar-list-utils'
community/perl-devel-patchperl --> 'perl-io'
community/perl-devel-patchperl --> 'perl-ipc-cmd>=0.40'
community/perl-devel-patchperl --> 'perl-mime-base64'
community/perl-device-gsm --> 'perl-test-simple'
community/perl-local-lib --> 'perl-cpan>=1.82'
community/perl-local-lib --> 'perl-extutils-install>=1.43'
community/perl-local-lib --> 'perl-extutils-makemaker>=6.42'
community/perl-local-lib --> 'perl-module-build>=0.36'
community/perl-package-deprecationmanager --> 'perl-carp'
community/perl-package-stash --> 'perl-scalar-list-utils'
community/perl-params-util --> 'perl-scalar-list-utils'
community/perl-sub-install --> 'perl-scalar-list-utils'
community/perl-test-fatal --> 'perl-carp'
community/perl-test-fatal --> 'perl-exporter>=5.57'
community/perl-test-fatal --> 'perl-test-simple'
extra/perl-anyevent --> 'perl-async-interrupt>=1.0'
extra/perl-anyevent --> 'perl-ev>=4.00'
extra/perl-anyevent --> 'perl-guard>=1.02'
extra/perl-libwww --> 'perl-encode>=2.12'
extra/perl-libwww --> 'perl-libnet'
extra/perl-libwww --> 'perl-mime-base64>=2.1'

Missing Makedepends
-
community/perl-data-optlist --> 'perl-extutils-makemaker>=6.30'
community/perl-devel-patchperl --> 'perl-extutils-makemaker>=6.30'
community/perl-dist-checkconflicts --> 'perl-extutils-makemaker>=6.31'
community/perl-package-deprecationmanager -->
'perl-extutils-makemaker>=6.30'
community/perl-package-stash --> 'perl-extutils-makemaker>=6.30'
community/perl-package-stash-xs --> 'perl-extutils-makemaker>=6.30'
community/perl-params-util --> 'perl-extutils-cbuilder>=0.27'
community/perl-params-util --> 'perl-extutils-makemaker>=6.52'
community/perl-params-util --> 'perl-pathtools'
community/perl-sub-install --> 'perl-extutils-makemaker'
community/perl-test-fatal --> 'perl-extutils-makemaker>=6.30'
community/perl-try-tiny --> 'perl-extutils-makemaker'
community/perlbrew --> 'perl-extutils-makemaker>=6.42'
community/perlbrew --> 'perl-file-temp'

Re: [arch-general] Proprietary nvidia driver for kernel-ARCH and kernel-rt

[Oon-Ee Ng]

On Jan 7, 2012 12:02 AM, "Thomas Bächler"  wrote:
>
> Am 06.01.2012 16:57, schrieb Ralf Madorf:
> > On Fri, 2012-01-06 at 16:47 +0100, Thomas Bächler wrote:
> >> Am 06.01.2012 16:32, schrieb Ralf Madorf:
> >>> [ 8.889] Current Operating System: Linux archlinux 3.0-rt #1 SMP
> >>> PREEMPT RT Mon Dec 26 13:03:51 CET 2011 x86_64
> >>
> >> The -rt kernel package still uses the old versioning scheme, where the
> >> patchlevel is removed from the version string. This means that the new
> >> nvidia PKGBUILD won't work and you need to start from an old version.
> >>
> >> Basically, make it look like it was before this change:
> >>
https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/nvidia&id=1b7954a332c32de0ef49a82806fbb18544b26949
> >
> > Thank you :)
> >
> > I'll try it tonight or tomorrow. OTOH I guess I can use 285.05.09-1
> > ( http://aur.archlinux.org/packages.php?ID=12132 ) with $ uname -r
> > 3.1.7-1-ARCH instead of doing this for 290.10?!
>
> No, you can't, you need a version that matches your nvidia-utils package.
>
> These module PKGBUILDs are a mess since I changed the external kernel
> module handling in 3.1 - some AUR kernels use the new scheme, some use
> the old one (hence the problems with nvidia-all).
>
>

I'll try and accommodate both in nvidia-beta-all by next week actually, it
doesn't seem too hard

Re: [arch-general] [signoff] linux-3.2-1

[jwbirdsong]

On 01/06/2012 01:39 PM, Laurent Carlier wrote:
> 2012/1/5 Tobias Powalowski 
> 
>> Hi guys,
>> please signoff 3.2 series for both arches.
>>
>> Upstream
>> changes:
>> http://kernelnewbies.org/LinuxChanges
>>
>> greetings
>> tpowa
>> --
>> Tobias Powalowski
>> Archlinux Developer & Package Maintainer (tpowa)
>> http://www.archlinux.org
>> tp...@archlinux.org
>>
>>
> No sign off here, wifi on my laptop doesn't work anymore.
> 
> It seem the driver brcmsmac (chipset broadcom) isn't available, reverting
> to 3.1.6 fixes the problem.
> 
> ++
> 
I don't have/use it (brcmsmac) so can't verify; but was just reading
this an hour or so before read your mail..
https://bugs.archlinux.org/task/27844?



signature.asc
Description: OpenPGP digital signature

[arch-general] RME HDSPe AIO no audio out

[Ralf Madorf]

Hi :)

there's no audio output by a HDSPe AIO, neither for
$ pulseaudio --kill, nor for $ pulseaudio --start.

Maybe I miss the forest for the trees. I'm not working on my Arch Linux
at the moment, I just tried to get some sound on the quick from YouTube
and then speaker-test.

A test tone from the mixing console to the RME stereo input is shown by
the HDSP Mixer's meters. Audio in seems to be ok, just audio out seems
to be disabled.


$ uname -a
Linux archlinux 3.1.7-1-ARCH #1 SMP PREEMPT Wed Jan 4 08:11:16 CET 2012
x86_64 AMD Athlon(tm) X2 Dual Core Processor BE-2350 AuthenticAMD
GNU/Linux


$ groups
lp wheel games video audio optical storage scanner power users


$ pacman -Qs alsa
local/alsa-firmware 1.0.24.1-1
ALSA firmware package
local/alsa-lib 1.0.24.1-1
An alternative implementation of Linux sound support
local/alsa-plugins 1.0.24-3
Extra alsa plugins
local/alsa-tools 1.0.24.1-1
ALSA tools package
local/alsa-utils 1.0.24.2-3
An alternative implementation of Linux sound support
local/pulseaudio-alsa 1-2 (pulseaudio-gnome)
ALSA Configuration for PulseAudio


$ aplay -l
 List of PLAYBACK Hardware Devices 
card 0: Default [RME AIO_579bcc], device 0: RME AIO [RME AIO]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: EWX2496 [TerraTec EWX24/96], device 0: ICE1712 multi [ICE1712
multi]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: EWX2496_1 [TerraTec EWX24/96], device 0: ICE1712 multi [ICE1712
multi]
  Subdevices: 1/1
  Subdevice #0: subdevice #0


$ lsmod|grep '^snd' | column -t
snd_ice1712 59678   4
snd_ice17xx_ak4xxx  24361   snd_ice1712
snd_ak4xxx_adda 91252   snd_ice1712,snd_ice17xx_ak4xxx
snd_cs8427  69691   snd_ice1712
snd_ac97_codec  114391  1   snd_ice1712
snd_hdspm   58424   0
snd_pcm 74368   3   snd_ice1712,snd_ac97_codec,snd_hdspm
snd_timer   19544   1   snd_pcm
snd_i2c 40652   snd_ice1712,snd_cs8427
snd_mpu401_uart 60111   snd_ice1712
snd_rawmidi 19458   2   snd_hdspm,snd_mpu401_uart
snd_page_alloc  71531   snd_pcm
snd_seq_device  53001   snd_rawmidi
snd_hwdep   63571   snd_hdspm
snd 58362   20
snd_ice1712,snd_ak4xxx_adda,snd_cs8427,snd_ac97_codec,snd_hdspm,snd_pcm,snd_timer,snd_i2c,snd_mpu401_uart,snd_rawmidi,snd_seq_device,snd_hwdep


$ hdspmixer

HDSPMixer 1.6 - Copyright (C) 2003 Thomas Charbonnel 
This program comes with ABSOLUTELY NO WARRANTY
HDSPMixer is free software, see the file COPYING for details

Looking for RME cards :
Card 0 : RME AIO S/N 0x579bcc at 0xfdbf, irq 18
RME AIO found !
Card 1 : TerraTec EWX24/96 at 0xbf00, irq 20
Card 2 : TerraTec EWX24/96 at 0xbb00, irq 21
1 RME cards card found.
Restoring last presets used

I used this preset with Debian, so I can't miss something muted, anyway
I muted and unmuted, resp. changed settings.

Regards,

Ralf

Re: [arch-general] [signoff] linux-3.2-1

[Laurent Carlier]

2012/1/5 Tobias Powalowski 

> Hi guys,
> please signoff 3.2 series for both arches.
>
> Upstream
> changes:
> http://kernelnewbies.org/LinuxChanges
>
> greetings
> tpowa
> --
> Tobias Powalowski
> Archlinux Developer & Package Maintainer (tpowa)
> http://www.archlinux.org
> tp...@archlinux.org
>
>
No sign off here, wifi on my laptop doesn't work anymore.

It seem the driver brcmsmac (chipset broadcom) isn't available, reverting
to 3.1.6 fixes the problem.

++

Re: [arch-general] [signoff] linux-3.2-1

[Jonathan Vasquez]

On Jan 6, 2012 3:27 AM, "Tobias Powalowski" <
tobias.powalow...@googlemail.com> wrote:
>
> Am 06.01.2012 02:58, schrieb Jonathan Vasquez:
> > On Thu, Jan 5, 2012 at 9:19 AM, Tobias Powalowski
> >  wrote:
> >> Hi guys,
> >> please signoff 3.2 series for both arches.
> >>
> >> Upstream
> >> changes:
> >> http://kernelnewbies.org/LinuxChanges
> >>
> >> greetings
> >> tpowa
> >> --
> >> Tobias Powalowski
> >> Archlinux Developer & Package Maintainer (tpowa)
> >> http://www.archlinux.org
> >> tp...@archlinux.org
> >>
> > You might want to hold off on that sign off. There is a Regression Bug
> > affecting Intel users in the final source of 3.2
> >
> > http://www.phoronix.com/scan.php?page=news_item&px=MTAzNzk
> >
> >
> We are not affected by this we don't enable iommu by default.
> You need to activate it with your posted link.
> intel_iommu=on
> So no issue for arch users.
>
> greetings
> tpowa
>
> --
> Tobias Powalowski
> Archlinux Developer & Package Maintainer (tpowa)
> http://www.archlinux.org
> tp...@archlinux.org
>
>

Alright that's good then.

Re: [arch-general] What package owns shread

[Squall Lionheart]

>
> Do you mean shred?
> Never heard of shread..
>

Yes I did, I found that I was just typing it wrong and the "shread" that I
have on my system is something I wrote a long time ago and it confused me.
Sorry for the noise and thanks for your help.

Re: [arch-general] What package owns shread

[Jari Vetoniemi]

Do you mean shred?
Never heard of shread..

Anyways shred is part of coreutils.
You should install pkgtools btw, it contains pkgfile which lets you
know what package provides.

2012/1/6 Squall Lionheart :
> Hello,
>
> I have been trying to figure out what package installs the gnu shread
> program and have had no luck.  Pacman doesn't seem to know either and I was
> hoping someone here might know.  If their is another way of looking this
> up, I would be interested to know as well.
>
> $ pacman -Qo shread
> error: No package owns /usr/local/bin/shread
>
>
> Thank you
>
> --
> Yesterday is history.
> Tomorrow is a mystery.
> Today is a gift.
> That's why its called the present.
>
> Headmaster Squall :: The Wired/Section-9
> Close the world  txen eht nepo
> $3R14L 3XP3R1M3NT$ #L41N
> http://twitter.com/headmastersqual

Re: [arch-general] What package owns shread

[Scott Lawrence]

coreutils owns /bin/shread, but you seem to have your own local copy.

-- 
Scott Lawrence



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] What package owns shread

[Kwpolska]

On Fri, Jan 6, 2012 at 6:42 PM, Squall Lionheart
 wrote:
> Hello,
>
> I have been trying to figure out what package installs the gnu shread
> program and have had no luck.  Pacman doesn't seem to know either and I was
> hoping someone here might know.  If their is another way of looking this
> up, I would be interested to know as well.
>
> $ pacman -Qo shread
> error: No package owns /usr/local/bin/shread
>
>
> Thank you
>
> --
> Yesterday is history.
> Tomorrow is a mystery.
> Today is a gift.
> That's why its called the present.
>
> Headmaster Squall :: The Wired/Section-9
> Close the world  txen eht nepo
> $3R14L 3XP3R1M3NT$ #L41N
> http://twitter.com/headmastersqual

It sits in /usr/local/bin, that means it was installed by hand, either
by you or someone else who has admin rights to this machine (it may
have been an app, too)

-- 
Kwpolska 
stop html mail      | always bottom-post
www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
GPG KEY: 5EAAEA16   | Arch Linux x86_64, zsh, mutt, vim.
# vim:set textwidth=70:

Re: [arch-general] What package owns shread

[Sven-Hendrik Haase]

On 06.01.2012 18:42, Squall Lionheart wrote:
> Hello,
>
> I have been trying to figure out what package installs the gnu shread
> program and have had no luck.  Pacman doesn't seem to know either and I was
> hoping someone here might know.  If their is another way of looking this
> up, I would be interested to know as well.
>
> $ pacman -Qo shread
> error: No package owns /usr/local/bin/shread
>
>
> Thank you
>
We have no packages that install to /usr/local/ that I know of. You
installed it there yourself using make install.

[arch-general] What package owns shread

[Squall Lionheart]

Hello,

I have been trying to figure out what package installs the gnu shread
program and have had no luck.  Pacman doesn't seem to know either and I was
hoping someone here might know.  If their is another way of looking this
up, I would be interested to know as well.

$ pacman -Qo shread
error: No package owns /usr/local/bin/shread


Thank you

-- 
Yesterday is history.
Tomorrow is a mystery.
Today is a gift.
That's why its called the present.

Headmaster Squall :: The Wired/Section-9
Close the world  txen eht nepo
$3R14L 3XP3R1M3NT$ #L41N
http://twitter.com/headmastersqual

Re: [arch-general] Proprietary nvidia driver for kernel-ARCH and kernel-rt

[Thomas Bächler]

Am 06.01.2012 16:57, schrieb Ralf Madorf:
> On Fri, 2012-01-06 at 16:47 +0100, Thomas Bächler wrote:
>> Am 06.01.2012 16:32, schrieb Ralf Madorf:
>>> [ 8.889] Current Operating System: Linux archlinux 3.0-rt #1 SMP
>>> PREEMPT RT Mon Dec 26 13:03:51 CET 2011 x86_64
>>
>> The -rt kernel package still uses the old versioning scheme, where the
>> patchlevel is removed from the version string. This means that the new
>> nvidia PKGBUILD won't work and you need to start from an old version.
>>
>> Basically, make it look like it was before this change:
>> https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/nvidia&id=1b7954a332c32de0ef49a82806fbb18544b26949
> 
> Thank you :)
> 
> I'll try it tonight or tomorrow. OTOH I guess I can use 285.05.09-1
> ( http://aur.archlinux.org/packages.php?ID=12132 ) with $ uname -r
> 3.1.7-1-ARCH instead of doing this for 290.10?!

No, you can't, you need a version that matches your nvidia-utils package.

These module PKGBUILDs are a mess since I changed the external kernel
module handling in 3.1 - some AUR kernels use the new scheme, some use
the old one (hence the problems with nvidia-all).




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Proprietary nvidia driver for kernel-ARCH and kernel-rt

[Ralf Madorf]

On Fri, 2012-01-06 at 16:47 +0100, Thomas Bächler wrote:
> Am 06.01.2012 16:32, schrieb Ralf Madorf:
> > [ 8.889] Current Operating System: Linux archlinux 3.0-rt #1 SMP
> > PREEMPT RT Mon Dec 26 13:03:51 CET 2011 x86_64
> 
> The -rt kernel package still uses the old versioning scheme, where the
> patchlevel is removed from the version string. This means that the new
> nvidia PKGBUILD won't work and you need to start from an old version.
> 
> Basically, make it look like it was before this change:
> https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/nvidia&id=1b7954a332c32de0ef49a82806fbb18544b26949

Thank you :)

I'll try it tonight or tomorrow. OTOH I guess I can use 285.05.09-1
( http://aur.archlinux.org/packages.php?ID=12132 ) with $ uname -r
3.1.7-1-ARCH instead of doing this for 290.10?!

Regards,

Ralf

Re: [arch-general] Proprietary nvidia driver for kernel-ARCH and kernel-rt

[Ralf Madorf]

PPS:
Regarding to the 3.1 vs 3.0 issue, is there the need to use an older
version of the proprietary nvidia driver with current kernel-rt? I don't
need the latest proprietary driver for my computer.

Re: [arch-general] Proprietary nvidia driver for kernel-ARCH and kernel-rt

[Thomas Bächler]

Am 06.01.2012 16:32, schrieb Ralf Madorf:
> [ 8.889] Current Operating System: Linux archlinux 3.0-rt #1 SMP
> PREEMPT RT Mon Dec 26 13:03:51 CET 2011 x86_64

The -rt kernel package still uses the old versioning scheme, where the
patchlevel is removed from the version string. This means that the new
nvidia PKGBUILD won't work and you need to start from an old version.

Basically, make it look like it was before this change:
https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/nvidia&id=1b7954a332c32de0ef49a82806fbb18544b26949



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Proprietary nvidia driver for kernel-ARCH and kernel-rt

[Ralf Madorf]

PS:
> I tried editing the AUR's kernel-rt (see 1. and 2. trial) and I tried to
 should be ^ nvidia-rt PKGBUILD
> build a package using abs (see 3. trail), all failed.

Re: [arch-general] Proprietary nvidia driver for kernel-ARCH and kernel-rt

[Ralf Madorf]

On Fri, 2012-01-06 at 12:03 +0100, Ralf Mardorf wrote:
> Von: arch-general-boun...@archlinux.org im Auftrag von Thomas Bächler
> Gesendet: Fr 1/6/2012 11:28
> > I suspect the AUR's nvidia-rt will conflict with the package
> nvidia?!
> >
> > No, the AUR's nvidia-rt package should be what you want (if you diff
> the
> > nvidia and nvidia-rt PKGBUILDs, the differences should be small).
> >
> Thanks, so you're referring to
>
https://wiki.archlinux.org/index.php/NVIDIA#Alternate_install:_custom_kernel ?
> 
> Ok, if nvidia-rt from AUR would be up to date I could use this? But
> because the module is for another driver version, I need to build it
> using abs? Perhaps editing the nvidia-rt PKGBUILD file would be ok
> too?
> 
> I simply will test it later ;).
> 
> Ciao :)
> 
> Ralf

Hi :)

I tried editing the AUR's kernel-rt (see 1. and 2. trial) and I tried to
build a package using abs (see 3. trail), all failed.


# 1. trial


I edited the PKGFILE from the tarball
http://aur.archlinux.org/packages/nv/nvidia-rt/nvidia-rt.tar.gz
by copying from
http://aur.archlinux.org/packages/nv/nvidia-all/PKGBUILD .

[spinymouse@archlinux nvidia-rt]$ diff PKGBUILD PKGBUILD.pri
8c8
< pkgver=290.10
---
> pkgver=285.05.09
11c11
< pkgdesc="NVIDIA drivers for kernel 3.0-rt."
---
> pkgdesc="NVIDIA drivers for kernel26."

[spinymouse@archlinux nvidia-rt]$ makepkg -s
==> Making package: nvidia-rt 290.10-1 (Fri Jan  6 13:44:01 CET 2012)
[snip]
==> Validating source files with md5sums...
NVIDIA-Linux-x86_64-290.10-no-compat32.run ... FAILED
nvidiart.patch ... Passed
==> ERROR: One or more files did not pass the validity check!


# 2. trial


I copied the lines for the checksums too. After installing nvidia-rt and
rebooting the kernel-ARCH, X started, but after booting kernel-rt it
finished with a black screen. I had to reset the computer.

[spinymouse@archlinux nvidia-rt]$ diff PKGBUILD PKGBUILD.pri
8c8
< pkgver=290.10
---
> pkgver=285.05.09
11c11
< pkgdesc="NVIDIA drivers for kernel 3.0-rt."
---
> pkgdesc="NVIDIA drivers for kernel26."
20,24c20,24
< _arch='x86'
< _pkg="NVIDIA-Linux-${_arch}-${pkgver}"
<
source=("http://us.download.nvidia.com/XFree86/Linux-${_arch}/${pkgver}/${_pkg}.run";)
< md5sums=('50319a4b3818c12c9c7243525e0e6316')
< 
---
>   _arch='x86'
>   _pkg="NVIDIA-Linux-${_arch}-${pkgver}" &&
md5sums=('2d469a90abef50320f548cfa8085e3a0'
'8f57481f4ae28fb1ec5a5f3af366cceb')
>
source=("http://download.nvidia.com/XFree86/Linux-${_arch}/${pkgver}/${_pkg}.run";
>   nvidiart.patch
> )
27,31c27,31
< _arch=$CARCH
< _pkg="NVIDIA-Linux-${_arch}-${pkgver}-no-compat32"
<
source=("http://us.download.nvidia.com/XFree86/Linux-${_arch}/${pkgver}/${_pkg}.run";)
< md5sums=('cebfba9a7e91716a06c66bb5b38d9661')
< 
---
>   _arch='x86_64'
>   _pkg="NVIDIA-Linux-${_arch}-${pkgver}-no-compat32" &&
md5sums=('2f4a0e78f5560c07220b7ed6fc1e27aa'
'8f57481f4ae28fb1ec5a5f3af366cceb')
>
source=("http://download.nvidia.com/XFree86/Linux-${_arch}/${pkgver}/${_pkg}.run";
>   nvidiart.patch
> )

[spinymouse@archlinux nvidia-rt]$ makepkg -s
==> Making package: nvidia-rt 290.10-1 (Fri Jan  6 13:55:33 CET 2012)
[snip]
==> Entering fakeroot environment...
==> Starting package()...
==> Tidying install...
  -> Purging other files...
  -> Compressing man and info pages...
  -> Stripping unneeded symbols from binaries and libraries...
==> Creating package...
  -> Generating .PKGINFO file...
  -> Adding install file...
  -> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: nvidia-rt 290.10-1 (Fri Jan  6 13:56:15 CET 2012)


# 3. trial


I'll followed the instructions given by
https://wiki.archlinux.org/index.php/NVIDIA#Alternate_install:_custom_kernel

There seemed to be the need to abort # abs, since nothing happened for
minutes. I tried again, fortunately then it only took some seconds.

[root@archlinux spinymouse]# pacman -Syy && pacman -S abs
[snip]
[root@archlinux spinymouse]# abs
==> Downloading tarballs...
==> core...
==> extra...
==> community...
==> multilib...
^C==> ERROR: Aborted by user! Exiting...
[root@archlinux spinymouse]# abs
==> Starting ABS sync...
receiving file list ... done
[snip]
[root@archlinux spinymouse]# exit
[spinymouse@archlinux ~]$ cd /usr/src
[spinymouse@archlinux src]$ mkdir abs
[spinymouse@archlinux src]$ cp -r /var/abs/extra/nvidia/ abs/
[spinymouse@archlinux src]$ cd abs/nvidia

Re: [arch-general] Warning about kmod replacing modules init tools in testing.

[fredbezies]

2012/1/6 Tom Gundersen 

> On Fri, Jan 6, 2012 at 10:56 AM, fredbezies  wrote:
> > I opened a bug on archlinux
> > BTS : https://bugs.archlinux.org/task/27846
>
> For the record, this has now been fixed in testing.
>
> -t
>

Thanks for the fix. It works now :)

-- 
Frederic Bezies
fredbez...@gmail.com

Re: [arch-general] [arch-dev-public] Signoff report for [testing]

[Marek Otahal]

On Friday 06 of January 2012 15:30:16 Roman Kyrylych wrote:
> My bad. Sorry, no working i686 with cryptsetup.
> For such cases a user signoff request on arch-general may be useful.
> Or just move it without signoff.
user sign-off for cryptsetup on i686, 4 partitions on a laptop, running daily. 
all ok.
-- 

Marek Otahal :o)

signature.asc
Description: This is a digitally signed message part.

Re: [arch-general] Warning about kmod replacing modules init tools in testing.

[Tom Gundersen]

On Fri, Jan 6, 2012 at 10:56 AM, fredbezies  wrote:
> I opened a bug on archlinux
> BTS : https://bugs.archlinux.org/task/27846

For the record, this has now been fixed in testing.

-t

Re: [arch-general] Proprietary nvidia driver for kernel-ARCH and kernel-rt

[Ralf Mardorf]

Von: arch-general-boun...@archlinux.org im Auftrag von Thomas Bächler
Gesendet: Fr 1/6/2012 11:28
> I suspect the AUR's nvidia-rt will conflict with the package nvidia?!
> 
> No, the AUR's nvidia-rt package should be what you want (if you diff the
> nvidia and nvidia-rt PKGBUILDs, the differences should be small).
> 
Thanks, so you're referring to
https://wiki.archlinux.org/index.php/NVIDIA#Alternate_install:_custom_kernel ?

Ok, if nvidia-rt from AUR would be up to date I could use this? But because the 
module is for another driver version, I need to build it using abs? Perhaps 
editing the nvidia-rt PKGBUILD file would be ok too?

I simply will test it later ;).

Ciao :)

Ralf

Re: [arch-general] Proprietary nvidia driver for kernel-ARCH and kernel-rt

[Thomas Bächler]

Am 06.01.2012 11:17, schrieb Ralf Mardorf:
> Von: arch-general-boun...@archlinux.org im Auftrag von Thomas Bächler
> Gesendet: Fr 1/6/2012 10:25
>> Apparently, the nvidia-all PKGBUILD does it wrong. I don't know why it
>> exists - you can install nvidia from [extra] and create a package for
>> nvidia-rt. At least then you know the PKGBUILD does something that
>> actually works.
> 
> Sorry for HTML, at the moment I'm not booted to Arch.
> 
> I'm using the nvidia package again. Btw. I forgot to add a link to the rt's 
> extramodules, but since there already was an issue for the regular kernel, I 
> suspect it won't fix anything.
> 
> How do I create a package for nvidia-rt?
> 
> Should I build a dummy-package and install the module by a k option?
> 
> I suspect the AUR's nvidia-rt will conflict with the package nvidia?!

No, the AUR's nvidia-rt package should be what you want (if you diff the
nvidia and nvidia-rt PKGBUILDs, the differences should be small).



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Proprietary nvidia driver for kernel-ARCH and kernel-rt

[Oon-Ee Ng]

On Jan 6, 2012 5:25 PM, "Thomas Bächler"  wrote:
>
> Am 06.01.2012 09:34, schrieb Ralf Madorf:
> > regarding to the rt issues I followed the explanations at
> > http://aur.archlinux.org/packages.php?ID=12132 .
> > I still get an issues with
> > http://aur.archlinux.org/packages.php?ID=32908 .
> > It's not only the described problem. If I boot 3.1.7-1-Arch I get
> > "nvidia: version magic '3.0-rt' should be '3.1.7-1-ARCH'" and if I boot
> > 3.0-rt I get "WARNING: GDMDisplay[snip]", both times X doesn't start.
> > FWIW I build a regular AUR kernel-rt.
>
> Apparently, the nvidia-all PKGBUILD does it wrong. I don't know why it
> exists - you can install nvidia from [extra] and create a package for
> nvidia-rt. At least then you know the PKGBUILD does something that
> actually works.
>
Not sure if the maintainer still updates from my (original)
nvidia-beta-all, but that one works just fine (unless kernel-Rt doesn't
implement the new extra modules)

Re: [arch-general] Proprietary nvidia driver for kernel-ARCH and kernel-rt

[Ralf Mardorf]

Von: arch-general-boun...@archlinux.org im Auftrag von Thomas Bächler
Gesendet: Fr 1/6/2012 10:25
> Apparently, the nvidia-all PKGBUILD does it wrong. I don't know why it
> exists - you can install nvidia from [extra] and create a package for
> nvidia-rt. At least then you know the PKGBUILD does something that
> actually works.

Sorry for HTML, at the moment I'm not booted to Arch.

I'm using the nvidia package again. Btw. I forgot to add a link to the rt's 
extramodules, but since there already was an issue for the regular kernel, I 
suspect it won't fix anything.

How do I create a package for nvidia-rt?

Should I build a dummy-package and install the module by a k option?

I suspect the AUR's nvidia-rt will conflict with the package nvidia?!

spinymouse11.2@suse11-2:/media/archlinux/usr/src/nvidia-all> sh 
NVIDIA-Linux-x86_64-290.10-no-compat32.run -A

-k, --kernel-name=KERNEL-NAME
  Build and install the NVIDIA kernel module for the
  non-running kernel specified by KERNEL-NAME (KERNEL-NAME
  should be the output of `uname -r` when the target kernel
  is actually running).  This option implies
  '--no-precompiled-interface'.  If the options
  '--kernel-install-path' and '--kernel-source-path' are not
  given, then they will be inferred from KERNEL-NAME; eg:
  '/lib/modules/KERNEL-NAME/kernel/drivers/video/' and
  '/lib/modules/KERNEL-NAME/build/', respectively.

-K, --kernel-module-only
  Install a kernel module only, and do not uninstall the
  existing driver.  This is intended to be used to install
  kernel modules for additional kernels (in cases where you
  might boot between several different kernels).  To use this
  option, you must already have a driver installed, and the
  version of the installed driver must match the version of
  this kernel module.

Ciao!

Ralf

[arch-general] Warning about kmod replacing modules init tools in testing.

[fredbezies]

I have two computers, both using nvidia driver.

My laptop started flawlessly, after I renamed empty file
modprobe.conf.pacsave to modprobe.conf in /etc/modprobe.d/

On my desktop computer, all went bad.

udevadm trigger doesn't work. I had to downgrade both packages (kmod
replaced by modules-init-tools) and mkinitcpio, blacklisting both of them
in my /etc/pacman.conf ignorepackage line.

My /etc/modprobe.conf is not empty :

#
# /etc/modprobe.d/modprobe.conf (for v2.6 kernels)
#
blacklist keucr
blacklist usblp

For now, I'm blocking upgrade for both package. I opened a bug on archlinux
BTS : https://bugs.archlinux.org/task/27846

I know testing can be busted sometimes, but this bust is one the worst I've
seen for a year or so.

-- 
Frederic Bezies
fredbez...@gmail.com

Re: [arch-general] haskell-text out of date

[Cédric Girard]

On Fri, Jan 6, 2012 at 10:30 AM, Jelle van der Waa wrote:

> On 05/01/12 11:43, Cédric Girard wrote:
> > Hi,
> >
> > haskell-text [1] has been flagged out of date in [extra], mid-November.
> It
> > has not been updated since.
> > Since this package has no maintainer I'm not sure this has even been
> > noticed.
>
> There are rumors that it will be updated, on the next ghc rebuild
>
>
Nice, let's just hope it won't be too far away. After all GHC 7.0.4 is only
6 months old. ;)

-- 
Cédric Girard

Re: [arch-general] haskell-text out of date

[Jelle van der Waa]

On 05/01/12 11:43, Cédric Girard wrote:
> Hi,
> 
> haskell-text [1] has been flagged out of date in [extra], mid-November. It
> has not been updated since.
> Since this package has no maintainer I'm not sure this has even been
> noticed.
> 
> This package is a dependency for the git version of xmobar [2].
> 
> cabal2arch gives a working PKGBUILD but I haven't tested the resulting
> package more than installing it.
> 
> [1] https://www.archlinux.org/packages/extra/x86_64/haskell-text/
> [2] https://aur.archlinux.org/packages.php?ID=44683
> 
There are rumors that it will be updated, on the next ghc rebuild

-- 
Jelle van der Waa



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Proprietary nvidia driver for kernel-ARCH and kernel-rt

[Thomas Bächler]

Am 06.01.2012 09:34, schrieb Ralf Madorf:
> regarding to the rt issues I followed the explanations at
> http://aur.archlinux.org/packages.php?ID=12132 .
> I still get an issues with
> http://aur.archlinux.org/packages.php?ID=32908 .
> It's not only the described problem. If I boot 3.1.7-1-Arch I get
> "nvidia: version magic '3.0-rt' should be '3.1.7-1-ARCH'" and if I boot
> 3.0-rt I get "WARNING: GDMDisplay[snip]", both times X doesn't start.
> FWIW I build a regular AUR kernel-rt.

Apparently, the nvidia-all PKGBUILD does it wrong. I don't know why it
exists - you can install nvidia from [extra] and create a package for
nvidia-rt. At least then you know the PKGBUILD does something that
actually works.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] kmod-3 in [testing]

[Myra Nelson]

 IMPORTANT: In line with the first change, it needs to be pointed out
 that we will no longer package /etc/modprobe.d/modprobe.conf. This means
 that if you wrote to that file, it will be .pacsave'd on removal of
 m-i-t and you must rename it. We will continue to ship what used to be
 called /etc/depmod.d/depmod.conf, but rename it /lib/depmod.d/search.conf.
 This will be a read only file -- users should put their own tweaks in
 /etc/depmod.d.

 One other thing you might notice is that kmod doesn't currently include
 man pages. I don't consider this a loss -- the m-i-t manpages did not
 provide full coverage, nor did the command line help. kmod's binaries
 all currently have full coverage of options via -h, --help.

 Lastly, there's an accompanying mkinitcpio update to account for some
 extra verbosity of kmod's modprobe and depmod tools. You do *not* need
 to regenerate your initramfs images unless you feel so inclined.

>> Update- because Dave is awesome, he whipped up some patches and I
>> tested them that appear to fix the above problem, so the latest kmod
>> package in [testing] should be safe to test.
>>
>> Thanks Dave!
>>
>> -Dan
>
> I just installed kmod-3-3 from [testing] and tried a reboot, which
> promptly left me with no rootfs and, oddly enough, no keyboard input in
> the initrd shell, which made the problem somewhat difficult to debug.
> However, an additional boot came up fine. I'm going to keep the package
> around to see if it happens again, but I hardly ever boot this box so it
> may take a while. This may not be quite ready for [core] just yet ;)
>
> Regards,
> Bjørn Øivind
>

As I said in my other post I've mostly got things working. I have to
log in then run sudo udevadm trigger ( I'm doing it twice, once with
--type=devices then subsystems ) to get all my modules loaded, then
sudo /etc/rc.d/net-profiles start to get my network up. Moving the
nouveau blacklist and sound.conf to /lib/modprobe.d took care of not
loading the the nouveau modules and finding my sound card.

It was probably the wrong move, but I tried putting udevadm trigger
--type=xxx in my rc.local with no success. Shows I still don't get all
the interactions with rc.local.

Myra

-- 
Life's fun when your sick and psychotic!

[arch-general] Proprietary nvidia driver for kernel-ARCH and kernel-rt

[Ralf Madorf]

Hi :)

regarding to the rt issues I followed the explanations at
http://aur.archlinux.org/packages.php?ID=12132 .
I still get an issues with
http://aur.archlinux.org/packages.php?ID=32908 .
It's not only the described problem. If I boot 3.1.7-1-Arch I get
"nvidia: version magic '3.0-rt' should be '3.1.7-1-ARCH'" and if I boot
3.0-rt I get "WARNING: GDMDisplay[snip]", both times X doesn't start.
FWIW I build a regular AUR kernel-rt.

Is there a way to fix this [1]?

Ciao!

Ralf

[1]
[spinymouse@archlinux nvidia-all]$ makepkg -s
==> Making package: nvidia-all 290.10-1 (Fri Jan  6 08:32:51 CET 2012)
==> Found 2 kernels
==> Working on the kernel: 3.0-rt
  -> Building module...
==> Working on the kernel: 3.1.7-1-ARCH
  -> Building module...

[root@archlinux nvidia-all]# pacman -U
nvidia-all-290.10-1-x86_64.pkg.tar.xz
nvidia-utils-290.10-1-x86_64.pkg.tar.xz
Proceed with installation? [Y/n]
(2/2) checking package integrity
(2/2) checking for file conflicts
(1/1) removing nvidia
(1/2) upgrading nvidia-utils
(2/2) installing nvidia-all
error: command failed to execute correctly

[root@archlinux nvidia-all]# ls /lib/modules
3.0-rt  3.1.7-1-ARCH  extramodules-  extramodules-3.1-ARCH

[root@archlinux nvidia-all]#
mv /lib/modules/extramodules- /lib/modules/extramodules-3.0-rt

Re: [arch-general] [signoff] linux-3.2-1

[Tobias Powalowski]

Am 06.01.2012 02:58, schrieb Jonathan Vasquez:
> On Thu, Jan 5, 2012 at 9:19 AM, Tobias Powalowski
>  wrote:
>> Hi guys,
>> please signoff 3.2 series for both arches.
>>
>> Upstream
>> changes:
>> http://kernelnewbies.org/LinuxChanges
>>
>> greetings
>> tpowa
>> --
>> Tobias Powalowski
>> Archlinux Developer & Package Maintainer (tpowa)
>> http://www.archlinux.org
>> tp...@archlinux.org
>>
> You might want to hold off on that sign off. There is a Regression Bug
> affecting Intel users in the final source of 3.2
>
> http://www.phoronix.com/scan.php?page=news_item&px=MTAzNzk
>
>
We are not affected by this we don't enable iommu by default.
You need to activate it with your posted link.
intel_iommu=on
So no issue for arch users.

greetings
tpowa

-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Kmod testing

[Myra Nelson]

On Fri, Jan 6, 2012 at 01:38, Myra Nelson  wrote:
>
> Fisrt Kmod experience, which spit out a lot of udevd messages, logged in, 
> startx, openbox starts, then one locked up box. I was going to Ctrl Alt F2, 
> log in, and do some work with udevadm but I had no keyboard of mouse control. 
> I turned the box off then on to reboot, pacman -Rdd kmod pacman -S 
> module-init-tools then reboot.  I've examined the boot log from the previous 
> run and here is a sample.
>
> Fri Jan  6 01:03:19 2012: udevd[310]: failed to execute '/sbin/modprobe' 
> '/sbin/modprobe -bv acpi:LNXCPU:': No such file or directory
> Fri Jan  6 01:03:19 2012:
> Fri Jan  6 01:03:19 2012: udevd[393]: failed to execute '/sbin/modprobe' 
> '/sbin/modprobe -bv acpi:PNP0C04:': No such file or directory
> Fri Jan  6 01:03:19 2012:
> Fri Jan  6 01:03:19 2012: udevd[334]: failed to execute '/sbin/modprobe' 
> '/sbin/modprobe -bv acpi:PNP0C02:': No such file or directory
> Fri Jan  6 01:03:19 2012:
> Fri Jan  6 01:03:19 2012: udevd[324]: failed to execute '/sbin/modprobe' 
> '/sbin/modprobe -bv acpi:PNP0401:': No such file or directory
>
> I went back and read the messages from Dave and Dan to see if I'd missed 
> anything and hadn't. After the install of Kmod, before I rebooted, I read the 
> help message from kmod --help and there were commands listed for compatibilty 
> mod with modprobe. I've already been triggering the udev rules after I boot 
> to find my audio card but that wont work for this behavior because triggering 
> the rules will simply look for /sbin/modprobe again. The kernel update came 
> in at the same time, so the initrd images were rebuilt prior to rebooting.
>
> For know I've put kmod in my ignore packages line in pacman.conf. Do the 
> udevd rules need to be written to point to kmod with it's compatibility mode 
> or is there another solution?
>
> Thanks for any assistance.
>
> Myra
> --
> Life's fun when your sick and psychotic!

I left the complete message in on purpose. I've managed to solve(?)
part of the problem. I did miss one item in the messages from Dave and
Dan, to rename/move depmod.conf then put it back after the update.
However the blacklist files ending in conf don't get parsed. My bad.

Sorry for the noise but may me being an idiot and dumping noise on the
mailing list will help others that don't read well either.

Mya




--
Life's fun when your sick and psychotic!

Re: [arch-general] [arch-dev-public] kmod-3 in [testing]

[Bjørn Øivind Bjørnsen]

On 06/01/12 05:44, Dan McGee wrote:
> On Thu, Jan 5, 2012 at 9:41 PM, Dan McGee  wrote:
>> On Thu, Jan 5, 2012 at 6:40 PM, Dave Reisner  wrote:
>>> Hey all,
>>>
>>> I've just dropped kmod-3 into testing as a replacement for
>>> module-init-tools. This is still a young project, but it has a lot of
>>> support from active people, and I (as well as Tom) have been working
>>> closely with upstream to flesh out and fix bugs.
>>>
>>> For the most part, you should not notice any difference. kmod was
>>> designed as a drop-in replacement for m-i-t, and all the binaries should
>>> exist with the (mostly) the same options. Whenever possible, options or
>>> features marked deprecated in m-i-t were removed, such as:
>>>
>>> - parsing of depmod/modprobe config for files not ending in .conf
>>> - modprobe's -l, --list options
>>>
>>> IMPORTANT: In line with the first change, it needs to be pointed out
>>> that we will no longer package /etc/modprobe.d/modprobe.conf. This means
>>> that if you wrote to that file, it will be .pacsave'd on removal of
>>> m-i-t and you must rename it. We will continue to ship what used to be
>>> called /etc/depmod.d/depmod.conf, but rename it /lib/depmod.d/search.conf.
>>> This will be a read only file -- users should put their own tweaks in
>>> /etc/depmod.d.
>>>
>>> One other thing you might notice is that kmod doesn't currently include
>>> man pages. I don't consider this a loss -- the m-i-t manpages did not
>>> provide full coverage, nor did the command line help. kmod's binaries
>>> all currently have full coverage of options via -h, --help.
>>>
>>> Lastly, there's an accompanying mkinitcpio update to account for some
>>> extra verbosity of kmod's modprobe and depmod tools. You do *not* need
>>> to regenerate your initramfs images unless you feel so inclined.
>>>
>>> Have fun!
>>
>> Or don't. Not to rain on Dave's parade (this isn't his fault), but
>> unless you want to sit at your initrd shell for a half hour
>> un-breaking stuff, I'd recommend steering clear of this package and
>> sticking with the old but proven module-init-tools. This package
>> causes modprobe when called by udev to randomly not load modules or
>> something; first noticable with uhci_hcd and my mouse (trivial), later
>> with ahci on boot (not cool, not having disk drives).
>>
>> **Tip**: if you get screwed, call `udevadm trigger` a few times, it
>> seems to knock some sense into the system. You can do this in the
>> initrd environment too.
> 
> Update- because Dave is awesome, he whipped up some patches and I
> tested them that appear to fix the above problem, so the latest kmod
> package in [testing] should be safe to test.
> 
> Thanks Dave!
> 
> -Dan

I just installed kmod-3-3 from [testing] and tried a reboot, which
promptly left me with no rootfs and, oddly enough, no keyboard input in
the initrd shell, which made the problem somewhat difficult to debug.
However, an additional boot came up fine. I'm going to keep the package
around to see if it happens again, but I hardly ever boot this box so it
may take a while. This may not be quite ready for [core] just yet ;)

Regards,
Bjørn Øivind



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] linux-api-headers in core is 3.1.5 while linux is 3.1.6

[Allan McRae]

On 06/01/12 18:00, Patrick Buddeberg wrote:
>>> Maybe is my little understanding of the situation, but isn't
>>> linux-api-headers behind what it (appears to me that it) should be?
> 
>> The linux-api-headers package is entirely unrelated to the running or
>> installed kernel. It contains the headers that give glibc the API to the
>> Linux kernel, and must never (NEVER NEVER NEVER) be different from the
>> version that glibc was built against.
>>
>> Please, someone give me a cent for every time this question is asked.
>>
> 
> It may help if this information is in an easily reachable area, as I
> couldn't find it anywhere after searching the wiki and forums followed
> by the internet as a whole. The closest thing that I found was from
> LFS, but this actually makes it seem like it is very closely bound to
> both kernel and glibc.
> 

https://bbs.archlinux.org/viewtopic.php?pid=955909

Re: [arch-general] linux-api-headers in core is 3.1.5 while linux is 3.1.6

[Patrick Buddeberg]

>> Maybe is my little understanding of the situation, but isn't
>> linux-api-headers behind what it (appears to me that it) should be?

> The linux-api-headers package is entirely unrelated to the running or
> installed kernel. It contains the headers that give glibc the API to the
> Linux kernel, and must never (NEVER NEVER NEVER) be different from the
> version that glibc was built against.
>
> Please, someone give me a cent for every time this question is asked.
>

It may help if this information is in an easily reachable area, as I
couldn't find it anywhere after searching the wiki and forums followed
by the internet as a whole. The closest thing that I found was from
LFS, but this actually makes it seem like it is very closely bound to
both kernel and glibc.

-Patrick