[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 4 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 9 fully signed off packages * 104 packages missing signoffs * 0 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (4 total) == * kdevelop-python-1.6.1-1 (i686) * swig-3.0.0-1 (i686) * kdevelop-python-1.6.1-1 (x86_64) * swig-3.0.0-1 (x86_64) == Incomplete signoffs for [core] (4 total) == * linux-firmware-20140316.dec41bc-1 (any) 0/2 signoffs * bash-4.3-3 (i686) 0/1 signoffs * bash-4.3-3 (x86_64) 0/2 signoffs * linux-3.13.6-2 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (100 total) == * accerciser-3.8.2-2 (any) 0/2 signoffs * django-1.6.2-2 (any) 0/2 signoffs * eric-5.4.2-2 (any) 0/2 signoffs * namcap-3.2.5-2 (any) 0/2 signoffs * orca-3.10.2-2 (any) 0/2 signoffs * pyatspi-2.10.0-2 (any) 0/2 signoffs * pylint-1.1.0-3 (any) 0/2 signoffs * pyopengl-3.0.2-6 (any) 0/2 signoffs * pyopenssl-0.14-3 (any) 0/2 signoffs * python-astroid-1.0.1-3 (any) 0/2 signoffs * python-beaker-1.6.4-2 (any) 0/2 signoffs * python-chardet-2.2.1-2 (any) 0/2 signoffs * python-cssselect-0.9.1-2 (any) 0/2 signoffs * python-feedparser-5.1.3-3 (any) 0/2 signoffs * python-logilab-common-0.61.0-2 (any) 0/2 signoffs * python-mako-0.9.1-2 (any) 0/2 signoffs * python-nose-1.3.1-2 (any) 0/2 signoffs * python-pip-1.5.4-2 (any) 0/2 signoffs * python-ply-3.4-4 (any) 0/2 signoffs * python-pyasn1-0.1.7-2 (any) 0/2 signoffs * python-pycparser-2.10-4 (any) 0/2 signoffs * python-pyelftools-0.21-2 (any) 0/2 signoffs * python-setuptools-3.3-3 (any) 0/2 signoffs * python-virtualenv-1.11.4-2 (any) 0/2 signoffs * python2-rdflib-4.1.0-2 (any) 0/2 signoffs * pyxdg-0.25-2 (any) 0/2 signoffs * xcb-proto-1.10-2 (any) 0/2 signoffs * apache-2.4.9-1 (i686) 0/1 signoffs * brltty-4.5-7 (i686) 0/1 signoffs * dbus-python-1.2.0-3 (i686) 0/1 signoffs * gedit-3.10.4-2 (i686) 0/1 signoffs * gnome-music-3.10.3-2 (i686) 0/1 signoffs * ibus-1.5.6-2 (i686) 0/1 signoffs * kdebindings-python-4.12.3-2 (i686) 0/1 signoffs * kdesdk-kate-4.12.3-2 (i686) 0/1 signoffs * kdevelop-python-1.6.1-1 (i686) 0/1 signoffs * liblouis-2.5.2-3 (i686) 0/1 signoffs * libpeas-1.9.0-2 (i686) 0/1 signoffs * libreoffice-4.2.2-5 (i686) 0/1 signoffs * nspr-4.10.4-1 (i686) 0/1 signoffs * nss-3.15.5-1 (i686) 0/1 signoffs * pyalpm-0.6.2-2 (i686) 0/1 signoffs * pycrypto-2.6.1-2 (i686) 0/1 signoffs * pygobject-3.10.2-2 (i686) 0/1 signoffs * pygobject2-2.28.6-10 (i686) 0/1 signoffs * pyqt4-4.10.4-1 (i686) 0/1 signoffs * pyqt5-5.2.1-1 (i686) 0/1 signoffs * python-3.4.0-2 (i686) 0/1 signoffs * python-cairo-1.10.0-4 (i686) 0/1 signoffs * python-cffi-0.8.2-4 (i686) 0/1 signoffs * python-cryptography-0.2.2-2 (i686) 0/1 signoffs * python-lxml-3.3.3-2 (i686) 0/1 signoffs * python-markupsafe-0.19-2 (i686) 0/1 signoffs * python-numpy-1.8.0-3 (i686) 0/1 signoffs * python-pycurl-7.19.3.1-2 (i686) 0/1 signoffs * python-urwid-1.2.0-2 (i686) 0/1 signoffs * python-zope-interface-4.1.0-2 (i686) 0/1 signoffs * qscintilla-2.8.1-1 (i686) 0/1 signoffs * ruby-2.1.1-2 (i686) 0/1 signoffs * sip-4.15.5-2 (i686) 0/1 signoffs * speech-dispatcher-0.8-3 (i686) 0/1 signoffs * swig-3.0.0-1 (i686) 0/1 signoffs * vde2-2.3.2-6 (i686) 0/1 signoffs * xf86-video-intel-2.99.911-1 (i686) 0/1 signoffs * apache-2.4.9-1 (x86_64) 0/2 signoffs * brltty-4.5-7 (x86_64) 0/2 signoffs * dbus-python-1.2.0-3 (x86_64) 0/2 signoffs * gedit-3.10.4-2 (x86_64) 0/2 signoffs * gnome-music-3.10.3-2 (x86_64) 0/2 signoffs * ibus-1.5.6-2 (x86_64) 0/2 signoffs * kdebindings-python-4.12.3-2 (x86_64) 0/2 signoffs * kdesdk-kate-4.12.3-2 (x86_64) 0/2 signoffs * kdevelop-python-1.6.1-1 (x86_64) 0/2 signoffs * liblouis-2.5.2-3 (x86_64) 0/2 signoffs * libpeas-1.9.0-2 (x86_64) 0/2 signoffs * libreoffice-4.2.2-5 (x86_64) 0/2 signoffs * nspr-4.10.4-1 (x86_64) 1/2 signoffs * pyalpm-0.6.2-2 (x86_64) 0/2 signoffs * pycrypto-2.6.1-2 (x86_64) 0/2 signoffs * pygobject-3.10.2-2 (x86_64) 0/2 signoffs * pygobject2-2.28.6-10 (x86_64) 0/2 signoffs * pyqt4-4.10.4-1 (x86_64) 0/2 signoffs * pyqt5-5.2.1-1 (x86_64) 0/2 signoffs * python-3.4.0-2 (x86_64) 0/2 signoffs * python-cairo-1.10.0-4 (x86_64) 0/2 signoffs * python-cffi-0.8.2-4 (x86_64) 0/2 signoffs * python-cryptography-0.2.2-2 (x86_64) 0/2 signoffs * python-lxml-3.3.3-2 (x86_64) 0/2 signoffs * python-markupsafe-0.19-2 (x86_64) 0/2 signoffs
Re: [arch-dev-public] brynhild down a.k.a pkgbuild.com
Am 22.03.2014 18:15 schrieb =?UTF-8?B?SW9udcibIELDrnJ1?= biru.io...@gmail.com: Update, they found nothing, that's not a surprise and we always had a problem with it (bit flip problem from time to time). I think is time to stop using this server and get a newer one. You guys mentioned that ecc it's a must. They have ex60 now with 32gb with intel xeon. for 69€/mo and for an additional ip we can have ipmi access as well but setup is 99€ My idea is to move forums/wiki/aur on this on since we struggle a bit with ram on alderaan and use alderaan as build box. What do you guys think? On Sat, Mar 22, 2014 at 11:56 AM, Ionuț Bîru biru.io...@gmail.com wrote: Hello, Just to let you guys know, the server became unstable and unreachable 2 hours ago. Is rebooting by itself couples of times and then is unreachable and cannot be even hard rebooted from the interface. The guys from hetzner are performing a hardware check right now, they said it may take up to 10-14 hours. Sadly, I won't be available more to follow this, Florian is getting all the emails from support. -- Ionut -- Ionut Hi, A replacement for alderaan would be great as we could easily use more RAM for our DB. I'd even say the EX40 with SSDs might be worth a look. That would probably solve our forum search issues by brute force. I'd prefer this over ECC, but I wouldn't argue if we can pay for both. As for the current alderaan server: I'd say we cancel this as well and get at least an EX40 as build system. It's faster, has better disks and four times the RAM. The monthly fee is the same. Greetings, Pierre
Re: [arch-dev-public] brynhild down a.k.a pkgbuild.com
On 22/03/2014 19:50, Florian Pritz wrote: Disclaimer: I have experience with multiple Hetzner boxes, their support work flow and they have a forum which has a good amount of insider info which I like a lot. Better the devil you know ... The relation with your box provider is very important and I fully understand that's a key choice. You don't choose your server only based on price and technical specs. Not sure which OVH offers you are talking about. Those you linked are at best 16GiB RAM and and i5 and ofc no ecc ram. I pointed out Kimsufi (OVH) boxes for their low cost because they allow to split services between hosts instead of having all in a big expensive server. Smaller boxes with dedicated CPU and unlimited bandwidth. For example one for forums, one for wiki, etc. Maybe it's an option you didn't consider for pricing reason. The cpu is weaker (e3-1270v3 vs e3-1240v3), 100Mhz[1] :) I'm feeling that you (and probably Pierre too) are more confident with Hetzner service. Remember that Online.net has a challenging offer which may interest you if we want diversify or we need a real unlimited bandwidth, which come with higher storage (like backup or ...). we'd get HW raid (which is probably more trouble than it's worth with a 2 disk system) and the choice between 600gb 10k sas, 120gb ssd or 3tb sata disks. I share your feeling with the HW RAID, but you could request to disabling it and use the raid card as an HBA. What I do on this box. Cheers, [1] http://ark.intel.com/compare/75055,75056 -- Sébastien Seblu Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A signature.asc Description: OpenPGP digital signature
[arch-dev-public] [RFC] Add ARM to archlinux.org
Hello, As you may know I'm running ARM[1] since the last maintainer resign in August 2013. I would like to propose its addition into our official services. My current suggestion is to keep the current server and hierarchy and to move it under an archlinux.org subdomain. So far, best suggestions are: - archive.archlinux.org - museum.archlinux.org - rollback.archlinux.org Current cost in byte is: # du -hcs 2013 2014 111G2013 55G 2014 165Gtotal In a second time, we could: - move the files on an official server - move installer backups[2] - add AUR - backup them (by mirroring or others) Current used scripts are freely available here[3]. [1] https://wiki.archlinux.org/index.php/ARM [2] https://users.archlinux.de/~pierre/archive/ [3] https://github.com/seblu/armtools -- Sébastien Seblu Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
On Mon, Mar 24, 2014 at 11:35:36PM +0100, Sébastien Luttringer wrote: Hello, As you may know I'm running ARM[1] since the last maintainer resign in August 2013. I would like to propose its addition into our official services. My current suggestion is to keep the current server and hierarchy and to move it under an archlinux.org subdomain. So far, best suggestions are: - archive.archlinux.org - museum.archlinux.org - rollback.archlinux.org Current cost in byte is: # du -hcs 2013 2014 111G2013 55G 2014 165Gtotal In a second time, we could: - move the files on an official server Does 2013 cover the whole year? You're suggesting that 2014 will occupy over 200GB. We'd need new infrastructure for this, and it comes with a monetary cost we'd need to accomodate (or are you proposing that you'll be paying for this forever?). Have you looked into how much this would be per month with a potential provider? How much bandwidth is associated with this? How long would packages be retained? What about resource planning for future growth? - move installer backups[2] Not sure why old install ISOs are interesting for anything but nostalgia. - add AUR This doesn't make sense. We already have a git repo which does a far better job of compressing the deltas between versions of text files. - backup them (by mirroring or others) There's going to be a large cost here and I doubt it's any potential benefit. Do you get complaints/requests from your users to mirror your implementation? Current used scripts are freely available here[3]. [1] https://wiki.archlinux.org/index.php/ARM [2] https://users.archlinux.de/~pierre/archive/ [3] https://github.com/seblu/armtools -- Sébastien Seblu Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
On 24.03.2014 23:50, Dave Reisner wrote: Current cost in byte is: # du -hcs 2013 2014 111G2013 55G 2014 165Gtotal Does 2013 cover the whole year? 2013 starts on August 31th. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
On 24/03/2014 23:50, Dave Reisner wrote: On Mon, Mar 24, 2014 at 11:35:36PM +0100, Sébastien Luttringer wrote: Does 2013 cover the whole year? Four full months. More details in listing this page[1] You're suggesting that 2014 will occupy over 200GB. We'd need new infrastructure for this, and it comes with a monetary cost we'd need to accomodate (or are you proposing that you'll be paying for this forever?). I don't suggest to pay forever, one of the benefits of moving this, is to stop rely on one guy. We already suffer of a previous shutdown on this service. Have you looked into how much this would be per month with a potential provider? How much bandwidth is associated with this? The current server cost is 16.99€/month excl. VAT with 2x1TB HDD with 1Gbit/s connectivity, 200Mbit/s internet bandwidth and unlimited traffic. A cheap solution based on a dedibox classic[2] with 2x1TB, 1 Gbit/s con, 150Mbit/s internet and unlimited traffic for 29.99€/month excl. VAT. should be sufficient. A more future proof solution may based on a dedibox pro[3] with 2x3TB drives, with 400Mbit/s internet bandwidth and unlimited traffic for 69€/month excl. VAT. Of course, any Hetzner alternative may fit, but traffic limitation may cause extra cost that we don't have with online.net offers. How long would packages be retained? What about resource planning for future growth? My suggestion would to keep them as far as we can, until costs is not a showstopper. With a 1TB server and 300GB by year, we can keep ~3 years. - add AUR This doesn't make sense. We already have a git repo which does a far better job of compressing the deltas between versions of text files. Keeping the git backend or not, it makes sense to me to move this from the build server (pkgbuild.com) to the archive server (something like archive.archlinux.org). Git is an awesome SCM, but it was not think to backup stuff, especially with a big directory tree. My feeling trying to find a previous version of a PKGBUILD with aur-mirror.git is: - a very long time to fetch the repository - a space based dig into changelog to find the right commit for my date - a long checkout to get the tree at this commit Having something with faster access and in a similar hierarchy may have use cases. - backup them (by mirroring or others) There's going to be a large cost here and I doubt it's any potential benefit. Do you get complaints/requests from your users to mirror your implementation? No extra cost is expected for mirroring, which is a kind of distributed backup. I see at least 2 potentials benefits for mirroring: - Better latency around the world. - Get our data back in case of disaster recovery. Of course, I suggest to keep these mirrors separate from our packages mirrors. Purpose and HW requirement are not the same. The only complain I get is because this service is not official and rely on my health. I had 3 requests: - One guy for mirroring because of latency. - One from ArchARM asking to add ARM to their project :) - One from a guy asking to add AUR support. Cheers, [1] https://seblu.net/a/arm/2013/ [2] http://www.online.net/fr/serveur-dedie/dedibox-classic [3] http://www.online.net/fr/serveur-dedie/dedibox-pro2k14 -- Sébastien Seblu Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
On Tue, Mar 25, 2014 at 12:55:51AM +0100, Sébastien Luttringer wrote: On 24/03/2014 23:50, Dave Reisner wrote: On Mon, Mar 24, 2014 at 11:35:36PM +0100, Sébastien Luttringer wrote: Does 2013 cover the whole year? Four full months. More details in listing this page[1] You're suggesting that 2014 will occupy over 200GB. We'd need new infrastructure for this, and it comes with a monetary cost we'd need to accomodate (or are you proposing that you'll be paying for this forever?). I don't suggest to pay forever, one of the benefits of moving this, is to stop rely on one guy. We already suffer of a previous shutdown on this service. Right, but throwing this responsibility on the arms of Arch developers isn't really a solution, either, without quiescence. You seem to be of the mindset of that adding this to the archlinux.org domain will magically lighten your own sysadmin load. While I think the idea is neat, I don't think is has a place underneath archlinux.org -- we'd be taking a step towards supporting partial upgrades (which we refuse to support everywhere else). Before you mention the AUR, remember that the AUR hosts source packages; not binary packages. Have you looked into how much this would be per month with a potential provider? How much bandwidth is associated with this? The current server cost is 16.99€/month excl. VAT with 2x1TB HDD with 1Gbit/s connectivity, 200Mbit/s internet bandwidth and unlimited traffic. A cheap solution based on a dedibox classic[2] with 2x1TB, 1 Gbit/s con, 150Mbit/s internet and unlimited traffic for 29.99€/month excl. VAT. should be sufficient. A more future proof solution may based on a dedibox pro[3] with 2x3TB drives, with 400Mbit/s internet bandwidth and unlimited traffic for 69€/month excl. VAT. And the SLA? This all seems reasonable at a glance, but I can't speak to how this would impact our budgeting. Of course, any Hetzner alternative may fit, but traffic limitation may cause extra cost that we don't have with online.net offers. How long would packages be retained? What about resource planning for future growth? My suggestion would to keep them as far as we can, until costs is not a showstopper. With a 1TB server and 300GB by year, we can keep ~3 years. - add AUR This doesn't make sense. We already have a git repo which does a far better job of compressing the deltas between versions of text files. Keeping the git backend or not, it makes sense to me to move this from the build server (pkgbuild.com) to the archive server (something like archive.archlinux.org). Sure, I agree with this. Our serving structure is pretty strange and it doesn't make sense to host the repo on the build server for any other reason than: this is where we had unallocated resources. Git is an awesome SCM, but it was not think to backup stuff, especially You lost me here. git is made up entirely of deltas and serves as a distributed backup. It's *really* *good* at this, even on wide trees. with a big directory tree. My feeling trying to find a previous version of a PKGBUILD with aur-mirror.git is: - a very long time to fetch the repository - a space based dig into changelog to find the right commit for my date - a long checkout to get the tree at this commit Seems like this is just three different ways to spin the same point. We can restructure to repo to make it more clone-friendly if that's all that's needed. Having something with faster access and in a similar hierarchy may have use cases. How often do you use the git repo? - backup them (by mirroring or others) There's going to be a large cost here and I doubt it's any potential benefit. Do you get complaints/requests from your users to mirror your implementation? No extra cost is expected for mirroring, which is a kind of distributed backup. I see at least 2 potentials benefits for mirroring: Are you really suggesting that mirroring 300GB-3TB of data has no cost? Who's hosting the mirrors? Have they agreed to shoulder the additional storage and bandwidth requirements? - Better latency around the world. - Get our data back in case of disaster recovery. Of course, I suggest to keep these mirrors separate from our packages mirrors. Purpose and HW requirement are not the same. The only complain I get is because this service is not official and rely on my health. I had 3 requests: - One guy for mirroring because of latency. - One from ArchARM asking to add ARM to their project :) - One from a guy asking to add AUR support. Do you have any metrics to show how many 30 day users you have? Downloads per day? Week? Bandwidth consumed? I'm really interested in knowing how much impact this actually has d
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
[2014-03-25 00:55:51 +0100] Sébastien Luttringer: On 24/03/2014 23:50, Dave Reisner wrote: On Mon, Mar 24, 2014 at 11:35:36PM +0100, Sébastien Luttringer wrote: Does 2013 cover the whole year? Four full months. More details in listing this page[1] Is there any use keeping packages older than, say, a year? That'd take 200 GB of disk space. Would you have an estimate of the average monthly bandwidth usage? Personally, although I think the AUR is a valuable service and that you shouldn't be assuming its costs and maintenance alone, I'm not sure if making it official would be a good thing (TM) in terms of encouraging users to downgrade packages rather than reporting bugs and upgrading cleanly when things break. -- Gaetan pgpv49u_vMCVc.pgp Description: PGP signature
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
On 3/24/14, Sébastien Luttringer se...@seblu.net wrote: - add AUR This doesn't make sense. We already have a git repo which does a far better job of compressing the deltas between versions of text files. Keeping the git backend or not, it makes sense to me to move this from the build server (pkgbuild.com) to the archive server (something like archive.archlinux.org). Git is an awesome SCM, but it was not think to backup stuff, especially with a big directory tree. My feeling trying to find a previous version of a PKGBUILD with aur-mirror.git is: - a very long time to fetch the repository - a space based dig into changelog to find the right commit for my date - a long checkout to get the tree at this commit Having something with faster access and in a similar hierarchy may have use cases. The Rollback Machine has a convenient CLI wrapper to access packages. Have you tried using the Rollback Machine with just a browser? It is nearly impossible. The CLI wrapper makes it much nicer. The aur.git backup has no such convenient wrapper. Yes, it is painful to use. About as painful as trying to navigate the Rollback Machine with a web browser. Write a front end instead of this vague, nebulous proposal. The only complain I get is because this service is not official and rely on my health. I had 3 requests: - One guy for mirroring because of latency. - One from ArchARM asking to add ARM to their project :) - One from a guy asking to add AUR support. Just to clarify the Arch Linux ARM thing. No one asked to incorporate ALARM into the Rollback Machine. Someone did ask for assistance with setting up their own Rollback Machine. And this guy was not from ArchARM, he was an ALARM mirror host. If only one guy is complaining about latency, great! Hundreds of people aren't. I wish I could do something where only one person complained about it. -Kyle http://kmkeen.com
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
On 25/03/2014 01:44, Dave Reisner wrote: Right, but throwing this responsibility on the arms of Arch developers isn't really a solution, either, without quiescence. You seem to be of the mindset of that adding this to the archlinux.org domain will magically lighten your own sysadmin load. I'm not expecting less sysadmin load, I could perfectly handle that for the time to come. But maybe one day, younger guy will replace me or worst if I met the bus factor. While I think the idea is neat, I don't think is has a place underneath archlinux.org -- we'd be taking a step towards supporting partial upgrades (which we refuse to support everywhere else). Before you mention the AUR, remember that the AUR hosts source packages; not binary packages. I don't think we change anything about that. Partial upgrade are not supported. We already have to handle users doing this, and we still continue to kill them if there system is not up-to-date before they report their issue. I'm suggesting an archlinux archive, not changing our successful rolling release model. And the SLA? This all seems reasonable at a glance, but I can't speak to how this would impact our budgeting. http://www.online.net/en/dedicated-server/service-level However, archive service is not a critical service, we can stay at basic level. Seems like this is just three different ways to spin the same point. We can restructure to repo to make it more clone-friendly if that's all that's needed. I don't know how to do this, I'm interested! Are you suggesting that storing the whole ARM archive into git is a good idea? Having something with faster access and in a similar hierarchy may have use cases. How often do you use the git repo? Everyday. Did you try to clone the aur-mirror repo? $ time git clone http://pkgbuild.com/git/aur-mirror.git Cloning into 'aur-mirror'... ^C git clone http://pkgbuild.com/git/aur-mirror.git 0,00s user 0,01s system 0% cpu 2:30,39 total Not even started in 2m30s. Are you really suggesting that mirroring 300GB-3TB of data has no cost? Yes, no *extra* cost for us. Who's hosting the mirrors? Like for our current package mirrors. Everyone who offer its help. Have they agreed to shoulder the additional storage and bandwidth requirements? You probably miss my suggestion to have separate archive mirrors. Do you have any metrics to show how many 30 day users you have? Downloads per day? Week? Bandwidth consumed? I'm really interested in knowing how much impact this actually has Impact is insignificant on my server. Last week network graph: - https://horus.seblu.net/~seblu/archive/if_eth0.png - https://horus.seblu.net/~seblu/archive/fw_packets.png - https://horus.seblu.net/~seblu/archive/fw_forwarded.png -- Sébastien Seblu Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
On 25/03/2014 02:02, Gaetan Bisson wrote: [2014-03-25 00:55:51 +0100] Sébastien Luttringer: On 24/03/2014 23:50, Dave Reisner wrote: On Mon, Mar 24, 2014 at 11:35:36PM +0100, Sébastien Luttringer wrote: Does 2013 cover the whole year? That'd take 200 GB of disk space. Would you have an estimate of the average monthly bandwidth usage? Not precisely, but I can dig trough the log files and do some math. Say lesser than 10Mbit/s, as the bandwidth and traffic can be included in the server price, that doesn't really matter. Personally, although I think the AUR is a valuable service and that you shouldn't be assuming its costs and maintenance alone,... I guess you are speaking of ARM (Arch Rollback Machine) not AUR here. -- Sébastien Seblu Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
[2014-03-25 02:46:23 +0100] Sébastien Luttringer: On 25/03/2014 02:02, Gaetan Bisson wrote: Personally, although I think the AUR is a valuable service and that you shouldn't be assuming its costs and maintenance alone,... I guess you are speaking of ARM (Arch Rollback Machine) not AUR here. Indeed, that was a typo. Sorry for the confusion. -- Gaetan pgpR0OfuKDbup.pgp Description: PGP signature
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
On 25/03/2014 02:15, keenerd wrote: On 3/24/14, Sébastien Luttringer se...@seblu.net wrote: The Rollback Machine has a convenient CLI wrapper to access packages. Have you tried using the Rollback Machine with just a browser? It is nearly impossible. The CLI wrapper makes it much nicer. I always use the web interface to get packages from ARM. No wrapper. The unique CLI tool I used was pacman to rollback a whole system. The ARM server latency is pretty good where pkgbuild.com is a nightmare. $ time wget -qO/dev/null https://seblu.net/a/arm/2014 wget -qO/dev/null https://seblu.net/a/arm/2014 0,02s user 0,00s system 33% cpu 0,063 tot $ time wget -qO/dev/null http://pkgbuild.com/git/aur-mirror.git/tree/?id=0b2c85b0b252c9bab30df2c411d506bf3475a1ae wget -qO/dev/null 0,17s user 0,74s system 18% cpu 4,970 total The aur.git backup has no such convenient wrapper. Yes, it is painful to use. About as painful as trying to navigate the Rollback Machine with a web browser. I'm not speaking of beauty, but speed and latency of answers. Write a front end instead of this vague, nebulous proposal. I did not wish hurt you in any manner. Your aur-mirror.git is a good initiative. Please don't take it personally. Just to clarify the Arch Linux ARM thing. No one asked to incorporate ALARM into the Rollback Machine. Someone did ask for assistance with setting up their own Rollback Machine. And this guy was not from ArchARM, he was an ALARM mirror host. Sorry if that was not clear in my first mail. Cheers, -- Sébastien Seblu Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
On Monday, March 24, 2014 21:15:06 keenerd wrote: On 3/24/14, Sébastien Luttringer se...@seblu.net wrote: - add AUR This doesn't make sense. We already have a git repo which does a far better job of compressing the deltas between versions of text files. Keeping the git backend or not, it makes sense to me to move this from the build server (pkgbuild.com) to the archive server (something like archive.archlinux.org). Git is an awesome SCM, but it was not think to backup stuff, especially with a big directory tree. My feeling trying to find a previous version of a PKGBUILD with aur-mirror.git is: - a very long time to fetch the repository - a space based dig into changelog to find the right commit for my date - a long checkout to get the tree at this commit Having something with faster access and in a similar hierarchy may have use cases. The Rollback Machine has a convenient CLI wrapper to access packages. Have you tried using the Rollback Machine with just a browser? It is nearly impossible. The CLI wrapper makes it much nicer. Just want to add a side note here, that the two most popular CLI wrappers (downgrade and downgrader in AUR) are using the web service hosted by Arch Linux Chinese Community (archlinuxcn). We are also hosting the service right at the day when the old A.R.M was down. I think we're implementing the services in two aspects: Sébastien is providing daily-based folders, which is great to rollback or freeze a system at some point, while archlinuxcn is providing API for CLI wrappers to query packages, which makes more sense for users using the CLI helpers. About the server resources: 83G ./community 70G ./packages There were some users from the forums gave us their old backups, so we have oldest package back to 2007 here, while packages (not including [testing]) from 2011 are generally available for search download. For example, a search for kernel26 returns every version down to 2.6.38.3, which was released on 2011-04-17 according to our svn log. So the resource consumption doesn't look scary at all :) I don't actually have a preference on making the service official or not, the current domain repo- arm.archlinuxcn.org looks OK to me as well. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
On 25 March 2014 04:35, Sébastien Luttringer se...@seblu.net wrote: Hello, As you may know I'm running ARM[1] since the last maintainer resign in August 2013. I would like to propose its addition into our official services. My current suggestion is to keep the current server and hierarchy and to move it under an archlinux.org subdomain. So far, best suggestions are: - archive.archlinux.org - museum.archlinux.org - rollback.archlinux.org Current cost in byte is: # du -hcs 2013 2014 111G2013 55G 2014 165Gtotal In a second time, we could: - move the files on an official server - move installer backups[2] - add AUR - backup them (by mirroring or others) Current used scripts are freely available here[3]. [1] https://wiki.archlinux.org/index.php/ARM [2] https://users.archlinux.de/~pierre/archive/ [3] https://github.com/seblu/armtools You may be forgetting an important point. I may be wrong, but we also have to serve the sources [1] for these binary packages if it's going to appear like we're supporting this system of rolling back. And for every version at that. Our argument for having only one version currently is because we support only one version at any one time. I'm not sure if having this system as part of our infrastructure is going to affect that position. [1] ftp://ftp.archlinux.org/sources -- GPG/PGP ID: C0711BF1
