- Arch-general - lists.archlinux.org

[arch-general] build db and files
by Sergio de Almeida Lenzi 15 Jun '11

15 Jun '11

Hello I must build the .db and .files (files that exists in the distribuition: core, community...) I must build them from the /var/abs/xxx directory. Can someone point me the the solution???? Thanks for any help, Sergio

2 1

[arch-general] TeXLive 2011 pretest
by Rémy Oudompheng 15 Jun '11

15 Jun '11

TeXLive 2011 is in pre-testing phase. Experimental builds of texlive-bin will be found in http://pkgbuild.com/~remy/texlive-experimental/ Current issues are: - no install script for texlive-bin where it should run "mktexlsr" and "fmtutil-sys --all" - dangling symlinks, due to new scripts appearing in texlive-* - segfaulting luatex, so I guess I'll keep with compiling it separately - no biblatex-biber. TeXLive only provide a binary that bundles Perl + all dependencies. I plan to adopt biblatex-biber from AUR for that and add it as an optional dependency of texlive-core. However, it comes with a very unusual set of dependencies. We can only blame François for being a great Perl enthusiast. Once upstream seems stable (they say ConTeXt is currently broken), and the PKGBUILDs reach a final form, packages will hit [testing]. Regards, -- Rémy.

7 6

[arch-general] {external, general}ized hooks in key packages [kernel26, ???] (WAS: Re: Reboot - Versioned Kernel Installs)
by C Anthony Risinger 14 Jun '11

14 Jun '11

