[gentoo-user] Re: Hubris?
Jeremi Piotrowski gmail.com> writes: > In general I have not had any problems setting up similar gentoo systems > running pure btrfs in raid1/single mode. Those systems, however, all have > initramfs' - not that that's a bad thing but see above. I too am also interested in booting a btrfs-raid1 all btrfs file system based gentoo, without an interramfs. Some discussions I've read seem to indicate this has occurred already; so maybe it's just a situation where the knowledge and tricks just need to be disseminated more clearly. > Btw. testing the mentioned patch turned out to be a 5 minute thing. > qemu-img create to make 2 disk images, qemu boot sysresuecd, create 2 > device btrfs volume, mount, unpack stage3 and shutdown. Patch spare kernel > in host, compile and boot passing the kernel and cmdline from outside the > guest. Works nicely for quick testing (forgot to set root passwd? who > cares, it boots!). Here [1] on the Btrfs 'gotchas' page are some interesting and related problems described in some detail. Also in the kernel pages [2] hint at issues with file systems that may be related; but more digging will is needed. I hope a documented solution is verified and integrated into Rich's btrfs, raid-1 install notes: [3] . The 'printk' comments are very similar to how and why 'netconsole' was used to diagnose booting issues with the kernel, hardware, fs etc etc [4]. This use of netconsole to perform a 'fine grained debug' of the kernel boot processes is something I hope to figure out and put into an automated gentoo installer as a integral part of the installation semantics, for gentoo. All you need is the system's ethernet port up and a second system to receive the (printk) data stream. hth, James [1] https://btrfs.wiki.kernel.org/index.php/Gotchas [2] http://kernelnewbies.org/Linux_4.0#head-6e2ee9e5b7cfdb480861fda324a804734dc14f89 [3] https://docs.google.com/document/ d/1VJlJyYLTZScta9a81xgKOIBjYsG3_VfxxmUSxG23Uxg/edit?pli=1 [4] https://www.kernel.org/doc/Documentation/networking/netconsole.txt
Re: [gentoo-user] Re: Hubris?
> Paul Tobias gmail.com> writes: > > It works, but a patched kernel is needed. Take a look at > > https://forums.gentoo.org/viewtopic-p-7275724.html The patch there was > > still working on the latest kernel a while ago. The patch from the forum thread does indeed work, and just reading it makes it clear *why* it doesn't work in linus' kernel. Thanks! > > I used it on 2 of my systems, but I moved on and now using dracut > > everywhere. While I agree that dracut (/genkernel) is painless, not hard to setup and *should* be the preferred way to boot nowadays, I felt that its a matter of principle that this should work without one. I mean, they even mention in the btrfs wiki that this works (supposedly). In any case I feel like this is a bug in the kernel. Once I work up the courage I'll contact the btrfs(/kernel) mailing list and see what they have to say about this. On Mon, 10 Aug 2015, James wrote: > I not sure but the OpenSuse btrfs (non-raid1) standard install uses only > btrfs partition types, including /boot and all other partitions. I do not > think it uses dracut or others, but I'm not that use to opensuse to make > install. I happen to have a fairly recent OpenSuse vm lying around, featuring a pure btrfs set-up - boot in a subvolume etc. It's non-raid1 but OpenSuse uses dracut so they do not have the problem that I brought up anyway. In general I have not had any problems setting up similar gentoo systems running pure btrfs in raid1/single mode. Those systems, however, all have initramfs' - not that that's a bad thing but see above. Btw. testing the mentioned patch turned out to be a 5 minute thing. qemu-img create to make 2 disk images, qemu boot sysresuecd, create 2 device btrfs volume, mount, unpack stage3 and shutdown. Patch spare kernel in host, compile and boot passing the kernel and cmdline from outside the guest. Works nicely for quick testing (forgot to set root passwd? who cares, it boots!).
Re: [gentoo-user] LVM not accessible after reboot
> my ideas is that LVM2 is not ready at the time of mounting partitions. how can i do this? I had the same problem on a system where scsi initialization was very slow. Adding "rootdelay=30" to the kernel command line fixed it. The "30" is how many seconds should the kernel wait before it starts mounting filesystems. There was an scsi-wait-scan module too, but I think that was removed from recent kernels. Maybe this is not the same problem you have, probably it's quite rare to have a slowly initializing disk subsystem.
Re: [gentoo-user] Configuring hostapd
On Monday, August 10, 2015 8:59:27 AM Cor Legemaat wrote: > On Thu, 2015-08-06 at 23:41 -0400, Fernando Rodriguez wrote: > > On Thursday, August 06, 2015 7:04:27 AM Cor Legemaat wrote: > > > On Wed, 2015-08-05 at 01:00 -0400, Fernando Rodriguez wrote: > > > > On Tuesday, August 04, 2015 8:18:43 PM Cor Legemaat wrote: > > > > > On Sun, 2015-08-02 at 19:56 -0400, Fernando Rodriguez wrote: > > > > > > On Sunday, August 02, 2015 11:12:07 PM Mick wrote: > > > > > > > On Sunday 02 Aug 2015 22:04:41 Fernando Rodriguez wrote: > > > > > > > > On Sunday, August 02, 2015 1:29:50 PM Mick wrote: > > > > > > > > > On Sunday 02 Aug 2015 01:50:21 Fernando Rodriguez > > > > > > > > > wrote: > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > After installing hostapd I can successfully connect > > > > > > > > > > to > > > > > > > > > > the > > > > > > > > > > AP, I can > > > > > > > > > > get DHCP from it, but I cannot access the network > > > > > > > > > > through it > > > > > > > > > > (neither > > > > > > > > > > lan or internet). > > > > > > > > > > > > > > > > > > This sounds like a (network) routing problem, rather > > > > > > > > > than a > > > > > > > > > hostapd > > > > > > > > > issue. > > > > > > > > > > > > > > > > It looks like that, but if I stop iptables completely on > > > > > > > > the > > > > > > > > router all > > > > > > > > unicast traffic still works in the lan (both wired and > > > > > > > > through > > > > > > > > an external > > > > > > > > AP), so if I connect to the hostapd AP with iptables off, > > > > > > > > shouldn't I at > > > > > > > > the very least be able to ping the wireless interface on > > > > > > > > the > > > > > > > > router? > > > > > > > > > > > > > > > > I also tried with only the following rule which enables > > > > > > > > internet > > > > > > > > access to > > > > > > > > all wired workstations and through external AP: > > > > > > > > > > > > > > > > iptables -t nat -A POSTROUTING -o enp0s8 -j MASQUERADE > > > > > > > > > > > > > > You should probably specify the local subnet, so that > > > > > > > multicast packets are > > > > > > > not sent out to the Internet, e.g.: > > > > > > > > > > > > > > iptables -t nat -A POSTROUTING -o enp0s8 -s 192.168.1.0/24 > > > > > > > ! -d > > > > > > 192.168.1.0/24 > > > > > > > -j MASQUERADE > > > > > > > > > > > > > > (Change 192.168.1.0/24 to suit your LAN subnet) > > > > > > > > > > > > I'm not actually using that rule except as a minimal setup > > > > > > for troubleshooting > > > > > > this issue. My actual rules do specify the subnet. > > > > > > > > > > > > > Also have you enabled ip forwarding in your kernel: > > > > > > > > > > > > > > sysctl -w net.ipv4.ip_forward=1 > > > > > > > > > > > > Yes, it is an existing router that works perfectly except > > > > > > for the hostapd AP. > > > > > > My current setup is as follows: > > > > > > > > > > > > Internet -> Gentoo Router -> Switch -> AP > > > > > > > > > > > > Where AP is a wifi router with routing features disabled. > > > > > > Never had > > > > > > problems > > > > > > with it. Now I installed hostapd on "Gentoo Router" and > > > > > > everything > > > > > > else still > > > > > > works fine except when I connect to the hostapd AP. Even > > > > > > with only > > > > > > that minimal > > > > > > iptable rule or no rules at all. > > > > > > > > > > > > Thanks, > > > > > > > > > > > Probably /dev/random depleated, try enable your hardware rng > > > > > or sys- > > > > > apps/haveged test with `cat > > > > > /proc/sys/kernel/random/entropy_avail` > > > > > > > > > > Regards: > > > > > Cor > > > > > > > > Thanks. II did get an error about depleted entropy at some point > > > > when starting > > > > hostapd but I went ahead and installed haveged and it still > > > > doesn't work. It > > > > doesn't even work when configured as an open AP. I checked the > > > > kernel config and > > > > I had VLAN support disabled. I've rebuilt it but can't reboot > > > > right now. Maybe > > > > it's required even though I'm not using VLANs? > > > > > > > Is there an IP configured on the interface or the bridge of that > > > interface? > > > > Yes > > > > > Can you ping your gateway? > > > > No...I can ping it locally or remotely when I connect through the > > external AP > > but not through hostapd. > > > > > If I'm correct dhcp uses > > > broadcast but you need a valid gateway IP switchable on mac layer. > > > > > > Does it stay connected? > > > > Yes > > > > > I have a problem with a link between hostapd > > > and a mikrotik device on 802.11a where I needed to patch hostapd > > > to get it to stay connected. But that should show in hostapd debug > > > logs. Mine is still running on hostapd-2.3 because if I update and > > > screw it my internet is broken, if that's your problem I will > > > search for my notes and mail it. > > > > Tried hostapd-2.3 too, same thing. > > I will try it on a laptop with a more recent adapter tomorrow to > >
Re: [gentoo-user] GCC-4.9?
On Monday, August 10, 2015 2:02:20 PM Neil Bothwick wrote: > On Mon, 10 Aug 2015 13:58:19 +0100, Peter Humphrey wrote: > > > > I've been using ~amd64 GCC on my MythTV boxes, which run mainly > > > stable, for a long time. I would keep 4.8 installed too, just in case > > > the odd package still doesn't like 4.9. Ironically, on my MythTV > > > boxes, the only package that fails with 4.9 is MythTV :-O > > > > That's reassuring - thanks Neil. Will I also have to upgrade bin-utils > > and libtool to ~ versions? I think those two need recompiling with a > > new gcc version, before any of the rest of the system. > > I really can't remember, but I'm sure portage will tell you if they do. You don't. It will tell you to run the script to fix the libtool files if you run into problems. I didn't run it and didn't run into problems. I think it's only needed if you remove the old compiler. -- Fernando Rodriguez
Re: [gentoo-user] Missing digest for *** Tree looks messed up.
On Mon, Aug 10, 2015 at 12:10 PM, Dale wrote:
> Peter Humphrey wrote:
>> On Monday 10 August 2015 09:13:01 Dale wrote:
>>
>>> I might add, sync is taking a LONG time again. Of course, my DSL is a
>>> bit slower than some folks. At least the bumpy road got smoothed out
>>> tho. It seems to be working again. Maybe next sync will be back to
>>> normal.
>> I do one sync a day, of my LAN server, and sync anything else to that. I
>> don't
>> know how long it took today because I have it on a cron job at night. :-)
>>
>
>
> I usually sync about twice a week, sometimes three if I see something I
> want or need. I just run my desktop here so updating isn't a huge
> deal. Sometimes I forget because I'm busy with other things and I might
> go a week or more without a single sync up.
>
> When I used to run several rigs, I'd sync one rig and then sync the
> others to my main rig. I try not to sync to often.
I couldn't tell you who I ripped this off of but my cron routine is:
ionice -n 7 nice -n 20 emerge --sync (alternatively
emerge-webrsync -k - preferred actually if you're using rsync)
ionice -n 7 nice -n 20 layman -S
emerge -puDv --changed-use world | col -bx | mutt -s "world update"
root@localhost
eix-update
Then I do this:
#!/bin/sh
LIST=$(mktemp);
emerge -puD --changed-use --color=n --columns --quiet=y --with-bdeps=n
world | awk '{print $2}' > ${LIST};
for PACKAGE in $(cat ${LIST});
do
printf "Building binary package for ${PACKAGE}... "
emerge -uN --quiet-build --quiet=y --buildpkgonly ${PACKAGE};
if [[ $? -eq 0 ]];
then
echo "ok";
else
echo "failed";
fi
done
That isn't optimally efficient, but works reasonably well.
The result is that the next morning I have an email containing a list
of the stuff to be merged, and a set of binary packages for most of it
(deps of modified packages cannot be pre-built in this way of course).
Then I just run an "emerge -uDNkv" world to install all of it, often
in minutes.
The script could be optimized - if libreoffice and chromium are on the
list and I don't install them for a few days, suffice it to say that
the heater won't be running as much those nights.
--
Rich
Re: [gentoo-user] Missing digest for *** Tree looks messed up.
Rich Freeman wrote: > On Mon, Aug 10, 2015 at 11:12 AM, Peter Humphrey > wrote: >> On Monday 10 August 2015 09:13:01 Dale wrote: >> >>> I might add, sync is taking a LONG time again. Of course, my DSL is a >>> bit slower than some folks. At least the bumpy road got smoothed out >>> tho. It seems to be working again. Maybe next sync will be back to >>> normal. >> I do one sync a day, of my LAN server, and sync anything else to that. I >> don't >> know how long it took today because I have it on a cron job at night. :-) >> > Well, if you synced with all broken manifest files, and re-synced with > all fixed manifest files, you'd expect one file to be updated for > every package in the repository, so that would be a long sync (but not > quite as long as the original one). > > This was never intended to be a user-visible change (hence no news, > etc). The digest issue was an oversight which was fixed. At this > point rsync should work as it always did, minus one really long sync. > > The main thing you'll probably see is that the headers of the ebuilds > all contain git hashes instead of cvs revisions. > What I was expecting, one longer than usual sync maybe and even more likely, a config update so that some change takes effect. I expected something to change but wasn't expecting what I got for sure. That had me wondering. We all good now tho. < thumbs up > Dale :-) :-)
Re: [gentoo-user] Missing digest for *** Tree looks messed up.
Peter Humphrey wrote: > On Monday 10 August 2015 09:13:01 Dale wrote: > >> I might add, sync is taking a LONG time again. Of course, my DSL is a >> bit slower than some folks. At least the bumpy road got smoothed out >> tho. It seems to be working again. Maybe next sync will be back to >> normal. > I do one sync a day, of my LAN server, and sync anything else to that. I > don't > know how long it took today because I have it on a cron job at night. :-) > I usually sync about twice a week, sometimes three if I see something I want or need. I just run my desktop here so updating isn't a huge deal. Sometimes I forget because I'm busy with other things and I might go a week or more without a single sync up. When I used to run several rigs, I'd sync one rig and then sync the others to my main rig. I try not to sync to often. Dale :-) :-)
[gentoo-user] testing system + gcc-5.2 anyone?
Hello, Just for grins, I'm thinking about installing a gentoo system that is (~) testing and newer codes and setting gcc-.5.2 as the default compiler. Anyone doing this yet? Will it mostly work or should I wait? Workstation with lxqt-0.9x. Hardened? What are the chances if it is set up (amd64) as hardened to work reasonable well as a platform for testing new codes/ebuilds? Caveats? or Suggestions? James
Re: [gentoo-user] Missing digest for *** Tree looks messed up.
On Mon, Aug 10, 2015 at 11:12 AM, Peter Humphrey wrote: > On Monday 10 August 2015 09:13:01 Dale wrote: > >> I might add, sync is taking a LONG time again. Of course, my DSL is a >> bit slower than some folks. At least the bumpy road got smoothed out >> tho. It seems to be working again. Maybe next sync will be back to >> normal. > > I do one sync a day, of my LAN server, and sync anything else to that. I don't > know how long it took today because I have it on a cron job at night. :-) > Well, if you synced with all broken manifest files, and re-synced with all fixed manifest files, you'd expect one file to be updated for every package in the repository, so that would be a long sync (but not quite as long as the original one). This was never intended to be a user-visible change (hence no news, etc). The digest issue was an oversight which was fixed. At this point rsync should work as it always did, minus one really long sync. The main thing you'll probably see is that the headers of the ebuilds all contain git hashes instead of cvs revisions. -- Rich
Re: [gentoo-user] Missing digest for *** Tree looks messed up.
On Monday 10 August 2015 09:13:01 Dale wrote: > I might add, sync is taking a LONG time again. Of course, my DSL is a > bit slower than some folks. At least the bumpy road got smoothed out > tho. It seems to be working again. Maybe next sync will be back to > normal. I do one sync a day, of my LAN server, and sync anything else to that. I don't know how long it took today because I have it on a cron job at night. :-) -- Rgds Peter
Re: [gentoo-user] Missing digest for *** Tree looks messed up.
Rich Freeman wrote: > On Sun, Aug 9, 2015 at 8:15 PM, Dale wrote: >> I'm sure I'm not alone on monitoring -dev to see upcoming changes. I >> noticed they switched to git or something and it seems to have caused a >> bit of trouble. > There are a few issues they're working through, but nothing really > serious. There were bound to be a few bumps with the change, and most > of the -dev posts are around trying to re-establish conventions, > especially around things like commit comments. The desire is to make > the history easy to read, parse, etc, but it isn't really stopping > work from getting done and nobody is going to care if their history > looks a little different. I was expecting a bump but not climbing a hill. lol Breaking things to the point I can't emerge anything, that's a pretty big bump. ;-) Makes me want to get out my tractor and box blade. >> At least I think it may have. I did my usual 'eix-sync >> && emerge -uvaDN world'. The sync took MUCH longer than usual. I'm >> talking a WHOLE LOT longer than usual. My first thought, one time thing >> because of the changes, maybe. Then I got a screen full of this sort of >> stuff. > Interesting. As I understand it rsync generation should be turned > off, but maybe some changes did make their way out. I don't believe > commits are getting to the rsync servers right now, so you might see a > delay in package updates for a day or so. > > Whether you've already seen it or will see it in the future, I would > expect the first rsync to be much longer. The git migration probably > touched virtually every file in the tree in some way, which means that > rsync is going to be modifying just about everything. > > I think it actually remains to be seen whether rsync is still the > fastest way to sync the new tree. If you sync from anonymous git > (which is supported by repos.conf) that would probably be pretty > efficient, since by design git keeps track of what did and didn't > change and it doesn't need to read every inode in /usr/portage to > figure it out, unlike rsync. I made a validator that finds what > changed between git revisions and you can do it VERY efficiently by > comparing the tree one directory level at a time (you can tell whether > anything in app-backup changed in a commit without having to read any > of the files, and if something changed you can repeat that one level > at a time until you read the actual files that changed - it is a O(log > base ) tree search times the number of commits (O(n))). > Now, for enough time passing (many months most likely) rsync might be > more efficient since at some point you end up reading almost all the > files anyway and rsync doesn't care if a file changed three times or > if it changed once. > > TL;DR - don't worry about it too much, but don't be surprised if > emerge --sync doesn't give you anything new for a day or two. You can > of course clone any of the URLs under > https://gitweb.gentoo.org/repo/gentoo.git/ to get the latest changes > now straight from git. We're up to 210 commits in git already today. > > I'm sure the transition could have been less bumpy, but I'm glad we're > finally seeing it happen. This has been in the works for a very long > time and sometimes you just have to pull the trigger. If rsync is > down for a day it isn't the end of the world. > > Oh, and a historical repo is posted at: > https://github.com/gentoo/gentoo-gitmig-20150809-draft > (that isn't official - I'm sure the official one will be > gentoo-hosted, but robbat has his hands plenty full already) > > -- > Rich > > It appears it was live even if it wasn't supposed to be. I got the updated version. Maybe someone forgot to flip a switch until things got settled?? Oh well. I've been reading -dev for ages. I been using Gentoo since about 2003. I try to at least keep a eye on the changes that are coming. I was aware that the git change was coming and have read where many are well, tickled pink about it. I'm fine with it because it seems to be a process that is heading toward something better. I just wasn't expecting this little hick-up. At least it wasn't that other thing that really gets on my nerve, that I don't want to mention. ;-) It broke my rig. That ain't good. I'm going to miss p.g.o. Sometimes, I go there and look to see if anything I'm interested in has been updated. KDE, Firefox, GIMP, k3b etc etc. If they haven't, I generally wait a day or so, especially if I know a update is coming and as soon as it is available, I want to sync and update. That saves a tiny fraction of load on servers and a little of my time as well. I see that someone else filed a bug about this. That was my reason for asking. I wanted to be sure it was a bug and not just a bad sync, corrupted bad not just a bumpy road bad, before I filed one. If I file a bug, I'm pretty much positive it is a bug. Anyway, here it is and it seems to be fixed. https://bugs.gentoo.org/show_bug.cgi?id=557184
Re: [gentoo-user] GCC-4.9?
On Mon, 10 Aug 2015 13:58:19 +0100, Peter Humphrey wrote: > > I've been using ~amd64 GCC on my MythTV boxes, which run mainly > > stable, for a long time. I would keep 4.8 installed too, just in case > > the odd package still doesn't like 4.9. Ironically, on my MythTV > > boxes, the only package that fails with 4.9 is MythTV :-O > > That's reassuring - thanks Neil. Will I also have to upgrade bin-utils > and libtool to ~ versions? I think those two need recompiling with a > new gcc version, before any of the rest of the system. I really can't remember, but I'm sure portage will tell you if they do. -- Neil Bothwick I backed up my hard drive and ran into a bus. pgpLAcjNMLLDB.pgp Description: OpenPGP digital signature
Re: [gentoo-user] GCC-4.9?
On Monday 10 August 2015 13:03:14 Neil Bothwick wrote: > On Mon, 10 Aug 2015 11:32:01 +0100, Peter Humphrey wrote: > > Has anyone any advice on whether it's a good idea to add a keyword to > > gcc-4.9.2 so that I can make progress here? This is a stable box and > > I'd like to know whether this one, rather central ~amd64 package would > > cause trouble. > > I've been using ~amd64 GCC on my MythTV boxes, which run mainly stable, > for a long time. I would keep 4.8 installed too, just in case the odd > package still doesn't like 4.9. Ironically, on my MythTV boxes, the only > package that fails with 4.9 is MythTV :-O That's reassuring - thanks Neil. Will I also have to upgrade bin-utils and libtool to ~ versions? I think those two need recompiling with a new gcc version, before any of the rest of the system. -- Rgds Peter
Re: [gentoo-user] GCC-4.9?
Neil Bothwick wrote: > On Mon, 10 Aug 2015 11:32:01 +0100, Peter Humphrey wrote: > > I've been using ~amd64 GCC on my MythTV boxes, which run mainly stable, > for a long time. I would keep 4.8 installed too, just in case the odd > package still doesn't like 4.9. Ironically, on my MythTV boxes, the only > package that fails with 4.9 is MythTV :-O Not replying to the OP, but your problem may be this one: https://bugs.gentoo.org/show_bug.cgi?id=516692 Adding -fno-devirtualize worked for me, although reading through the bug report maybe I was lucky. raffaele
Re: [gentoo-user] GCC-4.9?
On Mon, 10 Aug 2015 11:32:01 +0100, Peter Humphrey wrote: > Has anyone any advice on whether it's a good idea to add a keyword to > gcc-4.9.2 so that I can make progress here? This is a stable box and > I'd like to know whether this one, rather central ~amd64 package would > cause trouble. I've been using ~amd64 GCC on my MythTV boxes, which run mainly stable, for a long time. I would keep 4.8 installed too, just in case the odd package still doesn't like 4.9. Ironically, on my MythTV boxes, the only package that fails with 4.9 is MythTV :-O -- Neil Bothwick "I heard Tasha Yar is the Enterprise's expert on Data entry." pgpXiDUPDN6Rm.pgp Description: OpenPGP digital signature
[gentoo-user] LVM not accessible after reboot
hello list, Using grub2 i have gentoo box where i did a raid5 on 4 disks. On the raid i created a lvm partition and created some logical volumes. All is going fine. But when rebooting the machine "sometimes" the lvm is not available and the logic volumes did not get mounted. I have to reboot the machine several times since the partitions are mounted after reboot. In /etc/default/grub i set: GRUB_PRELOAD_MODULES="lvm xfs mdraid09 mdraid1x" so it should work after reboot. Any ideas why i have to reboot the machine sometimes multiple to access my logical volumes again? my ideas is that LVM2 is not ready at the time of mounting partitions. how can i do this? thanks marko
[gentoo-user] GCC-4.9?
Hello list, I'm having trouble compiling xf86-video-virtualbox, and the bug report [1] says that gcc-4.9 is required to compile it. Has anyone any advice on whether it's a good idea to add a keyword to gcc-4.9.2 so that I can make progress here? This is a stable box and I'd like to know whether this one, rather central ~amd64 package would cause trouble. A comment on the bug report also mentions earlier kernel versions being ok, so I tried booting gentoo-sources-3.14.48 but it didn't help. Thanks in advance. 1. https://bugs.gentoo.org/show_bug.cgi?id=550202 -- Rgds Peter
Re: [gentoo-user] Missing digest for *** Tree looks messed up.
2015-08-10 10:55 GMT+02:00 Mickaël Bucas : > > > 2015-08-10 2:15 GMT+02:00 Dale : > > > > Howdy, > > > > I'm sure I'm not alone on monitoring -dev to see upcoming changes. I > > noticed they switched to git or something and it seems to have caused a > > bit of trouble. At least I think it may have. I did my usual 'eix-sync > > && emerge -uvaDN world'. The sync took MUCH longer than usual. I'm > > talking a WHOLE LOT longer than usual. My first thought, one time thing > > because of the changes, maybe. Then I got a screen full of this sort of > > stuff. > > > > > > > > * Missing digest for > > '/var/cache/portage/tree/media-libs/fontconfig/fontconfig-2.11.1-r2.ebuild' > [...] > > I got a similar list about all my installed packages. The reason is that the Manifest files have changed. > Before there was a digest for each ebuild in a category, as can be seen here : > https://github.com/gentoo/gentoo-portage-rsync-mirror/blob/master/kde-base/knotes/Manifest > Now there is only the digests for source files > https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-base/knotes/Manifest > > > > > Can I take that "just saying" above back and say FUBAR instead? :-( > > > > Thoughts?? > > > > Dale > > Either the Manifest generator encountered a problem, or the digest for ebuilds is not necessary in new versions of portage, but the latter is less likely in my opinion as it would lower overall security. > I didn't find a bug about this subject, but I don't really know what and where to search... So the answer was in Git history, in the first commit : https://gitweb.gentoo.org/repo/gentoo.git/log/kde-base/knotes/Manifest?showmsg=1 "3. Transform all Manifests to thin" https://wiki.gentoo.org/wiki/Repository_format/package/Manifest "A Thin Manifest is a Manifest file in which checksums are stored only for distfiles (*DIST* type) and not for files inside the repository. The motivation for that is whenever the repository is fetched through a VCS which ensures local file integrity already." I think I understand the problem a bit better : the CVS repository contained classic Manifest files, and was exposed directly to rsync. The Git repository contains only thin Manifest, but has been set as the source for rsync at one point ! This has already been reported, and solved. https://bugs.gentoo.org/show_bug.cgi?id=557184 Best regards Mickaël Bucas
Re: [gentoo-user] Missing digest for *** Tree looks messed up.
On Sunday 09 August 2015 21:05:07 Rich Freeman wrote: > Whether you've already seen it or will see it in the future, I would > expect the first rsync to be much longer. The git migration probably > touched virtually every file in the tree in some way, which means that > rsync is going to be modifying just about everything. Yeah, 135,000 files transferred today. -- Rgds Peter
Re: [gentoo-user] Missing digest for *** Tree looks messed up.
2015-08-10 2:15 GMT+02:00 Dale : > > Howdy, > > I'm sure I'm not alone on monitoring -dev to see upcoming changes. I > noticed they switched to git or something and it seems to have caused a > bit of trouble. At least I think it may have. I did my usual 'eix-sync > && emerge -uvaDN world'. The sync took MUCH longer than usual. I'm > talking a WHOLE LOT longer than usual. My first thought, one time thing > because of the changes, maybe. Then I got a screen full of this sort of > stuff. > > > > * Missing digest for > '/var/cache/portage/tree/media-libs/fontconfig/fontconfig-2.11.1-r2.ebuild' [...] I got a similar list about all my installed packages. The reason is that the Manifest files have changed. Before there was a digest for each ebuild in a category, as can be seen here : https://github.com/gentoo/gentoo-portage-rsync-mirror/blob/master/kde-base/knotes/Manifest Now there is only the digests for source files https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-base/knotes/Manifest > > Can I take that "just saying" above back and say FUBAR instead? :-( > > Thoughts?? > > Dale Either the Manifest generator encountered a problem, or the digest for ebuilds is not necessary in new versions of portage, but the latter is less likely in my opinion as it would lower overall security. I didn't find a bug about this subject, but I don't really know what and where to search... Who could we ask for more insight into that strange behavior ? Best regards Mickaël Bucas
