Arch as a semi-rolling release ? [Solved]

Hi,
I'm considering setting an "old" server (bi-xeon) for my students in computer science -- mainly to learn programming languages and tools. They only needs to log in via an ssh -Y session from their Windows accounts.
Arch rolling release is perfect for me as it allows to use last versions of programming languages and tools but, for the system itself (kernel and core software) i wonder if i could safely ignore updates of the core set (i prefer to update this component once a year, during student holidays, just in case something goes wrong).
I suppose i could use IgnoreGroup = core in pacman.conf, but i don't know what could be the possible side-effects.
Last edited by jaco (2012-01-07 22:59:33)

You could do as you suggested and let your students fix the server. Perfect training.

Similar Messages

Arch & "Rolling Releases"

I had never heard of the concept of "rolling releases" that Arch uses until I started using it. (In case anyone doesn't know, you never have to do an OS upgrade with Arch because new versions of the OS are merely snapshots of the current packages.) However, this completely baffles my mind. I've searched all over for information about this but have come across very little, so hopefully some people can entertain my questions a bit.
Basically, how does Arch get away with this? Why does every other OS in the world seem to not use this concept such that you have to update their OS every so often? It seems like others (provided they're not selling their OS, of course ) would want to do this as well. Do any other linux distros follow this model? Why can't Red Hat Fedora, for example, do this as well? Or maybe, more accurately, why would they choose not to?
I'm not a linux guru but I just don't understand why this isn't more common with linux distros. Now that I've been fortunte enough to have been introduced to this concept with Arch, it pains me to think about using a distro that forces me to download their newest CDs and update every 6 months or so. (Don't worry, I have no intention of leaving )

It is a nice system that is composed by aggregating components. The components themselves need to be as modular as possible, and able to be moved in and out arbitrarily. This works well on a *nix based os.
Problems inherent in the system can occur when large changes are required to some founding element of the system. For instance, if the arch devs decided to change the hashing algorithm on packages for instance..*cough*..it would take quite a bit of overhead to make such a modification. With a classical release based system, the overhead would be there, but it would be mitigated through the ability to "freeze" creation of new packages in order to make a single "one shot" change-over. My example might not best illustrate what I am trying to say, but hopefully it is clear enough that you get some of my murky meaning.
For projects that are not so componentized, or that have rapidly changing interfaces (like the linux kernel, or openoffice, for instance), a rolling release would be harder to do. Things are not broken up into discreet elements, so updating one thing without effecting another is hard. Similarly, the inability to effectively freeze one feature in relation to another until code stability can again be achieved might be serious detriment to project advancement..
those are just ideas off the top of my head. When it works, it works. When it doesn't, it doesn't.
I don't know why other distros don't use more of a rolling release. It seems well suited to linux. Now that I think of it, debian does in its own way. They just tag a release, and effectively have serveral simultaneous rolling releases and just migrate data between them (waterfalling downwards towards stability).
*end babbling*

How is rolling release possible?

how do you maintain a rolling release that rolls this fast? Allow me to clarify with a hypothetical example:
i am running my favorite text based rpg called 'foo-1.0', it depends on lib-foo-1. i also play bar-1.0, which depends on lib-bar-1, and lib-foo-1.
bar 1.0 is pretty cool and its under heavy development... eventually bar 2.0 is released. yay! bar-2.0 comes with a new lib called lib-bar-2, but still depends the old lib-foo-1.
all of a sudden foo gets upgraded to foo-2.0, lib-foo also bumps up to lib-foo-2.0. is bar broken now? how do the arch devs keep up with all this?
is it up to the package maintainer to regularly check for new versions and hold them back if there is some kind of software conflict? is it up to him to make it work?
maybe all it takes to fix the broken "bar-2.0", is point the old lib-foo-1 at lib-foo-2, who would do that?
i am a little bewildered by the development of arch linux. i have used every distro under the sun, they all suck. except arch. arch has also turned out to be very stable for me, i run a full desktop, xfce, multimedia, stuff from the aur, how does it not break ?
could someone maybe explain this to me, or point me the appropriate wikki page
Last edited by machinecrusade (2011-03-12 06:42:58)

hardywu wrote:
As a new user of linux system, I noticed that "pacman" check the package dependences each time I want to remove a package.
So what would happen if there are packages
A, B and C such that A depends on B , B depends on C and C depends on A? They form a loop like
A <-B <-C <-A <-B .....
Does that means I will never be able to delete any of A, B and C unelse I format the disk ?
That would not happen. In any case there's an option to remove ignoring dependencies.

Help - doesn't Arch support my computer anymore? [solved]

I had a fine Arch Linux system running on my Laptop, until yesterday's package upgrade - which pulled in xf86-video-intel-2.10.0-1. For some reason, this new version of the intel video driver now requires kernel modesetting being enabled. This puts me in the following peculiar situation:
- without the -nomodeset boot option, the screen turns blank at udev initialization and stays that way until reboot, making Arch unusable (see this thread)
- with the -nomodeset boot option, X now refuses to start due to the new intel video driver complaining about missing KMS
- the xf86-video-fbdev driver doesn't work, either
- the xf86-video-intel-stable driver from AUR fails to compile altogether
- I don't have an older binary of xf86-video-intel in my /var/cache/pacman anymore, either
So I have three questions now:
1) What other option do I have now to get a running Arch Linux system again?
2) Why on earth doesn't Arch Linux keep at least one stable/legacy version for such important and at the same time fragile/error-prone packages as the intel video driver in its official repos?
3) Who on earth decided to drop support for non-KMS-mode from the intel video driver? Was this an upstream decision, or do the Arch devs just not care about users for whom KMS doesn't work? (And the *are* many such users, see the link above...)
Last edited by sas (2010-06-23 18:52:24)

