Re: [aur-general] had to change ~.ssh/config from archlinux.com to archlinux.org
Am 04.03.2016 um 23:55 schrieb David McInnis: > Hi gang, > > I apparently have had my .ssh/config mis-configured for some time. > Today the AUR suddenly stopped accepting my git commits. It gave me the > following error: > > Permission denied (publickey). > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > > > turns out I had the wrong host in my .ssh/config file: > > Host aur.archlinux.com > IdentityFile ~/.ssh/aur_davidmcinnis > User aur > > I needed to change to the following: > > Host aur.archlinux.org > IdentityFile ~/.ssh/aur_davidmcinnis > User aur The domain archlinux.com was never associated with Arch Linux. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Prefered way to create users/groups and handle files ownership
Am 25.01.2014 17:13, schrieb Maxime Gauduin: The reason why permissions should be set in the PKGBUILD is because that way pacman can track them. Then it's up to the maintainer to choose UIDs/GIDs that do not conflict with official packages, and to the user to check that they don't already use that particular UID/GID ,before installing an AUR package. This is not optimal, but there's a list of UIDs and GIDs: https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database Beyond that, there's two comments I have: 1) Software shouldn't really rely on files being owned/writable by certain users. An application is either a system service, which can adjust the needed permissions at runtime before dropping privileges - thus no need to hardcode uids or even user names. If the application is a user application, then it writes with the user's permissions anyway. If an admin wants a user application to run system-wide, it's his job to set up user and working directory. In short: apart from very few system-specific groups, the package manager should not be involved here, and packages that need files owned by special non-root users should be fixed. 2) *If* we really need specific UIDs, then pacman should gain a feature where it translates ownership during package extraction. signature.asc Description: OpenPGP digital signature
Re: [aur-general] AsciiDoc version of the TU bylaws
Am 31.10.2012 17:49, schrieb Lukas Fleischer: Hi! I converted our TU bylaws to AsciiDoc and imported he converted document into a Git repository that I temporarily hosted on [1]. Maybe we can eventually move that to one of the Arch Linux servers. If you need a git-shell account and repository for projects.al.org, contact me via Jabber or IRC. signature.asc Description: OpenPGP digital signature
Re: [aur-general] [arch-dev-public] TU Removal -- Kaiting Chen
Am 18.10.2012 05:08, schrieb Kaiting Chen: Hey guys I was actually just about to turn in my resignation. It's been great working with all of you but unfortunately I have absolutely no time anymore for my TU responsibilities and do not foresee any circumstance in the near future in which I will have such time available. Again you guys and the entire Arch community are awesome; best of luck going forward! --Kaiting. I guess you guys don't need a vote then :) Have fun Kaiting. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application - Ike Devolder - results
Am 13.03.2012 19:23, schrieb Stéphane Gaudreault: Ike, please follow these steps [1]. [...] [1] https://wiki.archlinux.org/index.php/New_Trusted_User_Checklist#TODO_list_for_new_Trusted_Users This list is missing an important (new) step: The PGP key needs to be verified by at least 3 of the 5 master key holders. This brings up an important point: For existing TUs/developers, I have been relying on server accounts for verification. For new people, I am not so sure what to do (maybe nothing). Anyway, the list should be extended to include the verification part. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application - Ike Devolder
Am 01.03.2012 15:31, schrieb Peter Lewis: On Thursday 01 Mar 2012 07:51:47 Stéphane Gaudreault wrote: This is a bit picky of me, but technically the sponsor is supposed to be a TU and as far as I can tell Stéphane is a dev rather than a TU... So ... Following this logic I have the power to break everything on your system ... but not to sponsor a future member of our trusted users team ? (Just kidding :D ). Heh, quite. I didn't claim to have logic on my side, I was just highlighting what our byelaws currently say. I said it was picky, but if we're happy for Devs to sponsor TU-ship, then we should just change the rules. I didn't want to create a big discussion out of this (unless of course people do disagree with devs being sponsors), so if there aren't any reasons contra, I'll put in a proposal to amend the byelaws. I guess this came from an original idea that the group of TUs are self- governing, independently of the developers. I always highlight that the Arch core developers usually don't interfere with the affairs of the TU group. In that sense, the bylaws make sense by saying you need to TU to sponsor him. However, the important part (voting) is done by TUs only. Personally, I always considered the sponsor requirement an unnecessary formality anyway. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application - Ike Devolder
Am 01.03.2012 08:33, schrieb Ike Devolder:
Hi,
Currently I'm using Archlinux as my primary operating system for over 6
years and for several years I'm maintaining a small number of packages in
AUR[1]. I also keep a repository with arch packages for everyone to use[2]
and view the pkgbuilds on github[3]. Originally the repository got created
so i could easily install some non-{core,extra,community}-packages on my
different computers.
Just some random formal remarks:
1) Nowadays, your application should be a PGP-signed email. You should
also somehow verify that you are who you say you are, for example, by
uploading your PGP key or fingerprint to your server or github.
2) What are your user names on bbs, bugs and IRC, if any?
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] [PATCH] Added handling of ctrl-c
Am 09.12.2011 11:21, schrieb Alexander Rødseth: --- namcap.py | 19 +++ 1 files changed, 19 insertions(+), 0 deletions(-) How about actually posting to the right list? https://mailman.archlinux.org/mailman/listinfo/arch-projects signature.asc Description: OpenPGP digital signature
Re: [aur-general] 2 recommendations needed for installing Arch Linux
Am 06.12.2011 12:28, schrieb Ralf Mardorf: Hi :) I'm new to the list. Wrong list. You want arch-general. Sorry that my mail is formatted in HTML. You're lucky you didn't get filtered. Apparently, we only strip the HTML from the message instead of blocking it completely. I'll switch to Arch Linux because for my needs, audio productions, it could be easier to keep it stable than it is for other distros. There was a blog post from some audio guy: http://www.linuxjournal.com/content/arch-tale Interesting read, he is very positive about Arch. I've got two questions. 1. What is a safe FS, that can be recovered? Ext4 seemingly isn't such a FS. They barely exist. Maybe try btrfs, but btrfs is still considered unstable by its developers. You should rather do proper backups that you don't accidently delete. The FS also should be usable for audio productions. What special properties does a file system need for audio production? Security regarding to multiple user usage, web access, server usage etc. are unimportant for a DAW. You won't find a filesystem that doesn't have the basic access control features. 2. For my main Linux I always prefer to use 64-bit architecture, but 32-bit architecture compatibility is needed. Is there something I should take care about when installing Arch Linux? You can get 32 bit compatibility, but you need to install the required libraries from the multilib repository. This repository is disabled by default. For a list of available binary packages, see here: https://www.archlinux.org/packages/?arch=x86_64repo=Multiliblimit=all signature.asc Description: OpenPGP digital signature
Re: [aur-general] GPG Key Signing
Am 01.12.2011 12:19, schrieb Xyne: I'm in the process of getting my key signed (Pierre has signed, Thomas and Ionut should sign soon, not sure if Dan will sign due to not knowing my real name). Dan's way isn't just about knowing the realname. He wants to verify that the name is correct. I can't believe that we are having the identity verification discussion again, but here is what I believe: You have been elected TU (or Developer) and thus I trust your key. Knowing (or not knowing) your real name doesn't change anything. In fact, I did not verify names for anyone. What's important to me: If I find out that you release packages that are harmful in any way, I can revoke my signature and block your packages from being installed. Knowing your real name does not make that easier, or prevent you from doing harmful things in the first place. signature.asc Description: OpenPGP digital signature
Re: [aur-general] GPG Key Signing
Am 01.12.2011 23:08, schrieb Gaetan Bisson: [2011-12-01 09:08:39 -0600] Thomas Dziedzic: I don't think anyone has actually verified that any of the given names are real names. Well, actually, CAcert (which Dan relies on) is all about verifying people's actual identity, in particular their name and birth date. And that information is useful to you because ...? What's important is that you're verified that you use the key to sign your packages in case someone does get compromised or decides to go rogue, then we will have a way to easily track which packages should become void. That feature was already achieved by permissions on gerolde/sigurd... It wasn't. The whole point of package signing is to neutralize attacks against our repositories (our servers but also third-party mirrors). That's only part of the point. The other part is - as mentioned - the ability to revoke trust from rogue packagers. I find Dan's verification requirements quite reasonable, and I am pleased he takes a different approach than other master key holders: what would be the point of everyone verifying the same thing? Yes, that Xyne person (well, it could even be a group of people, for all we know) has pushed good packages to the repos, but developers and trusted users are not just package producing machines, and it doesn't strike me as odd that a distro expects a little transparency from them. I'll ask you the same question I asked before, when we already had this discussion: What benefit does knowing someone's real identity give you? (and please, I'd really like to get an answer this time) TBH, I wish I would have chosen a pseudonym when I started doing things publicly on the internet. I wish I never would have given anyone my real name. It's too late for that now, I'm afraid. Of course, that is only my opinion: verification policy is for each master key holder to decide individually - that's what they were entrusted with when they were selected. We should have agreed on a common policy on this matter. It sends mixed signals when a packager is only signed by some key holders and not others. And, IMO, it is an affront to this community to reject someone who has been contributing for years. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application - Timothy Redaelli
Am 28.11.2011 13:30, schrieb Timothy Redaelli: Hi, I thought about applying as a TU for some time now, I think the selection of packages provided by Arch is already great but there is always space for additional quality software in community and I hope to help with that. Here's a little background about myself: I'm a 27yr old italian guy, working as a embedded developer in a broadband company. You should really sign your application email using your PGP key. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Developer / TU key signing, first master key available
Am 19.11.2011 15:38, schrieb Thomas Bächler: Hello developers / TUs, My Arch master key is available at [1] with fingerprint 6841 48BB 25B4 9E98 6A49 44C5 5184 252D 824B 18E8. Every packager, please do the following: 1) Reply to this email to tho...@master-key.archlinux.org and fully quote this email. Include your gerolde/sigurd username in the email. Sign your reply using your GPG key. 2) Upload your public key (gpg --armor --export $KEYID) to your home directory on gerolde/sigurd under the name $HOME/arch-linux-packager-key. 3) Name at least one package in the repositories already signed with your key. Sadly, this process will only prove that you are in posession of the ssh key to upload packages into the repositories. I will contact you personally afterwards if I need further identification. Please note: there are be 5 master key holders (Allan, Dan, Pierre, Ionut, me), and you need at least 3 signatures on your key so your packages will be trusted by pacman. Regards Thomas [1] https://dev.archlinux.org/~thomas/thomas_AT_master-key.archlinux.org.asc Please note: There are many TUs (and some devs) that didn't reply to this request yet. There are even TUs that replied to the other master key holders, but not me. Please be aware that you have to contact all master key holders separately in the way stated in the request. It is not sufficient to reply just one of them! Also be aware that after some transition time, gerolde and sigurd will check your signature on db-update, and WILL REJECT THE PACKAGE IF YOUR KEY IS NOT TRUSTED. Therefore, completing the key submission to the master key holders is non-optional! When replying, please make sure that tho...@master-key.archlinux.org is included in the To: field of your email (otherwise I will probably miss the mail). If you fail to configure your mail client for signing emails, please write the text into a plaintext file, sign it, and attach it. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Developer/TU key signing
Am 25.11.2011 14:27, schrieb Ionut Biru: Hi, my arch master key is available [1] with fingerprint 44D4 A033 AC14 0143 9273 97D4 7EFD 567D 4C7E A887. Every packager please do: 1) reply this email in the mailing list, include gerolde/sigurd username and sign your reply using your gpg key. 2) name at least one package you already signed. [1] https://dev.archlinux.org/~ibiru/ionut_AT_master-key.archlinux.org I'd like to take this opportunity to remind everyone that some people did not respond to my mail here: https://mailman.archlinux.org/pipermail/aur-general/2011-November/016540.html signature.asc Description: OpenPGP digital signature
[aur-general] Developer / TU key signing, first master key available
Hello developers / TUs, My Arch master key is available at [1] with fingerprint 6841 48BB 25B4 9E98 6A49 44C5 5184 252D 824B 18E8. Every packager, please do the following: 1) Reply to this email to tho...@master-key.archlinux.org and fully quote this email. Include your gerolde/sigurd username in the email. Sign your reply using your GPG key. 2) Upload your public key (gpg --armor --export $KEYID) to your home directory on gerolde/sigurd under the name $HOME/arch-linux-packager-key. 3) Name at least one package in the repositories already signed with your key. Sadly, this process will only prove that you are in posession of the ssh key to upload packages into the repositories. I will contact you personally afterwards if I need further identification. Please note: there are be 5 master key holders (Allan, Dan, Pierre, Ionut, me), and you need at least 3 signatures on your key so your packages will be trusted by pacman. Regards Thomas [1] https://dev.archlinux.org/~thomas/thomas_AT_master-key.archlinux.org.asc signature.asc Description: OpenPGP digital signature
Re: [aur-general] FYI: New packages have to be signed
Am 01.11.2011 19:05, schrieb Kwpolska: On Tue, Nov 1, 2011 at 4:04 PM, Smartboy smartboyath...@gmail.com wrote: Just wondering, as a user, does this mean Pacman will now complain if one builds and installs unsigned packages from the AUR? The default SigLevel is Optional for now. This should be changed to PackageRequired or Required IMO, but then you can't install unsigned packages with pacman -U any more. Maybe pacman -U --no-signature should exist. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Securing the AUR website
Am 03.09.2011 17:49, schrieb Gordon JC Pearce: The other is that switching to https has left AUR in a fundamentally broken state. If you search for a package on AUR with any of the significant search engines, they return an http link. You can't do anything with this, though, because *even if you're logged in* you get the ZOMG OH NOES YOU AREN'T USING HTTPS AND HTTPS IS TEH AWSUM11!!11! message. Now, if clicking on that took you *to the same page but with https* that would be fine, but it doesn't. It unceremoniously dumps you on the index page for AUR, with no way to get back to the package that you googled. This is a detail you could have shared in your first post and this discussion would have been a lot shorter. This is a bug, it belongs to the bugtracker and it is (as far as I can see) trivial to fix. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Securing the AUR website
Am 05.09.2011 14:51, schrieb Lukas Fleischer: On Mon, Sep 05, 2011 at 02:44:29PM +0200, Thomas Bächler wrote: Am 03.09.2011 17:49, schrieb Gordon JC Pearce: The other is that switching to https has left AUR in a fundamentally broken state. If you search for a package on AUR with any of the significant search engines, they return an http link. You can't do anything with this, though, because *even if you're logged in* you get the ZOMG OH NOES YOU AREN'T USING HTTPS AND HTTPS IS TEH AWSUM11!!11! message. Now, if clicking on that took you *to the same page but with https* that would be fine, but it doesn't. It unceremoniously dumps you on the index page for AUR, with no way to get back to the package that you googled. This is a detail you could have shared in your first post and this discussion would have been a lot shorter. This is a bug, it belongs to the bugtracker and it is (as far as I can see) trivial to fix. Do not open another ticket, please. There's FS#25757 [1] already and I sent a patch addressing that bug to aur-dev [2]. I will push that and update our live setup as soon as I get round to it. [1] https://bugs.archlinux.org/task/25757 [2] http://mailman.archlinux.org/pipermail/aur-dev/2011-August/001864.html No point to send the patch I just created then (there wasn't anything in aur.git). While looking at it, I noticed that in the action=... in the login form, there should also be htmlentities or similar around $_SERVER['REQUEST_URI']. Thanks anyway. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Securing the AUR website
Am 01.09.2011 13:01, schrieb Lukas Fleischer: archlinux.org - http - no login anyway bbs.archlinux.org - https- separate login page wiki.archlinux.org - https- separate login page bugs.archlinux.org - https- login on main page aur.archlinux.org - http - login on main page As you can see, AUR is the fish out of water here, login is on the arrival page, but you can't log in by default. I'm sorry to make the suggestion this late, but I'd vote for https as default for AUR. HTTPs is the default - unless you request the HTTP version explicitly. I know that some of the navigation bar links aren't updated yet. I sent a patch for Flyspray to Pierre, and also asked him to update the header include used in our cgit setup. It should be only a matter of time until all links are up-to-date. When I type aur.archlinux.org in firefox I get the http version, that's what I mean by default. Thanks for your efforts to secure AUR. Yeah, you request the HTTP version (your browser does this automatically if you skip the protocol part), so this is kind of expected behaviour. We could introduce an HTTPs redirect for the AUR home page. Not sure if that is the right thing to do, though. I'd like to remind everyone again that Arch Linux is now included in the https-everywhere default rules, see [1]. This will always redirect you to https on every Arch Linux site (even releng, www, planet, where it isn't actually needed). [1] https://www.eff.org/https-everywhere/ signature.asc Description: OpenPGP digital signature
Re: [aur-general] Securing the AUR website
Am 06.08.2011 14:32, schrieb Lukas Fleischer: For all tl;dr guys around. This is my proposal: * Use HTTPs links by default (this is already implemented). * Enable secure cookies. * Disallow HTTP login (or at least print a big, fat warning if a user tries to login via HTTP). I would really go with disallow. Don't even show a login form, just a link that directs to https _before_ being able to enter a password. * Possibly use HSTS. This should fix all possible vulnerabilities related to HTTPs we can actually fix. Let me know if I missed something. Yes, the list looks complete. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Securing the AUR website
Am 05.08.2011 23:54, schrieb Lukas Fleischer: [1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137 Those commits are nothing but a charade. The very least you must do is this: 1) ALWAYS force a redirect to https on the AUR login page, never allow the login to be submitted unencrypted. 2) Ensure that the cookie is never sent over http, only over https. Everything less than that is completely irresponsible. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Securing the AUR website
Am 06.08.2011 13:13, schrieb Lukas Fleischer: On Sat, Aug 06, 2011 at 01:02:03PM +0200, Thomas Bächler wrote: Am 05.08.2011 23:54, schrieb Lukas Fleischer: [1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137 Those commits are nothing but a charade. The very least you must do is this: 1) ALWAYS force a redirect to https on the AUR login page, never allow the login to be submitted unencrypted. Thought about that. The problem is that there currently isn't a separate login page. Maybe removing the overall login form and creating a separate page for that will make things easier. Then at least hardcode https for the login form, so the password is always sent securely. This will still have the problems Florian mentioned, but it is better than nothing. Alternatively: Do not display a login form on http, instead display a link If you want to login, switch to a secure connection first.. This way, the user verifies the certificate and URL first (by looking at the URL bar), then enters his password. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Securing the AUR website
Am 06.08.2011 10:52, schrieb Loui Chang: On Sat 06 Aug 2011 13:39 +0200, Thomas Bächler wrote: Alternatively: Do not display a login form on http, instead display a link If you want to login, switch to a secure connection first.. This way, the user verifies the certificate and URL first (by looking at the URL bar), then enters his password. I agree with this. As long as the rest of the site is functional via http. This is a solution I can live with, too. signature.asc Description: OpenPGP digital signature
[aur-general] udev rule files in /etc/udev/rules.d, usage of SYSFS
I just got flooded with this message:
'SYSFS{}= will be removed in a future udev version, please use ATTR{}=
to match the event device, or ATTRS{}= to match a parent device, in
/etc/udev/rules.d/51-hso-udev.rules'
And I remembered there are 2 things to fix.
1) Move all udev rule files provided by us to /lib/udev/rules.d
(/etc/udev/rules.d is for the user only)
community/multipath-tools (0.4.9-4) : /etc/udev/rules.d/kpartx.rules
community/multipath-tools (0.4.9-4) : /etc/udev/rules.d/multipath.rules
community/ozerocdoff (2-3) : /etc/udev/rules.d/51-hso-udev.rules
community/sysprof (1.1.6-1) : /etc/udev/rules.d/60-sysprof.rules
extra/laptop-mode-tools (1.57-2) : /etc/udev/rules.d/99-laptop-mode.rules
extra/v4l-utils (0.8.3-1) : /etc/udev/rules.d/70-infrared.rules
(The last one is probably my fault)
2) Remove the long deprecated SYSFS from all rule files (I didn't check
all packages here, but ozerocdoff is definitely one case)
signature.asc
Description: OpenPGP digital signature
[aur-general] New list: arch-projects
A new list has been created: arch-projects. This list is for development discussion, patches and pull requests for initscripts, netcfg, dbscripts, devtools (and maybe other projects, those are the ones I could think of). Anyone is free to subscribe, but please, no user discussions (keep those to the forums or arch-general). Fun fact: There was a mailing list called arch-projects once, and it has been deleted, but the old archives are still there. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Gzipped kernel modules
Am 11.03.2011 00:45, schrieb Thomas S Hatch: Wait, you are saying that insmod will load gzipped mods if compiled differently? No. depmod, modinfo and modprobe can do it, insmod can't. signature.asc Description: OpenPGP digital signature
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Am 19.01.2011 08:08, schrieb Allan McRae: If we want to be really pedantic about dependencies, we should list _ALL_ dependencies and not remove the ones that are dependencies of dependencies. Why don't we just do the correct thing: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. signature.asc Description: OpenPGP digital signature
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Am 19.01.2011 13:32, schrieb Seblu: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. And this check is done by a software not by a scientist predicate that varies depending on the experience of maintainer. For library-dependencies on binaries, yes. On scripts it is much harder to check this. I don't think it is possible to cover all cases with a piece of software here, but one should try. signature.asc Description: OpenPGP digital signature
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Am 19.01.2011 14:07, schrieb Allan McRae: Its has been many years since I did graph theory... but isn't a transitive closure essentially what we have been doing with only listing the top level of dependencies and having them cover the rest? It's the exact opposite. You list all dependencies, and dependencies of dependencies, and ... signature.asc Description: OpenPGP digital signature
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Am 19.01.2011 14:19, schrieb Allan McRae: On 19/01/11 23:07, Thomas Bächler wrote: It's the exact opposite. You list all dependencies, and dependencies of dependencies, and ... Ah... OK. then I don't understand this: Don't worry, me neither. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Changing AUR development infrastructure.
Am 17.01.2011 02:19, schrieb Loui Chang: Recently I've had the idea that I should move the 'main' AUR git repo, which I have been the caretaker of to the community server where all other community and AUR development is done. This would also mean we would have to run a git daemon, and should also install a web interface like cgit to browse the repo. I'm hearing that there is some opposition to this. I'd like to start a discussion to hear the reasons behind that. I'd like to point out that we have all the infrastructure on gerolde so that all repos are available for cloning and cgit-browsing in a central place. I don't see the point of duplicating that and scattering our infrastructure further. Currently, all Arch-related projects are hosted in a central place and I'd like to keep it that way. Here are the reasons I have for moving the repo: * The Trusted Users will have more control over the AUR development since it will be on their own server. * We can use the new infrastructure to host other TU and community projects. * We don't need to create superfluous shell accounts on gerolde to for push access to those repos. Those accounts already exist on sigurd. If you really think it is necessary, we could always put the main repo to sigurd and have a mechanism set up to sync it to gerolde (either pull with a cronjob, or push from sigurd to gerolde in post-update). As a side note, not more than one or maybe two people should have direct push access to a git repository. If anyone else wants to contribute, they should send pull requests - the maintainer of the main repository should be active enough to pull and merge them quickly though. signature.asc Description: OpenPGP digital signature
[aur-general] libnl 2.0 rebuild
So, libnl 2.0 was declared stable in October as I just learned. These packages are compatible with libnl 2.0: - crda - iw - wpa_supplicant - hostapd These packages don't as far as I can see: - libpcap - networkmanager These I didn't check: - kismet - net-snmp - knemo - libvirt - simh Can the respective maintainers find out whether there are patches for libnl 2.0 support? I'd like to do the rebuild on the weekend. If we can't fix all packages, we could put a libnl1 package to [extra]. (If there are no patches, it seems that porting to libnl 2.0 is not that difficult, so we could do it ourselves and submit it) signature.asc Description: OpenPGP digital signature
[aur-general] New repositories (community-staging, multilib-testing)
The TU server now has a staging repository, this has been requested due to the big python rebuild. All rebuilds that are made for the staging repository should be put into community-staging now. multilib now has a testing repository, in case we need it (especially useful when testing has a new toolchain). Last but not least, the adjust-permissions cronjob has been disabled on both servers - should you mess with the db file directly (which you really shouldn't), never forget to restore the right permissions. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Want to submit a PKGBUILD
Am 31.08.2010 14:48, schrieb 陈文龙: I tried to. But it says The address, *qzche...@gmail.com*, is already in use. I cannot remember my account, if I have registered. Your account is chenwl. signature.asc Description: OpenPGP digital signature
[aur-general] Changes to AUR and community due to the multilib repository
With the creation of the [multilib] repository, all 32-bit libraries are now installed in /usr/lib32 and compiled from source using the gcc-multilib package instead of being copied from i686 packages. All AUR users maintaining lib32-* and bin32-* packages are encouraged to adapt their packages to the new layout. All trusted users who want to maintain 32 bit packages should join the arch-multilib mailing list and ask for access there. The x86_64 community repository should remain lib32-free in the future. signature.asc Description: OpenPGP digital signature
Re: [aur-general] At last, clean multilib support
Am 22.08.2010 10:39, schrieb Thomas Bächler:
Jan Steffens and me spent the this weekend putting together a multilib
toolchain and a clean lib32-glibc package. I wanted to do this for at
least two years, and we finally managed to do it on FrOSCon now. This is
the plan of attack on this:
* Maintain the PKGBUILDs in svn-community/${pkgname}/trunk/
* Create a separate repo 'multilib',
(svn-community/${pkgname}/repos/multilib-x86_64)
* Remove ALL multilib packages from community. Do NOT mix pure 64 bit
with multilib. All multilib must go into the new multilib repository.
* Rebuild all multilib packages with the multilib compiler to solve the
numerous problems encountered by the hackish copy our 32 bit packages
into another path approach.
* Find TUs and Devs willing to work on multilib (please add your name to
https://wiki.archlinux.org/index.php/Multilib_Project)
Any comments are welcome. We will upload the multilib packages and
PKGBUILDs into a small test repository in a minute for review.
Mailing list is up, the discussion will continue there.
http://mailman.archlinux.org/mailman/listinfo/arch-multilib
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] At last, clean multilib support
Am 22.08.2010 10:39, schrieb Thomas Bächler:
Jan Steffens and me spent the this weekend putting together a multilib
toolchain and a clean lib32-glibc package. I wanted to do this for at
least two years, and we finally managed to do it on FrOSCon now. This is
the plan of attack on this:
* Maintain the PKGBUILDs in svn-community/${pkgname}/trunk/
* Create a separate repo 'multilib',
(svn-community/${pkgname}/repos/multilib-x86_64)
* Remove ALL multilib packages from community. Do NOT mix pure 64 bit
with multilib. All multilib must go into the new multilib repository.
* Rebuild all multilib packages with the multilib compiler to solve the
numerous problems encountered by the hackish copy our 32 bit packages
into another path approach.
* Find TUs and Devs willing to work on multilib (please add your name to
https://wiki.archlinux.org/index.php/Multilib_Project)
Any comments are welcome. We will upload the multilib packages and
PKGBUILDs into a small test repository in a minute for review.
A temporary repository is up: http://pkgbuild.com/~heftig/multilib/
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] Important: upcoming dbscripts release
I am pulling new dbscripts on sigurd now. Am 16.08.2010 19:49, schrieb Pierre Schmitz: Hi all, as the new dbscripts are quite done I'll send you a list with the most important changes. (If you are in a hurry read at least the next paragraph) Incompatible changes: * db-update will now update all packages found in your staging dir from all repositories * db-move has now a different syntax: repo-from repo-to pkgname|pkgbase ... You can move as many packages as you like at once. There is no need to specify an architecture here. * The wrapper scripts like testing2core have been removed as they are no longer needed; use db-move instead * testing2x now moves both arches at the same time (testing2x64 has been removed) * I have also started a user documentation at http://wiki.archlinux.org/index.php/DeveloperWiki:dbscripts Important changes: * implementation of a package pool: all packages are now stored in pool/packages or pool/community directories on the ftp server. The current repository directories like extra/os/i686 only contain symlinks. As a results moving pacakges between repositories is now a matter of altering symlinks and as such very cheap. This should solve the problems with not fully synced mirrors we had in the past when a lot of packages were moved from e.g. testing to extra. * Packages are only switched to this new layout if they are updated or moved. This way the migration should be slow but smooth. * db-move can now handle multiple packages within one transaction. General improvements: * unit tests based on shunit2 * heavy refactoring to share common functions * Added more integrity checks which are run before the repositories are touched. * rewritten functions for easier and smaller code * the scripts can handle other db compressions than gz (but there is no migration path yet) Note: even though the result is more or less a rewrite there are still things that can be improved or new useful features that can be added. The tests only cover some basic use cases so we should still have a look at it once the new version is deployed. I think we should deploy these soon (before Allan's big python rebuild party) with CLEANUP_DRYRUN enabled during the first days. Greetings, Pierre signature.asc Description: OpenPGP digital signature
Re: [aur-general] Proposal to move sage-mathematics into [community].
Am 12.08.2010 19:34, schrieb Ronald van Haren: Sorry it doesn't really make sense to me. Why would we want to duplicate all these packages that we already have in the repos with one big fat binary containing them all? I mean, all SAGE is doing is getting sources from open source projects and merge them in one big fat distribution if I'm not mistaken? You'll have a hard time making sage work trying to use our distro packages. We can and should remove some of the libraries from the build process, especially readline. Taking everything apart and putting our distro stuff will probably not only break sage, but be a ton of work. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application: Jan Steffens
Am 19.04.2010 08:27, schrieb Daniel J Griffiths (Ghost1227): Since then, I went through quite a few distributions: SuSE, Mandrake, Fedora, Ubuntu, Debian. Gentoo was the first distribution that got me interested in getting to know the internals a bit more. About a year ago, a fellow CS student introduced me to Arch. After I blew up my Fedora installation (accidentally wrote to /dev/root), I chose to give Arch a try. I got hooked. Its simplicity really makes it a joy to tinker with. :) Especially creating packages and offering them to others (AUR) is something Arch made easy. I currently run two Arch systems, one on my laptop and one on a headless box mainly acting as a router. Both are getting packages from [testing]. Arch is the first distribution I actually started contributing back to. I began frequenting the Archlinux channels on Freenode, now and then helping out others and asking my own questions. I reported bugs I found, and I uploaded and maintain 15 packages in the AUR [1]. I use Pulseaudio on my laptop: Some of my packages in the AUR center on it, and I gave the wiki page on Pulseaudio an overhaul. I'm interested in taking over maintenance of the pulseaudio packages in [community] and improve Pulseaudio on Arch Linux. A few days ago, I finally got up the nerve to write about my gripes with the gvim package and propose a solution [2]. I was overwhelmed with the positive response. Now Dan Griffiths approached me and offered to sponsor my application as a TU. Thank you, Dan. I hope I'm getting accepted as TU and we can work together on improving this great distribution. :-) Regards, Jan heftig Steffens 1: http://aur.archlinux.org/packages.php?SeB=mK=heftig 2: http://bugs.archlinux.org/task/19087 I'm happy to sponser Jan in his efforts to become a Trusted User! He has repeatedly shown an aptitude for helping users in IRC, and while he currently maintains only a few packages in AUR, those he does maintain are impeccable. He has expressed interest in maintaining the PulseAudio packages in [community] and given our recent losses, I would be happy to hand them off to him. Wasn't there a request for someone who would maintain audio packages in general (and pulseaudio-based stuff in particular) recently? signature.asc Description: OpenPGP digital signature
[aur-general] Orphaning hibernate-script
Its been a while since I actively maintained hibernate-script, and I don't use it anymore. I am orphaning it right now - if a dev or TU wants it, it's free for grabs. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU without [community] maintaining?
Am 03.02.2010 15:32, schrieb Lex Rivera: Hi all. I wanna ask is it possible to become TU without [community] maintaining, just as AUR moderator? I think it is a good idea. We could create the AUR moderator position instead of calling it Semi-TU. When I was a TU, I didn't care at all about moderating the AUR, and maybe other TUs feel the same and rather do packaging. Conversely, you don't seem to care about packaging but about AUR moderation. I am forwarding this to arch-dev-public for reference, but I guess ultimately the TUs have to decide. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU without [community] maintaining?
Am 03.02.2010 16:44, schrieb Angel Velásquez: On Wed, Feb 3, 2010 at 12:37 PM, Florian Friesdorf f...@chaoflow.net wrote: I'd give an AUR moderator all permissions to mess around in the AUR, be it packages of TUs or not. If somebody messes up, he/she can be punished later. Agreed. They should be responsible enough to not do any bullshit. Well, other question how will be the process of selection of these semi-tu ? Application, vote, done. It shouldn't be that complicated. how will be called the group semi-tu ? trusted but not at all? I'd simply say AUR Moderators. We have moderators on the forum, and on the wiki, so having them on the AUR makes sense - it is in fact a bit late, the AUR is too much anarchy for my taste. I'd suggest so start the process by just voting upon Lex and if (s)he (sorry, can't determine the sex from that name, my stupidity) is approved, one will see how it goes and if it's a good idea. Then one can think about adding more moderators or not. Just KISS. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU without [community] maintaining?
Am 03.02.2010 20:05, schrieb Lex Rivera: Lex/Alex/Alexander. Ah, he then :) Well, before we can set moderators, we must understand how that position will work from the code side. We can of course just grant access to orphan delete, if i understood correctly. IMO, just setting them as Trusted Users in the AUR interface would suffice, at least short-term. Creating an AUR moderator position long-term is still a possibility. signature.asc Description: OpenPGP digital signature
[aur-general] Module breakage (WAS: Re: [arch-dev-public] [signoff] kernel 2.6.32.3-1)
Am 08.01.2010 09:06, schrieb Tobias Powalowski: Hi guys, bump to latest bugfix version. Arch Linux bugfixes/feature requests: http://bugs.archlinux.org/task/17538 # added blktrace http://bugs.archlinux.org/task/17106 # finally added CONFIG_MMIOTRACE One of these changes broke aufs, a rebuild is necessary. At least virtualbox is also affected, maybe more. I am rebuilding aufs, please post if any other modules are affected. signature.asc Description: OpenPGP digital signature
[aur-general] rfkill package
I noticed that the rfkill package is in community now (very good). However, I have been asked if it was possible to make a few improvements: 1) Add a rfkill group (or use an existing group) and allow that group to write /dev/rfkill using udev (if we add a group, we should do that in the filesystem package, not the rfkill package). Apparently, some desktop applications would like to set the rfkill state, so this way we could allow that. 2) Add an init script that can optionally unblock wifi, bluetooth or anything else on boot. In the past, some devices were soft-blocked on boot by default (is this still an issue?), so this could be improved. Maybe we should even move this to extra or even core. Giovanni, this seems to be your package, what do you think? signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted User Application
Dieter Plaetinck schrieb: hey mate. cool to have you join the club. You're the first TU I actually know :) Yeah, same here ... except my former self. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Orphaning selinux and xen
helios schrieb: Hi. currently I am maintaining the Xen-Dom0-kernel and the Xen-HV-tools-package in AUR and therefor it would be no problem to maintain the Xen-Package in AUR, but I am not a TU. Out of curiosity, what is your Xen dom0 based on? Is it using forward-ported Xensource or the new experimental pv_ops-based code? signature.asc Description: OpenPGP digital signature
Re: [aur-general] script to check a binary package for architecture-independence
Chris Brannon schrieb: Gerardo Exequiel Pozzi wrote: Hello There is no attach here. The script is here: http://the-brannons.com/isanypkg The attachment must have been scrubbed. Plus, gmail doesn't give me copies of mail that I send to the list. Broken, broken gmail! [2] Should also check the machine (sufficient), because there are packages for example AVR and ARM that from point of view of -any are architecture-independence. (some crazy :P packages have SPARC ELFs) [3] And also (I din't see the script, so i just suppose), you also need to exactarc archives files (.a) and analize the content of each object Thanks so much for your insight! Your guess was right; I forgot about members of ar archives. On second thought, I wonder if these sorts of checks should be done within namcap? They should. Two checks: 1) Is an arch=any package architecture-dependent - error 2) Is an arch=whatever package architecture-independent - warning If you know python and have the time, you should write a patch against namcap.git and mail it to Hugo. I told him once that it's a good feature, no idea if he got to it. You can check namcap.git to see if he did something, and check the bugtracker if there is a feature request already. Yay, I just looked at the script and it is in python already, so I guess a patch for namcap is in order :) signature.asc Description: OpenPGP digital signature
Re: [aur-general] overriding architecture in split packages
Xyne schrieb: I'm (sort of) cross-posting but I'm hoping to get a quick answer so I can start this huge upload: http://bbs.archlinux.org/viewtopic.php?id=81143 Right now, neither dbscripts nor makepkg support this, so you should go with a separate PKGBUILD. signature.asc Description: OpenPGP digital signature
[aur-general] Enable ACLs on sigurd
Can someone who is all-powerful please run: mount -o remount,acl / and add the acl option to the appropriate line in /etc/fstab? I noticed that I couldn't set ACLs on sigurd this morning, and it would come in very handy sometimes. signature.asc Description: OpenPGP digital signature
Re: [aur-general] About AUR Translation zh_CN
Mod_Gao schrieb: actually i made a complete translation at 2008 but i am not submitted, i want to do a LAMP and do some tests for my translation but i got failures on LAMP, so i disappointed..and i could not found it today(maybe on my DVD+R). Most of us can't even read the signs, let alone understand it, so we cannot verify it. If you think you have a correct and complete installation, just submit it. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Recommended Encoding for PKGBUILDS?
Xavier schrieb: This is web server (lighttpd) setting again. It's possible to specify that files with .diff or .patch extension are actually of type text/plain and not application/octet-stream , but this was not done. I am not sure what you can do on the client / web browser side. Nothing really. The correct MIME type must be set on the server. There is a section for website problems on the tracker, maybe that should be posted there. signature.asc Description: OpenPGP digital signature
[aur-general] The [community-testing] repository
I think this has been requested and discussed a few times and I talked to several people about it, so I want to outline my ideas here: When moving the community db scripts to the new svn-based scripts, a community-testing repository should be created. With the new scripts, handling this is incredibly easy. And here is why: Rebuild sprees. We have the problem now with readline: libreadline.so.6 is in testing and community packages are built against .so.5. [testing] users cannot use everything from [community] and once we move everything to core and extra, it takes too much time for [community] to catch up. The [community-testing] repository will solve that: While the dev team does rebuilds in [testing], the TUs do the same in [community-testing]. When everything is done, a developer can move the core/extra and community packages simultaneously. This is not only useful for SONAME bumps, but also for kernel updates (there's a few kernel modules in [community]). I suggest this should be set up as soon as [community] is moved to SVN-based scripts, as the upcoming libjpeg rebuilds will break too many packages and we need to rebuild not only the [extra] but also the [community] packages in time. That's how I see it, opinions? signature.asc Description: OpenPGP digital signature
Re: [aur-general] Packages with libpcap dependency need a rebuild
Thomas Bächler schrieb: Soon (today or tomorrow), libpcap 1.0.0 will move to core. All community packages depending on libpcap will need a rebuild (iftop is among them, no idea if there are more). The rebuilds probably won't be necessary for each version anymore, as the libpcap.so has no a sane SONAME (.so.1) instead of having the whole version (including the minor) as SONAME. It took longer than I thought, but libpcap 1.0.0 is now in core! signature.asc Description: OpenPGP digital signature
[aur-general] Packages with libpcap dependency need a rebuild
Soon (today or tomorrow), libpcap 1.0.0 will move to core. All community packages depending on libpcap will need a rebuild (iftop is among them, no idea if there are more). The rebuilds probably won't be necessary for each version anymore, as the libpcap.so has no a sane SONAME (.so.1) instead of having the whole version (including the minor) as SONAME. signature.asc Description: OpenPGP digital signature