On Fri, Jun 10, 2011 at 2:44 PM, Mauro Santos <registo.mailling(a)gmail.com> wrote: > > Arch users have lived without the last good known kernel so far and > without an -lts kernel until recently. this applies to technology in general -- we don't need any of it, but forward we move nonetheless. > IMHO it is a lot more advisable > to have an install cd/usb, or even better, a custom install in some > external media that can be used to boot the system in case something > goes wrong or in case of emergency. Then you can just chroot into the > broken install and fix the problem or tell pacman where the root and > cache are located and fix things. why is that simpler/advisable? now you need to mount everything properly by hand else things like autodetection fail in mkinitcpio, etc. i don't think it's hard to recover, and i would never have any of these issues, but i think a *real* recovery shell is not a bad idea ... why add more work for me the human when the machine could get me 95% the way there? and offer some options even? On Fri, Jun 10, 2011 at 7:45 PM, Joe(theWordy)Philbrook <jtwdyp(a)ttlc.net> wrote: > > The only reason to even consider keeping an old kernel around with Arch was > just in case the new kernel is effectively borked... (possibly due to a > hardware incompatibility...) And if I remember right, you said something > about this not working if the new kernel can't boot... you wouldn't want to boot it past the final step, ie. you don't want to actually switch_root into your / device and continue the boot process ... however, at that moment, you have: ) booted a good kernel ) have all autodetected modules available (possibly not loaded tho) ) ... and (IIRC) -fallback version has the full module tree if needed ) loaded your last configuration of initcpio hooks/etc ) ... which means your / is probably mounted properly, even with encryption and other exotics ) other filesystems like /dev /sys are mounted, --move'd, and ready to go on the new_root ) the whole system is poised for regular boot ... so initcpio script *could*, if aware of your dilemma: ) drop to shell immediately with some helpful info ) chroot for you into /new_root (your real system) ) ... maybe bind mount the module hierarchy into new_root to prevent accidental loading of wrong mods (if that's even possible, not sure) ... basically just bring you 95% the way there, then let you fix it and reboot ... done. On Fri, Jun 10, 2011 at 8:06 PM, Joe(theWordy)Philbrook <jtwdyp(a)ttlc.net> wrote: > > It would appear that on Jun 10, Robert Howard did say: > >> Why not just copy the old kernel image, modules and initrd image somewhere >> by hand before you upgrade kernels. > > That wouldn't be such a bad idea. And in fact I already do that with the > kernel and initrd image. and that option will always be available ... but any trivially repetitive procedure requiring consistent user interaction is a poor solution IMO, if even worthy of being called a solution. definitely an exaggeration, but why even have timed scripts a la cron, or a packaging system at all, when we could just remember to do stuff? why not boot the system by hand :-)? probably because these automata improve consistency and reduce the likelihood of errors ... we suck at being computers :-) http://panko.shidler.hawaii.edu/HumanErr/ProgNorm.htm > * CRS : "Can't Remember Sh^Htuff" ha nice ... i've never heard anyone else say/use this (CRS acronym) ... my grandmother has been telling me that since i was a kid -- i always thought she made it up :-) -- one of those independently discoverable things i suppose. On Fri, Jun 10, 2011 at 8:33 PM, Heiko Baums <lists(a)baums-on-web.de> wrote: > Am Fri, 10 Jun 2011 21:21:17 -0400 > schrieb "Joe(theWordy)Philbrook" <jtwdyp(a)ttlc.net>: > >> Now that, Heiko, is a good idea. And one that I could actually do. >> I'd just have to decide which of my other Linux distributions to >> sacrifice to make room for it... Keeping in mind that as you say: >> "those cases in which an updated kernel is unbootable are very, very >> rare." I think I'd rather learn how to use the "pacman -U" method... > > Would at least be less work. how is installing another distro that you may never use easier? you'd still have to go thru the whole manual recovery process. LiveCD beats this any day for me -- i rarely install anything these days because my distro-hopping abruptly ended with Arch :-) (though i do check them out from time to time, or for work related things) -------------------------------------------------- and the end of the day people just want to reinstate a useable system as rapidly as possible. we can yammer on and argue that the user "should not be using testing then", "should be making full backups", "should have/know an alternate recovery plan", "should be manually backing up kernel related stuff", "should be awesomely l33t with linux by now", "prob shouldnt use Arch then" or limitless other assertions, none of which will help anyone learn anything. i can recover my system. i can recover it pretty much no matter how fubificated it is in only a couple minutes because my life is centered around these systems -- to others, if not most, the system is merely a conduit to their own needs/interests, not the focal point. this is important to remember. i think some basic recovery options are a fair request, and one i've seen often enough in various places. if their needs can be made possible by a simple externalized mechanism, and then implemented + maintained by the community, then who is losing? if you don't want it you can simply not use it and your system is no better or worse. in fact, it's not even affected to any degree save some extra checks failing here and there ... you may even find your own use for the triggers. such a mechanism could be used to save packages, save module tree, save images, or anything else one wanted it to do at that critical point. in my own case, i need a way to save the kernel and initramfs before they are replaced -- automatically -- so i can stuff them into a btrfs subvolume for system rollbacks ... i would never ask the user to perform this manually for a million good reasons. the only other option AFAICS is aliasing over the top of pacman. so, while i personally don't care about the threads specific request -- as it will never apply to me -- IMO the motivation is sound, and could be generalized. i propose this threads energy move away from the endlessly debatable focus on "versioning the kernel" to "providing a means to perform custom actions during kernel package transactions, and potentially any package" ... something that maybe everyone can agree on, and something that may prove to enable many new/interesting ideas. so, what sayeth anyone that can make the magic come to life, or anyone else? /etc/pacman/hooks.d/kernel26/<hookname> /etc/pacman/hooks.d/hook.kernel26.<hookname> /etc/kernel26.hook /etc/pacman.linux.hook <whatever> ill be looking into the pacman hooks proposal, but since i cant do C [yet :-] no patches will be from this guy ... external hooks to the .install file is probably pretty simple to implemented even in pacman (then any package could be hooked), but could easily be done in the .install file itself for certain packages, eg. kernel26. C Anthony

5 5

[arch-general] Cannot upgrade grub2 to 1.99-2 ?
by Frederic Bezies 13 Jun '11

13 Jun '11