barzam wrote:1) What did you do to remove the cached version?
"rm /var/cache/pacman/pkg/*" is what I did... Disk space was running out, and many gigabytes of packages had accumulated there...
barzam wrote:If I bet someone can mail it to you or maybe you can do a forum search for places to get older packages.
Ok, I did a search, and finally I managed to download xf86-video-intel-2.9.1-1 from an out-of-sync mirror and downgraded to that... Everything works again...
barzam wrote:2) Maybe you should try Debian stable if that's what you need.
No, that's *not* what I'm asking for, no need for sarcasm.
I like the rolling-release approach...
But *sometimes*, you *do* want to downgrade a specific package, and it would be nice if Arch would makes this possible without forcing you to go dumpster diving in out of sync mirror archives or some other ridiculously hackish approch (at least for a select set of critical packages, like the kernel and important drivers).
Edit: fixed quote
Last edited by sas (2010-02-12 22:20:11)

Noob question concerning rolling releases

Hi,
I'm little confused on how the rolling release /snapshot iso downloads that are available, works.
For instance, if I look into 'Don't panic 2007.08', it comes with the latest kernel found in 'Don't panic 2007.08-2'.
What are then the differences between 2007.08 and 2007.08-2?
Also, the core ISO available for download point to the latest kernel - ftp://ftp.free.fr/mirrors/ftp.archlinux … 07.08/i686
but the date indicates it was uploaded: 2007-10-04 06:26:00. Does it still mean that if I download an ISO *now* from 'core', I will get the latest packages = same as the ones I would get if I chose to do a FTP-installation?
Last edited by new2arch (2008-02-27 10:18:47)

new2arch wrote:What are then the differences between 2007.08 and 2007.08-2?
I think this is just a revision to remove bugs in the actual installer program.
new2arch wrote:Does it still mean that if I download an ISO *now* from 'core', I will get the latest packages = same as the ones I would get if I chose to do a FTP-installation?
No, but as long as you have a good internet connection without a download limit, then it shouldn't matter. With rolling release, you simply upgrade the system with the 'pacman -Syu' command and everything suddenly becomes up to date (well, by suddenly i mean a few hundred megabytes later. this is only for the first update after an install though. updating regularly will mean each update will be usually no more than 15MB)
From the arch wiki
Arch Linux releases coincide with each major kernel version, but are merely a snapshot of the /core repository, combined with various features or modifications to the installer script itself. The rolling release model keeps every Arch Linux system current and on the bleeding edge by issuing one command.
For this reason, releases are not terribly important in Arch, because the rolling-release system makes new releases out of date as soon as a package has been updated. If you are looking to obtain the latest Arch Linux release, you do not need to reinstall. You simply run the pacman -Syu command and your system will be identical to what you would get with a brand-new install.
For this same reason, new Arch Linux releases are not typically full of new and exciting features. New and exciting features are released as needed with the packages that are updated, and can be obtained immediately via pacman -Syu.

Component SEM-BW releases

