[arch-general] dynex USB microphone extremely quiet
The topic says it all. I've got a new microphone, and whereas it works, it's rather quiet when I try to record it wtih audacity. Most people on skype complain that my voice is rather quiet as well, and I have to basically put the mic in my mouth for them to hear to hear me properly. Nothing's showed up on dmesg since I've plugged it in, strangely, but it shows up as a selection in audacity and skype (AK5370 :USB Audio (hw:1,0)). I've got mic boost, capture volume, capture 1, and digital turned all the way up, and those seem to be the only relevant options in alsamixer. I'm a bit confused, any input? -- Samuel Baldwin - logik.li
Re: [arch-general] [arch-dev-public] [signoff] pciutils-3.1.6-1
Am Samstag 30 Januar 2010 schrieb Allan McRae: On 27/01/10 16:18, Tobias Powalowski wrote: Hi bump to latest version. Please signoff both arches. Signoff i686. Allan anyone for x86_64? -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-dev-public] [signoff] xfsprogs-3.1.1
Hi bump to latest version, xfsprogs-3.1.1 (29 January 2010) - Fix various blkid topology support problems in mkfs.xfs. - Fix various build warnings. - Add automatic build dependency calculations. - Cleaner build system output. - Add missing aclocal m4 file to the package generation. - Arrange for release tags to be digitally signed. please signoff both arches, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Baho Utot baho-u...@columbus.rr.com wrote: I have preformed some tests and guess what cdrkit works! Imagine that. It burnt the iso's for Slackware distribution, and using md5sum to sum both a Slackware distribution disk burned by both cdrkit and cdrtools and they are the same, how did that happen? There is a 99,999% chance that you did never used cdrtools. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
[arch-general] Firefox 3.5.7 not support eh !??
Something is seriously funny going on here with FF 3.5.7 (Shiretoko). I'm using it from the arch repos, but on visiting Google Help or Orkut, it says Browser not supported ? And the supported browser list says FF 1.5+ Something is wrong with the arch build ? -- Nilesh Govindarajan Site Server Adminstrator www.itech7.com
Re: [arch-general] Firefox 3.5.7 not support eh !??
On Sun, 2010-01-31 at 16:58 +0530, Nilesh Govindarajan wrote: Something is seriously funny going on here with FF 3.5.7 (Shiretoko). I'm using it from the arch repos, but on visiting Google Help or Orkut, it says Browser not supported ? And the supported browser list says FF 1.5+ Something is wrong with the arch build ? There's nothing wrong with our firefox package, it's buggy browser detection done by these websites. You might want to change the user agent string through about:config to get Firefox in the name. Websites with browser detection like this are plain stupid, you should complain about it and advise them to check for a gecko engine version.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
virus_found vir.fo...@gmail.com wrote: Now you know about several of those cases, for I wasn't able to burn my CD on a modern device (Lenovo SL500's DVD device) with cdrtools (alpha67, IIRC), but I was able to do it with cdrkit without an issue. There is a 99.9% chance that you are not telling the truth. If you really had a problem, you could describe it and send a log. People who have problems have a name and send bug reports. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] Netcfg after resume from suspend
On Sun, Jan 31, 2010 at 11:37:54AM +1100, James Rayner wrote: On Sun, 31 Jan 2010 00:34 +0100, f...@kokkinizita.net wrote: On Fri, Jan 29, 2010 at 05:00:04PM +0100, Thomas Bächler wrote: You should try the testing version of netcfg instead: http://mirrors.kernel.org/archlinux/testing/os/any/netcfg-2.5.0rc2-1-any.pkg.tar.gz Will this allow to specify additional routes (apart from GATEWAY) as well ? It's one thing I need e.g. at home where the gateway to the world is the ISP modem (192.168.1.1), but one of the machines on that net is also a router to second local network. Yes. That's already available in the current [core] release too. Have a look at /etc/network.d/examples/ethernet-iproute. You can pass an array of iproute options. The example there only sets a static ip and default route, but you can pass as many routes as you like. Yes, but I'm using netcfg for the wireless connection of the laptop, and AFAICS the IPCFG command used in ethernet-iproute does not work when using the 'wireless' profile. I may be wrong but have not been able to add any routing to a wireless config. The examples seem to assume that wireless implies 1. dhcp, and 2. just a default gw and not other routes. For (1) it is just the examples lacking. But (2) seems to be a hard-wired limitation. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Joerg Schilling wrote: Baho Utot baho-u...@columbus.rr.com wrote: I have preformed some tests and guess what cdrkit works! Imagine that. It burnt the iso's for Slackware distribution, and using md5sum to sum both a Slackware distribution disk burned by both cdrkit and cdrtools and they are the same, how did that happen? There is a 99,999% chance that you did never used cdrtools. Jörg Please show me the evidence to support your position. Please what evidence do you have that I have never used cdrtools? As a user of Linux since 1995 your assertions are ridicules. Just being a user from 1995 proves your claim to be false. Yes that is before cdrkit was ever released. I have been a early beta tester for Turbolinux, would you like a copy of my beta/prerelease TurboLinux CDs from that period? I also have RedHat Linux official versions from 5.0 to 9.0 and non official release 4.2 which I ran oracle on, the oracle db required Red Hat 4.2 at that time, again you look it up. Please do this, download Slackware 12 or 13 _LOOK_ at what it being distributed. You _WILL_ find that it is cdrtools. One _HAS_ to remove it by choice as I did and build and install cdrkit. Would you like my build script for cdrkit? Here is the script I used to test cdrtools and cdrkit #!/bin/sh # $Id: burnt_iso_md5_check.sh,v 1.1 2008/03/22 16:51:22 root Exp root $ # Written 2008 by Eric Hameleers al...@slackware.com # # This command will check the md5sum of a cd (ignoring possible padding at # the end by only checking the same amount of bytes at the iso image) and # also check the md5sum of the ISO image. # Idea found at: # http://www.linuxquestions.org/questions/showthread.php?p=3077366#post3077366 # and expanded a bit. # if [ $1 ]; then isoFile=$1 else echo Usage: $0 iso-image cd-drive echo E.g. $0 /tmp/slackware-12.0.iso /dev/dvd exit 1 fi if [ $2 ]; then cdDrive=$2 else echo Usage: $0 iso-image cd-drive echo E.g. $0 /tmp/slackware-12.0.iso /dev/dvd exit 1 fi if [ ! -b $cdDrive ]; then echo ERROR. '$cdDrive' is not a block device. exit 1 fi if [ ! -r $isoFile ]; then echo ERROR. ISO image '$isoFile' does not exist. exit 1 else echo ** Verifying md5sums between $isoFile - $cdDrive dd if=$cdDrive | head -c $(stat --format=%s $isoFile) | md5sum \ md5sum $isoFile fi You have confirmed my position. You just want to argue your point. You can continue to claim the above, But you now have _ZERO_ credibility with me.
Re: [arch-general] Firefox 3.5.7 not support eh !??
Il 31/01/2010 12:30, Jan de Groot ha scritto: On Sun, 2010-01-31 at 16:58 +0530, Nilesh Govindarajan wrote: Something is seriously funny going on here with FF 3.5.7 (Shiretoko). I'm using it from the arch repos, but on visiting Google Help or Orkut, it says Browser not supported ? And the supported browser list says FF 1.5+ Something is wrong with the arch build ? There's nothing wrong with our firefox package, it's buggy browser detection done by these websites. You might want to change the user agent string through about:config to get Firefox in the name. Websites with browser detection like this are plain stupid, you should complain about it and advise them to check for a gecko engine version. you can also use an add-ons like this: https://addons.mozilla.org/en-US/firefox/addon/59 -- Il Software Libero è una questione di libertà, non di prezzo.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On Sun, Jan 31, 2010 at 12:39:07PM +0100, joerg.schill...@fokus.fraunhofer.de wrote: virus_found vir.fo...@gmail.com wrote: Now you know about several of those cases, for I wasn't able to burn my CD on a modern device (Lenovo SL500's DVD device) with cdrtools (alpha67, IIRC), but I was able to do it with cdrkit without an issue. There is a 99.9% chance that you are not telling the truth. If you really had a problem, you could describe it and send a log. People who have problems have a name and send bug reports. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily Sometimes I really miss the topic close function on the mailing list. I known already enough, so I'll just ban this thread locally. Jaroslav (Dragonlord) Lichtblau Arch Linux Trusted User -- Der Wurf mag zuweilen nicht treffen, aber die Absicht verfehlt niemals ihr Ziel. -- Jean Jacques Rousseau (Träumereien eines einsamen Spaziergängers) pgpw2GqRAWPrR.pgp Description: PGP signature
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Hi, On the Wiki, Add a small note about cdrtools. proposing it as alternate over cdkit.so let the user decide: http://wiki.archlinux.org/index.php/CD_Burning_Tips Regards, Gaurish Sharma www.gaurishsharma.com
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Damjan Georgievski gdam...@gmail.com wrote: Would it be worth to do so? I am not convinced. The GPL was intentionally opened against any kind of libraries after it turned out that the first GCC version was legally unusable. I was part of this discussion and thus I know about this fact. The project mkisofs just uses independent libraries under CDDL and this is explicitely permitted for GPLd programs. You can always dual-license it... GPL for the stupid people* and CDDL for the smart ones. Dual licensing in general is a bad idea. For a period of time that is intended for a migration it may help in our case. The Apple HFS stuff would be then CDDL only, and distros could disable it. Apple HFS stuff is for Mac OS 9. For current Apple releases, UDF + Apple extensions (implemented in the original mkisofs) is better. For the next final version that is expected very soon (I just need to implement support for writing hidden audio tracks automated from *.inf files and do some BluRay tests) there will definitely support for Apple HFS in mkisofs. For the time that follows cdrtools-3.0-final, things may change. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] Vertical Quicklaunch on the Desktop in KDE4 - It's a Winner
On Sat, Jan 30, 2010 at 7:39 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: Man, your desktop theme is _slick_... What is its name? About the quickstart, I've used it some time, but now i use a taskbar called Fancy Task. It works as a quick launch and task manager. Very usefull. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto ---
[arch-general] Syncing the mirrors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We have a bit update today, and we see: The syncing process is not really good. So I suggest to change the procedure mirrorsyncs are done: We should have primary and secondary mirrors. When al.org is updated, the sync process of the primary mirrors should be started via ssh(or something similar). Then the primary mirrors start the sync process on the secondary mirrors via ssh. So the al.org server isn't overloaded and the mirrors are more up to date because of the push way. - -- Gruß, Benedikt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktlkM4ACgkQEbgIp8utRvBwAwCgiv9qBi/hEP5Xr447gHrauExn f5kAnAs7uzHXPIhz+Q+JnQAkwfJms2/T =6iqt -END PGP SIGNATURE-
Re: [arch-general] Syncing the mirrors
We have a bit update today, and we see: The syncing process is not really good. So I suggest to change the procedure mirrorsyncs are done: We should have primary and secondary mirrors. When al.org is updated, the sync process of the primary mirrors should be started via ssh(or something similar). Then the primary mirrors start the sync process on the secondary mirrors via ssh. So the al.org server isn't overloaded and the mirrors are more up to date because of the push way. Thanks for signing that message, I wasn't sure it was from you. The problem here is we haven't had anyone step up and *finish* a two tier mirror system. The situation has improved a bit, but without a developer actively working on it we aren't going to have it fully implemented. As far as pushing goes, that is a bad idea for a number of reasons, the primary being one compromised root server gains you ssh access to X more servers. -Dan
Re: [arch-general] Syncing the mirrors
On 01/31/2010 04:30 PM, Benedikt Müller wrote: 2010/1/31 Dan McGeedpmc...@gmail.com: As far as pushing goes, that is a bad idea for a number of reasons, the primary being one compromised root server gains you ssh access to X more servers. -Dan I didn't say that it must be root. One user with the only permission to use rsync would be the right for this task. heh. compromised might have a lot more sense. the user can still modify packages and db without any restrictions. -- Ionut
Re: [arch-general] Syncing the mirrors
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/31/2010 03:27 PM, Dan McGee wrote:
As far as pushing goes, that is a bad idea for a number of reasons,
the primary being one compromised root server gains you ssh access to
X more servers.
Can be solved easily by using forced commands:
http://oreilly.com/catalog/sshtdg/chapter/ch08.html#22858
- --
Florian Pritz -- {flo,bluewi...@server-speed.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJLZZSjAAoJEG0WVcFM4cE+5cAP/iKrzKsc30sqGOJDqZdJdrCY
xXH0FWP4BqakEdROYiQ9nlAynhQwdovVqtQ70dKnMdV3bxamgWugAraQuFY3bwGU
xPDNdGoRxviOL7csSUkTA1oEzDdgj0fxCOxLbIAdRMDXSwEzc+LM2n1/uYiC9tWx
KPUfAn5xqNL9egzsl8FDIFxswA3JhZe8i1qVL8pbZphgoV0bhzjVLuB24AGm/10n
tBTI0QBoIFFjwfPF8o4X57sK34qVm2laAXmrkSksDF6D7u5XJxD6JJsZsotJBQ/d
RehniBEC0v3QrRgQnkrVwKv4aK/34rbqnJ/eBJW6/uPc9aaL+6zYb38LDVm3Dj8U
Gfowh/sUoIyua/hkbE8d0Hc2R9ArY0RYXKxQSOYUu9qPLiC4h1hTuHlNaXXakCmb
v8jZumno3I/mSm2br4PBNQGWd42DK/B+HcduycvIImSeY1EVigbskNrTfGlmaSJt
qapDzFEOTxHhbchJv58szAook1mWxZe+zimmh7Kpmp0qw5ebg6dS6T2nzJ+kPRo7
OyoH7lK2xZnc7dfLVHjLFSffhcl1wxjHjdhkz4Lz8ZrbC0rP7vb6a95M1XPsYsrq
dG/fJ0CTtFHlgbGCoP6xziMarVmWdt0HiPFoPfgtol5ZaN6AnqsEjaJhi32OoAG2
Sh62vOa0R5Th+i/Cb4VQ
=SP5k
-END PGP SIGNATURE-
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Baho Utot baho-u...@columbus.rr.com wrote: Joerg Schilling wrote: Baho Utot baho-u...@columbus.rr.com wrote: I have preformed some tests and guess what cdrkit works! Imagine that. It burnt the iso's for Slackware distribution, and using md5sum to sum both a Slackware distribution disk burned by both cdrkit and cdrtools and they are the same, how did that happen? There is a 99,999% chance that you did never used cdrtools. Jörg Please show me the evidence to support your position. mkisofs writes a record with it's current version number, so if you use cdrtools, the content _definitely_ differs. It is unfortunately people like you who do never prove any of their claims and who claim things with an extremely low probability that create the impression of groundless attacks and zero credibility. You may try to trick out other people, here you will not have success. As people with some basic skills know, just writing an _image_ with cdrecord and wodim and then then comparing results does not prove the absense of problems in wodim or cdrkit. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] Syncing the mirrors
Am Sonntag, 31. Januar 2010 15:27:03 schrieb Dan McGee: Thanks for signing that message, I wasn't sure it was from you. OT: Can't we strip gpg-signatures from the mailinglist? It's of no use. Use s/mime instead ;-) The problem here is we haven't had anyone step up and finish a two tier mirror system. The situation has improved a bit, but without a developer actively working on it we aren't going to have it fully implemented. There are several methods to improve the situation: * multi tier mirroring. Roman started to work on this but might need some help here. It's mostly an organizing task * Add support for using both gz and xz compressed packages to db-scripts. This way we could migrate to the way better xz compression and reduce traffic: http://bugs.archlinux.org/task/17280 * Implement a common package pool and link to those packages from every repo. This would have reduce the amount of transfered data from several GB to a few KB in the current case. (also an dbscritps issue) dbscripts can be found at http://projects.archlinux.org/dbscripts.git/ Everybody could help implementing this and submit patches for us to review. Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
[arch-general] Arch Linux and security - it needs some work
I really like Arch. I switched about a year ago after being a Debian user for nine years. There is something that troubles me though about Arch. Its lack of security focus. By this I mean there is no consistent way that security issues are dealt with. There was a proposal for 'The Arch Linux Security Team' but it seems to have fallen by the wayside[1]. I propose to resurrect this in the spirit of Arch's users becoming contributors. I, hopefully not alone wish to draw up a list of processes that can be used to create a dedicated Arch Linux security team that can deal quickly and efficiently with security alerts. It would need to be able to liaise successfully with Arch developers and hopefully over time security team members can become trusted users. I'm mentioning it now as I notice that an Arch Conference is being organised in Canada. One of my proposals (shamefully stolen from Debian) would be to have key-signing parties at Arch Linux meet-ups. This could then be used to create an Arch Linux web of trust. So basically I'm going to get my ideas into writing and post them on this list. I hope others will be willing to come forward and contribute too. After some discussion we should be able to reach a consensus and start giving security issues the priority they deserve. regards, Ananda Samaddar [1] http://wiki.archlinux.org/index.php/Security_Task_Force signature.asc Description: PGP signature
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Gaurish Sharma cont...@gaurishsharma.com wrote: Hi, On the Wiki, Add a small note about cdrtools. proposing it as alternate over cdkit.so let the user decide: http://wiki.archlinux.org/index.php/CD_Burning_Tips This is of course better than doing nothing. Please note however that this discussion did not start because I like to include cdrtools into Arch linux but because Arch Linux users are interested to have cdrtools in arch linux by default instead of cdrkit. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] Arch Linux and security - it needs some work
On Sun, Jan 31, 2010 at 10:01, Ananda Samaddar ananda.samad...@vfemail.net wrote: I really like Arch. I switched about a year ago after being a Debian user for nine years. There is something that troubles me though about Arch. Its lack of security focus. Basically this and everything related to it comes down to manpower. Every time it gets brought up, the response is that would be nice and then no one does anything. If you want to make it happen, then work on submitting patches and doing the legwork that needs to be done.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
2010/1/31 Joerg Schilling joerg.schill...@fokus.fraunhofer.de: virus_found vir.fo...@gmail.com wrote: Now you know about several of those cases, for I wasn't able to burn my CD on a modern device (Lenovo SL500's DVD device) with cdrtools (alpha67, IIRC), but I was able to do it with cdrkit without an issue. There is a 99.9% chance that you are not telling the truth. If you really had a problem, you could describe it and send a log. People who have problems have a name and send bug reports. Ok, I didn't want to take part in this joke, but enough is enough. There is a 99.9% chance that you are not telling the truth. If you really had a relevant e-mail from Eben Moglen (or another lawyer, for the matter) that could really solve all of your problems with the cdrtools-vs-cdrkit querelle, you would have found a way to publish it and clear up the doubts. People who have problems have a name (ok, you have one) and send bug (law) reports. This is *your* argument. Do you think it is valuable? Ok, I'll just say I have *two* private e-mails from a very important lawyer that states that there *is* a legal problem with cdrtools. Now, how do you counter-argument *this*? Do you see how it makes no sense at all? You know what's the point? I had a deep respect for you, before I read this thread. Maybe you're the best coder in the world, but it's decades that code doesn't earn you respect. You are talking with *people* here, not pets. And your discussion is in no way technical as you required. «My software has legal issues? No, that's not true, trust me, I can't provide any proof but it's true.» «My software has technical issues? No, that's not true, I can't trust you and you must provide proof.» No, thanks. Corrado Primier
Re: [arch-general] Syncing the mirrors
Hi, There are several methods to improve the situation: * multi tier mirroring. Roman started to work on this but might need some help here. It's mostly an organizing task I strongly second that. Having a geographically organized hierarchy would be nice, so that there are tier-1 mirrors in every country (of course not if there are for example only two mirrors/country those could sync from the geographically closest tier-1 mirror), those being machines with a somewhat reasonable connection, and then have the mirrors sync from those machines and only the tier-1 (mirror.us,mirror.eu,mirror.de and the like) sync from rsync.archlinux.org and all others sync from those. As Pierre pointed out this is mostly an organizational problem as in selecting the tier-1 mirrors and asking the owners if they're going to support this plan. Eg for the tier-1 mirrors we could ask the guys from kernel.org for the main us and eu mirrors, and for eg germany ask the owner of ftp-stud.hs-esslingen.de or maybe Hosteurope. I don't know the situation in countries != de, but IIRC we have a lot of mirrors here. * Add support for using both gz and xz compressed packages to db-scripts. This way we could migrate to the way better xz compression and reduce traffic: http://bugs.archlinux.org/task/17280 I don't know much about the package-system but if theres a 25% decrease in package size this sounds like one would like to have this anway. Just my 2 cents on this topic. regards, Hannes 'hrist' Rist -- Hannes Rist ++ | Crew Selfnet e.V.NOC: ad...@selfnet.de | | Allmandring 8A http://www.selfnet.de | | 70569 Stuttgart Fax: +49 711 620 4796 | ++
Re: [arch-general] Syncing the mirrors
On 31 January 2010 17:05, Hannes Rist hr...@selfnet.de wrote: Hi, There are several methods to improve the situation: * multi tier mirroring. Roman started to work on this but might need some help here. It's mostly an organizing task I strongly second that. Having a geographically organized hierarchy would be nice, so that there are tier-1 mirrors in every country (of course not if there are for example only two mirrors/country those could sync from the geographically closest tier-1 mirror), those being machines with a somewhat reasonable connection, and then have the mirrors sync from those machines and only the tier-1 (mirror.us,mirror.eu,mirror.de and the like) sync from rsync.archlinux.org and all others sync from those. As Pierre pointed out this is mostly an organizational problem as in selecting the tier-1 mirrors and asking the owners if they're going to support this plan. Eg for the tier-1 mirrors we could ask the guys from kernel.org for the main us and eu mirrors, and for eg germany ask the owner of ftp-stud.hs-esslingen.de or maybe Hosteurope. I don't know the situation in countries != de, but IIRC we have a lot of mirrors here. * Add support for using both gz and xz compressed packages to db-scripts. This way we could migrate to the way better xz compression and reduce traffic: http://bugs.archlinux.org/task/17280 I don't know much about the package-system but if theres a 25% decrease in package size this sounds like one would like to have this anway. Just my 2 cents on this topic. regards, Hannes 'hrist' Rist -- Hannes Rist ++ | Crew Selfnet e.V. NOC: ad...@selfnet.de | | Allmandring 8A http://www.selfnet.de | | 70569 Stuttgart Fax: +49 711 620 4796 | ++ Hi all, I think that the syncing would be much less painful if there was some possibility to tell mirrors that package foo has been moved from [testing] to [extra]. Then these rebuilds would be only a matter of distributing information which packages should be moved from [testing] (that could be done by one text file). Lukas
Re: [arch-general] Syncing the mirrors
Am Sonntag, 31. Januar 2010 17:14:05 schrieb Lukáš Jirkovský: I think that the syncing would be much less painful if there was some possibility to tell mirrors that package foo has been moved from [testing] to [extra]. Then these rebuilds would be only a matter of distributing information which packages should be moved from [testing] (that could be done by one text file). See my third suggestion. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-general] Arch Linux and security - it needs some work
Hm, would be nice. :-) I ve been digging into SELinux and Arch lately, and yes some more official support would be nice. If there is something being organized, I'd gladly help, at least in this SELinux area. Regards, Ondrej Vadinsky -- Don`t it always seem to go That you don`t know what you`ve got Till it`s gone. (Joni Mitchell)
Re: [arch-general] Syncing the mirrors
On 31 January 2010 17:15, Pierre Schmitz pie...@archlinux.de wrote: Am Sonntag, 31. Januar 2010 17:14:05 schrieb Lukáš Jirkovský: I think that the syncing would be much less painful if there was some possibility to tell mirrors that package foo has been moved from [testing] to [extra]. Then these rebuilds would be only a matter of distributing information which packages should be moved from [testing] (that could be done by one text file). See my third suggestion. -- Pierre Schmitz, https://users.archlinux.de/~pierre I didn't understand what you meant first time. I think I got it now. If I understand it well you mean having all packages in one directory on server and the repos would be differentiated by some text files or symlinks. The difference is really small (have all packages in one place and link them vs. have current repository layout and move files between directories on server).
[arch-general] kernel-lts ....
I am new to the list, used Linux since Caldera 2.2. I noticed references to a kernel-lts, labelled as 'long-time-support' on the Arch website. I did a bit of googling noticed references to such from Arch Ubuntu forums. I found no references at kernel.org, although I noticed that they listed an upgrade to kernel 2.6.27.45, same number as the '-lts' kernel in Arch. Is the 'lts' kernel project Arch/Ubuntu-specific, or (semi-?) supported from kernel.org ? Also, I noticed that the bleeding edge kernels (seem to) include firmware packages, but I didn't see them for the lts kernels, did I just miss them or are they absent from the 'lts' series of kernels ? TIA -- William A. Mahaffey III -- The M1 Garand is without doubt the finest implement of war ever devised by man. -- Gen. George S. Patton Jr.
Re: [arch-general] Syncing the mirrors
On Sun, 31 Jan 2010 17:24:22 +0100 Lukáš Jirkovský l.jirkov...@gmail.com wrote: I didn't understand what you meant first time. I think I got it now. If I understand it well you mean having all packages in one directory on server and the repos would be differentiated by some text files or symlinks. The difference is really small (have all packages in one place and link them vs. have current repository layout and move files between directories on server). the difference is big, because rsync (used by mirrors to sync with us) doesn't/cannot know a file has moved. it deletes the old file and downloads it again under the new name/path Dieter
Re: [arch-general] Syncing the mirrors
On Sun, 31 Jan 2010 17:36:50 +0100 Lukáš Jirkovský l.jirkov...@gmail.com wrote: No, what I meant was that difference between having package pool to which packages are linked and sending some text file to all servers saying Hi, please move package foo-1.2.3-1-i686.pkg.tar.gz from [testing] to [core] which would result in something * like mv testing/foo-1.2.3-1-i686.pkg.tar.gz core/. Both would send only a list of files which should be moved. that would require custom scripting. it's much more convenient to use symlinks. rsync supports symlinks, no need to reinvent the wheel. Dieter
Re: [arch-general] dynex USB microphone extremely quiet
On Sun, Jan 31, 2010 at 3:32 AM, Samuel Baldwin recursive.for...@gmail.com wrote: The topic says it all. I've got a new microphone, and whereas it works, it's rather quiet when I try to record it wtih audacity. Most people on skype complain that my voice is rather quiet as well, and I have to basically put the mic in my mouth for them to hear to hear me properly. Nothing's showed up on dmesg since I've plugged it in, strangely, but it shows up as a selection in audacity and skype (AK5370 :USB Audio (hw:1,0)). I've got mic boost, capture volume, capture 1, and digital turned all the way up, and those seem to be the only relevant options in alsamixer. I'm a bit confused, any input? -- Samuel Baldwin - logik.li Starting with the obvious. did you select the right device in alsamixer? (use F6)
Re: [arch-general] kernel-lts ....
On Sun, 2010-01-31 at 10:34 -0600, William A. Mahaffey III wrote: I am new to the list, used Linux since Caldera 2.2. I noticed references to a kernel-lts, labelled as 'long-time-support' on the Arch website. I did a bit of googling noticed references to such from Arch Ubuntu forums. I found no references at kernel.org, although I noticed that they listed an upgrade to kernel 2.6.27.45, same number as the '-lts' kernel in Arch. Is the 'lts' kernel project Arch/Ubuntu-specific, or (semi-?) supported from kernel.org ? Also, I noticed that the bleeding edge kernels (seem to) include firmware packages, but I didn't see them for the lts kernels, did I just miss them or are they absent from the 'lts' series of kernels ? TIA The -lts kernels are stable kernels as maintained by kernel.org people. The 2.6.27 kernel has been maintained as stable kernel for 2-3 years now. When we added the kernel, our intentions were to have a maintained stable kernel that doesn't bring surprises after a security update, something that going from 2.6.31 - 2.6.32 won't offer you. The firmware binaries were included in drivers before, they've been split to standalone files in later versions of the kernel. That's why 2.6.27 doesn't come with a -firmware package.
Re: [arch-general] Firefox 3.5.7 not support eh !??
On Sun, Jan 31, 2010 at 6:42 AM, Giuseppe Turrisi giuseppeturr...@gmail.com wrote: Il 31/01/2010 12:30, Jan de Groot ha scritto: On Sun, 2010-01-31 at 16:58 +0530, Nilesh Govindarajan wrote: Something is seriously funny going on here with FF 3.5.7 (Shiretoko). I'm using it from the arch repos, but on visiting Google Help or Orkut, it says Browser not supported ? And the supported browser list says FF 1.5+ Something is wrong with the arch build ? There's nothing wrong with our firefox package, it's buggy browser detection done by these websites. You might want to change the user agent string through about:config to get Firefox in the name. Websites with browser detection like this are plain stupid, you should complain about it and advise them to check for a gecko engine version. you can also use an add-ons like this: https://addons.mozilla.org/en-US/firefox/addon/59 -- Il Software Libero è una questione di libertà, non di prezzo. or you could go into the Firefox config (URL: about:config) and change the value of general.useragent.extra.firefox to Firefox/3.5.7 -- Alexander Lam
Re: [arch-general] Arch Linux and security - it needs some work
Le Sun, 31 Jan 2010 15:01:15 +, Ananda Samaddar ananda.samad...@vfemail.net a écrit : After some discussion we should be able to reach a consensus and start giving security issues the priority they deserve. Maybe this is the problem: some people (including me) might think that perfect security is not a priority. The people from Debian see it this way: security functionnality simplicity I see it the other way around: simplicity functionnality simplicity Meaning: I prefer something that is simple and insecure. I am OK with more security if it doesn't make Arch tools overly complex. Otherwise, because Arch is a desktop (as opposed to server) distribution, it is just not worth it. -- catwell
Re: [arch-general] dynex USB microphone extremely quiet
2010/1/31 Alexander Lam lambchop...@gmail.com: Starting with the obvious. did you select the right device in alsamixer? (use F6) Nope... did that and moved it from 70% to 100%, it's a lot more manageable now. It's still a tad weak but it's probably just because it's a crappy mic. Excellent, thanks! -- Samuel Baldwin - logik.li
Re: [arch-general] kernel-lts ....
On 01/31/10 10:54, Jan de Groot wrote: On Sun, 2010-01-31 at 10:34 -0600, William A. Mahaffey III wrote: I am new to the list, used Linux since Caldera 2.2. I noticed references to a kernel-lts, labelled as 'long-time-support' on the Arch website. I did a bit of googling noticed references to such from Arch Ubuntu forums. I found no references at kernel.org, although I noticed that they listed an upgrade to kernel 2.6.27.45, same number as the '-lts' kernel in Arch. Is the 'lts' kernel project Arch/Ubuntu-specific, or (semi-?) supported from kernel.org ? Also, I noticed that the bleeding edge kernels (seem to) include firmware packages, but I didn't see them for the lts kernels, did I just miss them or are they absent from the 'lts' series of kernels ? TIA The -lts kernels are stable kernels as maintained by kernel.org people. The 2.6.27 kernel has been maintained as stable kernel for 2-3 years now. When we added the kernel, our intentions were to have a maintained stable kernel that doesn't bring surprises after a security update, something that going from 2.6.31 - 2.6.32 won't offer you. The firmware binaries were included in drivers before, they've been split to standalone files in later versions of the kernel. That's why 2.6.27 doesn't come with a -firmware package. Thanks for the clarifications. Does the Arch installer let me choose the 'lts' kernel during install, or would I install then 'downgrade' to it ? TIA -- William A. Mahaffey III -- The M1 Garand is without doubt the finest implement of war ever devised by man. -- Gen. George S. Patton Jr.
Re: [arch-general] Why taking so long?
On 31/01/2010, Andrea Fagiani andfagi...@gmail.com wrote: On 01/30/2010 01:37 PM, Heiko Baums wrote: Am Sat, 30 Jan 2010 13:11:26 +0100 schrieb Andrea Crottiandrea.crott...@gmail.com: Sometimes (only twice actually) I had to recompile the kernel with ice support from aur. Now compiling the kernel is not a short job, but it looks like it really compiles EVERYTHING! Maybe putting my .config somewhere it will not do it, how do you manage it? I guess this is the easiest way to compile your own kernel: 1. cp -R /var/abs/core/kernel26 /var/abs/local/kernel26-yourkernelname 2. Edit these variables in the PKGBUILD: pkgbase (to your package name) pkgname (copy the original one and replace kernel26* with kernel26-yourkernelname*) 3. Add the patches you like to the PKGBUILD. 4. Remove the comments of these lines: #make menuconfig # CLI menu for configuration (or the other options) #msg Stopping build #return 1 5. Run makepkg -g and replace the md5sums in the PKGBUILD. 6. Run makepkg and configure your kernel. (You don't need to change CONFIG_LOCALVERSION, this is done by the PKGBUILD automatically.) 7. cd /var/abs/local/kernel26-yourkernelname/src/linux-kernelversion diff -u .config.old .config cd ../.. Make the changes to the files config and config.x86_64 manually. or cd /var/abs/local/kernel26-yourkernelname cp src/linux-kernelversion/.config ./config or cp src/linux-kernelversion/.config ./config.x86_64 (depending on your CPU) 8. Run makepkg -g and replace the md5sums in the PKGBUILD. 9. Edit the PKGBUILD and comment the lines from 4. 10. Run makepkg and install the built package. 11. Finished! If you want to publish your kernel package in AUR then you unfortunately need to revert the PKGBUILD from a split to a single package. Greetings, Heiko Or, you could just edit the kernel26-ice PKGBUILD and enable the /menuconfig/ variable so that it triggers menuconfig in the build() section, there you can either modify the configuration on the run or load an alternate config file; just be sure to save the edited config to /.conf/ig . Andrea In the latest kernel, there is 'make localmodconfig' for precisely this problem. -- GPG/PGP ID: B42DDCAD
[arch-general] core/linux-api-headers?
Hi List, Just went to do a system upgrade and noticed this and unsure what it means or if I should so Yes: :: Replace kernel-headers with core/linux-api-headers? [Y/n] n Any comments? Thanks in anticipation. Richard
Re: [arch-general] core/linux-api-headers?
On 01/31/2010 03:05 PM, richard terry wrote: Hi List, Just went to do a system upgrade and noticed this and unsure what it means or if I should so Yes: :: Replace kernel-headers with core/linux-api-headers? [Y/n] n Any comments? Thanks in anticipation. Richard This has been discussed several times. A quick search of the forums should give you an idea.
Re: [arch-general] kernel-lts ....
You can simply install it through pacman -S kernel26-lts and edit you bootloader configuration to point to the new ramdisk and kernel image. On Sun, Jan 31, 2010 at 4:02 PM, William A. Mahaffey III w...@hiwaay.netwrote: On 01/31/10 10:54, Jan de Groot wrote: On Sun, 2010-01-31 at 10:34 -0600, William A. Mahaffey III wrote: I am new to the list, used Linux since Caldera 2.2. I noticed references to a kernel-lts, labelled as 'long-time-support' on the Arch website. I did a bit of googling noticed references to such from Arch Ubuntu forums. I found no references at kernel.org, although I noticed that they listed an upgrade to kernel 2.6.27.45, same number as the '-lts' kernel in Arch. Is the 'lts' kernel project Arch/Ubuntu-specific, or (semi-?) supported from kernel.org ? Also, I noticed that the bleeding edge kernels (seem to) include firmware packages, but I didn't see them for the lts kernels, did I just miss them or are they absent from the 'lts' series of kernels ? TIA The -lts kernels are stable kernels as maintained by kernel.org people. The 2.6.27 kernel has been maintained as stable kernel for 2-3 years now. When we added the kernel, our intentions were to have a maintained stable kernel that doesn't bring surprises after a security update, something that going from 2.6.31 - 2.6.32 won't offer you. The firmware binaries were included in drivers before, they've been split to standalone files in later versions of the kernel. That's why 2.6.27 doesn't come with a -firmware package. Thanks for the clarifications. Does the Arch installer let me choose the 'lts' kernel during install, or would I install then 'downgrade' to it ? TIA -- William A. Mahaffey III -- The M1 Garand is without doubt the finest implement of war ever devised by man. -- Gen. George S. Patton Jr. -- Flávio Coutinho da Costa
Re: [arch-general] Why taking so long?
Ray Rashif schivmeis...@gmail.com writes: In the latest kernel, there is 'make localmodconfig' for precisely this problem. Thanks to all of you, I recorded everything so I'll try next time. By the way I had to mask the kernel26 build (even if I don't use it) because broadcom-wl is always a bit too late and it wouldn't work with the new kernel. Could I just tell arch that I want to use the other kernel instead??
Re: [arch-general] core/linux-api-headers?
On Sun, 2010-01-31 at 15:22 -0600, Daniel Griffiths wrote: On 01/31/2010 03:05 PM, richard terry wrote: Hi List, Just went to do a system upgrade and noticed this and unsure what it means or if I should so Yes: :: Replace kernel-headers with core/linux-api-headers? [Y/n] n Any comments? Thanks in anticipation. Richard This has been discussed several times. A quick search of the forums should give you an idea. Or simply tell him the the package kernel-headers was renamed to linux-api-headers?
Re: [arch-general] core/linux-api-headers?
2010/1/31, Hussam Al-Tayeb ht990...@gmail.com: Or simply tell him the the package kernel-headers was renamed to linux-api-headers? Nope, pacman already said him that. :-) -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Re: [arch-general] core/linux-api-headers?
Am 31.01.2010 22:05, schrieb richard terry: Hi List, Just went to do a system upgrade and noticed this and unsure what it means or if I should so Yes: :: Replace kernel-headers with core/linux-api-headers? [Y/n] n Any comments? Thanks in anticipation. Richard Hello, That was just a rename of the package. You can savely answer Y. Regards Stefan
Re: [arch-general] core/linux-api-headers?
On Sun, 2010-01-31 at 23:26 +0100, Giovanni Scafora wrote: 2010/1/31, Hussam Al-Tayeb ht990...@gmail.com: Or simply tell him the the package kernel-headers was renamed to linux-api-headers? Nope, pacman already said him that. :-) Give a man a fish
Re: [arch-general] core/linux-api-headers?
On Sun, Jan 31, 2010 at 11:26:02PM +0100, Giovanni Scafora wrote: 2010/1/31, Hussam Al-Tayeb ht990...@gmail.com: Or simply tell him the the package kernel-headers was renamed to linux-api-headers? Nope, pacman already said him that. :-) So, if pacman ever asks: Replace cdrkit by cdrtools ? [Yn] that means that cdrkit has been renamed to cdrtools ? :-) (/me runs for a safe place) Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
Re: [arch-general] core/linux-api-headers?
On Sun, 2010-01-31 at 23:45 +0100, f...@kokkinizita.net wrote: On Sun, Jan 31, 2010 at 11:26:02PM +0100, Giovanni Scafora wrote: 2010/1/31, Hussam Al-Tayeb ht990...@gmail.com: Or simply tell him the the package kernel-headers was renamed to linux-api-headers? Nope, pacman already said him that. :-) So, if pacman ever asks: Replace cdrkit by cdrtools ? [Yn] that means that cdrkit has been renamed to cdrtools ? :-) No, that means that either someone uploaded a rogue package to community, or that you're using a repository that contains a cdrtools package that replaces cdrkit. Nothing more, nothing less.
Re: [arch-general] core/linux-api-headers?
2010/1/31, f...@kokkinizita.net f...@kokkinizita.net: that means that cdrkit has been renamed to cdrtools ? :-) Of course, it means that the software has benn renamed or replaced by another one. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Re: [arch-general] core/linux-api-headers?
On Sun, Jan 31, 2010 at 11:55:57PM +0100, Giovanni Scafora wrote: 2010/1/31, f...@kokkinizita.net f...@kokkinizita.net: that means that cdrkit has been renamed to cdrtools ? :-) Of course, it means that the software has benn renamed or replaced by another one. So it can mean two very different things. Which means that the exact background of the question 'Replace kernel-headers by api-headers ?' is unclear, and that the OP had good reason to ask what it meant. Pacman did *not* tell him this was just a rename. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
Re: [arch-general] core/linux-api-headers?
2010/2/1, f...@kokkinizita.net f...@kokkinizita.net: Pacman did *not* tell him this was just a rename. pacman just ask him if he wants to replace kernel-headers by api-headers, but it's obvious that software has been renamed or replaced by another one. If you dislike that behaviour, please send a request to pacman-dev ML. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Re: [arch-general] [signoff] inetutils 1.7-2
On Wed, Jan 27, 2010 at 10:56 PM, Eric Bélanger snowmanisc...@gmail.com wrote: Hi, inetutils-1.7-2 is in testing. The localstatedir was fixed (FS#17981). Please test and signoff. Users signoff will be appreciated as not a lot of devs use these tools. Eric bump. Anyone?
Re: [arch-general] core/linux-api-headers?
On 01/31/2010 04:24 PM, Giovanni Scafora wrote: 2010/2/1, f...@kokkinizita.net f...@kokkinizita.net: Pacman did *not* tell him this was just a rename. pacman just ask him if he wants to replace kernel-headers by api-headers, but it's obvious that software has been renamed or replaced by another one. If you dislike that behaviour, please send a request to pacman-dev ML. The difference between replaced and renamed is significant though. There's no reason not to replace kernel-headers with linux-api-headers, but there are some other packages (cdrtools vs cdrkit comes to mind) that would give the same message but have a very different effect. Just my 2 cents. -Brendan Long
Re: [arch-general] core/linux-api-headers?
On Sun, Jan 31, 2010 at 20:11, Brendan Long kori...@gmail.com wrote: The difference between replaced and renamed is significant though. There's no reason not to replace kernel-headers with linux-api-headers, but there are some other packages (cdrtools vs cdrkit comes to mind) that would give the same message but have a very different effect. Just my 2 cents. -Brendan Long The difference is that replaces was never meant for alternate software choices, it was meant for things like gaim-pidgin for example.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
On 30-01-2010 12:58, Baho Utot wrote: I don't think you get it. First of all, I don't care what happened when the split or fork happened. It makes _ZERO_ difference to me. This is what I have done because of _your_ direct actions on this list and other actions by you on some news groups I read. On the computers I have that run Slackware -12.2/13.0 I have removed cdrtools and installed cdrkit. Note that Slackware distributes cdrtools. I don't care if cdrtools is better than the very best or that cdrkit is worst than the worst. It doesn't matter. I have preformed some tests and guess what cdrkit works! Imagine that. It burnt the iso's for Slackware distribution, and using md5sum to sum both a Slackware distribution disk burned by both cdrkit and cdrtools and they are the same, how did that happen? Going forward I will use cdrkit on any system that I have any responsibilities on. Thanks. PS. I agree and support Arch Linux to distribute cdrkit. Strange, I have had the opposite experience. Trying to burn some CDs with cdrkit (on CentOS) give some problem with not being able to generate Joliet system and I have had trouble with utf-8 too. First I thought I was making some stupid mistake, but changing to cdrtools (from sourceforge repository) fixed that. Well, it was in another distro, but by what I've read in this thread it seems to make sense now. Armando
Re: [arch-general] Firefox 3.5.7 not support eh !??
On 01/31/2010 10:31 PM, Alexander Lam wrote: On Sun, Jan 31, 2010 at 6:42 AM, Giuseppe Turrisi giuseppeturr...@gmail.com wrote: Il 31/01/2010 12:30, Jan de Groot ha scritto: On Sun, 2010-01-31 at 16:58 +0530, Nilesh Govindarajan wrote: Something is seriously funny going on here with FF 3.5.7 (Shiretoko). I'm using it from the arch repos, but on visiting Google Help or Orkut, it says Browser not supported ? And the supported browser list says FF 1.5+ Something is wrong with the arch build ? There's nothing wrong with our firefox package, it's buggy browser detection done by these websites. You might want to change the user agent string through about:config to get Firefox in the name. Websites with browser detection like this are plain stupid, you should complain about it and advise them to check for a gecko engine version. you can also use an add-ons like this: https://addons.mozilla.org/en-US/firefox/addon/59 -- Il Software Libero è una questione di libertà, non di prezzo. or you could go into the Firefox config (URL: about:config) and change the value of general.useragent.extra.firefox to Firefox/3.5.7 I changed it using the addon. I could also do that, but to be on the safer side... I already had to install all my addons and themes due to some similar thing. So not taking risk again :D -- Nilesh Govindarajan Site Server Adminstrator www.itech7.com
Re: [arch-general] Arch Linux and security - it needs some work
On 01/31/2010 08:31 PM, Ananda Samaddar wrote: I really like Arch. I switched about a year ago after being a Debian user for nine years. There is something that troubles me though about Arch. Its lack of security focus. By this I mean there is no consistent way that security issues are dealt with. There was a proposal for 'The Arch Linux Security Team' but it seems to have fallen by the wayside[1]. I propose to resurrect this in the spirit of Arch's users becoming contributors. I, hopefully not alone wish to draw up a list of processes that can be used to create a dedicated Arch Linux security team that can deal quickly and efficiently with security alerts. It would need to be able to liaise successfully with Arch developers and hopefully over time security team members can become trusted users. I'm mentioning it now as I notice that an Arch Conference is being organised in Canada. One of my proposals (shamefully stolen from Debian) would be to have key-signing parties at Arch Linux meet-ups. This could then be used to create an Arch Linux web of trust. So basically I'm going to get my ideas into writing and post them on this list. I hope others will be willing to come forward and contribute too. After some discussion we should be able to reach a consensus and start giving security issues the priority they deserve. regards, Ananda Samaddar [1] http://wiki.archlinux.org/index.php/Security_Task_Force Key signing is not required for us I think. Because Arch people are the first to release package updates. It is tested properly and is given in .tar.gz archives. Even if a byte is altered in the archive then its md5sum would change so pacman will complain. -- Nilesh Govindarajan Site Server Adminstrator www.itech7.com
Re: [arch-general] Firefox 3.5.7 not support eh !??
On 02/01/2010 09:45 AM, Nilesh Govindarajan wrote: On 01/31/2010 10:31 PM, Alexander Lam wrote: On Sun, Jan 31, 2010 at 6:42 AM, Giuseppe Turrisi giuseppeturr...@gmail.com wrote: Il 31/01/2010 12:30, Jan de Groot ha scritto: On Sun, 2010-01-31 at 16:58 +0530, Nilesh Govindarajan wrote: Something is seriously funny going on here with FF 3.5.7 (Shiretoko). I'm using it from the arch repos, but on visiting Google Help or Orkut, it says Browser not supported ? And the supported browser list says FF 1.5+ Something is wrong with the arch build ? There's nothing wrong with our firefox package, it's buggy browser detection done by these websites. You might want to change the user agent string through about:config to get Firefox in the name. Websites with browser detection like this are plain stupid, you should complain about it and advise them to check for a gecko engine version. you can also use an add-ons like this: https://addons.mozilla.org/en-US/firefox/addon/59 -- Il Software Libero è una questione di libertà, non di prezzo. or you could go into the Firefox config (URL: about:config) and change the value of general.useragent.extra.firefox to Firefox/3.5.7 I changed it using the addon. I could also do that, but to be on the safer side... I already had to install all my addons and themes due to some similar thing. So not taking risk again :D Eh. I cannot keep on switching the User Agent every time I start firefox. So about:config :D ;) -- Nilesh Govindarajan Site Server Adminstrator www.itech7.com
Re: [arch-general] Firefox 3.5.7 not support eh !??
On 01/31/2010 10:25 PM, Nilesh Govindarajan wrote: On 02/01/2010 09:45 AM, Nilesh Govindarajan wrote: On 01/31/2010 10:31 PM, Alexander Lam wrote: [snip] Eh. I cannot keep on switching the User Agent every time I start firefox. So about:config :D ;) The about:config way will also make your Firefox-ing faster, since it won't have to load the addon every time it starts.
Re: [arch-general] Arch Linux and security - it needs some work
On 01/31/2010 09:18 PM, Nilesh Govindarajan wrote: On 01/31/2010 08:31 PM, Ananda Samaddar wrote: [snip] Key signing is not required for us I think. Because Arch people are the first to release package updates. It is tested properly and is given in .tar.gz archives. Even if a byte is altered in the archive then its md5sum would change so pacman will complain. Close, but what about the package list? The proposals I've seen have mostly been to just sign the package list, since the md5 takes care of everything else.
Re: [arch-general] Arch Linux and security - it needs some work
On Mon, Feb 1, 2010 at 12:19 AM, Nicky726 nicky...@gmail.com wrote: Hm, would be nice. :-) I ve been digging into SELinux and Arch lately, and yes some more official support would be nice. If there is something being organized, I'd gladly help, at least in this SELinux area. security isnt about SELinux. -jf -- Every nonfree program has a lord, a master -- and if you use the program, he is your master. --Richard Stallman It's so hard to write a graphics driver that open-sourcing it would not help. -- Andrew Fear, Software Product Manager, NVIDIA Corporation http://kerneltrap.org/node/7228
Re: [arch-general] Arch Linux and security - it needs some work
On 02/01/2010 11:01 AM, Jeffrey 'jf' Lim wrote: On Mon, Feb 1, 2010 at 12:19 AM, Nicky726nicky...@gmail.com wrote: Hm, would be nice. :-) I ve been digging into SELinux and Arch lately, and yes some more official support would be nice. If there is something being organized, I'd gladly help, at least in this SELinux area. security isnt about SELinux. -jf -- Every nonfree program has a lord, a master -- and if you use the program, he is your master. --Richard Stallman It's so hard to write a graphics driver that open-sourcing it would not help. -- Andrew Fear, Software Product Manager, NVIDIA Corporation http://kerneltrap.org/node/7228 And anyways, SELinux is extra complicated to understand and produce any desired result. I've many times tried to understand SELinux but always failed in it. While I was using Fedora, the first thing after installing the OS was to disable SELinux :D -- Nilesh Govindarajan Site Server Adminstrator www.itech7.com
Re: [arch-general] core/linux-api-headers?
On 01/02/2010, f...@kokkinizita.net f...@kokkinizita.net wrote: On Sun, Jan 31, 2010 at 11:55:57PM +0100, Giovanni Scafora wrote: 2010/1/31, f...@kokkinizita.net f...@kokkinizita.net: that means that cdrkit has been renamed to cdrtools ? :-) Of course, it means that the software has benn renamed or replaced by another one. So it can mean two very different things. Which means that the exact background of the question 'Replace kernel-headers by api-headers ?' is unclear, and that the OP had good reason to ask what it meant. Pacman did *not* tell him this was just a rename. Oh nono, $replaces isn't used like that. When for instance you have deleted a package and brought in a new one with a different name, often due to a name change (upstream or not), you need to make sure pacman will know and seamlessly update to the new package. Sometimes, projects go defunct and forks become active. Asking the user to answer the question resolves one big thing: 1) He will not complain later; he won't be freaked out when he finds one of his packages is missing and/or the system has something he can't recall installing. -- GPG/PGP ID: B42DDCAD
