Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On Nov 29, 2012 10:24 AM, Markos Chandras hwoar...@gentoo.org wrote: We could slightly simplify the handbook installation procedure if we told people to use emerge-webrsync to fetch the initial snapshot. What do people think? Seems a good improvement to me. I'm ok with it as well. I'll draft up something. I suspect emerge-webrsync is available on all platforms?
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
After a lot of screwing around, I found various ways to make the netbook not work in X, and even not boot. X won't work if I have CONFIG_STUB_POULSBO enabled. I also found that if I put video=640x480 in the lilo append= line, the machine would come up in 640x480 mode, and stay in 640x480 mode. Similarly for video=800x600. I assume it would also work for 1024x768. I believe the GRUB equivalent to lilo append= is GRUB_CMDLINE_LINUX=. I've added 2 duplicate entries in my lilo boot menu, with just the video= differing. I don't expect to give presentations with my netbook. But if I have to, I can downsize the video simply by rebooting into the appropriate mode. I have one of the really early netbooks (32-bit-only). I'm just happy that it works. One thing has made the process worthwhile. I found out via Google that setting aside some ram for the video noticably improves video performance. The netbook can now play 1080p HD Youtube videos in the large player. Not fullscreen. Before this, 1080p would stutter badly, even in Youtube's small player. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
On 24.11.2012 23.12, Pacho Ramos wrote: # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Doesn't build against recent kernels (#247898), all its supported # devices are not supported by latest kernels. Removal in a month. net-wireless/linux-wlan-ng-modules net-wireless/linux-wlan-ng-utils net-wireless/linux-wlan-ng-firmware net-wireless/linux-wlan-ng Thanks for the work. You could link here for to provide users information on the replacement modules: http://wiki.debian.org/linux-wlan-ng Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On 11/30/2012 06:46 AM, Sven Vermeulen wrote: On Nov 29, 2012 10:24 AM, Markos Chandras hwoar...@gentoo.org wrote: We could slightly simplify the handbook installation procedure if we told people to use emerge-webrsync to fetch the initial snapshot. What do people think? Seems a good improvement to me. I'm ok with it as well. I'll draft up something. I suspect emerge-webrsync is available on all platforms? It is part of sys-apps/portage. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On 11/28/2012 11:08 AM, Matthew Thode wrote: On 11/28/2012 09:05 AM, Richard Yao wrote: On 11/28/2012 09:17 AM, Maxim Kammerer wrote: On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao r...@gentoo.org wrote: We could slightly simplify the handbook installation procedure if we told people to use emerge-webrsync to fetch the initial snapshot. Using emerge-webrsync also makes the installation process more robust, since it only requires HTTP access (whereas many firewalls restrict RSYNC). Besides, emerge-webrsync can check PGP signatures, so I think that it should be the primary recommended portage tree synchronization method. The only downside of which I am aware is increased network traffic. However, we could redesign emerge-webrsync to take advantage of GNU Tar's incremental archive functionality. That would permit us to mirror compressed diffs in addition to regular portage snapshots. Doing that well could reduce bandwidth requirements. weekly fulls and daily diffs? Determining what is right here probably requires calculus, but this scheme does not seem like a bad choice to me. My main concern is that maintaining weekly full snapshots would require too much space for the mirrors. It might be better go monthly, with diffs on the following intervals: 1 week 1 day 30 minutes Doing that would eliminate the benefit of rsync entirely, with the caveat that we now need to mirror a ton of diffs. This would make it easy for us to provide the ability to obtain historical snapshots, which would be nice. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On Fri, Nov 30, 2012 at 10:57 AM, Richard Yao r...@gentoo.org wrote: On 11/28/2012 11:08 AM, Matthew Thode wrote: On 11/28/2012 09:05 AM, Richard Yao wrote: On 11/28/2012 09:17 AM, Maxim Kammerer wrote: On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao r...@gentoo.org wrote: We could slightly simplify the handbook installation procedure if we told people to use emerge-webrsync to fetch the initial snapshot. Using emerge-webrsync also makes the installation process more robust, since it only requires HTTP access (whereas many firewalls restrict RSYNC). Besides, emerge-webrsync can check PGP signatures, so I think that it should be the primary recommended portage tree synchronization method. The only downside of which I am aware is increased network traffic. However, we could redesign emerge-webrsync to take advantage of GNU Tar's incremental archive functionality. That would permit us to mirror compressed diffs in addition to regular portage snapshots. Doing that well could reduce bandwidth requirements. weekly fulls and daily diffs? Determining what is right here probably requires calculus, but this scheme does not seem like a bad choice to me. My main concern is that maintaining weekly full snapshots would require too much space for the mirrors. It might be better go monthly, with diffs on the following intervals: 1 week 1 day 30 minutes Doing that would eliminate the benefit of rsync entirely, with the caveat that we now need to mirror a ton of diffs. This would make it easy for us to provide the ability to obtain historical snapshots, which would be nice. Worth noting that all this moves us nicely in the direction of allowing HTTP proxies to cache data, reducing load on mirrors. And moves us in the direction of implementing mirrors themselves as a network of caching proxies. -- :wq
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/11/12 11:15 AM, Michael Mol wrote: On Fri, Nov 30, 2012 at 10:57 AM, Richard Yao r...@gentoo.org wrote: On 11/28/2012 11:08 AM, Matthew Thode wrote: On 11/28/2012 09:05 AM, Richard Yao wrote: On 11/28/2012 09:17 AM, Maxim Kammerer wrote: On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao r...@gentoo.org wrote: We could slightly simplify the handbook installation procedure if we told people to use emerge-webrsync to fetch the initial snapshot. Using emerge-webrsync also makes the installation process more robust, since it only requires HTTP access (whereas many firewalls restrict RSYNC). Besides, emerge-webrsync can check PGP signatures, so I think that it should be the primary recommended portage tree synchronization method. The only downside of which I am aware is increased network traffic. However, we could redesign emerge-webrsync to take advantage of GNU Tar's incremental archive functionality. That would permit us to mirror compressed diffs in addition to regular portage snapshots. Doing that well could reduce bandwidth requirements. weekly fulls and daily diffs? Determining what is right here probably requires calculus, but this scheme does not seem like a bad choice to me. My main concern is that maintaining weekly full snapshots would require too much space for the mirrors. It might be better go monthly, with diffs on the following intervals: 1 week 1 day 30 minutes Doing that would eliminate the benefit of rsync entirely, with the caveat that we now need to mirror a ton of diffs. This would make it easy for us to provide the ability to obtain historical snapshots, which would be nice. Worth noting that all this moves us nicely in the direction of allowing HTTP proxies to cache data, reducing load on mirrors. And moves us in the direction of implementing mirrors themselves as a network of caching proxies. Idea makes sense, I wonder if implementation would be better served by leveraging the fact that we already produce daily full snapshots: 1 - continue to provide the daily snapshots we do now 2 - provide two weeks (more?) of daily diffs, such that a daily snapshot from up to two weeks ago can be updated to present day 3 - provide hourly or 30-minute update diffs to get latest changes. If the tree is more than two weeks old, emerge-webrsync would just grab the latest daily plus the hourly diffs. If the tree is less than two weeks old, grab the daily diffs and hourly diffs. The local copy of the tree itself would need to be rolled back to the best-available daily diff before these diff updates could be applied; this may mean that a local cache of the latest full-day snapshot needs to be kept and/or generated. Also if said cache doesn't exist, then the whole full-day snapshot would be grabbed. The advantage to this would be significantly fewer distfiles, although the logic in emerge-webrsync would possibly be more complex. Regarding rolling back the local tree to a known-good state, I think that would be required regardless of the method as any local changes made to the tree by users would need to be discarded, right? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlC45f0ACgkQ2ugaI38ACPChKgD9GOBptQ9jJ1/eYyq1NEl5Oq1E dVy9UOab80bG5FZB9LwBAKwsifnT+iE3n/4d/ljnuT2qCnbtXNYr7yBjF/VcEpkq =y9eB -END PGP SIGNATURE-
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On Fri, Nov 30, 2012 at 5:57 PM, Richard Yao r...@gentoo.org wrote: My main concern is that maintaining weekly full snapshots would require too much space for the mirrors. Mirrors already keep last 8 full daily snapshots, in 2 formats each, e.g.: http://mirrors.kernel.org/gentoo/snapshots/ -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On Fri, Nov 30, 2012 at 8:59 AM, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/11/12 11:15 AM, Michael Mol wrote: On Fri, Nov 30, 2012 at 10:57 AM, Richard Yao r...@gentoo.org wrote: On 11/28/2012 11:08 AM, Matthew Thode wrote: On 11/28/2012 09:05 AM, Richard Yao wrote: On 11/28/2012 09:17 AM, Maxim Kammerer wrote: On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao r...@gentoo.org wrote: We could slightly simplify the handbook installation procedure if we told people to use emerge-webrsync to fetch the initial snapshot. Using emerge-webrsync also makes the installation process more robust, since it only requires HTTP access (whereas many firewalls restrict RSYNC). Besides, emerge-webrsync can check PGP signatures, so I think that it should be the primary recommended portage tree synchronization method. The only downside of which I am aware is increased network traffic. However, we could redesign emerge-webrsync to take advantage of GNU Tar's incremental archive functionality. That would permit us to mirror compressed diffs in addition to regular portage snapshots. Doing that well could reduce bandwidth requirements. weekly fulls and daily diffs? Determining what is right here probably requires calculus, but this scheme does not seem like a bad choice to me. My main concern is that maintaining weekly full snapshots would require too much space for the mirrors. It might be better go monthly, with diffs on the following intervals: 1 week 1 day 30 minutes Doing that would eliminate the benefit of rsync entirely, with the caveat that we now need to mirror a ton of diffs. This would make it easy for us to provide the ability to obtain historical snapshots, which would be nice. Worth noting that all this moves us nicely in the direction of allowing HTTP proxies to cache data, reducing load on mirrors. And moves us in the direction of implementing mirrors themselves as a network of caching proxies. Idea makes sense, I wonder if implementation would be better served by leveraging the fact that we already produce daily full snapshots: 1 - continue to provide the daily snapshots we do now 2 - provide two weeks (more?) of daily diffs, such that a daily snapshot from up to two weeks ago can be updated to present day 3 - provide hourly or 30-minute update diffs to get latest changes. If the tree is more than two weeks old, emerge-webrsync would just grab the latest daily plus the hourly diffs. If the tree is less than two weeks old, grab the daily diffs and hourly diffs. The local copy of the tree itself would need to be rolled back to the best-available daily diff before these diff updates could be applied; this may mean that a local cache of the latest full-day snapshot needs to be kept and/or generated. Also if said cache doesn't exist, then the whole full-day snapshot would be grabbed. The advantage to this would be significantly fewer distfiles, although the logic in emerge-webrsync would possibly be more complex. Regarding rolling back the local tree to a known-good state, I think that would be required regardless of the method as any local changes made to the tree by users would need to be discarded, right? How about we not change the docs until someone eagerly implements all the stuff you just said? Note that from an infra POV our existing system works fairly well and requires no day-to-day tinkering. I'm always happy to consider new options, but work needs to put in to make it feasible. I'm sure if we switched to http with zsync or something, we could make it feasible. I want to see a prototype, etc. -A -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlC45f0ACgkQ2ugaI38ACPChKgD9GOBptQ9jJ1/eYyq1NEl5Oq1E dVy9UOab80bG5FZB9LwBAKwsifnT+iE3n/4d/ljnuT2qCnbtXNYr7yBjF/VcEpkq =y9eB -END PGP SIGNATURE-
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On 11/28/2012 09:50 AM, Michał Górny wrote: On Wed, 28 Nov 2012 10:05:55 -0500 Richard Yao r...@gentoo.org wrote: On 11/28/2012 09:17 AM, Maxim Kammerer wrote: On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao r...@gentoo.org wrote: We could slightly simplify the handbook installation procedure if we told people to use emerge-webrsync to fetch the initial snapshot. Using emerge-webrsync also makes the installation process more robust, since it only requires HTTP access (whereas many firewalls restrict RSYNC). Besides, emerge-webrsync can check PGP signatures, so I think that it should be the primary recommended portage tree synchronization method. The only downside of which I am aware is increased network traffic. However, we could redesign emerge-webrsync to take advantage of GNU Tar's incremental archive functionality. That would permit us to mirror compressed diffs in addition to regular portage snapshots. Doing that well could reduce bandwidth requirements. There's emerge-delta-webrsync but it's mostly hand-work to reconstruct the webrsync tarball. Therefore, it is very slow and not worth the effort when syncing often. At least because I maintain emerge-delta-webrsync, I use it regularly as my sync method. Latest versions of emerge-delta-webrsync use a temp directory inside $PORTAGE_TMPDIR/portage, on which I have a tmpfs filesystem mounted. With tmpfs, performance does not seem so bad (using a sandy bridge core i5 here). However, I'm not aware of gnu tar's incremental archive. If it's much faster than the above, then it should probably replace emerge-delta-webrsync. If it has benefits over the current diffball approach used by emerge-delta-webrsync, then it seems like a good idea. It would be nice to integrate it directly into emerge-webrsync, and eventually deprecate emerge-delta-webrsync. -- Thanks, Zac
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/11/12 12:30 PM, Alec Warner wrote: How about we not change the docs until someone eagerly implements all the stuff you just said? Well, using emerge-webrsync for grabbing the initial snapshot during an installation still makes sense regardless of whether or not we do any of the above, iirc that was the original documentation request change wasn't it? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlC49Y4ACgkQ2ugaI38ACPDETgD/ZzleSQxyWCrgBYc8vg5Wvviz QVpnQa7CRF33qVYvYkkBAKDUx6bB2LbPmGQgFm22su72i32tKfUqiKOgEs6tgboa =CNSD -END PGP SIGNATURE-
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
El vie, 30-11-2012 a las 14:19 +0200, Petteri Räty escribió: On 24.11.2012 23.12, Pacho Ramos wrote: # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Doesn't build against recent kernels (#247898), all its supported # devices are not supported by latest kernels. Removal in a month. net-wireless/linux-wlan-ng-modules net-wireless/linux-wlan-ng-utils net-wireless/linux-wlan-ng-firmware net-wireless/linux-wlan-ng Thanks for the work. You could link here for to provide users information on the replacement modules: http://wiki.debian.org/linux-wlan-ng Regards, Petteri + 30 Nov 2012; Pacho Ramos pa...@gentoo.org package.mask: + Improve mask message for linux-wlan-ng (thanks to Petteri Räty for providing + it) + signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due lavajoe retirement
media-gfx/xv sys-apps/more media-sound/logitechmediaserver-bin - this package is special, it's maintained by a proxy maintainer but it was reassigned to maintainer-needed instead of proxy-maint herd. Was reviewing to reassign it when I saw: https://bugs.gentoo.org/show_bug.cgi?id=251494 that I have no idea about how to handle :| signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due lavajoe retirement
Dne Pá 30. listopadu 2012 20:37:22, Pacho Ramos napsal(a): media-sound/logitechmediaserver-bin - this package is special, it's maintained by a proxy maintainer but it was reassigned to maintainer-needed instead of proxy-maint herd. Was reviewing to reassign it when I saw: https://bugs.gentoo.org/show_bug.cgi?id%1494 that I have no idea about how to handle :| Simple, add hardmaks explaining possible secuirty issues due to bundling earthheaven, and then let the proxymaintainer play with it if he wants. The mask will be lifted only under condition these issues are fixed. People can unmask quite easily if they want, we don't need everything in stable :-) Tom signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On Fri, Nov 30, 2012 at 10:06 AM, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/11/12 12:30 PM, Alec Warner wrote: How about we not change the docs until someone eagerly implements all the stuff you just said? Well, using emerge-webrsync for grabbing the initial snapshot during an installation still makes sense regardless of whether or not we do any of the above, iirc that was the original documentation request change wasn't it? Zac can probably comment on where it fetches from. I can say with some certainty that we have enough rsync capacity, I can't say the same for HTTP based services. -A -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlC49Y4ACgkQ2ugaI38ACPDETgD/ZzleSQxyWCrgBYc8vg5Wvviz QVpnQa7CRF33qVYvYkkBAKDUx6bB2LbPmGQgFm22su72i32tKfUqiKOgEs6tgboa =CNSD -END PGP SIGNATURE-
