[adelie-devel] [RFC] Syncing with Alpine abuild, part 1: pulling changes
Hello, There has been quite some churn in Alpine abuild lately and I'd like to take some time to go through the individual changes and note if they are something we should cherry-pick or not. I expect most of these changes are somewhat breaking and therefore should be considered a post-1.0 project, but if that is not the case I will remark as such. Adélie's abuild is based on Alpine abuild version 3.3.1, released Tuesday 05 March 2019. In all there have been 158 commits to Alpine abuild since that time culminating in the release of version 3.6.0 on Thursday 28 May 2020. There have been no new changes since then, but there are 12 open merge requests. I will take a look at those also in a future email. Please reply if you disagree with any of my assessments or have other comments. On a related note, I think we should consider changing the name of the package to "adelie-abuild" if we continue to release versions that do not correspond to Alpine's versions. Already we have released versions 3.3.1+adelie, 3.4, and 3.4.1 which have no such correspondence. Taking a quick look at the patches we carry for abuild in packages.git, it seems we never applied the "keyhole" patch to our abuild.git. Since I sent that patch to Alpine as well, that will come up again naturally. This email is part 1 of 2 where I will look only at changes to cherry-pick from Alpine. Part 2 will look at sending some of our own changes back to Alpine. All commits in their respective sections are sorted oldest to newest. = Already applied = The first commit is patched in packages.git but needs to be applied to abuild.git; the latter is present in both. 297de93aef abuild-sudo: don't allow --keys-dir 93cc98930d abuild: Use $APK instead of apk = Already addressed = 77746a0c3d abuild-fetch: enable curl certificate verification 369e7069b8 Revert "abuild: replace command -v with which to fix build issues" f83d19ce79 newapkbuild: remove obsolete cd statements 635a699365 newapkbuild: fix empty function regression = Bootstrapping = I think the change in apk-tools it talks about is something we've picked up so we should apply this as well. As such we should probably apply this ASAP. c54d39d8aa abuild: rename makedepends_host virtual package = newapkbuild = Not really useful, but ok. da4aca278f Cosmetic: newapkbuild: comment for check sections This would be good to add. b743186dfe newapkbuild.in: add default check() for meson packages. Already applied in the same commit as the "cd" one. 2122fa7476 newapkbuild: use current directory for cmake We bundle setuptools with the main Python package, so the first commit isn't necessary. However, maybe we should consider dropping python3-dev from the default makedepends like the second commit does. bffe0efc06 newapkbuild: add py3-setuptools to python apkbuild b7fd57f681 newapkbuild: make python packages only depend on setuptools This is interesting. As long as the generated tarballs remain as "stable" as the URLs we've been using, I think this would be good to include. a8f564287e newapkbuild: simplify source URL derived from GitHub URL I'm sure people have Opinions on this. I don't have any so I would probably opt to skip this. e125a76489 newapkbuild: do out-of-source CMake builds by default These seem logical. d0ce42112f newapkbuild: treat packages that start with py[0-9]- as python packages. 7779e913e7 newapkbuild: allow -n option without url = pkgname/pkgver quoting = I don't think anyone agrees with this, but it would make onboarding easier in terms of consistency when writing APKBUILDs. The second commit reverted it. 49c7560c86 newapkbuild: quote pkgname and pkgver 1888007c38 newapkbuild.in: Allign with CODINGSTYLE quoting = Build types = The second commit mentions that we might not be passing CPPFLAGS and LDFLAGS correctly right now for cmake projects. I think these would be worthwhile to implement but it will cause a lot of breakage. 69fc8b8fc1 newapkbuild: use 'plain' buildtype for meson and 'None' buildtype for CMake 5cc73d98c3 newapkbuild: do not pass CFLAGS and CXXFLAGS explicitly = Reproducible packages = This is obviously something we should strive for in the long-term, and these changes are the bare minimum needed to have any hope of making reproducible apks. It will need to be adjusted accordingly for libarchive tar instead of GNU tar, and this may break abuild-gzsplit which is something I've been talking about with Alpine developers recently. ba16a67781 abuild: add SOURCE_DATE_EPOCH support 5b34b696d4 abuild: set SOURCE_DATE_EPOCH to last commit date by default 672032a4be abuild-sign: dont set timestamp in gzip f04a2ee34b abuild: make built package reproducible 1cfbdf688c abuild: fix git_* functions 114c0cf287 abuild: rename global last_commit to ABUILD_LAST_COMMIT 71d9d5233b abuild: get the git commit date only when needed 51d9e3bcb9 Revert "abuild: make built package reproducible" 918b7b1920 abuild:
[adelie-devel] Re: [RFC] Technical proposal for fakeroot removal
On Sun Sep 01 04:47 PM, Max Rees wrote: > As of this writing, there appears to be: > > * 24 packages that use the $pkgusers and $pkggroups directives. > * 3 packages that only use the $pkggroups directive. > * 0 packages that only use the $pkgusers directive. > * 12 packages that use chown(1) or chgrp(1) in the APKBUILD, 8 of which > are not included in any of the above. > > And an unknown amount of packages that perform their own chown or chgrp > during the vendor's installation process (this may later be estimated by > examining all available apks and checking for user, group != root). When I was originally investigating this I hit a blocking problem I described on IRC and forgot to mention here: Linux file extended attributes (xattrs), which abuild and apk already currently support. In particular, Linux file capabilities are implemented as xattrs under the the "security.capability" name: $ getfattr -d -m - /usr/bin/ping # file: usr/bin/ping security.capability=0sAgAgAAA= As it stands now, xattrs are handled opaquely by fakeroot. Our abuild creates the data.tar.gz file using the PAX format via libarchive's bsdtar (Alpine uses GNU tar and only recently switched to the PAX format in order to facilitate reproducible builds, which is something I'm also interested in). libarchive then stores xattrs as PAX extended attributes under the names "LIBARCHIVE.xattr" and "SCHILY.xattr" using two different encoding schemes for the xattr name and value. SCHILY.xattr is also supported by Jörg Schilling's "star" (hence SCHILY) and GNU tar, both with yet more different encoding schemes for the xattr name. However, for the vastly more common case of pure ASCII xattr names these formats are all interchangeable; and all implementations of SCHILY.xattr insert the xattr value as raw bytes (if the xattr value contains a newline this could be a conflict with the PAX extended attribute format...) The problem: libarchive's mtree does not currently support xattrs in any way. Indeed, I don't think FreeBSD nor NetBSD's mtree utilities do either. The only prior art I could find was "go-mtree" by Vincent Batts, which adds parsing for mtree keywords of the form: xattr.= This week I began implementing support for this format in libarchive's mtree plugins. I am still waiting to hear back on what its maintainers think of this proposal before I continue working on it. If I can move forward with this implementation, then I can also move forward (post-1.0) on replacing fakeroot completely with mtree declarations. In addition to getting rid of the ugly hack fakeroot imposes, this has some other nice properties: * it is always clear from the APKBUILD where certain files deviate from the standard root/root ownership, or when file capabilities are present. * it makes it easier to audit changes to these file attributes during package upgrades. Side notes: * It gets even more complicated when user namespaces are introduced. When a file capability is written by a user with sufficient permission inside a user namespace, the kernel actually translates it so that the capability also records information about the namespace (i.e. what UID maps to UID zero if I recall correctly): $ getfattr -d -m - ~/adelie-master-x86_64.chroot/usr/bin/ping # file: adelie-master-x86_64.chroot/usr/bin/ping security.capability=0sAwAgAACghgEA This is of course to prevent trivial privilege escalation: $ ~/adelie-master-x86_64.chroot/usr/bin/ping example.com ping: socket: Operation not permitted However, currently fakeroot intercepts the xattr creation calls before they ever reach the kernel, so in the data.tar.gz file the capabilities are stored with no container restrictions. This also will not be a problem when using mtrees; it's just an interesting facet I wanted to share from my research. * I'm also interested in trying to eliminate most of the setuid/gid binaries in Adélie using file capabilities. As far as I know only iputils currently uses them. * At some point I will probably adjust my much-revised checkapk script to switch to the mtree format in its output to facilitate this process. Max ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] [RFC] Technical proposal for fakeroot removal
Hello, As work towards the minimal viable product of APK Foundry nears completion, I have been thinking of large scale trybuilds that can be done in order to fully test its functionality. I think one such trybuild that would also serve a functional purpose would be to begin work on removing fakeroot(1) from the packaging process. Most of the utility of using fakeroot in abuild currently is in order to assign arbitrary user or group ownership to files before they are added to the final .apk file. It does so by using an LD_PRELOAD hack to shadow the libc's relevant functions, and uses a daemon to keep track of the fake ownership of files. As of this writing, there appears to be: * 24 packages that use the $pkgusers and $pkggroups directives. * 3 packages that only use the $pkggroups directive. * 0 packages that only use the $pkgusers directive. * 12 packages that use chown(1) or chgrp(1) in the APKBUILD, 8 of which are not included in any of the above. And an unknown amount of packages that perform their own chown or chgrp during the vendor's installation process (this may later be estimated by examining all available apks and checking for user, group != root). In regards to a replacement, I think in absence of fakeroot we can instead declaratively specify which files need special ownership requirements through the use of libarchive's mtree(5) functionality. The mtree file format is a BSD invention that describes the contents of a tar file and allows for arbitrary specification of user and group ownership as well as permissions, file type, etc. By generating a de facto mtree for the package contents with --uname root --gname root and allowing the packager to override this mtree where necessary, I think the need for fakeroot can be mostly eliminated. This of course would have the side effect of tying abuild to the libarchive implementation of bsdtar at runtime, unless we were to ship our own utilities (built from libarchive I presume) to handle the mtrees. abuild would have an opaque shell function or similar that allows specifying the file type, user ownership, group ownership, and permissions for a file in the package. This function would then write to a file in the control directory that contains the generated mtree override(s), and merges that with the default root:root mtree before using the merged mtree to build the data.tar.gz file. For example, system/abuild itself needs to install /var/cache/distfiles with abuild group ownership. The APKBUILD would have something like the following instead of a chgrp: > amtree -g abuild "$pkgdir"/var/cache/distfiles The amtree function would translate this into an mtree entry and add it to the $controldir/.mtree override file: > var/cache/distfiles gname=abuild uname=root mode=775 type=dir After merging the overrides with the default root:root mtree, libarchive then supports reading an mtree file as a description from which to build a tar file, like so: > tar -cf data.tar.gz --uname=root --gname=root @$controldir/.mtree I specifically think that the mtrees would have to be built on the fly (not statically / version controlled) because some packages will of course have filenames that differ between architectures. Thus if you need an mtree for each (architecture + subpackage) combination, things can quickly balloon. To make this a gradual process we can also add some option to $options if necessary. Thoughts? Max ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] Re: GRUB configuration update hook
On Jul 10 02:33 AM, Max Rees wrote: > Additionally, some mechanism must be employed so that users who: > > 1. Currently have a manual grub config > 2. Do not have a .manual_config file > > do not have their configuration file overwritten when this change is > made. By what mechanism this is made (public announcement, some sort of > technical measure) I'm not sure. mcrees on leliel ~ % head -n6 /boot/grub/grub.cfg # # DO NOT EDIT THIS FILE # # It is automatically generated by grub-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub # This presents two options: 1. Determine that the user has a manual grub.cfg solely by grepping for (part of) this header. No separate .manual_config flag file is needed. 2. Same as #1, but instead perform the grep at .post-upgrade time and make the .manual_config file in that case. It's late so I can't think very clearly about the pros/cons of these two options, so I'll post it here and hopefully someone else can figure it out later. Max ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] Re: iproute2 and GNU Bison
On Mar 07 04:46 PM, A. Wilcox wrote: > Hi there, > > I have just done an experimental build of system/ without GNU Bison > available. The only package that uses Bison extensions to Yacc is > iproute2. There are three ways forward I can determine: > > 1) Move iproute2 to user/. > > We still have `ifconfig` and `route` from net-tools in system/ for base > installs. This allows us to continue to move GNU out of system/. I think this is the best course of action for now, and it was the first thought that came to my mind - if we don't absolutely need iproute2 in the base install / bootstrapping system, it shouldn't be in @system anyway. > 2) Port iproute2 to real Yacc. > > I am concerned that the upstream of iproute2 may not want this, though > there has never been any public discussion that I've found on this > topic. If they do not, then we would have to carry the patch for it. > > I will note that iproute2 only uses Yacc/Bison in one file, so it would > not be a particularly large patch to carry, but it would still be a > non-zero effort for every version bump of iproute2. This option could be pursued at a later date if it is deemed necessary to keep iproute2 in @system. Max ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] Re: abuildd design considerations
On Sep 06 01:07 AM, Max Rees wrote: > What if all applicable build servers are unavailable (busy or offline) > when we want to delegate a new task? For the webhook, this should be > easy to get around since it's built to be asynchronous, so we can just > keep polling the list of servers until something's available. In case of > a webhook crash we have the SQL database as a backup. For the enqueue > CLI we would probably just fail by default and have an option to keep > polling for X time or indefinitely. One thing I'd like to add here: in order to support restarts of the webhook without losing all of that state, we could initially set the state of the tasks in the SQL database to be something like "new" which would then be changed to "building" once it has been properly delegated. Max ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] Re: 1.0-BETA1 release criteria
On Sep 05 09:23 PM, A. Wilcox wrote: > * Missing list > > This goes in to the version freeze; are we having a package freeze too? > If so, our missing list is frozen and we will not ship with any of the > packages left on it. If not, this can probably be shifted to b2. We have not previously discussed that the version freeze would coincide with a new packages freeze. As such, a new packages freeze should be no earlier than beta2. Speaking of which, there are still a few packages from the missing list for which I sent patches to adelie-pkg@ that may have gotten lost in the churn that I can re-send as MRs if you like. Max ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] Re: abuildd design considerations
On Wed, Sep 5, 2018 at 5:05 PM M. J. Everitt wrote: > Are you using a custom Message Broker system, or something that would > integrate with other tools, eg RabbitMQ, etc? > Might be good for 'portability' and interaction with other tooling perhaps. The plan is to use MQTT as the communication between the webhook/enqueue server and the build servers. The build servers will subscribe to a MQTT topic for their architecture, and the enqueue server will post new jobs/tasks to those topics as necessary (this is actually the next step in development so I have not worked out the details yet). When the build server finishes a build - success or failure, it will post as such to a "completion" topic for its architecture. I think another thing that needs fleshing out in this area is how multiple build servers of the same architecture will be handled - perhaps a build server can post a message so that it can "claim" a task before the other same-architecture build servers get to it. Max ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] abuildd design considerations
Hello all,
During some brief free time today I was thinking about how to go about
implementing some of the upcoming features that I plan to add to abuildd in
the next few weeks. Specifically, I am concerned about the handling of
dependencies.
My current proposal is that each new push to a branch ("push event") or update
to a merge request ("MR event") will create a new "job". The job can be
composed of one or more "tasks" which would be building a package on a
specific architecture. As an example, if a push event is received that changed
two APKBUILDs, a job would be added that would include tasks to build those
two packages on all applicable architectures.
I do not expect there to be any problems with handling dependencies between
tasks in a single job (intra-job dependencies). However, dependencies between
multiple jobs (inter-job dependencies) is more complex, at least the way I see
it now.
For push events, it could be easy to handle inter-job dependencies as long as
the artifacts for each job are collected and kept for that branch. It is MR
events that I am more concerned about.
I believe that as it stands right now (I cannot check it at the moment), my
abuildd-enqueue implementation does not distinguish between new commits added
to an existing MR, a force push over an existing MR, or a completely new MR.
Thus all added/changed (NB: *not* deleted) packages for a MR would be rebuilt
on each change to the MR.
I think it is possible to implement it such that we keep state for each MR and
thus only perform builds as necessary, but I'd like to hear all of your
thoughts on this.
If there are other questions or considerations you'd like to make, please let
me know. Another feature I thought of during the same period today is that it
should be possible to prioritize jobs based on type (push, MR) and branch, if
applicable. Things such as being able to skip a build that would be caused by a
particular commit (I have seen things like having "[ci-skip]" in the commit
title before) are more difficult in the present implementation, but I'm sure it
can be done at some point.
Max
___
Adélie Development mailing list -- adelie-devel@lists.adelielinux.org
To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] Re: Nice-to-haves for 1.0
On May 17 07:47 PM, A. Wilcox wrote: > Hi all, > > I'd like to have a discussion on whether or not it would be worth it to > invest actual time and resources into the following projects before we > release 1.0. Perhaps we could even delay 1.0's release slightly, if > they are deemed critical enough. The relative importance of these projects depend on what the goals are for the distribution - specifically what level of technical literacy we expect our users to have. At early adoption levels it will be relatively high of course, but at the 1.0 release I think Adélie should be accessible to all. > PackageKit Plugin for APK > = > > This would allow us to have graphical UIs for installing, removing, and > updating packages with APK for "free". As such, this is probably one of the more important projects that needs to get going. > One thing that bothers me is that APK doesn't yet have tagging or > category support, so every package would be in a single, large, > unwieldy list. It'd be very nice if we could add tagging first. > > Of course, writing the plugin and then adding tagging to APK later is > another option. > > Note that both KDE (Muon) and Gnome (gnome-packagekit) have GUI tools > built on top of PackageKit, so we would not need to write any GUIs. Tagging can probably be added after-the-fact if it is determined that adding this functionality to APK will take too long. As long as the search isn't too bad things should be fine for the time being. > Parcel > == > > This is the Web and CLI UI for determining package availability, > version, and architectures. Similar to Alpine's pkgdb or Gentoo's > Package Home for the Web UI, and similar to eix on the CLI. > > I still think this is a very worthy endeavour, but time is a precious > commodity and I don't know if we have the time to build it before 1.0 > unless 1.0 is delayed. This can probably be pushed back for now. I kind of see it as a trade-off with the PackageKit plugin for APK since they have similar features, but the plugin will have some functionality that Parcel necessarily cannot have - such as being able to install packages to the user's system, unless something like openSUSE's "one click install" feature[1] is implemented. That would essentially be a bridge between Parcel and the desktop package manager, so the plugin should still be prioritized over Parcel. > Register > > > This is the popcon-like system that will let us explore and inspect > packages that are popular (and not popular) with the user community at > large. Cadey on IRC has been writing a prototype. > > This, too, seems like a very important feature for 1.0. Can't say I disagree. I'm sure it would be very nice to know what to prioritize, which is also the subject of this thread :) > Steam with gcompat > == > > I still have been unable to test the Steam binary on gcompat because it > requires 32-bit x86 and I don't have a 32-bit x86 installation with > gcompat anywhere. (The only 32-bit x86 install I have of Adélie, > outside of the builders, is a 500 MHz Pentium III laptop. Hardly an > amazing gaming system, that.) > > I don't know if that is important enough to work on for 1.0, since you > can just use an Ubuntu chroot to play Steam games (this also prevents > the icky binary blobs from touching your rootfs). However, I will defer > to the community for that decision. chroot is probably fine for now to keep the distro's focus narrow. I already use a chroot for other software such as widevine (eww) and LibreOffice, for example. > Horizon > === > > There has been renewed interest in Horizon since the linux-wiiu team has > joined us. We could likely spin partitioning out to KDE Partition > Manager (https://www.kde.org/applications/system/kdepartitionmanager). > > Since the linux-wiiu would like Horizon to use PackageKit (so that it > can handle any future pivots, if desired), it'd be a great idea to have > an APK PackageKit backend before we go back to Horizon. This is a pretty important project, if not one of the most important projects in my opinion. The manual installation process works, but it isn't without bugs at times and it's certainly not intuitive to the casual user - reminiscent of the Arch installation process, but much more streamlined at least. A simple yet configurable installation process is key to onboarding new users and as such I think this project should be given priority, as well as maintenance of the manual installation documentation. > Others? > === > > If anyone has any other 1.0 goals that aren't covered in the current > roadmap (https://wiki.adelielinux.org/wiki/Project:Roadmap), let's > discuss them here. It would be nice to have LibreOffice by 1.0 :) Of course, I can use my chroot as long as need be but it's certainly very useful software for both "Education" and "Office". [1]: https://en.opensuse.org/openSUSE:One_Click_Install
[adelie-devel] Re: Adding cmd:which (or similar) to build-tools
On Feb 17 08:49 PM, A. Wilcox wrote: > I am, however, considering adding cmd:which as a dependency for > build-tools. I'd like to set debianutils-which as the primary provider > since their utility is light (just a wrapper for POSIX command(1)) > compared to the full-blown which (~ 100 KB). > > The only alternative that I can think of is maintaining i3lock and > libvpx in user or system and adding cmd:which to their makedepends. I > am open to further alternatives. Adding cmd:which to build-tools doesn't seem like a bad idea to me, but I just wanted to note here that if i3lock needs to be maintained in packages.git I can do so since I use it daily. Max ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] Re: main/ -> system/ + user/ vs aports.git fork [1]
On Feb 11 05:54 PM, A. Wilcox wrote: > We even still have the archive of Gentoo-based ebuilds, in case we need > them: https://code.foxkit.us/adelie/packages/tree/ebuild In my opinion these should be removed from packages.git and put in a separate archive as well, unless it's something that you refer to often. > As someone who *uses* three of those plugins on my own system, I would > be very disappointed to have to give them up. But I don't want to have > to maintain ffmpeg, and I don't think I could track their releases. > Does anyone else want to? If nobody else steps up I can do this possibly. > I'm not seeing visual artifacts anywhere, on my desktop 21" wide-screen > flat panel monitor, my laptop 13" panel, or my 17" CRT. Is it only in > some software or does it affect all X clients? Maybe start a new thread > about that. It was mostly firefox-esr I believe. Once alpha5 is released I will test again and report the results. Max ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] Re: main/ -> system/ + user/ vs aports.git fork [1]
On Feb 11 02:00 PM, A. Wilcox wrote: > Currently we have a "fork" of aports.git. It's very difficult to rebase > what we have, so it definitely needs to "restart" imo. We can move > aports.git to aports-historic.git and then re-clone from Alpine to make > it cleaner, but I think the better thing is to pull all the packages > that we want to keep different from Alpine and put them in system/ in > packages.git, leaving our aports.git fork strictly for changes we wish > to upstream. This makes sense to me. I was concerned about what would happen to the old repo, so archiving it seems like a good idea. > audacious (and audacious-plugins): > > We are shipping the Qt variant. Alpine are shipping the Gtk variant. > Since Alpine doesn't have Qt5 in main/ we unfortunately cannot upstream > this change. We could rename it audacious-qt and ship it in user/, > where even Alpine users could enjoy it, but it would need a maintainer. audacious-qt is probably the better choice. Gentoo also calls it audacious-qt, so there is some precedent. > ffmpeg: > > We enable a LOT more plugins: libcdio, ladspa, lzma, libspeex, freetype, > wavpack, libwebp, and pulseaudio output support. Almost none of those > are in Alpine main/ so it is impossible to add them to ffmpeg > dependencies upstream. I really don't want to maintain ffmpeg myself > since it is a frequent security flyer; if someone else wants to maintain > it in system/ then that is fine. As someone who *uses* three of those > plugins on my own system, I think you forgot to finish this part. > freetype: > > Our freetype-profile.sh differs (we enable infinality by default). We > have no other changes. Alpine upstream temporarily did re-enable > infinality by default, but they did not like it (I believe there was > some bug in their XFCE 4 maybe?) so they reverted it. There is something weird going on with the LCD filtering such that only "lcdnone" is usable on Adélie last time I tried, and even then there are still some visual artifacts. I'm not sure if this is related to infinality or not but it's worth investigating. The rest of your proposals make sense to me. Max ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