Hello. Facing a strange problem. I'm using this grub2 version : [fred@fredo-arch ~]$ pacman -Qi grub2-{common,bios} | grep Version Version : 1.99~rc2.r3238-1 Version : 1.99~rc2.r3238-1 And when I want to upgrade it to 1.99-2 (last version in testing), I got this : :: Début de la mise à jour complète du système... résolution des dépendances... Avertissement: impossible de résoudre "grub2-common=1.99", une dépendance de "grub2-bios" :: Le paquet suivant ne peut pas être mis à jour à cause de dépendances insatisfaisables: grub2-bios Voulez-vous ignorer le paquet ci-dessus pour cette mise à jour ? [o/N] n Erreur: la préparation de la transaction a échoué (la satisfaction des dépendances a échoué) :: grub2-bios: requiert grub2-common=1.99 Important part : error: failed to prepare transaction (could not satisfy dependencies) :: Starting full system upgrade... :: grub2-bios: requires grub2-common=1.99 Any idea to fix this problem ? I don't want to use --force option. Thanks. -- Frederic Bezies - fredbezies(a)gmail.com Blog : http://frederic.bezies.free.fr/blog/

3 2

[arch-general] Where are kernel files cached now? Not in /var/cache/pacman/pkg? Renamed?
by David C. Rankin 12 Jun '11

12 Jun '11

Guys, I tagged this to the kernel 2.6.39.1-1 sign-off message, but got no replies. Where are the kernel packages cached now? In /var/cache/pacman/pkg I only have: 13:16 nirvana:/var/cache/pacman/pkg> ls -1 kernel26-* kernel26-2.6.38.8-1-x86_64.pkg.tar.xz kernel26-docs-2.6.38.8-1-x86_64.pkg.tar.xz kernel26-firmware-2.6.33.4-1-x86_64.pkg.tar.xz kernel26-headers-2.6.38.8-1-x86_64.pkg.tar.xz kernel26-lts-2.6.32.41-2-x86_64.pkg.tar.xz kernel26-lts-headers-2.6.32.41-2-x86_64.pkg.tar.xz kernel26-manpages-2.6.35.8-1-x86_64.pkg.tar.xz kernel26-manpages-2.6.38-1-any.pkg.tar.xz kernel26-xen-2.6.37-1-x86_64.pkg.tar.xz Where did kernel26-2.6.39.9-1-x86_64.pkg.tar.xz go? -- David C. Rankin, J.D.,P.E.

4 4

Re: [arch-general] Reboot - Versioned Kernel Installs
by Paul Gideon Dann 12 Jun '11

12 Jun '11

I would really like to the kernel that is being replaced kept as a backup. If the latest kernel breaks your hardware, or something else goes wrong, I'd like to have the option of using the kernel that was just replaced, because it's known to work. I wouldn't want more than one old version of the kernel, though. Also, although the -lts kernel is good for this, it isn't intended to solve this problem, and isn't always a perfect fit. For instance, my new laptop has UEFI-related issues that are only being addressed in the *very* latest kernels. I'm not sure -lts would boot for me, but I know that my *current* kernel boots; seems a pity to throw it out it straight away on upgrade, before I can test that the new kernel boots OK... Paul On Monday 06 June 2011 18:23:50 Tom Gundersen wrote: > On Mon, Jun 6, 2011 at 6:22 PM, Tavian Barnes <tavianator(a)tavianator.com> wrote: > > I have kernel26-lts installed as a backup kernel, and this is all > > that's really necessary for rolling back broken kernel updates. I've > > been bitten by a BTRFS bug once and rolled back with -lts no problem. > > -1 from me on keeping multiple kernel versions installed; I really > > like that arch doesn't keep 6 old kernels around. > > I agree. > > The reason I am against keeping old kernels around is that we would > not be able to test user space against all the possible combinations, > so it would not be a good idea to suggest that we do (we do try to > support all sorts of self-compiled kernels, but at least if you > compile your own kernel it is pretty obvious that it will not be as > well tested as the "official" ones). > > One possibility would be to do like upstream does and always rename > the previous kernel to .old. That should keep the last known working > kernel around while making it clear that it should not be relied on > for day-to-day use (and that it will get overwritten on the next > kernel upgrade so these things won't get old). > > That said, I'm not involved with packaging the kernel, so if you want > anything to change with how it is packaged (maybe after this > discussion is over), it would be best to file a feature request on FS. > > Cheers, > > Tom

