bug#25020: guix refresh does not discover updates if URLs are "non-standard"
Hi, > Hartmut Goebel wrote: > >> Hi, >> >> I just updated kde-frameworks to 5.28 and found that not all updates >> have been discovered. >> >> Those where the URL is following the standard schema where found: >> "mirror://kde/stable/frameworks/" (version-major+minor version) "/" name >> "-" version ".tar.xz")) >> >> Those having a different name of the archive or having an additional >> directory behind the first version-part have not been found. >> >> Update found for: >> >> (name "extra-cmake-modules") >> (version "5.27.0") >> (source (origin >> (method url-fetch) >> (uri (string-append >> "mirror://kde/stable/frameworks/" >> (version-major+minor version) "/" >> name "-" version ".tar.xz")) >> >> Update not found for (archive-name has "5" appended): >> >> (name "oxygen-icons") >> (version "5.27.0") >> (source (origin >> (method url-fetch) >> (uri (string-append >> "mirror://kde/stable/frameworks/" >> (version-major+minor version) "/" >> name "5" "-" version ".tar.xz")) >> >> Update not found for (additional directory level): >> >> (name "kross") >> (version "5.27.0") >> (source >> (origin >>(method url-fetch) >>(uri (string-append >> "mirror://kde/stable/frameworks/" >> (version-major+minor version) "/portingAids/" >> name "-" version ".tar.xz")) Fixed for oxygen-icons in commit 683c5ab70accb909697717bb61741a7692c52c09. I can’t tell about kross because it’s not committed yet. However, I can tell the logic behind ‘latest-kde-release’ in (guix gnu-maintenance) recurses in sub-directories, Ludo’.
bug#22629: ‘guix pull’ and external dependencies
Hello, Chris Marusich skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> So I think what we need to do is for “guix pull-ng” to build and install >> a complete ‘guix’ package, and to manage it pretty much like other >> packages is managed, > > I think that's very reasonable. It seems more intuitive than the > current way 'guix pull' works. I suspect that managing the installed > version of Guix via the same Guix mechanisms that we use to manage any > other package might be the best, most intuitive solution. > > Would it simplify the problem if we packaged the "Guix client stuff", > the "Guix daemon stuff", and maybe the "Guix package definition stuff" > separately? Then a user could just install the "Guix client stuff" > package if she wanted to upgrade the Guix client tools, or the "Guix > package definition stuff" package if she wanted to get the latest > package definitions. It would be bad to separate package definitions from the rest because they are very much intertwined: package definitions depend on the definition of ‘package’, on build system implementations, and so on. We could have guix-sans-daemon though, if that helps (which I suspect is not the case). >> except not in the user’s main profile (because that could lead to >> undesirable behavior, > > If we don't store Guix in the user's main profile, where would it go? In “some sort of a profile” in ~/.config/guix/latest or similar. > It's not clear to me why it's riskier to store Guix in a profile rather > than outside the profile (but still in the store via the > $HOME/.config/guix/latest symlink), which is what 'guix pull' does now. > You seem to think it's riskier; I'm curious to know more about why. There’s the manifest format change issue I mentioned, or the inability to roll back if you install a broken Guix. >> where upgrading Guix creates a new generation, > > Why should upgrading Guix NOT create a new generation? I thought that a > new profile generation would be created any time you upgrade a package, > and I thought that was a good thing because it facilitates easy, > transactional roll-back. Perhaps I'm missing something. I’m suggesting that upgrading Guix creates a new generation (so we agree here), just not in the user’s profile. >> or, in theory, unrecoverable problems, where you cannot roll back >> because previous generations use an old Guix that does not understand >> the new manifest format.) > > Why would a change in manifest format be unrecoverable? It looks like > each profile generation contains a manifest file. Assuming that the new > Guix functions well enough to perform roll back, couldn't we just roll > back to the previous profile generation, where we would have both (1) > the old profile's manifest file, and (2) the previous Guix, which > understands that format? Since rolling back a profile is basically just > a symlink flip, I think the new Guix could probably do that even if it > didn't understand the old manifest format. Yeah, I think you’re right. :-) In general, I think my concern is more that we cannot promise that downgrading Guix will work, considering the potential for on-disk format changes. It’s a bit theoretical, but not entirely sci-fi either. >> The difficulty is that ./configure && make && make install in Guix takes >> some time, and we probably wouldn’t want to do that on each ‘guix pull’ >> invocation (esp. with Guile 2.2’s compilation times.) >> >> So we may have to provide substitutes of Guix itself, and arrange so >> that ‘guix pull’ pulls up to a tag for which we have substitutes. > > What if we had a special package version of Guix (e.g., "v0.11.0") which > we kept up to date via some mechanism? Maybe something as simple as a > Git hook could help increase the likelihood of that version being > substitutable. For example, we could have a Git hook that prevents > someone from checking in a change if the latest Git tag does not > correspond to a Guix package version. Maybe we can do better. Right, we could do something like that. There are still non-zero chances that someone running ‘guix pull’ at an arbitrary point in time will have to build locally, which is not great. > I actually think it would be a good thing if we can run "guix pull" > without substitutes available. But it should use a substitute by > default, and "build from source" should be a fallback mechanism that the > user has to explicitly request, just like when installing new packages. > That would help avoid unexpectedly long "guix pull" invocations. Yes, using substitutes or falling back to source builds is always the default. Thanks for your feedback! Ludo’.
bug#24993: System installer grows brittle with time
David Craven skribis: > I have a nice one too. How to run guixsd on any hardware :) This is off-topic, and it is not what this project is about, as you know (well of course, we all want it to run on any hardware, just not at any cost!). Ludo’.
bug#24993: System installer grows brittle with time
Leo Famulari skribis:
> On Mon, Nov 28, 2016 at 08:45:39AM -0900, Christopher Howard wrote:
>> I was able to make more progress with the --substitute-urls=... option
>> you mentioned. However, later, when the system is building the
>> gnupg-2.1.13 drv (I did not pass --fallback, but it still builds stuff)
>> one of the 36 check tests fails ("tofu.test"), causing the build to fail.
>
> It will build stuff if it can't find a substitute (not an error).
> '--fallback' is only required when substitution fails (an error).
>
> That particular test failure was a bug in GnuPG's test suite that we
> worked around:
>
> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=d404a6f9711c8dcc1cc6cf55d8c07901aa450192
>
> Code with an expiration date is very annoying!
>
> It sounds like you will need to use `guix pull`.
>
> What do others think? Should we mention `guix pull` in the installation
> documentation?
I’m not a fan of this, for the reasons you gave.
> I'm skeptical for reasons described upthread. I think the real bug is
> that the installation image becomes brittle as time passes (so I changed
> the subject of my reply).
Right.
A solution that some suggested before (but for other reasons) would be
to include more packages on the installation image.
The image is currently slightly below 1G, but we could add binaries for
GTK+, Python, and a few other relevant packages. We’d need to find out
what makes sense and how much extra space it would take.
> this become less pressing when we have more storage space and can store
> substitutes for a longer period?
True.
The mirror has room to store things for a long period of time, but
there’s a subtle problem with non-deterministic builds: the mirror might
cache a narinfo and the corresponding nar, then the narinfo leaves the
cache, then a new narinfo is fetched from hydra.gnu.org, and at this
point the mirror has a narinfo advertising a hash that doesn’t match
that of its nar.
Of course the solution to this is reproducible builds, but the fact is
that we still have a bunch of non-reproducible packages.
I recently lowered narinfo caching time in the mirror because of that:
http://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=caaeb7bea3515e7ef45e33e5e75674f7b72c2f06
… but that’s not great since it means the mirror can lose narinfos
quickly, even though it has enough room to store them.
Ideas?
Ludo’.
bug#25036: make check-system hangs.
On Sun, Nov 27, 2016 at 11:58:39PM +0100, Ludovic Court??s wrote: John Darrington skribis: > Whenever I run > > make check-system TESTS=openssh > > it gets as far as: > > > PASS: tests/test-filter-redirector > TEST: tests/postcopy-test... (pid=10426) > /i386/postcopy: > > and hangs there indefinitely. The above lines seem to come from the test suite QEMU, so what you???re observing here is QEMU???s test suite hanging. You???d have to find out which of the qemu* packages we provide is failing. https://hydra.gnu.org/job/gnu/master/qemu-minimal-2.7.0.x86_64-linux You're right. qemu-minimal hangs at this test. J' -- Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. signature.asc Description: Digital signature
bug#25043: mount is unable to locate mount helpers
This was recently fixed in the core-updates branch.
J'
On Sun, Nov 27, 2016 at 03:18:41PM +0100, Tom ??ech wrote:
mount command from util-linux is expecting helpers in /sbin/
directory, which is not available on GuixSD.
If found it when I tried to mount manully NFS:
# mount -t nfs server:/some/path /mnt
Manual page of `mount' - section EXTERNAL HELPERS and strace seems to
agree:
...
stat("/sbin/mount.nfs", 0x7ffe421e9080) = -1 ENOENT (No such file or
directory)
stat("/sbin/fs.d/mount.nfs", 0x7ffe421e9080) = -1 ENOENT (No such file or
directory)
stat("/sbin/fs/mount.nfs", 0x7ffe421e9080) = -1 ENOENT (No such file or
directory)
getuid()= 0
geteuid() = 0
getgid()= 0
getegid() = 0
prctl(PR_GET_DUMPABLE) = 1
getuid()= 0
geteuid() = 0
getgid()= 0
getegid() = 0
prctl(PR_GET_DUMPABLE) = 1
stat("/run", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/etc/mtab", {st_mode=S_IFLNK|0777, st_size=17, ...}) = 0
lstat("/run/mount/utab", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("/run/mount/utab", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 3
close(3)= 0
mount("disk:/", "/mnt", "nfs", MS_MGC_VAL, NULL) = -1 EINVAL (Invalid
argument)
write(2, "mount: ", 7mount: ) = 7
write(2, "wrong fs type, bad option, bad s"..., 110wrong fs type, bad
option, bad superblock on disk:/,
missing codepage or helper program, or other error) = 110
write(2, "\n", 1
) = 1
write(2, " (for several filesystems "..., 108 (for several
filesystems (e.g. nfs, cifs) you might
need a /sbin/mount. helper program)
) = 108
write(2, "\n In some cases useful inf"..., 86
In some cases useful info is found in syslog - try
dmesg | tail or so.
) = 86
close(1)= 0
close(2)= 0
exit_group(32) = ?
+++ exited with 32 +++
The best approach to me seems to patch mount so it search PATH or
introduce some other environment variable to search helpers in.
--
Avoid eavesdropping. Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.
signature.asc
Description: Digital signature
bug#24993: System installer grows brittle with time
I have a nice one too. How to run guixsd on any hardware :)
(use-modules (gnu)
(gnu system nss)
(guix build-system trivial)
(guix download)
(guix git-download)
(guix packages))
(use-service-modules base networking)
(use-package-modules certs linux)
(define-public linux-firmware
(let ((commit "21e216f591bed97ec1adcda0e8b4b28ddf065433"))
(package
(name "linux-firmware")
(version (string-append "2016.11.27-" (string-take commit 7)))
(source (origin
(method git-fetch)
(uri (git-reference
(url (string-append
"https://github.com/wkennington/linux-firmware";))
(commit commit)))
(sha256
(base32
"0iiayy00zr3fk8xfi8i9vrbpg7r59n5vfzx9x7cpx6gjaja8czxa"
(build-system trivial-build-system)
(arguments
`(#:modules ((guix build utils))
#:builder
(begin
(use-modules (guix build utils))
(let* ((source (assoc-ref %build-inputs "source"))
(out (assoc-ref %outputs "out"))
(firmware (string-append out "/lib/firmware")))
(mkdir-p firmware)
(copy-recursively source firmware)
(home-page "https://github.com/wkennington/linux-firmware";)
(synopsis "Linux firmware")
(description "Linux firmware.")
(license #f
(define-public linux
(package
(inherit linux-libre)
(version "4.8.11")
(source (origin
(method url-fetch)
(uri (string-append
"https://cdn.kernel.org/pub/linux/kernel/v4.x/";
"linux-" version ".tar.xz"))
(sha256
(base32
"03w90vfjfcya38mcp1njasa5c67za203sgp9n3w52gms13s443yc"))
(operating-system
(host-name "system76")
(timezone "Europe/Zurich")
(locale "en_US.UTF-8")
(kernel linux)
(firmware (list linux-firmware))
(bootloader (grub-configuration (device "/dev/sda")))
(file-systems (cons (file-system
(device "my-root")
(title 'label)
(mount-point "/")
(type "ext4"))
%base-file-systems))
(users (cons (user-account
(name "dvc")
(comment "David Craven")
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "video"))
(home-directory "/home/dvc"))
%base-user-accounts))
(packages (cons* nss-certs
%base-packages))
(services (cons* (dhcp-client-service)
%base-services))
;; Allow resolution of '.local' host names with mDNS.
(name-service-switch %mdns-host-lookup-nss))
bug#25045: [Website] Packages page takes too long to load
Ludovic Courtès writes: > Luis Felipe López Acevedo skribis: > >> On 2016-11-28 12:00, Alex Sassmannshausen wrote: >>> Hi Luis, >>> >>> Indeed, I had a first bash at solving this problem by providing a >>> set of >>> static html pages paginated by the first letter of the package name. >>> >>> I'm not particularly wedded to this solution, so if you feel strongly >>> about going another way, I'd be keen to hear/see about it. >>> >>> In the meantime, I'm open to testing/feedback. I will unfortunately >>> not >>> be able to put work into this until at least Saturday/Sunday, as some >>> Perl work has higher priority at the moment. >>> >>> But let me know if you have questions or feedback! >>> >>> Best wishes, >> >> Hi, Alex :) >> >> The solution I had in mind includes an alphabetic index, and >> pagination as well. However, it includes a few more things, and would >> take some time to design and implement. So I think we should use your >> patch to fix the size issue as soon as possible. > > I agree! > > Alex, was there anything left to address? If not, feel free to push. > :-) Having pushed some other stuff around my calendar, I should now be able to spend some time on polishing the patch tonight. >> For what is worth, this is what I had in mind: >> >> /packages/ >> First page of the list of packages. Packages listed here only provide >> a summary: package logo (if any), name, version, description, and an >> indicator if it has issues. This page also has filters to find >> packages (for now, alphabetic filter. In the future, category filter, >> and search box). >> >> /packages/page/N/ >> Page N of the list of packages. >> >> /packages/a/ >> First page of the list of packages whose name starts with A. Packages >> are presented the same way as in /packages/. >> >> /packages/a/page/N/ >> Page N of the list of packages starting with letter A. >> >> /packages/icecat/X.Y.Z/ >> Page with details about IceCat version X.Y.Z. It includes all the >> information about this package, including its issues (which are >> currently listed in a separate page along with the issues of other >> packages: /packages/issues.html). Including the issues of a package in >> its detail page could avoid having the current issues page grow too >> much, like the current Packages page. >> >> This static pagination and filtering would generate A LOT of pages, >> but of reasonable size for web browsers to load. The routing schema looks pretty neat to me! :-) > Sounds like a good plan as well, though that’s indeed a lot of web pages > for that rusty CVS repo to handle… > > Medium-term, I think we should consider a solution involving pages > generated on the fly server-side, with a caching proxy (nginx!) in front > of it. We’ll have to seek assistance from the gnu.org web masters, but > ISTR they were not against that idea. This sounds like a pretty good idea — though I probably won‘t have time to take the initiative here, I'm happy to do review and discussion of patches. Alex > > Thanks! > > Ludo’.
bug#24993: System installer grows brittle with time
On Mon, Nov 28, 2016 at 09:33:36PM -0500, Leo Famulari wrote:
> On Mon, Nov 28, 2016 at 08:45:39AM -0900, Christopher Howard wrote:
> > I was able to make more progress with the --substitute-urls=... option
> > you mentioned. However, later, when the system is building the
> > gnupg-2.1.13 drv (I did not pass --fallback, but it still builds stuff)
> > one of the 36 check tests fails ("tofu.test"), causing the build to fail.
>
> It will build stuff if it can't find a substitute (not an error).
> '--fallback' is only required when substitution fails (an error).
>
> That particular test failure was a bug in GnuPG's test suite that we
> worked around:
>
> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=d404a6f9711c8dcc1cc6cf55d8c07901aa450192
>
> Code with an expiration date is very annoying!
>
> It sounds like you will need to use `guix pull`.
>
> What do others think? Should we mention `guix pull` in the installation
> documentation?
>
> I'm skeptical for reasons described upthread. I think the real bug is
> that the installation image becomes brittle as time passes (so I changed
> the subject of my reply).
>
> Does anyone have ideas to mitigate this? Can we tweak the mirrors? Will
> this become less pressing when we have more storage space and can store
> substitutes for a longer period?
>
>
Currently when people pop into IRC saying they're having trouble with
their install, the suggestion is "run guix pull, use one of the
'default' configurations and then reconfigure after you're finally up
and running, and my favorite, no one really knows why ratpoison is the
fallback WM even when it's not listed in the OS config."
I think we should add 'guix pull' as a regular part of the install
process, and we should add more example configs so people can mix and
match them with fewer issues by virtue of having more examples to
compare against. It would also give us examples to point to for 'how to
use encrypted partitions', 'how to not use wicd', 'how to use a
swapfile', 'i want my kid's account's shell to be 'bambam' or
'gcompris', how do I do that?'
--
Efraim Flashner אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
