IRC channel logs
2024-09-30.log
back to list of logs
<meaty>is there any automation for making packages that provide a systemd service work with shepherd? or something like 'guix import systemd-service *.service' <podiki>no, and I don't think shepherd has all the capabilities of systemd services, at least not in some drop-in way <podiki>(e.g. exposing or not different directories and hardening, user overrides, etc.) <mirai_>meaty: no automation but it doesn't sound out of reach <mirai_>sure some features will be missing as podiki pointed out, but it sounds doable <amano>Is guix compatible with turnstile + seatd? <amano>turnstile tries to manage home service manager. <amano>guix tries to manage its own. <amano>You can replace elogind with seatd and something that create xdg_runtime_dir. <bumble>my guix system uses seatd only and not elogind <bumble>have not used or heard of turnstile before <amano>bumble: But, elogind is still installed, right? <amano>My gentoo system doesn't use elogind, but has it. <amano>usbguard require polkit which requires elogind. <amano>Okular relies on polkit indirectly. <amano>How do you prevent elogind from being launched? <amano>I also use dumb_runtime_dir for creating XDG_RUNTIME_DIR. <Rutherther>You dont add it to your system services, so it will not launch <amano>Some applications will trigger elogind. <amano>system dbus will launch elogind if applications try to communicate with elogind through system dbus. <amano>Execute `pgrep -af elogind`. <amano>You may find elogind running. <amano>guixrus channel provides sway-seatd. <bumble>I don't think I have elogind running, I do have sans-dbus configurations for some things in my system config <bumble>for example, wpa-supplicant-service-type includes the option (dbus? #f) <bumble>well that's the only one, actually <Rutherther>How would dbus launch something it doesnt know about? It doesnt even have to be present in the system at all when you dont have it in services... <Rutherther>Dbus launches services that are in services folders. Elogind wont be there if you dont put it to your system <amano>dbus won't find elogind on guix? But, it will find elogind on gentoo linux. <amano>That's the consequence of global packages. <amano>So, guix users want to avoid elogind? <bumble>the system config I'm using has `(service seatd-service-type)` and then later `(delete login-service-type)` <amano>elogind has to align with systemd which is controlled by IBM through redhat. I don't know whether guix users specifically want to be free from corporate control of linux softwares. <bumble>guix steers users into dbus, elogind and other such things, my setup is not usual <amano>dbus is unavoidable if you want to use pipewire and xdg-desktop-portal. I cannot avoid xdg-desktop-portal if I want to use screen sharing on sway. <bumble>however, while guix does install elogind dbus and other annoything things here, it does not require me to use them and the system I am typing this from does not use them <bumble>I am using pipewire without dbus <amano>Can you open URLs on web browsers through scripts without dbus? <bumble>it is not too difficult and it is less difficult than it was about a year ago <amano>In my experiences, if I want to open multiple URLs on web browsers, I needed dbus. <amano>I mean I wanted to open URLs through a script. <amano>Doesn't pipewire-pulseaudio require dbus? <Rutherther>bumble guix doesnt install elogind. You probably put desktop services to your services list that contains it <bumble>guix installs a lot of stuff I don't use <amano>dbus is still required for xdg-desktop-portal and other things. <bumble>I'm not using xorg but guix installs a lot of xorg and xorg-related things <amano>keyring seems to require dbus. <amano>xdg-desktop-portal is annoying, but is required for screen sharing on sway. <bumble>I don't know about those but, yeah, many things expect dbus and if you want to forego dbus you might need to compromise on some things <bumble>for example audio up / down brightness up / down... you probably need to "show" your own indicators for those and not use (most things) that rely on dbus for that <amano>elogind can be avoided, but the reward is not really worth the effort it takes to avoid elogind. <bumble>I basically agree but am still glad to not be using elgoind here <bumble>and my own experience on this machine is pretty good <amano>I'd rather lock down elogind through apparmor. <bumble>the reason my system is using wpa-supplicant-service is because wpa-supplicant does not rely on dbus and iwd does <amano>bumble: You may want to stop using WiFi altogether for desktop computers. <bumble>there is also eiwd, which is like eudev and removes the dbus reliance, but there is no guix package for eiwd and the author admits that it leaks memory because of the related changes <amano>Ethernet is always better and simpler. <amano>LiFi for home situations, but LiFi is not widespread, yet. <bumble>basically agree but some areas are better for wired than others and my current circumstance is not good for wired connections <amano>And, I minimize EMF in my life for long-term health. Basically, EMF is like cigar smoking. You may not feel anything, but it increases inflammation and decreases cognitive abilities somewhat. <amano>It adds noise to brain and disrupts cells. <amano>Brain fog decreases if you reduce EMF in your environment. <amano>Brain is an electromagnetic organ. EMF is going to disrupt the brain. <amano>Does elogind have any effect on security or privacy? I was afraid of elogind becoming a spyware. <amano>I mean systemd becoming spyware. <bumble>one can't take a stand for everything... the food we eat, the phones we use, the hardware around us in our cars our computers etc... I take a principled stand in one area and the other areas are compromised. starting to accept this as a fact of life <amano>Elogind is separate from systemd. <amano>Elogind is probably okay since it doesn't just copy and paste systemd. <bumble>elogind entangles one to the systemd platform of software <amano>elogind is not entangled with systemd. It is entangled with corporate softwares. <amano>But, elogind doesn't force you to use systemd-resolvd and other systemd stuff. <amano>systemd is trying to turn linux into windows where microsoft tries to take a screenshot of your system every few minutes. <amano>Windows actually tried to take a screenshot of your monitor frequently.... <amano>They are just going to do this with open-source..... <amano>Open-source doesn't mean free from control. <bumble>yeah I read about that. people contacted me after being out of touch saying they read this article about windows and now they really need to get off windows and use linux, what do I think they should do first? <amano>Don't expect people to learn guile scheme and guix. <bumble>people (probably) won't agree with this but I told them to probably start with ubuntu and try the usb environment there <amano>PopOS is better than ubuntu in terms of privacy. <bumble>I was thinking they could get started that way then navigate themselves from there <bumble>I don't know if they did it or not I just talked to them recently after a long period a week or so ago didn't think to ask about it <bumble>maybe I'll recommend popos in the future if that happens again <amano>A lot of people refuse to hit "update button" on mac os. <amano>Hitting update button is easy. <amano>I think eudev and elogind will largely be free from spying. So, I wouldn't obsess with avoiding them. <bumble>bad elements can also sponsor useless features, force changes that break compatibility along different points, suck attention away from other more deserving places and other such non-sense <amano>elogind might be replaced, but eudev has no replacement, yet. <amano>There is no option as long as bad corporations write tons of bad softwares. <bumble>are you using guix now or exploring using it? how has your experience with it been? <bumble>have you used nixos (I have not)? how does it compare? <amano>bumble: I am on gentoo linux, but I may learn guix in the future. <amano>Gentoo linux is messy but more flexible than guix. <amano>I have encrypted zfs root on gentoo linux. Guix can't do this. <bumble>oh yeah I think I saw your message about it when lurking the mailing list <Square2>I have used Nix as a package manager (naapm) quite a lot, but never done a full NixOS install. It's fantastic. <bumble>Square2: thanks for sharing that <Square2>I use it for creating development environments and build pipelines. Just check them in and they work as expected 99% of the time. What causes 1% problems I'm not sure I can attribute to nix. <skrech>Hey, is there a possibility to pin versions of dependencies (in inputs/propagated-inputs) of a package? <taeaad>amano: Your whole body is an EM organ. <Rutherther>skrech sure, make a definition of a package with specific version and put it in the inputs. You can inherit the current one, but you might run into problems at some point when the build process will change <attila_lendvai>skrech, yep, by introducing a new foobar/pinned variable that holds the package, and using that. there are some examples in the codebase. you can also grep for a foobar-next pattern, but i think the new consensus is to use the foobar/pinned <skrech>Thanks, that's what i've imagined -- I need to define new package pinned to a specific version, then update te dependency in the package I'm working on... I can't use the xyz@3.2.1 syntax <Rutherther>skrech that syntax is called specifications. You could use them even in inputs, but it is not very common and not very specific. The package you end up with could change based on other package of same version being added to the channel. <attila_lendvai>skrech, there's a strange duality/redundancy in guix between the scheme module namespace and the package repository. they both hold packages, but there's no 1-to-1 mapping between the two. if you ask me, it's the kind of redundancy that should be resolved because it leads to all kinds of confusion. but i don't have a proposal about the how. <skrech>the problem I'm trying to resolve is that `clojure-tools` depends on `clojure-tools-deps`, which itself depends on maven-resolver-* libraries. It seems that clojure-tools-deps depends on older version 1.8.* of maven-resolver-* and guix has maven-resolver 1.9-* which is incompatible... So, my only way now is to define maven-resolver-*-1.8 packages and switch to them in clojure-tools-deps <skrech>the problem is that maven-resolver-* are 6-7 libraries, that all need to be defined on older version... :( <skrech>it's kind of pity to have a braking change between version 1.8 and 1.9... <attila_lendvai>it would be nice if the old definitions would not be overwritten by the version update, but were available forever to use, e.g. as dependencies. it's not a trivial feature to implement, though. it would introduce another dimension to the entire guix codebase. kinda like reifying the time-machine feature as a first class element. <nckx>Bringing it fullish-circle, <should be resolved […] but i don't have a proposal about the how> is exactly how I feel about inferiors. <adanska>is there a savannah degredation atm? cant access the repo or do a pull... <efraim>the version of rust on the rust-team branch is too new to build icecat <efraim>adanska: I failed to git clone the gnuzilla repo <nckx>adanska: Yes. It's been on the blink for... months now? and this seems to be the latest downtime. <adanska>right. hope they can wrangle it again, i wonder how the savannah hosting works, and why it seems to have frequent downtime. not to bash the savannah sysadmins, they have their work cut out for them. its probably a funding issue <efraim>adanska: savannah git seems to be back up <futurile>ooh someone committed all the patches that had been reviewed / passed ci for master - nice <attila_lendvai>compiling dropbear with debug trace available is +4kb in the binary. should i add that to the package definition? then users can specify -v to increase verbosity of the log. <futurile>attila_lendvai: I'd say that's sufficiently useful for a minor cost - lets be honest debbugging ssh connections is a "thing" <cow_2001>something about a missing function, but i see that there is a (require 'greader) from where the function is being used, so it should be defined <cow_2001>./greader.el defines the function greader-get-language, and ./greader-dict.el (require 'greader), so it should have greader-get-language <attila_lendvai>futurile, yeah, 4k is not much, but i have some doubts whether debug trace could introduce vulnerabilities that otherwise are not present... <sepeth>Hi Guix, I have a package built semi-successfully and it is in the store, I want to be able to keep building since the output is broken, but when I run guix build now, I just get the output dir. How do I force build? <apteryx>sepeth: add --no-grafts --check to your build command <apteryx>but if you haven't touched the package definition, it should give you the same thing again (still broken) <apteryx>assuming the package can be built reproducibly (most are -- if it's not, it's a bug!) <futurile>sepeth: you can remove it from the store with guix gc --delete /blah/blah right; or if you want to force a rebuild do guix build <your normal options> --check <sepeth>apteryx: Right! I was actually at a point where I needed to change the package definition, which solved the problem in a different way ^-^ <sepeth>futurile: Thanks! I was wondering about that, given the store is read only, one can't just rm it ^-^ <sepeth>Separate question, where can I learn more about the regex syntax for substitute*? It complains when I do \s* with "invalid character in escape sequence: #\s" <nckx>It's just (extended) regexp, but don't forget that you need to escape escape characters. <nckx>"\s" means ‘the Guile escape sequence \s’ which is invalid. <nckx>I didn't say it wasn't confusing. <nckx>You'll see a lot of "\\$\\(MAKE_VAR\\)" etc. for this reason. <nckx>(‘…unless you want an obsolete—sorry, ‘basic’, you basic b—regexp, then you…’ gotta love the opinionated GNU manuals.) <nckx>So Guix uses the ‘extended (“modern”) regexps’. <sepeth>Thank you nckx, futurile, the link is super useful also <nckx>As for unescaped ‘(’ and ‘)’, a wild nckx tangent appears. An under-used and -documented feature of substitute* is capturing matches with brackets: (substitute* "foo.c" (("(char|int) (foo|bar)" entire-match type name) (format #f "/* the expression ‘~a’ declares the ~a named ‘~a’ /*" entire-match type name))). You can do cool things with that. <nckx>This is in no way related to your original question. You're welcome. <willcl-ark>Am I correct in understanding that, to add a rust binary package, I need to satisfy all its Cargo.toml dependencies with other guix packages? (i.e. if some deps don't exist as packages yet, then I need to add those first, and so on.) Or is there a way to build all dependencies automagically? <sepeth>nckx: oh that's nice. I haven't need the capture bit yet. I will give my thanks when I do :P <sepeth>willcl-ark: guix import crate -r was useful to me. You may need to tweak things but it will do the bulk of the work. <sepeth>It also takes --recursive-dev-dependencies. <willcl-ark>sepeth: ok thanks, I'll take a go with that. This crate has ~60 dependencies and a fair few missing, so just wondering whether I am gunna have to create all of _those_ (and possibly *their* deps), too :o <futurile>willcl-ark: yes, you probably will. You can look for places where you can snip the dependency graph, because sometimes they're not all needed. <futurile>willcl-ark: I would start having a go at it - and then talk to efraim and see if he has suggestions <sepeth>willcl-ark: afaik, yes! but if you can directly use cargo as well if you are hacking on a rust project. <futurile>willcl-ark: that's what I did when I started on a package and it was much easier as he was able to tell me places I didn't have to package <willcl-ark>Ok thanks all. So is the output of `guix import crate -r` not enough necessarily to build the package for myself? It looks pretty comprehensive to me at first glance <futurile>willcl-ark: it will probably be sufficient to build it for yourself. <futurile>willcl-ark: it wouldn't be at a good enough quality level to contribute up to the project. It doesn't describe the package well, I think it misses out development crates etc <futurile>willcl-ark: also be aware that generally speak the rust-team branch will be ahead of master <efraim>there's some ~300 packages on the rust-team branch <efraim>the downside of the recursive import of crates is we still need to build them to make sure they're correct, so we do still need the cargo-development-inputs <efraim>also, once I figure out icecat with the newer rust I'll probably put the rust-team branch in the merge queue <Rutherther>Why is this solution prefered to something like Nix has, where the dependencies are fetched via cargo? <efraim>so that we can download all the crates ahead of time, or patch any of their sources without patching each other package which uses them <efraim>that said, we're open to other ideas for doing rust stuff <Rutherther>Yeah, its true the patches are not so nice with that other way. What I dont like about the Guix one is that it is common to have version mismatches between dependencies. And what is more frustrating is that the cargo import sometimes just chooses a close one, but incompatible when using recursive. Though that is more of a problem of the import behavior rather than rust packaging itself <Rutherther>Would it maybe make sense to make it easier to patch the cargo toml? Currently afaik manual substitute has to be used to make it less strict when authors chose to put in too strict version <PotentialUser-87>Hello! My new workplace is about to order a laptop which I plan to run guix on. Does anybody know if I would be successful in installing guix on a thinkpad t14 gen 5, or should I ask for another model? <sneek>PotentialUser-87, you have 2 messages! <futurile>PotentialUser-87: you should do a general search for linux support on the T14 gen5, that will probably help you the most. As Guix doesn't have binary drivers that's going to be the thing to look for. <Rutherther>PotentialUser-87: amd or intel? amd would for sure have a problem with amdgpu that is unfree. Additionally, my guess would be wifi chip is also unfree. That's how I have it is on my T14s G4 at least. <PotentialUser-87>It would be intel. Wifi should not be a problem, I have a libre dongle available for those cases. <sham1>What do you mean? Do you mean why it wasn't used in the patches in that thread? Or do you mean if those variables exist in Guix? <jacobk>Hello, does anyone know how to debug a graphical application (tuxmath in my case) on a foreign distro (Trisquel 10 in my case), that segfaults? It was working the other day and I tried rolling back to when I installed it but that didn't fix it, so I suspect the change is in the foreign distro. The package from apt still works fine. I've tried using containers and gdb but the containers have different errors I don't understand and I'm <lispmacs[work]>Does emacs-guix currently have a maintainer? From the code it looks like it was coded by Alex Kost. <futurile>lispmacs[work]: there aren't any 'maintainers' for individual packages - in the same way as Debian. <futurile>lispmacs[work]: there's an emacs-team - you can find it by running etc/teams.scm list-teams - from a source checkout <futurile>lispmacs[work]: what are you trying to do? <lispmacs[work]>well, I just haven't ever gotten any response on emacs-guix bug reports the last few years, and was wondering if there was package maintainer or something for that, or if I needed to take up the fallen mantle, so to speak, and start fixing my own emacs-guix bugs. I started submitting investigative notes to my most recent bug (73462) but all is silence. <lispmacs[work]>in Emacs proper they have package maintainers for different things like eshell, and so on, so I just wondered if there was somebody I should be communicating with about submitting emacs-guix patches and such <futurile>lispmacs[work]: I think you answered your own question - if you're not getting any response in 'years' <futurile>lispmacs[work]: generally the project could do with more help - there is an emacs team - but it's three people so I'm sure they'd welcome any help <futurile>lispmacs[work]: the manual covers the dev process pretty well - but in short there are no maintainers - there are teams that are people saying they're "interested" in working on an area <futurile>lispmacs[work]: sorry - just to clarify there are no "package maintainers" in your meaning <lispmacs[work]>okay, I suppose I can just work up a solution/patch, and then CC the Emacs team <lispmacs[work]>maybe I should e-mail them and ask if anybody is working on emacs-guix already <futurile>lispmacs[work]: I 'contribute' patches, but don't have commit rights <futurile>lispmacs[work]: yep - and/or email guix-devel and ask <sepeth>jacobk: did you find out what was wrong? gdb can give you the backtrace via bt or backtrace command after segfault. The warning about shared lib arch is not compatible with target arch sounds super dodgy. <jacobk>sepeth: I did not yet find out what was wrong. I admit after I asked I stopped looking at the problem for a bit. Thank you for the information about backtrace, I'm looking into that now. <nckx>I've never seen a kaji here. <Rutherther>could it be "kaij"? or are they someone different? <nckx>All these stupid random four-letter nicks >:( <kaij>I may have misspelled it on reddit they found me :) <dariqq>is there someone still interested in desktop environments for i686? mate is failing to build because of test failures in the dependency graph. Annoyingly a failing package has a custom check phase not honouring #:tests? so a simple --without-tests does not work <stochastic>How hard would it be to place the kernel/initramfs files in the same partition as boot ? <Rutherther>I have yet to implement removal of old unused files <Rutherther>the gist of it is: grub config generator saves needed files in the grub.cfg file in a known format. install-bootloader script will read the config file (since it doesn't have access to the config), and copy the files from /gnu/store to /boot/gnu/store. <stochastic>Until now I was using a bash script to do something similar <Rutherther>Assumptions currently are: /boot is a separate partition. targets is /boot, not /boot/efi, and that there will be no crypto partitions opened by grub. I would like to get it better but I don't have much time for it now, so this does for me <Rutherther>I've been thinking of a better solutions, because it doesn't sound very good the bootloader itself does this. But honestly I have none yet. Mainly since apart from kernel files it is only the bootloader who knows what files it needs - the keymap, background etc. <vagrantc>for some architectures, you may need a device-tree file <nckx>dariqq: Assuming it's not a mass rebuild I'll push a fix for that missing tests? guard if you write one. <dariqq>nckx: its the skia package. Would it be enough to wrap it with a (when tests? ... ) ? <nckx>Yes. And according to guix refresh it's not a mass rebuild, which… I did not expect because ‘graphics libraries’ like to rebuild the entire desktop world, but I guess it'll totally be different this time, we swear. <nckx>You might want to check the guix build libreoffice gnome --derivation just in case. <nckx>(Comparing the hashes before & after your change.) <jacobk>Regarding my problem with tuxmath, a line that's part of the trace is `strncpy(tuxmath_locale.setlocale_ret, s1, 64);`, copying 0x0 (NULL I think) to a '\000' 64 (or maybe 63) times. I have to leave now but I'll look at the problem again later and ask another question. <dariqq>nckx: where do you get libreoffice from, or is that just a good canary? The rebuild of gnome/mate meta packages seems to come via cantarell font <nckx>It's civodul's cliché, not mine. <futurile>Anyone got a current checkout of master that they can quickly see if they can start building 'emacs-ivy'? I keep being told that the hash is wrong <futurile>I just updated my checkout of master, and started reviewing something else. Emacs-ivy is one of the dependent packages. I can't get it to build as guix build complains the hash is wrong <futurile>it says that the hash it's getting when it downloads the source is: 1h9gfkkcw9nfw85m0mh08qfmi2y0jkvdk54qx0iy5p04ysmhs6k1 <dariqq>debugging why these tests fail on i686 is more tricky (especially because one is the node package) <futurile>./pre-inst-env guix build --no-substitutes --source emacs-ivy <nckx>futurile: That's not a given. <nckx>It's coincidence but I'm actually working on tracking down & fixing sources that have disappeared or been modified upstream. Screenshot of that workspace to set the mood: https://www.tobias.gr/1727726932.png <nckx>Lots of emacs packages in that list. <nckx>Finding out what exactly changed upstream is most of the work in these cases. <nckx>(Or… you did something silly, who'm I to contradict you.) <nckx>‘Luckily’, this is hidden from most user who do use substitutes. <nckx>Even when building from source. <nckx>I also get the mismatch. <futurile>nckx: well from common experience - at least for me - it's nearly a Problem In Chair Not Computer (PICNIC) <nckx>Today be your lucky day. <futurile>nckx: though, in this case I think it is a problem in Guix as I just downloaded the source and checked teh hash <nckx>docs5eOqw.info changed to doczSQuZD.info in the tarball, whatever that means. <nckx>diffoscope old.tar new.tar <nckx>new.tar is what you get from the (failed) guix build --source --no-substitutes, old.tar is what you get with substitutes. <nckx>Less cool is elpa changing tarballs in-place 😒 <dariqq>nckx: See #73573 (not sure when mumi will catch it). I have wrapped the test phase with '(if tests )' and added a message when things get skipped <futurile>nutcase: did you manage to build any of the dependent packages, how far did you get? <nutcase>or are the packages already built because the issue is now tagged as "patch"? <nutcase>futurile: I had to cancel ungoogled-chromium and libreoffice, since I need my machine for my day job <nutcase>a lot of packages were rebuilt, I didn't check which in particular <dariqq>wow, by linecount my biggest patch to guix so far, though most of it is just whitespace change <nckx>dariqq: Would be the perfect diff in which to hide something nasty! (Don't worry, I both trusted you and checked.) <nutcase>futurile: what makes QA pick up some issues / patches? <futurile>nutcase: I guess you could ask for testers on guix-devel is one option. <futurile>nutcase: you could request a branch be created to test it. I would *guess* (having never done it) that being able to say you've build some % of the packages locally and it looked good would be useful <nutcase>futurile: how could I identify the % ? Locally I did a "guix system reconfigure" with my local git repository containing the patch in my channels. When I do it that way, aren't only those packages rebuilt that are necessary to be rebuilt my specific system? <dariqq>nckx: thank you, not sure if it is worth to try to dig into the test failures though (but it would be nice if half of the de options in the installer would not be broken) <nckx>FOSS user entitlement is out of control! <nckx>It sure would be nice if breaking commits were forcefully rejected by one or more heavily-armed robots. <nckx>I'd welcome the robots as my personal saviour, personally. <alex4164>hi. does anyone here run parabola, or trisquel? <sneek>alex4164, you have 1 message! <sneek>alex4164, lloda says: i tried your guile-cairo patch and it makes make check fail before make-install <futurile>alex4164: that's the bot - it's a message from earlier that, that person left for you <futurile>nckx: looks like emacs-seq might have the same problem <nckx>futurile: I'm not able to fix another package just now. While --no-substitutes should work, can you not do without it for now? <nckx>‘Should work’ as in is valid & supported, obviously it won't work in the current situation. <futurile>nckx: yep I can do without it for now. I'm rebuilding dependents. I'll just mark it in my file and come back later. Seems like there might be lots <nckx>There are :-/ Lots of them emacs-*. <aarcov>Does the CI require a bug to be reviewed before it tries to build it? I have a few open open issues: <futurile>aarcov: it should pick them up automatically. You can see the list of the ones it's processing from patches sent in here: https://qa.guix.gnu.org/ - take the link "List of issues for patches" <aarcov>@futurile, sweet, I even see mine in that list, wasn't sure if I missed something since it's been sitting open for a bit <futurile>aarcov: it won't be able to figure out your second one - it won't know that bug 7339 depends on the other one <aarcov>hoping to start merging my private channel stuff into mainline (and cleanup old issues since I *finally* have some free time) <futurile>aarcov: it can take a while depending on what else is building, and the automation doesn't always pick stuff up <aarcov>@futurile, will it try to re-apply that patch later (after the pre-req patch has been applied), or can I bump the issue once the pre-req has been added (or should I just pull the patches back down and create a new issue that correctly combines them?) <futurile>aarcov: no it won't try and re-apply, it's not that clever. You can try and merge the two bugs (or close one of them). If you send a re-roll v2, that will trigger it to try and redo things. <futurile>aarcov: so if I mess-up I sometimes reroll and see if that causes it to figure it out. <bavier>question about packages that provide udev rules: is the documentation under `udev-service-type` enough, or should package descriptions also mention how to install the provided udev rules? 