Re: [arch-general] pacman trust DB issue
What is it I'm missing? THX Frank try updating archlinux-keyring first.
Re: [arch-general] CUPS HP OfficeJet 8620 Pro
Jörg Jellissen: > Hello, > > my printer is a HP OfficeJet 8620 Pro. > But i still can't find any drivers for arch. > > Normally it is enough to install hplip package from the repos > but it don't work. > > Can anyone help me to fix this problem? > > > Thank you > Hi, I've got the same printer, works fine with hplip (without any AUR packages). relevant lines in my /etc/cups/printers.conf MakeModel HP Officejet 6800, hpcups 3.20.6 DeviceURI hp:/net/Officejet_6800?ip=192.168.2.150 regards signature.asc Description: OpenPGP digital signature
Re: [arch-general] HP Laserjet plus 1020 Problem
19.08.2020 16:52, das via arch-general: Dear friend Karx asked me to try to print something and then give the differences in the three files in /var/log/cups. I tried to print one page from Libreoffice Writer and here is the result of running diff for the old and new versions of the three files for the three files. You seem to just learn the first basic steps of debugging and finding a problem in your linux setup. The mailinglist is not a good place for that, it is meant for more in-detail discussions of interest for many. You might be better off opening a thread at the forum [0], where somone can slowly walk you through the process. This helps both you (you learn a lot more than here with very short answers) and the subscribers of this list (less irrelevant noise). Thank you and good luck [0] bbs.archlinux.org
Re: [arch-general] NFS "updates"?
Personally, I have no standing here nor there, so I won't follow your suggestion. The linux-nfs@ members would probably reply that downstream distributions are free to ship nfs over udp enabled kernels if they choose so... Response to the proposal of deprecating UDP transport <https://www.spinics.net/lists/linux-nfs/msg74889.html> was positive, as much as there was. Cheerio, Hauke As a workaround you could set up a local repo and ship your own kernel, that you rebuild (semi-?)automatically from the ABS. That way you don't depend on somebody else to fix this, but it of course puts the maintenance burden on you. Georg
Re: [arch-general] how to upgrade 2017 server ?
Am 11.01.20 um 03:57 schrieb Shadrock Uhuru via arch-general: i have a server that has not been booted since 2017, i tried upgrading with pacman -Syu, i have post the screen output at http://paste.openstack.org/show/788264/ i thought adding Eli Schwartz' personal repository to pacman.conf would have allowed the upgrade with his Binary builds of pacman-static. is my problem still to do with the xz to zstd change or something different ? shadrock You can use the ALA [0] to update to a specific date. Pick a date not too far before the first zst packages roll in, update (keyring first) and then you should be able to use the current mirrors. [0] https://wiki.archlinux.org/index.php/Arch_Linux_Archive#How_to_restore_all_packages_to_a_specific_date
Re: [arch-general] What happened to Arch Wiki recent changes news feed?
Also, it's been two months, isn't it time to make even the Special: pages openly accessible again? You can not expect the devs to read this list, and they are the ones to decide. I'd write a polite inquiry directly to the author of the mentioned message.
Re: [arch-general] What happened to Arch Wiki recent changes news feed?
I noticed some time ago the feed stopped working. I used to follow it using the gwene.org gateway, but even following the link from https://www.archlinux.org/feeds/ to https://wiki.archlinux.org/index.php?title=Special:RecentChanges=rss sends me to a "Login Required" page. So apparently either the feed is gone for good intentionally (I hope not) and shouldn't be listed, or is broken and should be fixed? I think you are bitten by changes introduced in the wiki update ~10 weeks ago. See [0] for details. [0] https://lists.archlinux.org/pipermail/arch-dev-public/2019-September/029664.html
Re: [arch-general] js60 update -- reveals older packages installed as deps not updated and left on system
Am 18.05.2019 01:23, schrieb David C. Rankin: $ pmq | grep '^js' js 24.2.0-4 js17 17.0.0-4 js52 52.9.0-2 js60 60.6.3-1 What puzzles me is the wide range of version numbers with the un-suffixd package not even being the highest. Can anyone explain their versioning scheme, like does it make sense when read backwards or what? grateful for any sane explanation Georg
Re: [arch-general] adding to capacity to /
Hi Pete, you could rsync your system to another partition, create a new, greater, encrypted partition and rsync everything back. there's an article on the wiki about backing up root partitions with rsync! worked for me a couple of times. regards -- Georg Pfahler On March 9, 2019 9:26:01 PM GMT+01:00, pete via arch-general wrote: >Hi folks . > >i have a problem when i built this system i thought i had allowed >enough space for the / partition but it seems now i was wrong . I do >not really want to start again and rebuild the system . > >I have several spare drives lurking is it possible to add space to the >partition by adding another drive mounting it as / .. > > > >Thanks Pete .
Re: [arch-general] Which MTA to use to store mails?
Am 03.07.2018 um 19:37 schrieb Peter Nabbefeld: > Am 03.07.2018 um 16:00 schrieb Dan Haworth: >> On 03/07/18 14:52, Peter Nabbefeld wrote: >>> >>> Hello, >>> >>> topic is probably not so precise. What I want is the following: >>> - I've got some Email/IMAP account. >>> - My mail is hosted on a server by GMX. >>> - I've got too many Emails on the host. >>> - I don't want to loose any of the emails. >>> - So I will have to install my own mail server, >>> fetching all my emails from the host. >>> - The mail server will then have to interact with >>> my providers server like a client, working as a server for me. >>> >>> I'm sure there're some good servers, but I don't know which one >>> - works as expected, >>> - and is easy to configure. >>> >>> Any help appreciated. >>> >>> Kind regards >>> >>> Peter >> Hey Peter, >> >> Personally I have always been happy with exim and dovecot for local >> mail servers. Regarding downloading your mail from your remote >> provider regularly, I would personally use fetchmail for that - it >> sounds exactly what you're looking for >> (https://sourceforge.net/projects/fetchmail/). >> >> Hope that helps, >> >> Dan >> > Hello Dan, > > seems I need a certificate for dovecot including my server's name, but I > don't have a fixed IP nor a DNS name. > > Regards, > Peter Hi Peter, in the mail ecosystem a self-signed certificate is just doing well enough, the alternative to a failed certificate chain verification is plaintext anyways. Gruß Georg
Re: [arch-general] Which MTA to use to store mails?
Hello, topic is probably not so precise. What I want is the following: - I've got some Email/IMAP account. - My mail is hosted on a server by GMX. - I've got too many Emails on the host. - I don't want to loose any of the emails. - So I will have to install my own mail server, fetching all my emails from the host. - The mail server will then have to interact with my providers server like a client, working as a server for me. I'm sure there're some good servers, but I don't know which one - works as expected, - and is easy to configure. Any help appreciated. Kind regards Peter Hi Pete, you might want to read this wiki page: https://wiki.archlinux.org/index.php/OfflineIMAP Cheers Georg
Re: [arch-general] Automatic login
I have an automatic login option in KDEs "System Settings" -> "Startup and Shutdown"-> "Login Screen (SDDM)" -> "Advanced" -> "[ ] Auto Login". The package extra/sddm-kcm is needed for that. Georg
Re: [arch-general] gnupg: systemd enable in post_install
what's the rationale to enable the gnupg sockets in post_install of the package? https://git.archlinux.org/svntogit/packages.git/tree/trunk/install?h=packages/gnupg#n21 I don't disagree that the sockets maybe should be enabled (I have them enabled for me), it's just a strange way to enable them in post_install, and linking them in /etc/ Why doesn't the PKGBUILD make the symlinks in /usr/lib/systemd/user/sockets.target.wants/ ? I did that in the pulseaudio package at first and people complained that they couldn't "disable" the pulseaudio socket and "mask" also prevented a manual start. Hence I moved pulseaudio from static symlinks to enable/disable post_install. GnuPG follows this. dbus does that for ex. The DBus `make install` sets it up that way; it wasn't a downstream decision. Packages should never enable or start any services. The same holds for sockets IMHO. From my point of view the appropriate solution would be a message in post_install stating the necessity of enabling the socket/service. georg
[arch-general] Linux x64 no-execute protection (NX) not enabled by default?
Hey, is there a reason for x64 no-execute [1] being disabled by default in Arch? I opened FS#46496 on this. https://bugs.archlinux.org/task/46496 Regards, Georg [1] https://en.wikipedia.org/wiki/NX_bit -- PGP-Key: 0x1E320E65 D150 7783 A0D1 7507 1266 C5B3 BBF1 9C42 1E32 0E65 I don't like the idea of secret agencies to analyse and archive personal communication. GnuPG is available as open source, free as as in freedom, as a countermeasure. I use http://www.enigmail.net/ for Mozilla Thunderbird. If you can, please use a frontend of your choice to send me encrypted e-mail. See http://www.gnupg.org/ for an overview.
Re: [arch-general] postgresql 9.3 - 9.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Looks like I hit quite a nail here. Let me describe my usecase. I was doing this on my personal box. If it was on a production server, I would have looked three times before doing an upgrade of any kind. I would refrain from having a rolling release distro on a server anyway, but that is another topic. Probably I should have looked at the pacman output more closely. And running a postgresql instance one should know that minor upgrades need a dump and restore. I also think there are people with less experience that are caught unprepared by such a situation. I know arch is for experienced people, but what's the harm of showing a _pre_ upgrade notice anyway? In the end, a distribution and a packaging system should make life easier not harder, right? I humbly propose that for the next postgresql release that needs manual intervention, there should be a _pre_ upgrade notice, clearly saying that manual intervention is needed. It doesn't look like pacman provides this capability though or does it? Regards, Georg -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUyhJVAAoJELvxnEIeMg5lGMIIAIwLJSSiBuD5RduqZH9VkaYw YdFhg+L5zVyR3QPx1Hw3F4l0xS5QoGvQG3aZiF14lQhvf4ANlkLahJpZBMa4MRpM eZzJVpSNTNiLDXqpycxn1dD8N2yjvrT4j7Qa/dmropArHdWn14Xy8lg4Q1lBW2vN heLSZgIKL90vd+I3bJFOCxoU92w5tzn9L65Wl3qxW/exLcka/VMVXknp5NOMD0tb 0xXB615r9IOzcMgfaxRDMcuzx5doBS/e/ICNlShG52ZcAPmhCBVAfeHzwQRIIerT D+DCCHl1HQTgzPBIcfxmerlOTmIN4ZWbjIS0Tyj36QFqD2Zv5xYwfa+znOEExDQ= =TNjm -END PGP SIGNATURE-
Re: [arch-general] postgresql 9.3 - 9.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29.01.2015 17:40, Don deJuan wrote: From someone who runs Arch in prod on a ton of servers. It was the admins fault. Not arch's not pacman's and not PGSQL's it was the admin. Running a rolling release in prod requires the ability to pay attention to every detail fully for every action you make. Be accountable for your own mistake. This thread is a joke at this point. The OP messed up by nothing other than his own lack of admining a prod box productively and effectively. This situation would have been avoided if you were on top of your prod box and not just blindly running pacman -Syu. And yes I actually had 0 issues with this update cause I saw it in the queue to install and took the needed steps to avoid the OP's exact situation. Have a screwed up on one of these sure and was never anything more than my own mistake. Whatever happened to self accountability? Know the software you run, dont let the software run you. Look, I don't see what you are getting at here. I am not blaming anyone for anything. I am _not_ running anything like a production environment. Again, this is my personal desktop computer. I cannot spent much time for every update that shows up. And, as I said before, we live in a world where remote security flaws appear almost daily and thus, as a responsible person, you have to update often. It would be nice if the packaging system would support me doing this and not run me as it did in this special case. I am merely _suggesting_ to implement a warning message. It certainly _is_ easy to miss something in the pacman -Suy output. As such, I think this would be beneficial to everybody running postgresql, be it on a single desktop computer or a farm of servers. Regards, Georg -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUynWBAAoJELvxnEIeMg5lfPIIAILHHZjEJfwiH1xlvOvqYpFC lJbVasAL4XlRtO2FksSqVEw01srwr5YLkKL1/nsQmrm23C8iGD8H5Gt3dFWZSaPt +H+kqa1HyEZuBwNA8ti/u540OaH+kTDeXCS/OfW+WJRhQUtMx/Fu7hT74s0HekDE vOCbNZlQUlvVsAnVeqQnDnxpKpmJsTnjSugLBxSkOnP1Jg2LzsQdaH7+L8UYb/P8 4ToAmUY2JvVSXabLJHOH5VsAftaPOZQnwpK7SBgUVmyKi4a8bsZFhhwM1Xkm2rbd tteKH0/TItgwGnXdOzJ0kZ+9OWgkJmnv6vEGy1bNYVopQks1ebCBfgpTxjySyjI= =HNoY -END PGP SIGNATURE-
Re: [arch-general] changelogs (was Re: postgresql 9.3 - 9.4)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29.01.2015 17:44, Lukas Fleischer wrote:
On Thu, 29 Jan 2015 at 17:06:43, Georg Altmann wrote:
[...] On 29.01.2015 14:22, Bardur Arantsson wrote:
If the problem here is that it would be a chore to do this for
maintainers for every X.Y - X.(Y+1) upgrade, then maybe Arch
package descriptions could grow a field or flag to handle such
things semi-automatically? Maybe something as simple as if
the version number is about to change in *this way*, then warn
loudly using *this message*.
Wouldn't that be a sensible way? The increased overhead for the
maintainer would be to tick a flag in addition to the version
bump. In the case of postgresql this would be a as simple as
if (oldMajor newMajor || ((oldMajor == newMajor) (oldMinor
newMinor)) { printUpgradeWarning(); }
Of course the condition would have to be serialized in the
package meta-data some way. I have only very limited knowledge on
the pacman internals. Maybe someone can come up with an estimate
how big the effort would be to implement this. [...]
It isn't that easy. You cannot simply tick a flag, you need to
maintain a variable that keeps track of the last version that
caused a warning. Otherwise, there's no way to warn a user who
upgrades straight from 1.0.0 to 2.1.0 when there were intermediate
releases 1.1.0 and 2.0.0 and some change between 1.1.0 and 2.0.0
that is worth a warning. And as a matter of fact, that is what we
already do in a lot of packages. You can have a look at the install
scriptlets of btrfs-progs, cups, dhcp, dmraid, dovecot, ebtables,
intel-ucode, linux, lirc, lvm2, mariadb, nginx, openvpn, systemd,
varnish, just to get an idea of what it looks like. As I mentioned
before, adding a similar check to PostgreSQL might be a good idea
but I, as a non-PostgreSQL user, cannot judge whether that works
and is worthwhile.
For postgresql it is exactly that easy. A comparison of the version
numbers is enough: If they differ at least a minor version, churn out
the warning. Implementing it this way, the overhead for the maintainer
would be zero.
But thanks for clarifying. I will look into the scriptlets for the
packages you mentioned. And I will try to make a bug report based on
that for postgresql.
Regards,
Georg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUynXYAAoJELvxnEIeMg5lrWYH+QHdJbx+wuLv5KcaLWeM0ZVO
+lzehIt3Z+XvyJQQrtX/BXUEzq3rUNC4nnswKWqOZv/zyzoAfZchF+cIi75k7/Mt
W5ZWPpnU/gmQCRifHI+wHSF19aa+0hvFtR7CGdEkO4nnPtmveyibNDxtDaD0Jy8B
kZrSZ5gXsVFqIoGUZivq4eXDTHDXljui60SFzD76BCc1zywWpWJlbUG4ZjSCt8bP
DRtlfEQzC/XQrZhoaGJceM+MT0Xp/GhoPITUtkeAuN/VF/hUbJOtuoKAs1vcq63U
Ps4vLaqCMk8vQm5UFnzBXSAFR91nb8CceuYfKtaHGNy3P8UF2g2Be7C4ruLhMlE=
=mvrh
-END PGP SIGNATURE-
Re: [arch-general] changelogs (was Re: postgresql 9.3 - 9.4)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29.01.2015 16:33, Lukas Fleischer wrote:
On Thu, 29 Jan 2015 at 16:08:02, Carl Schaefer wrote:
The thread about the postgresql update reminded me of one of the
few things about Ubuntu that I miss: package updates usually
included a useful changelog entry describing what was fixed
and/or new. Perhaps I assume too much, but I imagine Arch
package maintainers would generally be aware of the changes in
an update they're making, and so it wouldn't be much additional
work to include that information in a changelog entry.
It actually *is* much additional work. Bumping the package version
usually takes ~5 seconds. That does not include the time to build
and test the package but we don't need to watch the build process
and packages are often tested by using them in production. So,
compared to those five seconds, looking up every single change and
coming up with a change log is a lot of time -- and it usually
doesn't pay off, apart from corner cases. Please examine the
mailing lists, this story has been discussed several times
already. Keeping bureaucracy to a minimum is one of the reasons we
can provide updates much faster than other distributions.
I understand the effort the packaging requires. Writing changelogs may
be to much work and this is not what I propose. On the other hand,
upgrades that break stuff are seldom. As is the case for postgresql.
This happens every few month or so.
On 29.01.2015 14:22, Bardur Arantsson wrote:
If the problem here is that it would be a chore to do this for
maintainers for every X.Y - X.(Y+1) upgrade, then maybe Arch
package descriptions could grow a field or flag to handle such
things semi-automatically? Maybe something as simple as if the
version number is about to change in *this way*, then warn loudly
using *this message*.
Wouldn't that be a sensible way? The increased overhead for the
maintainer would be to tick a flag in addition to the version bump.
In the case of postgresql this would be a as simple as
if (oldMajor newMajor ||
((oldMajor == newMajor) (oldMinor newMinor)) {
printUpgradeWarning();
}
Of course the condition would have to be serialized in the package
meta-data some way. I have only very limited knowledge on the pacman
internals. Maybe someone can come up with an estimate how big the
effort would be to implement this.
While I agree that warnings and front page news should be given
where appropriate, I cannot comment on PostgreSQL, which I don't
use. As it seems to be a similar process on every major update and
there even seems to be a script to warn you, I don't see any need
for another notice, though. As a database administrator, you
should be aware of what happens when you update the DBMS. Maybe
some post-upgrade message would be helpful...
Agreed -- it's just that I am not a DBMS admin in this case. This was
on my personal computer where I can hardly spent the time to look up
every package version change. In times where remotely exploitable
security flaws turn up almost daily, this is just not acceptable.
So, I have to trust the packaging system to some degree. Of course one
should check Arch announcements on the website and maybe follow the
mailing lists. There wasn't any notice for postgresql in this case.
Regards,
Georg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUylqNAAoJELvxnEIeMg5luLUH/0gTG37RjJNpV6XTFqesVUqH
ASNywi0VRQ0SSQAV4FFv/BymNMet9OVBBsxCOQooucGt6kakferujJMtRM4qkDtM
eGJK1ZJ1gtgNU415rZTWN/wCOby3J3r/HCL0NfTfXjmYJ2Q53WmcsCtGCSyQIJxR
jcggzK52kuTPYobeS7c2FoQguIS0CIdEJqUDcgF/PcxjXe/a9t6is4m+CeejJnXI
J5U8yqgaB9/4/wtiHMaGP9LCGQFW6582pIUwGd4ozId6Rr9ZJhcDDHrGaxtTu9oG
zWzG68hvhQKZUi2leNIhDh9k3tG8dOzyTt+kaM3IZkgiAwRG373cVGG+2IWti38=
=OqYb
-END PGP SIGNATURE-
[arch-general] postgresql 9.3 - 9.4
Hi, There was nothing mentioning a minor realease upgrade or did I miss something? Next time a heads up would be nice, so I know I have to dump and restore beforehand. Thanks! Georg -- PGP-Key: 0x1E320E65 D150 7783 A0D1 7507 1266 C5B3 BBF1 9C42 1E32 0E65 I don't like the idea of secret agencies to analyse and archive personal communication. GnuPG is available as open source, free as as in freedom, as a countermeasure. I use http://www.enigmail.net/ for Mozilla Thunderbird. If you can, please use a frontend of your choice to send me encrypted e-mail. See http://www.gnupg.org/ for an overview.
Re: [arch-general] [Fwd: [arch-announce] Dropping i686 support]
chrooting 32 bit did always work with arch64. I had some problems with that one though, and by dropping i686 completely, you'll still need somebody to build all those 32bit packages, or do it yourself On Wed, Apr 1, 2009 at 12:23 PM, Abdul Halim sagikli...@gmail.com wrote: On Wed, Apr 1, 2009 at 6:12 PM, Dieter Plaetinck die...@plaetinck.be wrote: On Wed, 1 Apr 2009 11:29:58 +0200 (CEST) Thomas Bohn tho...@bohnomat.de wrote: On Wed, April 1, 2009 11:00, M Rawash wrote: a more obvious choice would be to stick with archlinux+ABS, remember we're just dropping BINARY package support, arch's build tools will remain the same, think of it as a less sucky gentoo. To compile mplayer on my Atom N270 takes forever, I can't imagine to compile X or Firefox on that machine. Thomas distcc/crosscompiling etc. you can compile on your 64bit box for 32bit. Is there a chroot to 32bit from 64bit host in Arch? I guess it is time to do so. How am I gonna run my skype and wine application? :-) sounds like a cool project, maintaining some tools and scripts to do that on arch. Xyne has probably already written it. Dieter
Re: [arch-general] xorg-server 1.6.0 in testing
I've got the same problem here. The 945 chipset works fine, the 855 here does not. Anyway, what I did was simply installing the old intel driver : sudo -E pacman -U /var/cache/pacman/pkg/xf86-video-intel-2.4.3-1-i686.pkg.tar.gz So it's the intel driver which is most likely broken upstream for our chipset. The old intel driver works perfectly with the new xorg and libdrm. Kind regards, Georg On Tue, Mar 3, 2009 at 4:09 AM, Eric Bélanger snowmanisc...@gmail.comwrote: On Mon, Mar 2, 2009 at 1:34 PM, Jan de Groot j...@jgc.homeip.net wrote: The upcoming version of xorg-server will have a lot of workarounds and patches removed. Doing so, the package becomes easier to understand, as even its maintainer has no idea what is happening anymore. When upgrading to xorg-server-1.6, you will see these file conflicts on most systems: error: failed to prepare transaction (conflicting files) xorg-server: /usr/lib/xorg/modules/extensions/libdri.so exists in filesystem xorg-server: /usr/lib/xorg/modules/libwfb.so exists in filesystem It's safe and advised to overwrite these files. The symlinks were previously created from post_install by the xorg-server and nvidia-utils packages. It is advised to install xorg-server first by using pacman -Sf xorg-server, after which you can upgrade the rest of your system. This release of xorg-server requires a rebuild of all video and input drivers. Older drivers will fail to load with an ABI mismatch. Drivers in our repositories will receive an update to match the xorg-server ABI. Nvidia has updated their latest drivers with support for this version of xorg-server. AMD does not support xorg-server-1.6 yet in their Catalyst drivers. AMD users are advised to switch to the xf86-video-ati or xf86-video-radeonhd drivers instead, or keep any X.Org related updates on hold via IgnorePkg in pacman.conf. This can be done by putting xorg-server in IgnorePkg in pacman.conf. All other updates should have conflicts set, so it will be clear which additional packages should be added to the IgnorePkg list on your system. Note that there will be no support for older versions of xorg-server when this version moves to extra. I'm having problems with the intel drivers and OpenGL. With OpenGL sceensavers, I don't really know how to describe it but I can guess what's on the screen but it's garbled. With some OpenGL games, I get a black screen. I get the following message on the terminal: get fences failed: -1 param: 6, val: 0 I also get that message when running glxgears which works fine. My video card: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) Ask if you need more informations. Eric
Re: [arch-general] xorg-server 1.6.0 in testing
Would be interested in how you got that chipset running with the new drivers ... I can't get it working with the 82865G chipset, and there's not too much difference with those two. On Tue, Mar 3, 2009 at 11:22 PM, Mikkel Poulsen whargoul.mik...@gmail.comwrote: According to glxgears, my FPS falls from 400 to 100 FPS. On the contrary, YouTube Videos don't lag as much anymore. Intel card: 82852/855GM -- Cheers - Mikkel Poulsen
Re: [arch-general] xorg-server 1.6.0 in testing
Hmh, I'm not using a xorg.conf either, and still X freezes with the new driver and the arch stock kernel. Strange, I've filed a bug report at freedesktop for the intel driver now, let's see what they can tell us about this problem. Maybe there'll be a fix for this some time soon. On Wed, Mar 4, 2009 at 11:09 AM, Mikkel Poulsen whargoul.mik...@gmail.comwrote: For one, I don't use a xorg.conf at all. But when I wrote that post, I were using the 2.6.29-rc6-zen1 kernel. With the stock kernel I see much improvement (700 FPS - almost 80% improvement) with EXA. With UXA I only get about 200 FPS. 2009/3/4 Georg Grabler ggrab...@gmail.com Would be interested in how you got that chipset running with the new drivers ... I can't get it working with the 82865G chipset, and there's not too much difference with those two. On Tue, Mar 3, 2009 at 11:22 PM, Mikkel Poulsen whargoul.mik...@gmail.comwrote: According to glxgears, my FPS falls from 400 to 100 FPS. On the contrary, YouTube Videos don't lag as much anymore. Intel card: 82852/855GM -- Cheers - Mikkel Poulsen -- Cheers - Mikkel Poulsen
Re: [arch-general] Is qt 4.4.2-1 broken?
Depends on if the application itself or QT drops the dbus connection. A backtrace would be interesting where the errors occur. Kind regards, Georg On Fri, Sep 19, 2008 at 6:43 PM, Lee MaRS [EMAIL PROTECTED] wrote: Hi, all After upgrading to qt 4.4.2-1, I found that some qt4 program became broken, such as VirtualBox, and Qterm. All of these programs get a error like this: process 4272: The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details. Most likely, the application was supposed to call dbus_connection_close(), since this is a private connection. D-Bus not built with -rdynamic so unable to print a backtrace Aborted Is it really a bug of application, or just a bug of qt, or just a bug for this package?
Re: [arch-general] Is qt 4.4.2-1 broken?
Can be, but must not be. But you're right, most likely it's a bug in QT. On Fri, Sep 19, 2008 at 7:37 PM, Thomas Bächler [EMAIL PROTECTED]wrote: Lee MaRS schrieb: Hi, all After upgrading to qt 4.4.2-1, I found that some qt4 program became broken, such as VirtualBox, and Qterm. All of these programs get a error like this: process 4272: The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details. Most likely, the application was supposed to call dbus_connection_close(), since this is a private connection. D-Bus not built with -rdynamic so unable to print a backtrace Aborted Is it really a bug of application, or just a bug of qt, or just a bug for this package? My suspect here is qt. All the talk above comes from dbus, talking about an application doing things wrong. From the programmer of a qt application, dbus should be invisible.
Re: [arch-general] Linuxtag 2008 Berlin
I'll drive from Vienna to Berlin on the 28th of March. Since we're going by car, and will take a longer break (most likely), I'll arrive in Berlin somewhen in the eve'. On 5/15/08, Peter Feuerer [EMAIL PROTECTED] wrote: Hi, I'll be on the linuX-gamers.net booth presenting the arch based live.linux-gamers.net livedvd. --peter On Thu, 2008-05-15 at 10:51 +0200, Didi wrote: Hey Is anyone going to the Linuxtag in Berlin http://www.linuxtag.org/2008/en/home/welcome.html Would be cool to meet up, as fellow archers, and have a beer or something. Cheers Didi www.cern.ch/ribalba / www.ribalba.de Email / Jabber: [EMAIL PROTECTED] Phone (Work) : +41 22 7679376 Skype : ribalba Address : CERN / IT-FIO-FS / GENEVE 23/ SCHWEIZ
