Re: [arch-general] What to do about the blender package?
2009/7/19 Allan McRae al...@archlinux.org: Sven-Hendrik Haase wrote: Dear Arch Devs, I'm reposting this mail to arch-general because I was ignored on arch-dev-public. You can not post to arch-dev-public so your message was not ignored, we just never saw it. I wonder what should be done about the blender package in [extra]. The package hasn't been updated for quite some time (it is correctly marked out-of-date), a few bug reports have been filed for it, it doesn't build anymore and the package maintainer doesn't answer my mails. What can be done in such a case? So the package is out-of-date and the new version does not build? Could be a reason why it is not updated... Anyway, the way this tends to be dealt with, is someone posts a working PKGBUILD here and another dev updates it. If this happens regularly for a package, either another dev with take over maintenance or it will be dropped to [community]. Allan IMO the problem is that you (devs) use make to build blender which is several years deprecated and probably no-one builds blender this way. Maybe they've dropped support for it completely. I suggest using SCons. Maybe you can reuse my blender-svn PKGBUILD from AUR, only thing that has to be changed for this purpose is the part where data is downloaded from SVN server. There is one problem which I'm aware of with this package – it installs blender executable in /usr/share/blender and adds wrapper to /usr/bin. I'll probably move blender to /opt in near future. Lukáš stativ Jirkovský
[arch-general] firefox 3.5 en-us 3.03 dictionary
anyone get this installed? it's supposedly compatible with 3.5 and yet I can't install it. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [arch-general] What to do about the blender package?
2009/7/19 Lukáš Jirkovský l.jirkov...@gmail.com: IMO the problem is that you (devs) use make to build blender which is several years deprecated and probably no-one builds blender this way. Maybe they've dropped support for it completely. I suggest using SCons. Maybe you can reuse my blender-svn PKGBUILD from AUR, only thing that has to be changed for this purpose is the part where data is downloaded from SVN server. There is one problem which I'm aware of with this package – it installs blender executable in /usr/share/blender and adds wrapper to /usr/bin. I'll probably move blender to /opt in near future. There is also a request about building to SCons: http://bugs.archlinux.org/task/14893 and there is a PKGBUILD too (for stable, not svn version). -- Roman Kyrylych (Роман Кирилич)
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
Aaron Griffin schrieb: However, I must point out: odds are most people don't touch inittab, so the upgrade will do things as expected and the sed line will only do work a small subset of end users. You are wrong here. I would guess virtually any user touched it. And to be clear, I definitely do not like the pandering to users thing... if people whining about stupid shit gets on your nerves, stop visiting the forums and IRC. It worked for me! ( google 'eternal september' for kicks :). Yeah, we are proud of our great community which we like to ignore. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
Allan McRae schrieb: First off, I don't like modifying config files. But, given I did this update and still managed to screw my system up when testing it with a reboot... So, the average advanced user won't even notice the problem, even you didn't (and you did get a .pacnew and a warning, didn't you?). It would take someone like me to notice it on his own - and let's admit it, there's not too many people like me. Let's view this from another angle: It's not just the noobs and the unattentive users that will fall for this, it's also over half of the advanced and experienced users. That said, we do modify configuration files all the time. We run grpck on a shadow update so users can still log in, some gtk update generate files in /etc so it still finds its plugins and more. We just don't do it ourselves, but hide behind some program provided to us and tell ourselves It's okay, upstream wanted it this way. And guess what, nobody even notices. So it is a question of which I hate more; post install messages or automatically fixing the file. A post install message means that I tell all complaining users that they should have read their pacman output. But hang on, they are already told that there is a .pacnew file for what is a very important config file. Yes, and there has been a warning for inittab.pacnew several times in the past few months, always with some completely irrelevant added comment or added default lines. So, we give the user a pacnew with irrelevant things until he knows he can ignore it and THEN we break his system, how nice is that? A short and simple message explaining what about this .pacnew is rather important might be in order. It could be as short as Please read http://www.archlinux.org/news/1234 before you reboot. Or a bit more pragmatic, like Your system is cannot reboot now. Please thank the Arch developers. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
Le Sat, 18 Jul 2009 23:29:28 -0500, Aaron Griffin aaronmgrif...@gmail.com a écrit : And to be clear, I definitely do not like the pandering to users thing... if people whining about stupid shit gets on your nerves, stop visiting the forums and IRC. It worked for me! ( google 'eternal september' for kicks :). Pyther, I like your sentiment. Same here. I'm just a user but I like to think that Arch is a distribution that gives control to power users, and that teaches other users how things work. That teaching might require breaking the system of those that don't follow simple rules such as read the output of Pacman. Moreover, I have modified /etc/inittab, and depending on what the sed does, it might break my system. I don't think I'm the only user to have done that. So, even if you go the sed way, you will need to use post_upgrade() to warn the users that you changed something, and probably create a .pacsave... But in fact, if your goal is to make the systems of people who don't know what /etc/inittab is work, why use sed and not just replace the file with a new one using tty? Anyway, I second pyther, phrakture and all those who are against automatic changes to critical configuration files. And I think every post or bug report complaining about that should be closed with a link to the news post about the move from vc to tty. -- catwell
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
Pierre Chapuis schrieb: That teaching might require breaking the system of those that don't follow simple rules such as read the output of Pacman. How can a user distinguish between important pacman output and the crap that is put everywherre? Moreover, I have modified /etc/inittab, and depending on what the sed does, it might break my system. I don't think I'm the only user to have done that. So, even if you go the sed way, you will need to use post_upgrade() to warn the users that you changed something, and probably create a .pacsave... But in fact, if your goal is to make the systems of people who don't know what /etc/inittab is work, why use sed and not just replace the file with a new one using tty? There was the time when pacman saved the old file as .pacsave and put the new one in place, effectively restoring the default configuration and leaving it to the user to merge in his custom configuration. I am beginning to understand why someone would do it this way. Nowadays, as soon as you modify the file, the new files are installed as .pacnew which makes sense most of the time. But in this case ... let's admit it, most users don't really care about inittab. Some HOWTO told them to uncomment a line for their login manager and they forgot about it. If you really want to educate users, remove all those HOWTOs that people follow step-by-step without understanding a word and let them figure it out themselves. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
i don't get the point of this discussion! isn't it the devs choice to do it how _he_ thinks it's good and reasonable? if thomas thinks putting a sed line in the .install is the best way, then he should do it! On Sun, Jul 19, 2009 at 12:57:30PM +0200, Thomas Bächler wrote: Pierre Chapuis schrieb: That teaching might require breaking the system of those that don't follow simple rules such as read the output of Pacman. How can a user distinguish between important pacman output and the crap that is put everywherre? Moreover, I have modified /etc/inittab, and depending on what the sed does, it might break my system. I don't think I'm the only user to have done that. So, even if you go the sed way, you will need to use post_upgrade() to warn the users that you changed something, and probably create a .pacsave... But in fact, if your goal is to make the systems of people who don't know what /etc/inittab is work, why use sed and not just replace the file with a new one using tty? There was the time when pacman saved the old file as .pacsave and put the new one in place, effectively restoring the default configuration and leaving it to the user to merge in his custom configuration. I am beginning to understand why someone would do it this way. yes, creating a pacsave file is an elegant solution. vlad --
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
On Sun, Jul 19, 2009 at 13:16, Thomas Bächlertho...@archlinux.org wrote: Aaron Griffin schrieb: However, I must point out: odds are most people don't touch inittab, so the upgrade will do things as expected and the sed line will only do work a small subset of end users. You are wrong here. I would guess virtually any user touched it. That's questionable. It depends if users configured their X login manager in inittab or just added gdm/kdm/slim/whatever to DAEMONS in rc.conf (as I did). I doubt there is any statistics on it, so it's hard to correctly assume anything. Anyway these are valid points: That said, we do modify configuration files all the time. We run grpck on a shadow update so users can still log in, some gtk update generate files in /etc so it still finds its plugins and more. We just don't do it ourselves, but hide behind some program provided to us and tell ourselves It's okay, upstream wanted it this way. And guess what, nobody even notices. The whole discussion is getting on a way to flamewar IMO. I'm fine with just newsitem in advance and a post_upgrade message, but Thomas' idea about doing sed and saving user's config as .pacsave and posting a message about what was done is reasonable as well: * users who weren't careful will have a working system after reboot, * users who are careful will see the .pacsave and will check\ if sed didn't break their config. -- Roman Kyrylych (Роман Кирилич)
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
On Sun, 2009-07-19 at 12:01 +1000, Allan McRae wrote:
First off, I don't like modifying config files. But, given I did this
update and still managed to screw my system up when testing it with a
reboot...
So it is a question of which I hate more; post install messages or
automatically fixing the file.
A post install message means that I tell all complaining users that they
should have read their pacman output. But hang on, they are already
told that there is a .pacnew file for what is a very important config
file. So I can say that anyway. So here is my prototype install file...
post_install()
{
if [ -f /etc/inittab.pacnew ]; then
echo You are being very stupid if you did not take notice of that
warning about a .pacnew file
fi
}
A simple sed of the config file means much, much less complaining
users. And given the number of complaints I got about libjpeg7 (wheres
the thanks now gtk and kde are working?), I am very, very tempted just
to do the sed.
Allan
Not that my option means squat but
I agree. Since this update/upgrade will break everyone/most peoples
systems I think a relaxing of the rule for this one is justified
.
Rules are meant to be broken, that's why there are rules :)
You do want to be a distro without rules don't you?
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
On Sun, 2009-07-19 at 12:20 +1000, Allan McRae wrote:
Daenyth Blank wrote:
On Sat, Jul 18, 2009 at 22:01, Allan McRaeal...@archlinux.org wrote:
post_install()
{
if [ -f /etc/inittab.pacnew ]; then
echo You are being very stupid if you did not take notice of that
warning
about a .pacnew file
fi
}
+1 to this solution from me.
I guess you missed my sarcasm. It is difficult to convey across email.
I see absolutely no point in repeating warnings. If they did not read
the first, why would they read the second?
Allan
Because their machine is broke?
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
On Sat, 2009-07-18 at 22:34 -0400, Loui Chang wrote:
On Sun 19 Jul 2009 12:01 +1000, Allan McRae wrote:
First off, I don't like modifying config files. But, given I did
this update and still managed to screw my system up when testing it
with a reboot...
So it is a question of which I hate more; post install messages or
automatically fixing the file.
A post install message means that I tell all complaining users that
they should have read their pacman output. But hang on, they are
already told that there is a .pacnew file for what is a very
important config file. So I can say that anyway. So here is my
prototype install file...
post_install()
{
if [ -f /etc/inittab.pacnew ]; then
echo You are being very stupid if you did not take notice of that
warning about a .pacnew file
fi
}
A simple sed of the config file means much, much less complaining
users. And given the number of complaints I got about libjpeg7
(wheres the thanks now gtk and kde are working?), I am very, very
tempted just to do the sed.
If you expect the users to be stupid they will be stupid, and you will
hold their hand, and they will begin to expect you to hold their hand,
and then we're in trouble. We will snowball right into Archbuntu.
So. Do what's right. Give users a warning, give them time to adjust.
If people start complaining, give them the straight line, plug your ears
and sing 'Lalalala I warned you.' Don't stress yourself.
You're not even being paid after all.
Are you saying to users.
Don't use Arch we don't care or Piss off we do what we want?
[arch-general] Problem with sound under vmware server
Hi I've been running arch as a virtual machine using vmware server for a few months now without problems. However, I upgraded all packages yesterday, and now I know longer have any sound. According to lspci the soundcard is an Ensoniq ES1371, and according to lsmod the snd-ens1371 module is loaded. If I do speaker-test then it seems to work, it plays a static hissing sound, but it repeatedly gives the error Write error: -32, broken pipe If I aplay a wav file, then no sound is played, and I get the error underrun!!! (at least 1829490232.202 ms long) underrun!!! (at least 1829490234.191 ms long) I've tried running alsaconf, and this seems to run successfuly, but sound still doesn't work. Does anyone have any suggestions as to how to fix this? Many thanks Alastair Irving
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
On Sat, 2009-07-18 at 23:03 -0400, Matthew wrote: Allan McRae wrote: First off, I don't like modifying config files. But, given I did this update and still managed to screw my system up when testing it with a reboot... So it is a question of which I hate more; post install messages or automatically fixing the file. A post install message means that I tell all complaining users that they should have read their pacman output. But hang on, they are already told that there is a .pacnew file for what is a very important config file. So I can say that anyway. ... A simple sed of the config file means much, much less complaining users. And given the number of complaints I got about libjpeg7 (wheres the thanks now gtk and kde are working?), I am very, very tempted just to do the sed. Allan Could someone please enlighten me why you and Thomas want to please the users that complain? I simply do not understand. You said yourself that you don't like modifying config files, so don't. To hell with the users that don't like it. There are a lot of people that appreciate all the work that went into to the libjpeg and readline rebuilds.You don't hear from the users that appreciate all of your hard work. All you guys see/hear are the users that complain. Many times we take it for granted that things just works! And we are at fault for not speaking up and saying, Hey thanks for the hard work! I haven't yet heard any users on the Mailing List who are in favor of sedding /etc/inittab. Many of the ML followers probably use testing and reports bugs when ever they encounter anything. Going out on a limb, I would say nearly all users that read the ML want to be involved with arch in one way or the other. I, personally, run testing and I am always amazed at how smoothly things run. I was on IRC earlier today and somebody posted a youtube video on how to install arch linux: http://www.youtube.com/watch?v=BIVcF5t1kZw Now just look at some of the comments on the video. These users are probably on the extreme, but these are some of our users. We also have many users that have just a little bit more knowledge, but they are still left clueless. I'd guess these are the users that complain. Point is users, that complain, probably lack the skills needed to run arch. If you think that automating file modifications is good and in the best interest of the users that you are targeting then go for it. To hell with me and the others. After all, the distro is your work. If that is the path chosen, it is sad to see something so great dissolve away. In that case thank you for the ride and good luck in the future. ~pyther 1st off I am just one of those ignorant users. Yes I do complain but I am only complaining so others don't have the same problem I did. I am only trying to help. If I find a problem in a PKGBUILD or when building a package I file a bug report. I think packages should build with little or no problems. If devs or anyone at Arch thinks it is bogus you can simply close it. If I post something to help with a problem and it is wrong or can be done better, then some one corrects me then everyone has an opportunity to learn, that is how me/us ignorant users learn so have a little patient with us. I don't see anything dissolving away. It is just you have a problem with a update and need to solve it. I am for solving this problem on its own merits and not only by the rules then doing the proper thing. Any way you have been warned, that one of your config files may have been edited.. so respond appropriately. Oh see it works both ways.
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
Baho Utot wrote: On Sat, 2009-07-18 at 22:34 -0400, Loui Chang wrote: If you expect the users to be stupid they will be stupid, and you will hold their hand, and they will begin to expect you to hold their hand, and then we're in trouble. We will snowball right into Archbuntu. So. Do what's right. Give users a warning, give them time to adjust. If people start complaining, give them the straight line, plug your ears and sing 'Lalalala I warned you.' Don't stress yourself. You're not even being paid after all. Are you saying to users. Don't use Arch we don't care or Piss off we do what we want? Exactly. Right on the dot! That was the way it once was and that is what made arch great.
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
FWIW, I subscribe to this list and have read every post in this thread, and my system was killed because I didn't fix the file before a reboot out of my own laziness. It took me all of 2 minutes to fix my system. Could it have been prevented? Yes. Do I really give a shit that I had to fix it? No, because it was my own fault. Had this been one of the remote machines that I administer I would have been more careful when doing the upgrade and this wouldn't have happened. I think of out all the options here, copying the current inittab to .pacsave and installing a new, working inittab makes the most sense. Then a user would at least have a chance to boot and read their logs to see what happened if they even notice there is a problem.
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
On Sun, Jul 19, 2009 at 10:23, Randy Morrisrandy.mor...@archlinux.us wrote: I think of out all the options here, copying the current inittab to .pacsave and installing a new, working inittab makes the most sense. Then a user would at least have a chance to boot and read their logs to see what happened if they even notice there is a problem. This is exactly what Arch *doesn't* do, and it provides .pacnew files for this purpose.
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
On Sun 19 Jul 2009 13:43 -0400, Daenyth Blank wrote: On Sun, Jul 19, 2009 at 10:23, Randy Morrisrandy.mor...@archlinux.us wrote: I think of out all the options here, copying the current inittab to .pacsave and installing a new, working inittab makes the most sense. Then a user would at least have a chance to boot and read their logs to see what happened if they even notice there is a problem. This is exactly what Arch *doesn't* do, and it provides .pacnew files for this purpose. Well, I do think saving the current config as a pacsave is a hell of a lot better than altering it and wondering what the hell happened to your original config. So that's a compromise I'd be willing to accept.
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
On Sun, Jul 19, 2009 at 7:43 PM, Daenyth Blankdaenyth+a...@gmail.com wrote: On Sun, Jul 19, 2009 at 10:23, Randy Morrisrandy.mor...@archlinux.us wrote: I think of out all the options here, copying the current inittab to .pacsave and installing a new, working inittab makes the most sense. Then a user would at least have a chance to boot and read their logs to see what happened if they even notice there is a problem. This is exactly what Arch *doesn't* do, and it provides .pacnew files for this purpose. But in this special case, you could always do : sed -i'.pacsave' 's#vc/\([0-9]\)#tty\1#' /etc/inittab
[arch-general] [signoff] dhclient-3.1.2p1
Please signoff both architectures. The new version fixes CVE-2009-0692 (https://www.isc.org/node/468). I have cleaned up the PKGBUILD and removes our patches. So please test it carefully and report any issue to the bugtracker or the ML. On works here on my PC, but it needs definitely more testing. Daniel
Re: [arch-general] [signoff] dhclient-3.1.2p1
On Sun, 19 Jul 2009 20:21:21 +0200 Daniel Isenmann daniel.isenm...@gmx.de wrote: Please signoff both architectures. The new version fixes CVE-2009-0692 (https://www.isc.org/node/468). I have cleaned up the PKGBUILD and removes our patches. So please test it carefully and report any issue to the bugtracker or the ML. On works here on my PC, but it needs definitely more testing. Daniel I have opened a forum thread for issue discussion: http://bbs.archlinux.org/viewtopic.php?pid=587153 If there are any issues...
Re: [arch-general] [signoff] dhclient-3.1.2p1
Daniel Isenmann schrieb: Please signoff both architectures. The new version fixes CVE-2009-0692 (https://www.isc.org/node/468). I have cleaned up the PKGBUILD and removes our patches. So please test it carefully and report any issue to the bugtracker or the ML. On works here on my PC, but it needs definitely more testing. Daniel Did you remove the patch to dhclient-script? I added a patch in there ages ago to kill all the down on the ifconfig lines. If you reverted that patch, mac80211 wireless cards will fail to work with dhclient, as bringing the interface down on a DHCPNAK will render the wireless connection unusable. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [signoff] dhclient-3.1.2p1
On Sun, 19 Jul 2009 21:08:21 +0200 Thomas Bächler tho...@archlinux.org wrote: Daniel Isenmann schrieb: Please signoff both architectures. The new version fixes CVE-2009-0692 (https://www.isc.org/node/468). I have cleaned up the PKGBUILD and removes our patches. So please test it carefully and report any issue to the bugtracker or the ML. On works here on my PC, but it needs definitely more testing. Daniel Did you remove the patch to dhclient-script? I added a patch in there ages ago to kill all the down on the ifconfig lines. If you reverted that patch, mac80211 wireless cards will fail to work with dhclient, as bringing the interface down on a DHCPNAK will render the wireless connection unusable. Yes I have removed. I have asked before on the dev-public but nobody answered. I will release a new pkgrel with added patch soon. Any other things about the patches I should know?
Re: [arch-general] [signoff] dhclient-3.1.2p1
On Sun, Jul 19, 2009 at 4:06 PM, Daniel Isenmanndaniel.isenm...@gmx.de wrote: On Sun, 19 Jul 2009 21:08:21 +0200 Thomas Bächler tho...@archlinux.org wrote: Daniel Isenmann schrieb: Please signoff both architectures. The new version fixes CVE-2009-0692 (https://www.isc.org/node/468). I have cleaned up the PKGBUILD and removes our patches. So please test it carefully and report any issue to the bugtracker or the ML. On works here on my PC, but it needs definitely more testing. Daniel Did you remove the patch to dhclient-script? I added a patch in there ages ago to kill all the down on the ifconfig lines. If you reverted that patch, mac80211 wireless cards will fail to work with dhclient, as bringing the interface down on a DHCPNAK will render the wireless connection unusable. Yes I have removed. I have asked before on the dev-public but nobody answered. I will release a new pkgrel with added patch soon. Any other things about the patches I should know? It conflicts with dhcp: error: could not prepare transaction error: failed to commit transaction (conflicting files) dhclient: /usr/include/isc-dhcp/boolean.h exists in filesystem dhclient: /usr/include/isc-dhcp/dst.h exists in filesystem dhclient: /usr/include/isc-dhcp/int.h exists in filesystem dhclient: /usr/include/isc-dhcp/lang.h exists in filesystem dhclient: /usr/include/isc-dhcp/list.h exists in filesystem dhclient: /usr/include/isc-dhcp/result.h exists in filesystem dhclient: /usr/include/isc-dhcp/types.h exists in filesystem dhclient: /usr/include/omapip/alloc.h exists in filesystem dhclient: /usr/include/omapip/buffer.h exists in filesystem dhclient: /usr/include/omapip/omapip.h exists in filesystem dhclient: /usr/lib/libomapi.a exists in filesystem Errors occurred, no packages were upgraded.
Re: [arch-general] [signoff] dhclient-3.1.2p1
Daniel Isenmann schrieb: Yes I have removed. I have asked before on the dev-public but nobody answered. I will release a new pkgrel with added patch soon. Any other things about the patches I should know? I must have missed that. Isn't the 3.X version out of date anyway? Hasn't there been a dhcp 4 release for years? signature.asc Description: OpenPGP digital signature
Re: [arch-general] [signoff] dhclient-3.1.2p1
On Sun, 19 Jul 2009 16:27:20 -0400 Eric Bélanger snowmanisc...@gmail.com wrote: On Sun, Jul 19, 2009 at 4:06 PM, Daniel Isenmanndaniel.isenm...@gmx.de wrote: On Sun, 19 Jul 2009 21:08:21 +0200 Thomas Bächler tho...@archlinux.org wrote: Daniel Isenmann schrieb: Please signoff both architectures. The new version fixes CVE-2009-0692 (https://www.isc.org/node/468). I have cleaned up the PKGBUILD and removes our patches. So please test it carefully and report any issue to the bugtracker or the ML. On works here on my PC, but it needs definitely more testing. Daniel Did you remove the patch to dhclient-script? I added a patch in there ages ago to kill all the down on the ifconfig lines. If you reverted that patch, mac80211 wireless cards will fail to work with dhclient, as bringing the interface down on a DHCPNAK will render the wireless connection unusable. Yes I have removed. I have asked before on the dev-public but nobody answered. I will release a new pkgrel with added patch soon. Any other things about the patches I should know? It conflicts with dhcp: error: could not prepare transaction error: failed to commit transaction (conflicting files) dhclient: /usr/include/isc-dhcp/boolean.h exists in filesystem dhclient: /usr/include/isc-dhcp/dst.h exists in filesystem dhclient: /usr/include/isc-dhcp/int.h exists in filesystem dhclient: /usr/include/isc-dhcp/lang.h exists in filesystem dhclient: /usr/include/isc-dhcp/list.h exists in filesystem dhclient: /usr/include/isc-dhcp/result.h exists in filesystem dhclient: /usr/include/isc-dhcp/types.h exists in filesystem dhclient: /usr/include/omapip/alloc.h exists in filesystem dhclient: /usr/include/omapip/buffer.h exists in filesystem dhclient: /usr/include/omapip/omapip.h exists in filesystem dhclient: /usr/lib/libomapi.a exists in filesystem Errors occurred, no packages were upgraded. I will remove those headers from the dhclient package. Thanks for reporting.
Re: [arch-general] [signoff] dhclient-3.1.2p1
On Sun, 19 Jul 2009 22:38:00 +0200 Thomas Bächler tho...@archlinux.org wrote: Daniel Isenmann schrieb: Yes I have removed. I have asked before on the dev-public but nobody answered. I will release a new pkgrel with added patch soon. Any other things about the patches I should know? I must have missed that. Isn't the 3.X version out of date anyway? Hasn't there been a dhcp 4 release for years? Yes, there is a dhcp 4 release, but it doesn't work here. The 3.1.2p1 release is also marked as a productive stable release, so it's ok to use this release for fixing the security issue. I will have a look at the dhcp 4 release later.
Re: [arch-general] [signoff] dhclient-3.1.2p1
Daniel Isenmann schrieb: Yes I have removed. I have asked before on the dev-public but nobody answered. I will release a new pkgrel with added patch soon. Any other things about the patches I should know? I must have missed that. Isn't the 3.X version out of date anyway? Hasn't there been a dhcp 4 release for years? Yes, there is a dhcp 4 release, but it doesn't work here. The 3.1.2p1 release is also marked as a productive stable release, so it's ok to use this release for fixing the security issue. I will have a look at the dhcp 4 release later. Great. Tell me when you get the package with the fixed dhclient-script up, as I'd like to use a secure dhclient with autowifi (but as I mentioned, the fact that it brings the interface down on very weird occasions breaks mac80211). signature.asc Description: OpenPGP digital signature
Re: [arch-general] reconfiguring vi to work like it did before the last update?
On Saturday 18 July 2009 12:54:06 am David C. Rankin wrote: On Saturday 18 July 2009 12:38:29 am David C. Rankin wrote: On Monday 13 July 2009 03:49:49 am solsTiCe d'Hiver wrote: i think you're using [testing] and then use vi-1.79 which is nvi. and not the vi you know which was a stripped down version of vim snip I'll go load vim and report back. Thanks! WHEW!! All back to normal: For anyone else caught with the same problem. I wrote a small script that reinstalls vim and moves vi to vi.vni. The script is nothing more that what you would simply do by hand, it just collects all the commands in one place. The script is attached to prevent unwanted line breaks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] reconfiguring vi to work like it did before the last update?
2009/7/19, David C. Rankin drankina...@suddenlinkmail.com: For anyone else caught with the same problem. I wrote a small script that reinstalls vim and moves vi to vi.vni. The script is nothing more that what you would simply do by hand, it just collects all the commands in one place. The script is attached to prevent unwanted line breaks. Your script is not attached. Please, link it to an external website. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Re: [arch-general] What to do about the blender package?
On Sun, Jul 19, 2009 at 11:28:51PM +0200, Sven-Hendrik Haase wrote: On 19.07.2009 12:42, Alessandro Doro wrote: On Sun, Jul 19, 2009 at 12:29:20PM +0300, Roman Kyrylych wrote: 2009/7/19 Lukáš Jirkovský l.jirkov...@gmail.com: IMO the problem is that you (devs) use make to build blender which is several years deprecated and probably no-one builds blender this way. Maybe they've dropped support for it completely. I suggest using SCons. Maybe you can reuse my blender-svn PKGBUILD from AUR, only thing that has to be changed for this purpose is the part where data is downloaded from SVN server. There is one problem which I'm aware of with this package – it installs blender executable in /usr/share/blender and adds wrapper to /usr/bin. I'll probably move blender to /opt in near future. There is also a request about building to SCons: http://bugs.archlinux.org/task/14893 and there is a PKGBUILD too (for stable, not svn version). That PKGBUILD needs a cleanup; depends and makedepends are wrong. I'll soon post an updated version. FYI I had success with the NaN method. The key is (http://bugs.archlinux.org/task/14766#comment46628): export NAN_DEBUG=-O Today I'll work for a PKGBUILD. I fixed both packages and uploaded them. Take whichever you want. http://doubleskill.de/svens_stuff/blender-pkgs.tar.gz So you're providing a (scons) PKGBUILD for x86_64 with '-march=i686' and '-mtune=generic' compile flags? Note that all you need (no sedding) for the NaN method is, not reviewed: export NAN_NO_PLUGIN=true export NAN_PYTHON_VERSION=2.6 export INTERNATIONAL=true export WITH_BF_OPENMP=true export NAN_USE_FFMPEG_CONFIG=true export NAN_ODE=/usr export WITH_VERSE=true export NAN_DEBUG=-O and a patch (assuming we DO want sound): - NAN_SND_LIBS += $(NAN_OPENAL)/lib/libopenal.a + NAN_SND_LIBS += -lopenal in source/Makefile
Re: [arch-general] What to do about the blender package?
On 20.07.2009 03:46, Alessandro Doro wrote: On Sun, Jul 19, 2009 at 11:28:51PM +0200, Sven-Hendrik Haase wrote: On 19.07.2009 12:42, Alessandro Doro wrote: On Sun, Jul 19, 2009 at 12:29:20PM +0300, Roman Kyrylych wrote: 2009/7/19 Lukáš Jirkovský l.jirkov...@gmail.com: IMO the problem is that you (devs) use make to build blender which is several years deprecated and probably no-one builds blender this way. Maybe they've dropped support for it completely. I suggest using SCons. Maybe you can reuse my blender-svn PKGBUILD from AUR, only thing that has to be changed for this purpose is the part where data is downloaded from SVN server. There is one problem which I'm aware of with this package – it installs blender executable in /usr/share/blender and adds wrapper to /usr/bin. I'll probably move blender to /opt in near future. There is also a request about building to SCons: http://bugs.archlinux.org/task/14893 and there is a PKGBUILD too (for stable, not svn version). That PKGBUILD needs a cleanup; depends and makedepends are wrong. I'll soon post an updated version. FYI I had success with the NaN method. The key is (http://bugs.archlinux.org/task/14766#comment46628): export NAN_DEBUG=-O Today I'll work for a PKGBUILD. I fixed both packages and uploaded them. Take whichever you want. http://doubleskill.de/svens_stuff/blender-pkgs.tar.gz So you're providing a (scons) PKGBUILD for x86_64 with '-march=i686' and '-mtune=generic' compile flags? Note that all you need (no sedding) for the NaN method is, not reviewed: export NAN_NO_PLUGIN=true export NAN_PYTHON_VERSION=2.6 export INTERNATIONAL=true export WITH_BF_OPENMP=true export NAN_USE_FFMPEG_CONFIG=true export NAN_ODE=/usr export WITH_VERSE=true export NAN_DEBUG=-O and a patch (assuming we DO want sound): - NAN_SND_LIBS += $(NAN_OPENAL)/lib/libopenal.a + NAN_SND_LIBS += -lopenal in source/Makefile Whoops, sorry. Didn't see that as I hoped that scons would do some magic for me. Oh well, mind adding a little sed magic into the PKGBUILD to make up for it? Apart from that, building using scons seems to work quite well AND IT HAS COLORS. Honestly though, I don't mind whatever PKGBUILD and build system you are going to choose as long as I won't miss out on any features in Blender :). Since the current Blender version in [extra] is a couple of months old, it should be a priority to update that package as soon as possible.
[arch-general] Firefox on Arch - crash on exit
Hello listmates,
I'm hoping someone can shed some light on what's going on with Firefox.
While running arch (not ubuntu 9.04/fedora 11 which I also have
installed on the same laptop), I run into the following scenario nearly
every time I attempt to launch Firefox.
Firefox is already running, but is not responding. To open a new
window, you must first close the existing Firefox process, or restart
your system.
Sure enough, I'm not being lied to:
$ ps -ef | grep firefox
tgelter 10871 4318 2 22:30 ?00:00:02 /usr/bin/firefox
$ killall firefox firefox
and I'm in business.
The thing is, it doesn't matter how I shut down Firefox (click the X,
file-quit, ctrl+w closing each tab until the last takes down Firefox),
I always end up in the same situation. I went to #archlinux on freenode
to talk about the issue a while back (this issue has been plaguing me
for weeks) and was told to try disabling extensions/themes, creating a
new profile and using that, pacman -Rsn firefox pacman -Sy
firefoxing, I even got so fed up that I did a fresh install on a new
partition and tried again. Nothing has worked, at all. Following is my
info, I really doubt I'm the first person to run into this so please,
can anyone help?
arch x86_64 on a Lenovo T61 laptop (nvidia video card w/ proprietary driver)
x86_64 version of Firefox, x86_64 versions of jre/flash installed (this
is a must)
I run a kde 4.2.4 desktop installed from kdemod.
$ pacman -Sl | awk '{print $1}' | sort | uniq -c
1900 community
175 core
1983 extra
390 kdemod-core
82 kdemod-extragear
62 kdemod-playground
As you can see above, I don't have any testing/unstable packages
installed though there are some from extra kdemod-playground.
If you need any other info, let me know. Remember this problem only
happens under arch, I have the same usage patterns and package
selections under Fedora/Ubuntu as far as I know.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Firefox on Arch - crash on exit
hmm, i could only trigger it once and when i attached to the process with strace i saw it hung on EAGAIN i quit the browser while watching a youtube video which sort of aligns with the EAGAIN error