14 41

[arch-general] [netcfg] Prerelease package before 2.6 release
by Rémy Oudompheng 12 Jun '11

12 Jun '11

Hello, I have uploaded a premilinary netcfg package including the latest changes. It does not correspond to a particular tag in the Git repository (it's commit 1f5183b8). http://dev.archlinux.org/~remy/netcfg/netcfg-2.5.90-1-any.pkg.tar.xz I plan to produce version 2.6 after some polishing has been made. * I can test static configuration * I can test IPv4 wireless * I remember wireless IPv6 worked previously, maybe due to autoconfiguration. I don't know if there are real people out in the world using DHCP for IPv6. net-tools is now an optional dependency. It's only necessary if you want to use the IFCFG option. Changes: version 2.6 - add support for IPv6 configuration (FS#18699) - add support for static routes configuration (FS#18700) - add support for creating tun/tap interfaces (FS#15049) - wireless: add support for explicit BSSID (FS#24582) - wireless: add support for ad-hoc connections (FS#19683) - use /run instead of /var/run - drops dependency on net-tools package Regards, Rémy.

1 0

[arch-general] Network Config - Fixed IP - ifconfig no longer reports broadcast address?
by David C. Rankin 12 Jun '11

12 Jun '11

Guys, Bug or feature? After updating rc.conf to contain the new network configuration for a fixed IP, ifconfig no longer reports the broadcast address. Using the new config of: interface=eth0 address=192.168.6.14 netmask=255.255.255.0 gateway=192.168.6.13 I get: 17:48 archangel:~> ifconfig eth0 Link encap:Ethernet HWaddr 00:21:85:1A:8C:FA inet addr:192.168.6.14 Bcast:0.0.0.0 Mask:255.255.255.0 ^^^^^^^^^^^^^^ inet6 addr: fe80::221:85ff:fe1a:8cfa/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:102 errors:0 dropped:0 overruns:0 frame:0 TX packets:140 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14657 (14.3 Kb) TX bytes:15177 (14.8 Kb) Interrupt:41 Base address:0x2000 Prior to the change, the broadcast address was correctly reported. eth0 Link encap:Ethernet HWaddr 00:21:85:1A:8C:FA inet addr:192.168.6.14 Bcast:192.168.6.255 Mask:255.255.255.0 inet6 addr: fe80::221:85ff:fe1a:8cfa/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:103 errors:0 dropped:0 overruns:0 frame:0 TX packets:139 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14683 (14.3 Kb) TX bytes:15505 (15.1 Kb) Interrupt:41 Base address:0x2000 If I modify rc.conf and change back to the old format: # old network config for broadcast address eth0="eth0 192.168.6.14 netmask 255.255.255.0 broadcast 192.168.6.255" INTERFACES=(eth0) gateway="default gw 192.168.6.13" ROUTES=(gateway) then the broadcast address is correctly reported again. Is this a bug or feature? -- David C. Rankin, J.D.,P.E.

3 3

[arch-general] [signoff] kernel26-2.6.39.1-1
by Tobias Powalowski 12 Jun '11

12 Jun '11

Hi guys, please signoff 2.6.39 series for both arches. Upstream changes: http://kernelnewbies.org/LinuxChanges WARNING: AUFS2 support is gone for now, if this is no showstopper we should go move it to [core]. If noone has real objections, I hope to get this kernel into [core]. Along with this the binary modules mentioned on the previous thread will be removed from [core] and [extra]: - tiacx (broken) - ndiswrapper (not needed anymore) - intel536/537 (does not compile on .39 series) - madwifi (obsolete) - martian (old modem driver) - tiacx-lts - ndiswrapper-lts greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 3

[arch-general] blacklisting/MOD_AUTOLOAD - what drove the change?
by David C. Rankin 12 Jun '11

12 Jun '11

Guys, Just curious for the reason behind the changes to blacklisting and MOD_AUTOLOAD. What drove the change? -- David C. Rankin, J.D.,P.E.

2 1