Re: [aur-general] delete request - pidgin-msn
On Thu, Sep 1, 2011 at 6:40 AM, jwbirdsong jwbirds...@jwbirdsong.homelinux.com wrote: Along these same lines we should delete pigdin-light-msngroup (1) Removed, thanks.
Re: [aur-general] TU Resignation
On 31.08.2011 03:11, Loui Chang wrote: It was a pleasure to work with you folks. See you around! Thanks for your work and good luck. -- Florian Pritz signature.asc Description: OpenPGP digital signature
[aur-general] Delete firefox-extension-firebug-stable
As discussed in a previous forgotten thread [1] consider to remove, again firefox-extension-firebug-stable [2], replaced by a simpler firefox-firebug [3], updated to work with latest ff 6.0.1 Votes could be merged. The main reason is a better naming consistency, since firefox-extension-firebug-stable makes little sense and other extensions in [community] follows the same convention (firefox-adblock-plus, firefox-noscript). firefox-extension-firebug-svn [4] can be also, probably, deleted (unmaintained, latest update on 2008) [1] http://mailman.archlinux.org/pipermail/aur-general/2011-August/015462.html Thomas S Hatch, who preferred to keep the old one, did not answer any more, maybe away [2] https://aur.archlinux.org/packages.php?ID=44809 [3] https://aur.archlinux.org/packages.php?ID=52050 [4] https://aur.archlinux.org/packages.php?ID=17554 P.S. I opted for a new thread since is September 1 here Tnx - speps -
Re: [aur-general] Deletion Request
Am 31.08.2011 19:49, schrieb speps: Hi, some stuff to delete here [ 1] fftw-thread https://aur.archlinux.org/packages.php?ID=30594 [ 2] csound5 https://aur.archlinux.org/packages.php?ID=7600 [ 3] csound5-cecilia https://aur.archlinux.org/packages.php?ID=44816 [ 4] csound5-cvs https://aur.archlinux.org/packages.php?ID=34149 [ 5] csound5.12-cvs https://aur.archlinux.org/packages.php?ID=38899 [ 6] gsharkdown-lite https://aur.archlinux.org/packages.php?ID=51528 [ 7] ramen https://aur.archlinux.org/packages.php?ID=49423 [ 8] ramen-svn https://aur.archlinux.org/packages.php?ID=35229 [ 9] ramen-bin https://aur.archlinux.org/packages.php?ID=39617 [10] ramenhdr https://aur.archlinux.org/packages.php?ID=35308 [ 1] fftw in [extra] has threads support too [ 2] csound version 5 is provided by csound on AUR [ 3] csound5-cecilia is a build with options suggested by cecilia4 devs, useless since it works fine with csound too [ 4] [ 5] csound VCS switched to git [ 6] gsharkdown-lite, replaced by gsharkdown [ 7] to [10] source or binary repo is not available anymore, btw there is a new development uploaded as ramen-bin64, 64 binary only, no source yet nor repository and not sure if will be one. Thanks - speps - removed, thanks
Re: [aur-general] cinelerra-transitions
Am 31.08.2011 17:25, schrieb Cédric Girard: cinelerra-transitions [1] is orphaned. Its original maintainer was the upstream owner. The source and website is dead. As it claims to be Transitions for cinelerra mostly from akirad and OpenShot, I've uploaded a PKGBUILD cinelerra-swtc [2] containing the akirad transitions. I think cinelerra-transitions should be deleted as it is no more usable. I don't know if it makes sense to merge votes with cinelerra-swtc as it is only a subset of cinelerra-transitions. [1] https://aur.archlinux.org/packages.php?ID=38137 [2] https://aur.archlinux.org/packages.php?ID=52037 removed [1]
Re: [aur-general] Deletion Request
On Thu, 01 Sep 2011 11:04:38 +0200 Stefan Husmann stefan-husm...@t-online.de wrote: Am 31.08.2011 19:49, schrieb speps: Hi, some stuff to delete here [ 1] fftw-thread https://aur.archlinux.org/packages.php?ID=30594 [ 2] csound5 https://aur.archlinux.org/packages.php?ID=7600 [ 3] csound5-cecilia https://aur.archlinux.org/packages.php?ID=44816 [ 4] csound5-cvs https://aur.archlinux.org/packages.php?ID=34149 [ 5] csound5.12-cvs https://aur.archlinux.org/packages.php?ID=38899 [ 6] gsharkdown-lite https://aur.archlinux.org/packages.php?ID=51528 [ 7] ramen https://aur.archlinux.org/packages.php?ID=49423 [ 8] ramen-svn https://aur.archlinux.org/packages.php?ID=35229 [ 9] ramen-bin https://aur.archlinux.org/packages.php?ID=39617 [10] ramenhdr https://aur.archlinux.org/packages.php?ID=35308 [ 1] fftw in [extra] has threads support too [ 2] csound version 5 is provided by csound on AUR [ 3] csound5-cecilia is a build with options suggested by cecilia4 devs, useless since it works fine with csound too [ 4] [ 5] csound VCS switched to git [ 6] gsharkdown-lite, replaced by gsharkdown [ 7] to [10] source or binary repo is not available anymore, btw there is a new development uploaded as ramen-bin64, 64 binary only, no source yet nor repository and not sure if will be one. Thanks - speps - removed, thanks Tnx, btw is there a reason you deleted ramen-bin64, too? As I pointed before, that is the only official resource still active of the ramen project (only 64 bit binary at the moment). Take a look here: http://ramencomp.blogspot.com/2011/05/download-ramen.html If you have no objections, I can re-upload the build script again. - speps -
Re: [aur-general] cinelerra-transitions
On Thu, Sep 1, 2011 at 11:06 AM, Stefan Husmann stefan-husm...@t-online.dewrote: removed [1] Thanks. -- Cédric Girard
[aur-general] VCS Packages
*Dead repo due to dead project. I can't find any mirrors:* qutim-protocol-icq-git (https://aur.archlinux.org/packages.php?ID=33004). ICQ support is now built into qutim anyway (http://qutim.org/) omvviewer-artwork-git (https://aur.archlinux.org/packages.php?ID=24456). It is now built into omvviewer anyway ( http://git.byteme.org.uk/cgi-bin/gitweb.cgi?p=snowglobe.git;a=summary) bash-view-git (https://aur.archlinux.org/packages.php?ID=34592) *Repo has moved:* mcabber-module-ping-git (https://aur.archlinux.org/packages.php?ID=31820) had moved to mercurial but is now included in mcabber-hg ( https://aur.archlinux.org/packages.php?ID=26873) anyway All mcabber-module-*-git packages have moved to mercurial. Some may also be built into mcabber-hg now as well. pastebin-cli-git (https://aur.archlinux.org/packages.php?ID=46621) now uses svn. pastebin-cli-svn does not yet exist so I've left a comment on the package. thunar-actions-plugin-git (https://aur.archlinux.org/packages.php?ID=30184) now uses svn. thunar-actions-plugin-svn does not yet exist. lingo-dictionary-git (https://aur.archlinux.org/packages.php?ID=49590) now uses bzr and has been replaced by lingo-dictionary-bzr ( https://aur.archlinux.org/packages.php?ID=49764) python-commons-git (https://aur.archlinux.org/packages.php?ID=47324) now uses svn. python-commons-svn does not exist yet. *Unmaintained repos:* eee-control-git (https://aur.archlinux.org/packages.php?ID=25437). The PKGBUILD uses a dead repo but there is a mirror here ( https://github.com/amorozov/eee-control), though upstream hasn't been updated since 2009 (Is this long enough to wait before considering it as unmaintained?). No votes or maintainer. eee-control ( https://aur.archlinux.org/packages.php?ID=22076) still exists. *Other requests:* caw (https://aur.archlinux.org/packages.php?ID=28856) is the same as caw-git (https://aur.archlinux.org/packages.php?ID=29425). Upstream is no longer in development. Gadget3000
Re: [aur-general] Securing the AUR website
Excerpts from Lukas Fleischer's message of 2011-08-06 12:14:14 +0200: On Sat, Aug 06, 2011 at 11:10:48AM +0200, Pierre Schmitz wrote: On Sat, 6 Aug 2011 02:29:13 +0200, Lukas Fleischer wrote: Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway. I didn't tell to disable HTTP. Of course you add a redirect there and you might even add the HSTS header. It's not only about links, also people will just typoe in aur.archlinux.org into their browser bar and that will open http by default. Well, Redirect all http traffic to https by default sounded to me like disabling plain HTTP. Perhaps I took this too literally. Anyway, I see I am talking to walls here. Sometimes I wonder why there is so much resistance against encryption. One would think it was the other way round. Again, and I'm not going to repeat this... I am not against enabling encryption and I am not against making it the default. All I said is that we shouldn't turn down HTTP. I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults: 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. Best regards, Philipp
Re: [aur-general] Securing the AUR website
On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote: Excerpts from Lukas Fleischer's message of 2011-08-06 12:14:14 +0200: On Sat, Aug 06, 2011 at 11:10:48AM +0200, Pierre Schmitz wrote: On Sat, 6 Aug 2011 02:29:13 +0200, Lukas Fleischer wrote: Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway. I didn't tell to disable HTTP. Of course you add a redirect there and you might even add the HSTS header. It's not only about links, also people will just typoe in aur.archlinux.org into their browser bar and that will open http by default. Well, Redirect all http traffic to https by default sounded to me like disabling plain HTTP. Perhaps I took this too literally. Anyway, I see I am talking to walls here. Sometimes I wonder why there is so much resistance against encryption. One would think it was the other way round. Again, and I'm not going to repeat this... I am not against enabling encryption and I am not against making it the default. All I said is that we shouldn't turn down HTTP. I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults: 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.
Re: [aur-general] Securing the AUR website
Excerpts from Lukas Fleischer's message of 2011-09-01 12:32:03 +0200: On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote: Excerpts from Lukas Fleischer's message of 2011-08-06 12:14:14 +0200: On Sat, Aug 06, 2011 at 11:10:48AM +0200, Pierre Schmitz wrote: On Sat, 6 Aug 2011 02:29:13 +0200, Lukas Fleischer wrote: Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway. I didn't tell to disable HTTP. Of course you add a redirect there and you might even add the HSTS header. It's not only about links, also people will just typoe in aur.archlinux.org into their browser bar and that will open http by default. Well, Redirect all http traffic to https by default sounded to me like disabling plain HTTP. Perhaps I took this too literally. Anyway, I see I am talking to walls here. Sometimes I wonder why there is so much resistance against encryption. One would think it was the other way round. Again, and I'm not going to repeat this... I am not against enabling encryption and I am not against making it the default. All I said is that we shouldn't turn down HTTP. I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults: 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. Regards, Philipp
Re: [aur-general] Securing the AUR website
On 01/09/11 11:51, Philipp Überbacher wrote: Excerpts from Lukas Fleischer's message of 2011-09-01 12:32:03 +0200: On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote: Excerpts from Lukas Fleischer's message of 2011-08-06 12:14:14 +0200: On Sat, Aug 06, 2011 at 11:10:48AM +0200, Pierre Schmitz wrote: On Sat, 6 Aug 2011 02:29:13 +0200, Lukas Fleischer wrote: Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway. I didn't tell to disable HTTP. Of course you add a redirect there and you might even add the HSTS header. It's not only about links, also people will just typoe in aur.archlinux.org into their browser bar and that will open http by default. Well, Redirect all http traffic to https by default sounded to me like disabling plain HTTP. Perhaps I took this too literally. Anyway, I see I am talking to walls here. Sometimes I wonder why there is so much resistance against encryption. One would think it was the other way round. Again, and I'm not going to repeat this... I am not against enabling encryption and I am not against making it the default. All I said is that we shouldn't turn down HTTP. I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults: 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. Regards, Philipp When I visit aur.archlinux.org I get the https version (chromium). Try to clean your firefox cache...
Re: [aur-general] Securing the AUR website
On Thu, Sep 01, 2011 at 12:51:24PM +0200, Philipp Überbacher wrote: Excerpts from Lukas Fleischer's message of 2011-09-01 12:32:03 +0200: On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote: [...] I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults: 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.
Re: [aur-general] Securing the AUR website
On 01/09/11 12:01, Lukas Fleischer wrote: On Thu, Sep 01, 2011 at 12:51:24PM +0200, Philipp Überbacher wrote: Excerpts from Lukas Fleischer's message of 2011-09-01 12:32:03 +0200: On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote: [...] I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults: 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. There's an option if firefox that should use https under Advanced Encryption tab in Preferences, if I remember that correctly.
Re: [aur-general] Securing the AUR website
Excerpts from Lukas Fleischer's message of 2011-09-01 13:01:50 +0200: On Thu, Sep 01, 2011 at 12:51:24PM +0200, Philipp Überbacher wrote: Excerpts from Lukas Fleischer's message of 2011-09-01 12:32:03 +0200: On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote: [...] I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults: 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. So it's a firefox default to try http first and the other parts of the website redirect?
Re: [aur-general] Securing the AUR website
On 01/09/11 11:51, Philipp Überbacher wrote: Excerpts from Lukas Fleischer's message of 2011-09-01 12:32:03 +0200: On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote: Excerpts from Lukas Fleischer's message of 2011-08-06 12:14:14 +0200: On Sat, Aug 06, 2011 at 11:10:48AM +0200, Pierre Schmitz wrote: On Sat, 6 Aug 2011 02:29:13 +0200, Lukas Fleischer wrote: Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway. I didn't tell to disable HTTP. Of course you add a redirect there and you might even add the HSTS header. It's not only about links, also people will just typoe in aur.archlinux.org into their browser bar and that will open http by default. Well, Redirect all http traffic to https by default sounded to me like disabling plain HTTP. Perhaps I took this too literally. Anyway, I see I am talking to walls here. Sometimes I wonder why there is so much resistance against encryption. One would think it was the other way round. Again, and I'm not going to repeat this... I am not against enabling encryption and I am not against making it the default. All I said is that we shouldn't turn down HTTP. I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults: 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. Regards, Philipp This firefox extension works for me - HTTPS finder; https://addons.mozilla.org/en-us/firefox/addon/https-finder/
Re: [aur-general] Delete firefox-extension-firebug-stable
On 01.09.2011 11:02, speps wrote: As discussed in a previous forgotten thread [1] consider to remove, again firefox-extension-firebug-stable [2], replaced by a simpler firefox-firebug [3], updated to work with latest ff 6.0.1 Votes could be merged. done firefox-extension-firebug-svn [4] can be also, probably, deleted (unmaintained, latest update on 2008) removed [1] http://mailman.archlinux.org/pipermail/aur-general/2011-August/015462.html Thomas S Hatch, who preferred to keep the old one, did not answer any more, maybe away [2] https://aur.archlinux.org/packages.php?ID=44809 [3] https://aur.archlinux.org/packages.php?ID=52050 [4] https://aur.archlinux.org/packages.php?ID=17554 PS: CCing old maintainer -- Florian Pritz 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] VCS Packages
On 01.09.2011 12:07, gadget3000 wrote: *Dead repo due to dead project. I can't find any mirrors:* qutim-protocol-icq-git (https://aur.archlinux.org/packages.php?ID=33004). ICQ support is now built into qutim anyway (http://qutim.org/) removed omvviewer-artwork-git (https://aur.archlinux.org/packages.php?ID=24456). It is now built into omvviewer anyway ( http://git.byteme.org.uk/cgi-bin/gitweb.cgi?p=snowglobe.git;a=summary) removed bash-view-git (https://aur.archlinux.org/packages.php?ID=34592) removed *Repo has moved:* mcabber-module-ping-git (https://aur.archlinux.org/packages.php?ID=31820) had moved to mercurial but is now included in mcabber-hg ( https://aur.archlinux.org/packages.php?ID=26873) anyway removed All mcabber-module-*-git packages have moved to mercurial. Some may also be built into mcabber-hg now as well. pastebin-cli-git (https://aur.archlinux.org/packages.php?ID=46621) now uses svn. pastebin-cli-svn does not yet exist so I've left a comment on the package. thunar-actions-plugin-git (https://aur.archlinux.org/packages.php?ID=30184) now uses svn. thunar-actions-plugin-svn does not yet exist. python-commons-git (https://aur.archlinux.org/packages.php?ID=47324) now uses svn. python-commons-svn does not exist yet. Please create the new packages first so comments and votes can be merged. lingo-dictionary-git (https://aur.archlinux.org/packages.php?ID=49590) now uses bzr and has been replaced by lingo-dictionary-bzr ( https://aur.archlinux.org/packages.php?ID=49764) removed and merged *Unmaintained repos:* eee-control-git (https://aur.archlinux.org/packages.php?ID=25437). The PKGBUILD uses a dead repo but there is a mirror here ( https://github.com/amorozov/eee-control), though upstream hasn't been updated since 2009 (Is this long enough to wait before considering it as unmaintained?). No votes or maintainer. removed eee-control ( https://aur.archlinux.org/packages.php?ID=22076) still exists. *Other requests:* caw (https://aur.archlinux.org/packages.php?ID=28856) is the same as caw-git (https://aur.archlinux.org/packages.php?ID=29425). Upstream is no longer in development. caw removed. I'll keep caw-git in case someone finds a new repo. -- Florian Pritz signature.asc Description: OpenPGP digital signature
[aur-general] wtf? tcp_wrappers back in [community]?
Sergej, We spent a week rebuilding packages to get tcp_wrappers out of [core] and out of the repos. Now I see that you've moved it back into [community]. What the hell? Were you going to start recompiling packages against tcp_wrappers and adding it back as a dep? Not acceptable. We all made this decision as a team, so I'm not sure why you're trying to fight us. I'm db-remove'ing this (again) and putting it back where it belongs. Regards, Dave
Re: [aur-general] wtf? tcp_wrappers back in [community]?
Dave, we should not recompile anything. But it is usefull package with 24 votes which has many dependencies in AUR. It is just a way to make things easier for guys who want to use tcp_wrappers. I assume all developers build packages in chroots and it should not break anything even if some developer occasionaly install tcp_wrappers. At Thu, 1 Sep 2011 10:59:40 -0400, Dave Reisner d...@falconindy.com wrote: Sergej, We spent a week rebuilding packages to get tcp_wrappers out of [core] and out of the repos. Now I see that you've moved it back into [community]. What the hell? Were you going to start recompiling packages against tcp_wrappers and adding it back as a dep? Not acceptable. We all made this decision as a team, so I'm not sure why you're trying to fight us. I'm db-remove'ing this (again) and putting it back where it belongs. Regards, Dave
Re: [aur-general] wtf? tcp_wrappers back in [community]?
On Thu, Sep 1, 2011 at 6:05 PM, Sergej Pupykin m...@sergej.pp.ru wrote: we should not recompile anything. But it is usefull package with 24 votes which has many dependencies in AUR. It is just a way to make things easier for guys who want to use tcp_wrappers. I'm sure that whoever wants to use tcp_wrappers, and therefore is willing to recompile all the services that support it on every update, won't mind building one more package. I'd say we keep it out of the binary repos. :)
[aur-general] delete grub-legacy-gfx
Hi, Please remove grub-legacy-gfx https://aur.archlinux.org/packages.php?ID=50986 . I initially uploaded it as a replacament for grub-gfx https://aur.archlinux.org/packages.php?ID=2416 but now its just a duplicate of grub-gfx. TIA. Regards. Keshav
Re: [aur-general] delete grub-legacy-gfx
On 1 September 2011 17:22, KESHAV P.R. skodab...@gmail.com wrote: Hi, Please remove grub-legacy-gfx https://aur.archlinux.org/packages.php?ID=50986 . I initially uploaded it as a replacament for grub-gfx https://aur.archlinux.org/packages.php?ID=2416 but now its just a duplicate of grub-gfx. TIA. Regards. Keshav Done. I also merged votes/comments into grub-gfx (mostly because I wanted to try this feature).
Re: [aur-general] Securing the AUR website
Excerpts from Thomas Bächler's message of 2011-09-01 14:16:20 +0200: 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/ Do I understand it correctly that https-everywhere goes through a lot of trouble (browser-plugin with whitelist and custom rules for every page) for what could be achieved by simply defaulting to https?
Re: [aur-general] Securing the AUR website
On Thu, Sep 1, 2011 at 5:55 PM, Philipp Überbacher hollun...@lavabit.comwrote: Do I understand it correctly that https-everywhere goes through a lot of trouble (browser-plugin with whitelist and custom rules for every page) for what could be achieved by simply defaulting to https? The rules are included with the plugin and you benefit from its functionalities with a lot of other sites. But I do have installed this plugin because of the AUR. -- Cédric Girard
Re: [aur-general] Securing the AUR website
Excerpts from Cédric Girard's message of 2011-09-01 18:05:36 +0200: On Thu, Sep 1, 2011 at 5:55 PM, Philipp Überbacher hollun...@lavabit.comwrote: Do I understand it correctly that https-everywhere goes through a lot of trouble (browser-plugin with whitelist and custom rules for every page) for what could be achieved by simply defaulting to https? The rules are included with the plugin and you benefit from its functionalities with a lot of other sites. But I do have installed this plugin because of the AUR. I've installed it now and it works fine, thanks for the tip. What I wonder is whether it's worth the trouble to register the site, maintain the rules and have users install a plugin. I'm also sceptical because this is an opt-in solution for a security feature, which means that a lot of users won't benefit. Thanks, Philipp
Re: [aur-general] wtf? tcp_wrappers back in [community]?
On Thu, Sep 01, 2011 at 07:05:01PM +0400, Sergej Pupykin wrote: Dave, we should not recompile anything. But it is usefull package with 24 votes which has many dependencies in AUR. It is just a way to make things easier for guys who want to use tcp_wrappers. I assume all developers build packages in chroots and it should not break anything even if some developer occasionaly install tcp_wrappers. There are packages that we don't want in the binary repos, even if they have a lot of votes. awesome [1] is another good example. It has almost 400 votes but uses cairo-xcb which is broken. We decided to remove tcp_wrappers. -1 to moving it back to [community].
Re: [aur-general] wtf? tcp_wrappers back in [community]?
On 09/01/2011 07:52 PM, Lukas Fleischer wrote: On Thu, Sep 01, 2011 at 07:05:01PM +0400, Sergej Pupykin wrote: Dave, we should not recompile anything. But it is usefull package with 24 votes which has many dependencies in AUR. It is just a way to make things easier for guys who want to use tcp_wrappers. I assume all developers build packages in chroots and it should not break anything even if some developer occasionaly install tcp_wrappers. There are packages that we don't want in the binary repos, even if they have a lot of votes. awesome [1] is another good example. It has almost 400 votes but uses cairo-xcb which is broken. dude wtf, don't give him ideas! We decided to remove tcp_wrappers. -1 to moving it back to [community]. -- Ionuț
Re: [aur-general] Securing the AUR website
On Thu, 01 Sep 2011 17:55:57 +0200 Philipp Überbacher hollun...@lavabit.com wrote: Do I understand it correctly that https-everywhere goes through a lot of trouble (browser-plugin with whitelist and custom rules for every page) for what could be achieved by simply defaulting to https? I don't really understand why it's so important to break existing links by forcing everyone onto the https page. What happens if you *don't want to use https*? Why are the Arch webby bods forcing this nanny-state twatmuppetry down our throats? -- Gordon JC Pearce MM0YEQ gordon...@gjcp.net
Re: [aur-general] Securing the AUR website
On Thu, Sep 1, 2011 at 8:15 PM, Gordon JC Pearce gordon...@gjcp.net wrote: I don't really understand why it's so important to break existing links by forcing everyone onto the https page. And what in rewriting http://aur.archlinux.org/foo into https://aur.archlinux.org/foo is breaking links ? What happens if you *don't want to use https*? I still have difficulties to understand why people would like to purposely avoid using https. Do you ask the admin of the server you have to connect to, to enable rlogin to be able to connect to there server insecurely as well ? -- Cédric Girard
Re: [aur-general] Securing the AUR website
Excerpts from Gordon JC Pearce's message of 2011-09-01 20:15:28 +0200: On Thu, 01 Sep 2011 17:55:57 +0200 Philipp Überbacher hollun...@lavabit.com wrote: Do I understand it correctly that https-everywhere goes through a lot of trouble (browser-plugin with whitelist and custom rules for every page) for what could be achieved by simply defaulting to https? I don't really understand why it's so important to break existing links by forcing everyone onto the https page. What happens if you *don't want to use https*? Why are the Arch webby bods forcing this nanny-state twatmuppetry down our throats? It shouldn't be enforced, it should be the default. But you're right, it seems it is enforced in some cases, with the redirect on bugs.archlinux.org for example. In this case the login is on the main page, which is probably the reason for the redirect. It's really somewhat confusing, in the meantime I start to think that optimally both would be available and the browser settings should be the place to decide (in general).
Re: [aur-general] VCS Packages
*Dead repo due to dead project. I can't find any mirrors:* evil-poison-git (https://aur.archlinux.org/packages.php?ID=27852) qutim-protocol-mrim-git (https://aur.archlinux.org/packages.php?ID=33005). Unsure if mrim is built into qutim now or not. axkb-git (https://aur.archlinux.org/packages.php?ID=25243). axkb still exists (https://aur.archlinux.org/packages.php?ID=2). *Repo has moved:* phinix-svn (https://aur.archlinux.org/packages.php?ID=24168) was replaced by phinix-git (https://aur.archlinux.org/packages.php?ID=48443). phinix-git's repo died, but only between April and now so another git repo may pop up soon. tinyos-git (https://aur.archlinux.org/packages.php?ID=35948) has been replaced by tinyos-svn (https://aur.archlinux.org/packages.php?ID=46714) *Unmaintained repos:* *Other requests:* 3dslicer-git (https://aur.archlinux.org/packages.php?ID=45280) has been replaced by 3dslicer-svn (https://aur.archlinux.org/packages.php?ID=45301) *(Just for reference). Repo has moved. Needs a replacement package before merging/deletion:* All mcabber-module-*-git packages have moved to mercurial. Some may also be built into mcabber-hg now as well. pastebin-cli-git (https://aur.archlinux.org/packages.php?ID=46621) now uses svn. thunar-actions-plugin-git (https://aur.archlinux.org/packages.php?ID=30184) now uses svn. python-commons-git (https://aur.archlinux.org/packages.php?ID=47324) now uses svn. thrift-git (https://aur.archlinux.org/packages.php?ID=17977) now uses svn. phinix-git (https://aur.archlinux.org/packages.php?ID=48443). Dead repo. I can't find a mirror but the repo died only between April and now so another may pop up soon. Gadget3000 P.S. Thanks for processing the others, Florian. On 1 September 2011 13:22, Florian Pritz bluew...@xinu.at wrote: On 01.09.2011 12:07, gadget3000 wrote: *Dead repo due to dead project. I can't find any mirrors:* qutim-protocol-icq-git (https://aur.archlinux.org/packages.php?ID=33004 ). ICQ support is now built into qutim anyway (http://qutim.org/) removed omvviewer-artwork-git (https://aur.archlinux.org/packages.php?ID=24456). It is now built into omvviewer anyway ( http://git.byteme.org.uk/cgi-bin/gitweb.cgi?p=snowglobe.git;a=summary) removed bash-view-git (https://aur.archlinux.org/packages.php?ID=34592) removed *Repo has moved:* mcabber-module-ping-git (https://aur.archlinux.org/packages.php?ID=31820 ) had moved to mercurial but is now included in mcabber-hg ( https://aur.archlinux.org/packages.php?ID=26873) anyway removed All mcabber-module-*-git packages have moved to mercurial. Some may also be built into mcabber-hg now as well. pastebin-cli-git (https://aur.archlinux.org/packages.php?ID=46621) now uses svn. pastebin-cli-svn does not yet exist so I've left a comment on the package. thunar-actions-plugin-git ( https://aur.archlinux.org/packages.php?ID=30184) now uses svn. thunar-actions-plugin-svn does not yet exist. python-commons-git (https://aur.archlinux.org/packages.php?ID=47324) now uses svn. python-commons-svn does not exist yet. Please create the new packages first so comments and votes can be merged. lingo-dictionary-git (https://aur.archlinux.org/packages.php?ID=49590) now uses bzr and has been replaced by lingo-dictionary-bzr ( https://aur.archlinux.org/packages.php?ID=49764) removed and merged *Unmaintained repos:* eee-control-git (https://aur.archlinux.org/packages.php?ID=25437). The PKGBUILD uses a dead repo but there is a mirror here ( https://github.com/amorozov/eee-control), though upstream hasn't been updated since 2009 (Is this long enough to wait before considering it as unmaintained?). No votes or maintainer. removed eee-control ( https://aur.archlinux.org/packages.php?ID=22076) still exists. *Other requests:* caw (https://aur.archlinux.org/packages.php?ID=28856) is the same as caw-git (https://aur.archlinux.org/packages.php?ID=29425). Upstream is no longer in development. caw removed. I'll keep caw-git in case someone finds a new repo. -- Florian Pritz
Re: [aur-general] wtf? tcp_wrappers back in [community]?
On 1 September 2011 17:05, Sergej Pupykin m...@sergej.pp.ru wrote: Dave, we should not recompile anything. But it is usefull package with 24 votes which has many dependencies in AUR. It is just a way to make things easier for guys who want to use tcp_wrappers. I assume all developers build packages in chroots and it should not break anything even if some developer occasionaly install tcp_wrappers. And tomorrow we'll get some Feature Request with the title Build X with tcp_wrappers support - Just add it to depends array. -1. Bring it to AUR! -- Andrea
Re: [aur-general] VCS Packages
On Thu, Sep 1, 2011 at 3:27 PM, gadget3000 gadget3...@msn.com wrote: *Dead repo due to dead project. I can't find any mirrors:* evil-poison-git (https://aur.archlinux.org/packages.php?ID=27852) removed qutim-protocol-mrim-git (https://aur.archlinux.org/packages.php?ID=33005). didn't remove because I don't know if mrim is built into qutim either, maybe another tu knows? Unsure if mrim is built into qutim now or not. axkb-git (https://aur.archlinux.org/packages.php?ID=25243). axkb still exists (https://aur.archlinux.org/packages.php?ID=2). removed axkb-git *Repo has moved:* phinix-svn (https://aur.archlinux.org/packages.php?ID=24168) was replaced by phinix-git (https://aur.archlinux.org/packages.php?ID=48443). phinix-git's repo died, but only between April and now so another git repo may pop up soon. removed phinix-svn tinyos-git (https://aur.archlinux.org/packages.php?ID=35948) has been replaced by tinyos-svn (https://aur.archlinux.org/packages.php?ID=46714) removed tinyos-git *Unmaintained repos:* *Other requests:* 3dslicer-git (https://aur.archlinux.org/packages.php?ID=45280) has been replaced by 3dslicer-svn (https://aur.archlinux.org/packages.php?ID=45301) removed 3dslicer-git *(Just for reference). Repo has moved. Needs a replacement package before merging/deletion:* All mcabber-module-*-git packages have moved to mercurial. Some may also be built into mcabber-hg now as well. pastebin-cli-git (https://aur.archlinux.org/packages.php?ID=46621) now uses svn. thunar-actions-plugin-git (https://aur.archlinux.org/packages.php?ID=30184 ) now uses svn. python-commons-git (https://aur.archlinux.org/packages.php?ID=47324) now uses svn. thrift-git (https://aur.archlinux.org/packages.php?ID=17977) now uses svn. phinix-git (https://aur.archlinux.org/packages.php?ID=48443). Dead repo. I can't find a mirror but the repo died only between April and now so another may pop up soon. Will delete as soon as new packages arrive. Thanks! Gadget3000 P.S. Thanks for processing the others, Florian. On 1 September 2011 13:22, Florian Pritz bluew...@xinu.at wrote: On 01.09.2011 12:07, gadget3000 wrote: *Dead repo due to dead project. I can't find any mirrors:* qutim-protocol-icq-git ( https://aur.archlinux.org/packages.php?ID=33004 ). ICQ support is now built into qutim anyway (http://qutim.org/) removed omvviewer-artwork-git (https://aur.archlinux.org/packages.php?ID=24456 ). It is now built into omvviewer anyway ( http://git.byteme.org.uk/cgi-bin/gitweb.cgi?p=snowglobe.git;a=summary) removed bash-view-git (https://aur.archlinux.org/packages.php?ID=34592) removed *Repo has moved:* mcabber-module-ping-git ( https://aur.archlinux.org/packages.php?ID=31820 ) had moved to mercurial but is now included in mcabber-hg ( https://aur.archlinux.org/packages.php?ID=26873) anyway removed All mcabber-module-*-git packages have moved to mercurial. Some may also be built into mcabber-hg now as well. pastebin-cli-git (https://aur.archlinux.org/packages.php?ID=46621) now uses svn. pastebin-cli-svn does not yet exist so I've left a comment on the package. thunar-actions-plugin-git ( https://aur.archlinux.org/packages.php?ID=30184) now uses svn. thunar-actions-plugin-svn does not yet exist. python-commons-git (https://aur.archlinux.org/packages.php?ID=47324) now uses svn. python-commons-svn does not exist yet. Please create the new packages first so comments and votes can be merged. lingo-dictionary-git (https://aur.archlinux.org/packages.php?ID=49590) now uses bzr and has been replaced by lingo-dictionary-bzr ( https://aur.archlinux.org/packages.php?ID=49764) removed and merged *Unmaintained repos:* eee-control-git (https://aur.archlinux.org/packages.php?ID=25437). The PKGBUILD uses a dead repo but there is a mirror here ( https://github.com/amorozov/eee-control), though upstream hasn't been updated since 2009 (Is this long enough to wait before considering it as unmaintained?). No votes or maintainer. removed eee-control ( https://aur.archlinux.org/packages.php?ID=22076) still exists. *Other requests:* caw (https://aur.archlinux.org/packages.php?ID=28856) is the same as caw-git (https://aur.archlinux.org/packages.php?ID=29425). Upstream is no longer in development. caw removed. I'll keep caw-git in case someone finds a new repo. -- Florian Pritz
Re: [aur-general] wtf? tcp_wrappers back in [community]?
On 02.09.2011 00:48, Andrea Scarpino wrote: And tomorrow we'll get some Feature Request with the title Build X with tcp_wrappers support - Just add it to depends array. Sure. I moved it to community with 24 votes. Return it back with resetting vote counter to zero. Now it has 55 votes. Flashmob? :)
Re: [aur-general] Securing the AUR website
2011/9/1 Philipp Überbacher hollun...@lavabit.com: Excerpts from Gordon JC Pearce's message of 2011-09-01 20:15:28 +0200: On Thu, 01 Sep 2011 17:55:57 +0200 Philipp Überbacher hollun...@lavabit.com wrote: Do I understand it correctly that https-everywhere goes through a lot of trouble (browser-plugin with whitelist and custom rules for every page) for what could be achieved by simply defaulting to https? I don't really understand why it's so important to break existing links by forcing everyone onto the https page. What happens if you *don't want to use https*? Why are the Arch webby bods forcing this nanny-state twatmuppetry down our throats? It shouldn't be enforced, it should be the default. But you're right, it seems it is enforced in some cases, with the redirect on bugs.archlinux.org for example. In this case the login is on the main page, which is probably the reason for the redirect. It's really somewhat confusing, in the meantime I start to think that optimally both would be available and the browser settings should be the place to decide (in general). I normally look for AUR packages in my google search engine, in case I'm not already in AUR interface. Since https is the default login, google search find the http interface. That's not much bad, but if I want to login after that, I can't just mouse-click the new http login disabled message. IMHO, it would be nice to have a URL in front of this warning that forwards to https in the same page you are at the moment, instead of going to AUR Home. Example: http://aur.archlinux.org/packages.php?ID=41362 # goes to https://aur.archlinux.org/packages.php?ID=41362 -- Rafael
Re: [aur-general] Securing the AUR website
Am Thu, 1 Sep 2011 19:57:51 -0300 schrieb rafael ff1 rafael.f...@gmail.com: I normally look for AUR packages in my google search engine, in case I'm not already in AUR interface. Since https is the default login, google search find the http interface. That's not much bad, but if I want to login after that, I can't just mouse-click the new http login disabled message. IMHO, it would be nice to have a URL in front of this warning that forwards to https in the same page you are at the moment, instead of going to AUR Home. Example: http://aur.archlinux.org/packages.php?ID=41362 # goes to https://aur.archlinux.org/packages.php?ID=41362 There's already a feature request for this: https://bugs.archlinux.org/task/25757?project=2 Heiko