Dear All,
In the context of SAP ERP EhP releases, component SEM-BW releases are 6.02 - 6.05 (EhP2 - EhP5).
It is clear.
But what is "SEM-BW Release 634"?
It is mentioned, for example in [SAP Note 1171344 - SEM-BCS in the context of SAP ERP 6.0 EHP|https://service.sap.com/sap/support/notes/1171344] in "Affected Releases" section.
Best regards,
Anton Kuznetsov

Dear Anton,
I guess You found the answer in the meantime. Anyway, please check notes 1539356 (Upgrade to NW 7.3 with SEM-BW, FINBASIS, SAP_BS_FND, WEBCUIF) and 1531022 (Deployment options for SAP SEM based on SEM-BW 6.04). SEM-BW 6.34 is the relevant version if one wants to follow the upgrade option to NW 7.3.
Best regards,
Olaf Benkert

[Fake News] Arch Linux to change its release cycle

Today the Arch Linux community proclaimed that Arch Linux will change its release cycle and version numbering, as this was requested by billions of corporate goonies, Freemasons and Illuminati throughout the universe.
Releases will henceforth be scheduled in intervals deemed posh by the GNU/Linux community at the particular moment. The version numbering will be based on year the a new release is being published. Arch Linux "2016" will be released in early 2006. All following releases will have an offset of at least 10 years to underline how much more pure dead brilliant Arch Linux is compared to Mandrake.
To achieve a smooth transition, an transitional release will be made at once, named "Useless Marketing Edition". The Arch Linux FTP server will be configured allow one download of the iso image only. This will also be an experiment to find out how the community will be able to spread such a limited edition.
An Arch Linux user who wishes to remain nameless said in an exclusive interview with the almighty incinerator: "This is a great opportunity for Arch Linux, the new release numbering will confuse and divert computer illiterate lusers from installing our beloved Arch Linux, freeing us from answering stupid support requests. Now we can finally start to work towards our ultimate goal: To become the only GNU/Linux community being as elitist as OpenBSD's."

Ach guys, you don't get it :-(
The version numbering scheme was supposed to mock the fact Mandrake plans to release their "2006" version in 2005. That reminds of old times, when (computer) magazines were trying to beat each other releasing the most up-to-date issue to the market. The whole affair became absolutely silly, there were magazines that had the "April" issue hitting the shelves at the end of January. These "issue number wars" occur every now and then.
The funny scenario I can imagine is that other (GNU/Linux) vendors could jump onto that train and "predating" their releases further and further.
The rest is just various mockery about lusers and other things found in the Mandrake's press release. And of course the arrogantly elitist OpenBSD community always deserves getting their arses whipped ;-)

Issues with Arch 2009.02 in VMware Workstation [SOLVED]

I installed Arch Linux 2009.02 i686 as a guest in VMware Workstation 6.5.1, my host is Vista x64. The installation of Arch itself and Xorg wasn't a problem although from this point I've had several issues.
I was unable to 'startx' or 'xinit' without getting crashes, however adding hal to the daemons fixed that problem - some wiki entries state to add dbus, but dbus is already started. A lot of content on the wiki is outdated, telling users to use hwd; I did install hwd separately (from sourceforge) although it gave me hundreds? of errors related to PCI and eventually failure to parse some x configuration binary in /usr/bin.
Multimedia Issues
I then installed xfce4 and gstreamer-plugins. All video and audio play back too quickly, i.e. it seems to play the streams as fast as they can decode. This also happens with flash content such as youtube after I'd installed the appropriate programs. Thinking this may be a timing issue, I editted the vmware config file on my Windows host although it did not help; the timing in the VM seemed to be correct anyway.
Display Issues
When I run 'startxfce4' from a terminal, Xfce will start as 800x600 - if I go to change this resolution all options show 0Hz as the refresh rate and many options my monitor cannot display are shown even though I have VMware set to allow a maximum size of 1680x1050. I was unable to generate a 'good' xorg.conf file using 'X -configure' and as mentioned earlier, hwd would not work for me. I installed xf86-video-vmware and xf86-video-vesa as well as both open-vm-tools and normal vmware-tools (not at the same time or together) but can't seem to sort this issue. vmware-tools was able to generate a valid xorg.conf file but it only included a handful of 4:3 resolutions and some of these still showed 0hz. For some strange reason 'startx' and 'xinit' now do not work having failed to find /dev/fb0.
VMware Tools
When I did try to install vmware-tools, it had many difficulties trying to build the modules - mostly regarding to not recognising __FREEBSD__, I cannot remember the complete error. I also tried to build open-vm-tools but that gave an error about not being able to find libproc even though I had procps installed. Stopping open-vm-tools on shutdown also always fails and occurs twice.
I'm going to try reinstalling now that I know a little more about what I did to get things working but if anyone could give me a hand it'd be much appreciated.
Last edited by andyxl987 (2009-08-04 00:17:29)

After a lot of experimentation I've got a satisfactory installation although a few minor problems remain:
Adjustments required to correctly run Alsa+Xorg in Arch Linux 2009.02 using VMware Workstation
The current kernel does not play nicely with alsa, downgrade to kernel26-2.6.29.4-1:
wget http://www.schlunix.org/archlinux/core/ … pkg.tar.gz
pacman -U kernel26-2.6.29.4-1-i686.pkg.tar.gz
Install/Upgrade dbus:
pacman -Sy dbus
Add hal (if it's not installed then make sure to do so) to your daemons located in /etc/rc.conf, e.g.
DAEMONS=(syslog-ng network netfs crond hal)
The current open-vm-tools-modules is not compatible with the older kernel, instead use open-vm-tools-modules-2009.04.23-1:
wget http://www.schlunix.org/archlinux/commu … pkg.tar.gz
pacman -U open-vm-tools-modules-2009.04.23-1
The installation will prompt you with an error that /etc/modprobe.conf could not be found (as does the current version), add the following to /etc/modprobe.d/modprobe.conf:
install pcnet32 /sbin/modprobe -q --ignore-install vmxnet; /sbin/modprobe -q --ignore-install pcnet 32 ; /bin/true;
You can now install open-vm-tools:
pacman -S open-vm-tools
To autoload open-vm-tools on start up you need to add it to your daemons located in /etc/rc.conf, e.g.
DAEMONS=(syslog-ng network netfs crond hal open-vm-tools)
Add vmware-user to your /etc/X11/xinit/xinitrc file if you desire (for seamless mouse and display switching), e.g. my xinitrc with xfce4 ends with:
vmware-user &
exec startxfce4
Install the following components: xf86-video-vmware xf86-video-vesa xf86-input-vmmouse xf86-input-mouse:
(You will not be able to start x if you have installed xf86-video-fbdev and do not have a valid xorg.conf file, this is addressed later)
pacman -S xf86-video-vmware xf86-video-vesa xf86-input-vmmouse xf86-input-mouse
Lastly we need to edit/create the /etc/X11/xorg.conf file to use our vmware drivers, this will enable automatic resolution switching and seamless mouse functionality:
(All of the following is necessary otherwise X will ignore our vmware drivers)
Section "ServerFlags"
Option "AllowEmptyInput" "false"
EndSection
Section "InputDevice"
Identifier "VMware Mouse"
Driver "vmmouse"
Option "Protocol" "ps/2"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "true"
EndSection
Section "Device"
Identifier "VMware SVGA"
Driver "vmware"
EndSection
Section "ServerLayout"
Identifier "VMware Config"
InputDevice "VMware Mouse" "CorePointer"
EndSection
Issues
* open-vm-tools fails to stop during a shutdown or /etc/rc.d/open-vm-tools stop/restart
* most screen resolutions show 0Hz (although everything works correctly) and adding VertRefresh to xorg.conf produces a major error
* playback of flash video produces a sound artefact when starting - although I think this may be to do with the decoder rather than system
I've marked this as solved although I welcome any suggestions regarding these minor issues. The open-vm-tools one I can probably sort out but it's too late now to look into tonight
Last edited by andyxl987 (2009-08-04 00:21:03)

Trying out Arch on VirtualBox, a real PITA (solved)

Hi there, I've been having a hard time lately trying to install Arch on VirtualBox latest version (3.1.4 IIRC) on a windows host to give it a try.
First I tried the net-install edition, so I wouldn't have to update later and it run flawlessly until pacman began to download packages, when it reached the kernel package it stalled there forever. Tried different repos with the same result.
Instead of giving up I decided to install the core version so at least I'd had an Arch running system. On this occasion the setup went smoothly but as soon as I tried to run a pacman -Syy on the running system to refresh the package list it wouldn't download a thing, getting stalled at 0% on "core". Pinging to google.fr resolves it to an ip and pinging an internet ip address there's also a response so I don't get it. Also tried to download something with wget and it worked like a charm. Changing to another repo doesn't seem to help at all. Any other ideas?
Tomorrow I'll try to use an older VB version and reinstall Arch to check if that's the problem. Thanks in advance!
Last edited by maqbeq (2010-03-20 00:15:21)

loafer wrote:Can you download with wget using pacman (i.e. uncomment in /etc/pacman.conf)?
Thanks for that tip! Finally I was able to run pacman and update the system. This m8 be considered as a fallback if pacman doesn't work (like in this case) for next net-install release.

Arch gets *really* bleeding-edge: releases KDE 4.2 before KDE does!

I know distro devs get KDE a full week or so earlier to begin testing with their distro, etc., and the essentially unchanged RC was here before, but KDE 4.2 stable is in Arch's main repos now - _before_ it's available on the KDE web site! I mean, I knew Arch was bleeding-edge, but come on!
http://www.archlinux.org/news/431/
(And, yes, the 4.2 ChangeLog link is broken, I suspect there will be such a page within 24hrs)
www.kde.org still says KDE 4.2 is to be released tomorrow, and I can't download the 4.2.0 source from the location specified in the KDE 4.2 PKGBUILDs. None of the KDE mirrors have it.
Not that I'm complaining...
Last edited by Ranguvar (2009-01-27 00:18:31)

that seems to be a small problem with upgrade:
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
archlinuxfr is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
Targets (31): mysql-clients-5.0.75-2 mysql-5.0.75-3 akonadi-1.1.1-1 phonon-4.3.0-2 soprano-2.1.67-1 kdelibs-4.2.0-4 kdeaccessibility-4.2.0-1 kdebase-runtime-4.2.0-2 libical-0.43-1
kdepimlibs-4.2.0-1 kdebase-workspace-4.2.0-2 kdebindings-4.1.3-1 pycups-1.9.42-2 system-config-printer-1.1.1-2 kdeadmin-4.2.0-1 kdeartwork-4.2.0-1 kdebase-4.2.0-1
kdeedu-4.2.0-1 kdegames-4.2.0-1 kdegraphics-4.2.0-1 kdemultimedia-4.2.0-1 libmsn-4.0beta4-1 ortp-0.15.0-1 kdenetwork-4.2.0-2 libmal-0.44-1 kdepim-4.2.0-1
kdeplasma-addons-4.2.0-1 kdesdk-4.2.0-1 kdetoys-4.2.0-1 kdeutils-4.2.0-1 kdewebdev-4.2.0-1
Total Download Size: 0.00 MB
Total Installed Size: 773.78 MB
Proceed with installation? [Y/n]
checking package integrity...
(31/31) checking for file conflicts [######################################################################################################################################] 100%
error: could not prepare transaction
error: failed to commit transaction (conflicting files)
/usr/share/apps/plasma_scriptengine_ruby/applet.rb exists in both 'kdebase-workspace' and 'kdebindings'
/usr/share/apps/plasma_scriptengine_ruby/data_engine.rb exists in both 'kdebase-workspace' and 'kdebindings'
/usr/share/kde4/services/plasma-scriptengine-ruby-applet.desktop exists in both 'kdebase-workspace' and 'kdebindings'
/usr/share/kde4/services/plasma-scriptengine-ruby-dataengine.desktop exists in both 'kdebase-workspace' and 'kdebindings'
Errors occurred, no packages were upgraded.
Last edited by zyghom (2009-01-27 05:22:22)

How can I get arch-chroot to source /root/.profile [solved]

I really like the arch-chroot script. When I come into the chroot using the script, I see that the shell is /bin/sh instead of bash. That is ok. How can I get the root user inside the chroot to source /root/.profile automatically? I have a line in there that will
exec /usr/bin/bash
. Thank you.
Last edited by maggie (2013-09-16 19:27:20)

2ManyDogs wrote:
Beginner's Guide wrote:
Note: Use
arch-chroot /mnt /bin/bash
to chroot into a bash shell.
That works. Thank you.

What's wrong with my Arch linux grub bootup/FSTAB? [Solved]

So ever since I did a fresh install of Arch Linux, every time it boots up and I select the Grub option it says "A start job is running for /dev/drive/" and shortly after it says timed out and continues onto the login screen as normal.
I have two drives, Windows is on the other one and on the Linux one I have just two partitions, root and swap.
I've tried to do a couple of things such as creating another grub option and setting the root to that ID however it still seems to be occurring. It seems to me that it keeps changing because sometimes when I boot it doesn't do it but it is very rare that it doesn't do the start job.
How can I permanently make the GRUB2 menu boot the correct drive and partitions, both root{ext4} and swap without it having to run a start job every time I boot it up?
Last edited by Developer (2015-04-09 19:02:42)

WorMzy wrote:
Note that sda,sdb,sdc... names are assigned on a first-come, first-served, per boot basis, so they are not ideal for use in your fstab. Instead, you should use UUIDs or labels.
https://wiki.archlinux.org/index.php/Pe … ice_naming
The problem is back, the drive names keep changing, how can I use UUID's for the fstab?
I saw something about UUID's above each drive name however, they were commented out. Do I replace the drive name part with the UUID for every drive, so for example:
/dev/sdb1 / ext4 rw,relatime,discard,data=ordered
to
UUID=b411dc99-f0a0-4c87-9e05-184977be8539 /home ext4 rw,relatime,discard,data=ordered
Or do I just uncomment the UUID part? which would leave me with something along the lines of:
UUID=b411dc99-f0a0-4c87-9e05-184977be8539
/dev/sdb1 / ext4 rw,relatime,discard,data=ordered

I can boot into Arch, but not DM or DE [solved]

I just recently installed Arch in VirtualBox. Arch is running on 1GB of RAM (changed from 512MB) and 8GB of storage with dynamic size enabled. I set the specs low as I want this to be portable and load on almost any machine. When it boots up I can access command line, but not DM or DE. If I set it to automatically boot into a DM or DE, it hangs (black screen). I have tried different DMs (GDM, KDM, SDDM) and DEs (Gnome, KDE, Plasma), but I get the same problem. During the boot process I get intel_rapl: no valid rapl domains in package 0 and SMBus base address uninitialized. While researching though, these problems don't appear to be linked to mine. Any advice would be helpful, thanks.
Last edited by flavinator (2015-06-12 04:46:33)

flavinator wrote:Update: So, I'm a little lost. I got all the packages installed. I edited the xinit file the way it says to. I chmod it.
Why did you chmod it? This is not in the instructions.
flavinator wrote:When I startx though, X has no file or directory, and don't see where it says how to create one.
What does this mean? Is this some translation or interpretation of an error message? Post the *actual* output.
flavinator wrote:I thought it would do that when XDM installed.
XDM is also not part of the instructions for testing TWM. If you start doing random other steps, we will not be able to help you as we will not understand what state your machine is in.
flavinator wrote:Update 2: I got startx to run, but then it fails with "Using system config directory "/usr/share/X11/xorg.conf.d" 0x00c00000, type = 1) Invalid argument (22) (II) Server terminated successfully"
Please post the *full* output. The server terminated successfully suggests a problem with your xinitrc, so as ewaller requested, we'll need to see that - after you provided the actual output and error messages you are getting.

Lots of arch=('armv6h') package in the AUR [SOLVED]

I see many threads get closed if asking for help on ARM systems so I think it is not allowed. Is it allowed?
Last edited by maggie (2013-04-04 11:56:20)

Support here on the BBS is offered only to Arch-proper—that is, not any of its derivatives (including, but not limited to, those projects which offer support for other platforms). Having said that, the AUR is 100 percent unsupported (by anyone other than the maintainer) anyway, so if a PKGBUILD allows for an unsupported architecture, that shouldn't be a big deal.
All the best,
-HG
Last edited by HalosGhost (2013-04-03 11:27:01)

Gnome-cups-manager and rolling release

can anyone make an update of gnome-cups-manager for voodoo? it as been 6 months since the last one...some help here please

I [03/Jan/2007:07:36:20 -0100] Configured for up to 100 clients.
I [03/Jan/2007:07:36:20 -0100] Allowing up to 100 client connections per host.
I [03/Jan/2007:07:36:20 -0100] Using policy "default" as the default!
I [03/Jan/2007:07:36:20 -0100] Full reload is required.
I [03/Jan/2007:07:36:20 -0100] Loaded MIME database from '/etc/cups': 34 types, 39 filters...
I [03/Jan/2007:07:36:20 -0100] Loading NextJobId from job cache file "/var/cache/cups/job.cache"...
I [03/Jan/2007:07:36:20 -0100] Full reload complete.
I [03/Jan/2007:07:36:20 -0100] Listening to ::1:631 on fd 2...
I [03/Jan/2007:07:36:20 -0100] Listening to 127.0.0.1:631 on fd 3...
E [03/Jan/2007:07:36:20 -0100] Unable to set ACLs on root certificate "/var/run/cups/certs/0" - Operation not supported
here is the log of cups...please some help here...

Arch as a semi-rolling release ? [Solved]

Similar Messages

Maybe you are looking for